psf
Add response.future_requests_uri, deprecate response.is_permanent_redirect
response.is_permanent_redirect is unreliable/useless/dangerous for chains of redirects, just give the user the correct URI instead.
example use-case: foo redirects temporarily to bar, which in turn redirects permanently to baz. future requests should still be made to foo, but using is_permanent_redirect would lead to them being made to baz instead.
That method was not introduced for users to use and was part of internal machinery that was ripped out
https://requests.readthedocs.io/en/master/api/#requests.Response.is_permanent_redirect ?
I think an alternative check for the first history item being a permanent redirect would be a more accurate way to calculate this? The actual permanent redirect url would be gotten from the last permanent redirect among the contiguous group of initial permanent redirects. Maybe?
@SoniEx2 I believe autoclass will auto-document a public method. That doesn't mean it's encouraged for you to use
Could we get it removed from the docs? It's hard to expect developers to consider a documented non-leading-_ attribute private... Or implement it more sensibly (based on my minute or two of thought, maybe I'm missing something).
it does add value fwiw - if you're doing things yourself.
but don't rely on it as representative of the whole response chain.
Instead of checking is_permanent_redirect blindly, you should: Follow the redirect chain carefully. Only update your stored endpoint if the original request itself (foo → …) was a permanent redirect. Otherwise, keep requesting the original URL (foo) next time. Just don’t trust response.is_permanent_redirect if multiple redirects are involved—store the final URI only if the very first hop was permanent.
