-
-
Notifications
You must be signed in to change notification settings - Fork 19
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 bad nonce errors with a new nonce #65
Conversation
Just realised that I don't need to do the clone of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking great, thanks! A whole bunch of minor suggestions follow, please squash everything into one commit which I think I could release shortly.
This is great, thanks! |
Sorry, I didn't realise you were actively reviewing and force pushed a change to use the |
No problem! |
src/lib.rs
Outdated
nonce = response | ||
.parts | ||
.headers | ||
.get("Replay-Nonce") | ||
.and_then(|v| v.to_str().map(|s| s.to_string()).ok()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is nonce_from_response()
? Can we use that here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it is. Done!
Retry `urn:ietf:params:acme:error:badNonce` errors as they are defined as retryable[^1]. Requests failing with a bad nonce error will be retried three time retried three times before the failure is returned to the caller. This implenments the `BytesBody` trait for `bytes::Bytes` as we need to consume the response body to be able check if the failure was due to a bad nonce which required parsing the body. The body is only consumed if the response status is bad request, in all other cases the body is still lazily consumable. [^1]: https://datatracker.ietf.org/doc/html/rfc8555/#section-6.5
Thanks! |
I'm putting this up as a possible solution for handling bad nonce errors. The new
BytesBody
implementation feels a bit weird but I couldn't think of a better way that wouldn't have wide reaching interface changes. I think it makes sense to do the retry withinClient
so that everything benefits from it. The main thing this is missing is some backoff, though that may not even be necessary because we're not retrying due to a network or server side error.Fixes: #62