Closed stcioc closed 6 years ago
This isn't how redirects work. The RFCs (3986, 7230, 7231, 7232, 7233, 7234, 7235) do not require or prescribe retaining the fragment. If you want us to retain the fragment you'll need to handle redirects yourself. The server is telling us what to redirect to and we're supposed to follow that.
Thanks for opening this issue to clarify.
Actually this was formalized in the rewrite of HTTP/1.1 (see also https://stackoverflow.com/questions/2286402/url-fragment-and-302-redirects)
This is a fantastic way to leak some data to an untrusted server, however, and is probably far from ideal. Oh well, we'll have to fix this.
In case that StackOverflow question goes away, here's the relevant portion of 7231: https://tools.ietf.org/html/rfc7231#section-7.1.2
This should be resolved on master with #4452 and available in the next release. Thanks again for the report @stcioc!
In the following case (see detailed explanation and test case at http://www.webdbg.com/test/redir/fragment/):
Expected Result
The expected result is that requests library follows the redirection and appends the original fragment from the link (e.g. it redirects to http://bar/#SomeInfo)
Actual Result
The redirect link is followed without the fragment (e.g. requests tries to open http://bar)
Reproduction Steps
output is "http://www.enhanceie.com/test/redir/fragment/final.asp" output should be "http://www.enhanceie.com/test/redir/fragment/final.asp#HereIsSomeInfo"
System Information
This command is only available on Requests v2.16.4 and greater. Otherwise, please provide some basic information about your system (Python version, operating system, &c).