Open krukas opened 6 years ago
Could you recreate a testcase using httpbin so we can verify this? :)
Maybe ignore large values or at least if Retry-After is bigger then timeout
timeout
is not a wall-clock timeout. timeout
applies to time it takes to connect to the server and time it takes to read the contents.
The logic you're asking for could instead be implemented in a subclass of Retry
, if I remember correctly. It's not inherently correct when you consider what timeout
does for the library.
I agree with @sigmavirus24. I would consider a pull request that adds an additional kwarg (something like max_retry_wait_length
) that raises an exception (with sufficient information to allow retrying the request after the server-given interval) when the response wants to wait longer than a specified interval. Of course, you can also configure using a Retry object that disables obeying Retry-After
headers.
Maybe a weird case but if a website gives back an Retry-After that is higher then given timeout it will accept that.
In my case some website gives back a retry of 3600 and so my checkup tasks was waiting for 1 hour to try it one more time.
Maybe ignore large values or at least if Retry-After is bigger then timeout then use timeout or ignore Retry-After