-
-
Notifications
You must be signed in to change notification settings - Fork 601
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
Retry-After on NewOrder #4104
Comments
Good idea. I think it may be time to bump up the priority on setting Retry-After headers in various places, and NewOrder seems like a good place to start. |
Hello Jacob and Alex, Sorry to hijack this, but I did not want to create a new ticket for just a question. On https://tools.ietf.org/html/rfc8555#section-8.2 the Q: Is there a plan on implementing this? Is there already a PR we can review? I am asking this because I need this and I was thinking if I should write it and contribute back. But if you already have something working I could contribute there. Thanks for your time. |
The retry-after header is only required on challenge validation if the server supports challenge retries, which boulder does not. Note this ticket is about retry-after on order generation which is related to rate limits. |
The NewOrder endpoint now has a Retry-After header: #6256 |
With #2800 and #4074 closed, is there anything more needed to provide rate limit info in rateLimited responses - as Retry-After and maybe also problem details?
As a result of #2800, users are somewhat losing the ability to guesstimate the window, since the 'renewal bit' doesn't really exist in CT logs, making the query a hog.
Would be super handy for both humans and ACME clients!
The text was updated successfully, but these errors were encountered: