Incorrect handling of HTTP redirects about urllib3 HOT 8 CLOSED

Mmm good point, might have to move redirect logic into PoolManager. Good find.

I'll try to have a closer look at this when I have time. If you can think of a nice solution, a patch branch is welcome.

from urllib3.

Double bonus points for a failing unit test.

from urllib3.

Btw, I'm wondering if we could refactor redirect logic so that Requests could use it instead of doing its own... @kennethreitz what do you think?

from urllib3.

Requests will always do its own redirection handling. Urllib3 dependence is intended to be as loosely coupled as possible.

from urllib3.

Ok, thanks for info.

from urllib3.

...

from urllib3.

I considered factoring it out but it's currently only ~2 lines of code which didn't seem worth it.

urllib3's goal is to keep the code as simple and orthogonal as possible, whereas Requests tries to cater more towards convenience and a larger featureset.

I want to be conservative in how much logic we pull down from Requests into urllib3 by design, but if it comes to the point where through necessity and correctness urllib3 implements more of what Requests does, we'll re-evaluate then.

from urllib3.

I have a test demonstrating the problem, I'm going to meditate on the correct solution some more this week and hopefully write down the answer shortly after.

If anyone else wants to take a crack at this before then, let me know.

from urllib3.