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

[bbigras]

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]

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:

reqwest-middleware/reqwest-retry/src/retryable_strategy.rs

Line 113 in 2927624

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