Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When to poll again if server does not send Retry-After? #69

Closed
mholt opened this issue May 3, 2024 · 2 comments
Closed

When to poll again if server does not send Retry-After? #69

mholt opened this issue May 3, 2024 · 2 comments

Comments

@mholt
Copy link

mholt commented May 3, 2024

Section 4.2 says:

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

@mholt
Copy link
Author

mholt commented May 3, 2024

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.

@aarongable
Copy link
Owner

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.

@aarongable aarongable closed this as not planned Won't fix, can't repro, duplicate, stale Jul 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants