Expose Retry-After header on all ACME responses#264
Conversation
nckslvrmn
force-pushed
the
expose-retry-after-header-on-errors-and-resources
branch
from
1d9ad36 to
7674aea
Compare
unixcharles
left a comment
unixcharles
left a comment
There was a problem hiding this comment.
Looks good. Let me know what you think on the Time vs Integer.
|
@unixcharles I reworked the implementation a bit so it always assumes time because that's how certbot does it. |
|
What do you think of leaving |
yeah I didn't think about how this changes the previous expectation of that fields type. doing it that way will definitely solve that problem. and even if we get only a time back, we can still generate both. Ill get that updated! |
* ARI related improvements * Fix ARI tests: extract replaces from order response, re-record cassettes with Pebble - Add :replaces to extract_attributes in attributes_from_order_response (bug: replaces was sent in requests but never parsed from responses) - Re-record VCR cassettes against Pebble with real ARI data: - renewal_info_supported: real suggested window + retry-after - new_order_with_replaces: order response includes replaces field - new_order_already_replaced: real 409 alreadyReplaced error - Update certificate_chain.pem fixture with cert from Pebble - Remove pending() from replaces tests in order_spec and renewal_info_spec --------- Co-authored-by: Ben Burkert <ben@benburkert.com> Co-authored-by: Nick Silverman <nckslvrmn@gmail.com>
nckslvrmn
force-pushed
the
expose-retry-after-header-on-errors-and-resources
branch
from
7a37c7d to
f17b14e
Compare
|
@unixcharles I found a legitimate bug with the retry after where when we get a date back, the field was being set to 0. so now it always parses to an int and computes from date if we get a date, and then the date field is the inverse of that. should be good to go! |
|
Can we get this last one merged in and a release cut? I would love to make use of the retry after header on a few of the poller jobs I am working on. Thanks in advance! |
|
Released in |
thank you so much! |
2 participants
Per RFC 8555 §6.6 and RFC 7231 §7.1.3, CAs can include a
Retry-Afterheader on any response — rate limits, order polling, challenge polling, 503s, etc. Previously this was only surfaced onRateLimitederrors.Changes
retry_afteris now consistently an Integer (seconds) across all classesRateLimited: integer seconds (unchanged, defaults to10); HTTP-date inputs are now correctly converted to seconds-until rather than returning0nilif no header was presentsleep e.retry_afternow works safely on anyAcme::Client::ErrorsubclassNew
retry_after_timefield everywhereTime(ornil), parsed viaAcme::Client::Util.parse_retry_after"120") and HTTP-date formats per RFC 7231 §7.1.3RangeErrorguarded for pathologically large integer valuesExposed on more places
Acme::Client::Errorbase class and all subclassesOrder,Authorization, andChallengeresourcesRenewalInfoalready hadretry_after; now also hasretry_after_timeVCR upgraded
~> 6.0—CGI.parsewas removed in Ruby 4.0; cassette format and config API are unchanged.