Provide Response headers access in on_error method #503

New issue

Closed

opened 2018-11-19 05:23:07 -08:00 by domeniconappo · 2 comments

domeniconappo commented

2018-11-19 05:23:07 -08:00

(Migrated from github.com)

Hi,

Twitter streaming api is very sensitive on number of connections attempts in a window time or number of active connections for same api keys (the twitter app).

In such a case, http error 420 is raised and, according to documentation, a new connection attempt should happen after the Retry-After header that is being set in the Response.

Another case is http error 429 and x-rate-limit-reset response header.

I think this logic should be implemented either directly in Twython or, at least, the Twython lib should give access to response.headers in the on_error method, so that the developer can instruct the client code to wait/sleep for the right amount of time before to retry. Currently, the on_error method takes only error status code and the binary response.content, giving no possibility to inspect those headers.

Hi, Twitter streaming api is very sensitive on number of connections attempts in a window time or number of active connections for same api keys (the twitter app). In such a case, http error 420 is raised and, according to documentation, a new connection attempt should happen after the Retry-After header that is being set in the Response. Another case is http error 429 and x-rate-limit-reset response header. I think this logic should be implemented either directly in Twython or, at least, the Twython lib should give access to response.headers in the `on_error` method, so that the developer can instruct the client code to wait/sleep for the right amount of time before to retry. Currently, the on_error method takes only error status code and the binary response.content, giving no possibility to inspect those headers.

ryanmcgrath commented

2020-04-02 23:50:20 -07:00

(Migrated from github.com)

Merged... years later, but merged.

👍 1 🎉 1 😆 1

domeniconappo commented

2020-04-03 00:06:47 -07:00

(Migrated from github.com)

Thank you!