Rate limited retry after #127
Conversation
| def retry_after | ||
| @env.response_headers.fetch('Retry-After', DEFAULT_RETRY_AFTER).to_i | ||
| end | ||
| end |
There was a problem hiding this comment.
CI is being picky about the newline
That's true, but I wanted to point out that if you're targetting Let's Encrypt and the Boulder implementation of the ACME spec we don't presently send this Retry-After header. |
|
@cpu oh, derp. Thanks for pointing that out. Was hoping to be rescue and set my job to be retried after the value provided by that header. |
|
@jeromegn I'm hopeful we can add it one day. I suspect it will be something we would evaluate as part of the "v2" implementation for Jan 2018. Apologies for being the bearer of bad news! |
|
I don't think it hurt adding it already. Any opposition? |
|
@unixcharles I would love to use this – any interest on merging & cutting a new release? |
|
@parkr The |
|
@cpu its the reason why it was never merged.
I never merged because its not implemented in boulder but if you have a different server implementation that supports it, I don't have any strong opposition. |
|
Do we know if this has been implemented by boulder when using ACME v2? |
Boulder doesn't implement |
I just hit a rate limited error when creating a new certificate (due to a bug, that created a loop of trying to create a certificate)
I thought I'd add this
retry_afterproperty toAcme::Client::Error::RateLimitedinstances (when available.)According to the spec, the server may return a
Retry-Afterheader containing a value in seconds after which one may retry the same operation.Let me know if you'd like this done another way.