Retry-After on NewOrder

[alexzorin]

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!

[jsha]

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.

[daramousk]

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 Retry-After header on the challenge response is marked as a must.

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.

[rolandshoemaker]

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.

[aarongable]

The NewOrder endpoint now has a Retry-After header: #6256