-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Behavioral difference between Linux and Windows in httprequest with 302 reply and # #25119
Comments
cc: @stephentoub Looks like the Uri fragment is missing from the redirect. CurlHandler will need to be fixed. Might need to fix SocketsHttpHandler. |
We should add a test for this, and SocketsHttpHandler if necessary. |
We have this test: |
That does seem to match what the repro is doing. |
I took a look at the spec, and the behavior outlined in the test does seem correct:
I have an Ubuntu 16.04 machine allocated right now, so I can test the repro to see if I get the same result. |
I'm able to reproduce the issue on Ubuntu. I also gave the CurlHandler redirect code a cursory look, but didn't see anything obviously stripping the fragment. |
Interesting, thanks Max. I can't see what's different between this and the test Stephen linked. Do you see anything? |
Possibly the test is bogus somehow. I'm looking at SocketsHttpHandler's redirect logic, and I don't see it doing anything with fragments specifically. Yet this test is passing. |
Yep, it's a bogus test. The key line of the is the comparison at the end: |
Well, that's bad. Glad we found this. |
Is that a bug of its own, or by design for some reason? |
I fixed the test and SocketsHttpHandler in dotnet/corefx#27360. The observed Linux behavior is due to libcurl explicitly never sending fragments. It's been that way by design since v7.20 in 2010. Desktop also doesn't send fragments. WinHttpHandler does send fragments, but it doesn't correctly handle the case called out as a "must" in the RFC where redirecting from a URI with a fragment to a URI without a fragment is supposed to inherit the fragment into the redirect. The test special cases all of these. |
Also regarding my question:
I see this is called out in the docs: |
I had always assumed the behavior was correct because it was explicitly mentioned in the docs, but it actually looks a little less clear. There is a basis for our current behavior in section 6.1:
But ultimately in section 6.2.3 the spec states:
That second section seems to clearly establish that the fragment should be included in equality checks. So our behavior looks like a deviation from the spec, even if it is one we probably don't want to fix. |
@jdelrue commented on Thu Feb 01 2018
General
Operating system 1: Windows 10
Operating system 2: Ubuntu (16.04 or 17.04)
Execute:
Output Windows: http://www.google.be/#youdontgetthisinlinux
Output Linux: http://www.google.be/
Expected output is the Windows version. Workaround: Disable autoredirect and read location header.
The text was updated successfully, but these errors were encountered: