You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The server SHOULD include a Retry-After header indicating the polling interval that the ACME server recommends. Conforming clients SHOULD query the renewalInfo URL again after the Retry-After period has passed, as the server may provide a different suggestedWindow.
Because of SHOULD instead of MUST, what should clients do for poll timing if the Retry-After header is omitted?
The only potentially relevant advice I can find is at the end of the section:
If the client receives no response or a malformed response (e.g. an end timestamp which is equal to or precedes the start timestamp), it SHOULD make its own determination of when to renew the certificate, and MAY retry the renewalInfo request with appropriate exponential backoff behavior.
But this seems to be related more to error handling and not a successful response without a Retry-After header. If we were to do exponential backoff as the norm (i.e. with successful responses), we'd likely end up hammering the endpoint at first and then potentially missing the window later!
Should we poll every... hour? Day? 2 hours? 10 minutes? I guess I'm looking for what to do in practice here. Thanks
The text was updated successfully, but these errors were encountered:
Thinking on this more, I wonder if a default poll interval of some ratio until the start of the suggestedWindow would make sense, since in general, we have no idea what timescales we'll be operating on.
If the system wakes every minute, you don't want to poll every time if the remaining certificate lifetime is on the order of weeks or months.
If the certificate lifetime is on the order of hours, you probably want to poll more often.
I don't think this level of detail is worth specifying at the protocol level. Clients have been implementing polling, and servers have been implementing rate-limiting, since time immemorial. There are many good ways to do it, and many bad ways to do it, and I don't think it is within the purview of this small document to try to solve them.
Section 4.2 says:
Because of SHOULD instead of MUST, what should clients do for poll timing if the Retry-After header is omitted?
The only potentially relevant advice I can find is at the end of the section:
But this seems to be related more to error handling and not a successful response without a Retry-After header. If we were to do exponential backoff as the norm (i.e. with successful responses), we'd likely end up hammering the endpoint at first and then potentially missing the window later!
Should we poll every... hour? Day? 2 hours? 10 minutes? I guess I'm looking for what to do in practice here. Thanks
The text was updated successfully, but these errors were encountered: