Support Retry-After in ExponentialBackoffPlugin about guzzle

[mtdowling]

Passing the response to the method sounds like a good idea. I won't be able to get to this for a few days, so a PR would be awesome :)

On May 25, 2012, at 2:50 PM, David [email protected] wrote:

I am trying to add support for HTTP 429 responses to a web service client I am developing. Specifically, I was attempting to specify my own callable $failureCodes function and checking for the header presence in the response.

However, the problem I ran into is that I have no way to handle this with the current implementation of the ExponentialBackoffPlugin. With the current design there is no way for the "should we retry" callback to "tell" the "calculateWait" callback how long to delay. The calculateWait callback can't determine that for itself either since it doesn't have access to the Response object.

The two options I see:

• The ExponentialBackoffPlugin could natively support 429 and handle Retry-After headers (note: Retry-After is not exclusive to 429 responses)
• Pass the Response object (if any) to the calculate wait method so that I could check the Retry-After header in my client code

I don't have a problem implementing either, but the former seems like it may be a more robust approach (less client code, and potentially useful to many) albeit greater in scope. Please let me know your thoughts.

---

Reply to this email directly or view it on GitHub:
#63

[mtdowling]

The request object is now passed to the calculateWait() function of the exponential backoff plugin. You'll need to get the response object from the request in your callback function to do any custom checks. Make sure that a response is associated with the request though. Some cURL related errors might trigger the exponential backoff plugin and a response will not be associated with the request.

[hobodave]

Thanks @mtdowling ! I was too busy with the holiday weekend to do a PR; I would have this week, but you beat me to it.