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

reqwest-retry: does it support the Retry-After header? #146

Open
bbigras opened this issue Apr 23, 2024 · 2 comments
Open

reqwest-retry: does it support the Retry-After header? #146

bbigras opened this issue Apr 23, 2024 · 2 comments

Comments

@bbigras
Copy link

bbigras commented Apr 23, 2024

Does it support Retry-After?

The Retry-After response HTTP header indicates how long the user agent should wait before making a follow-up request. There are three main cases this header is used:

When sent with a [503](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/503) (Service Unavailable) response, this indicates how long the service is expected to be unavailable.
When sent with a [429](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429) (Too Many Requests) response, this indicates how long to wait before making a new request.
When sent with a redirect response, such as [301](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301) (Moved Permanently), this indicates the minimum time that the user agent is asked to wait before issuing the redirected request.
@cbeck88
Copy link
Contributor

cbeck88 commented Jun 1, 2024

The crate is very customizable, but this particular thing I don't think is possible right now.

The idea right now is that the RetryStrategy looks at what happened and decides whether to retry, and the RetryPolicy decides how to long wait for, and it doesn't get to see the response itself when it makes that judgment, so I don't think you could make a custom RetryPolicy that does this right now.

The place where you would want to read the header might be like here:

pub fn default_on_request_success(success: &reqwest::Response) -> Option<Retryable> {

and you can see that the header is not inspected. But even if it is, with this trait you can only return whether to retry or not, and there's nowhere to stick the server-suggested deadline.

If you wanted to add support, you could try adding a new enum variant to Retryable that is like, transient with server-suggested deadline, and then making the middleware object use that info. That would be a breaking change though. It’s probably simpler to make a new middleware tbh

@joebowbeer
Copy link

See https://github.com/melotic/reqwest-retry-after

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants