net/http: DefaultServeMux incorrectly redirect (301) to path if path includes %2F%2F
#21955
Comments
%2F%2F
%2F%2F
FWIW it happens even with
The key aspect being two consecutive |
Redirecting |
%2F%2F
%2F%2F
I fixed similar bug in the past, so I will confirm this. |
Change https://golang.org/cl/103696 mentions this issue: |
I'm not sure if this actually a bug in the first place. The URL reported in the original comment is:
The decoded path is:
ServerMux.Handler uses path.Clean. That path clearly has a double slash and path.Clean translates double slashes to single slashes. Also see here. The godoc for ServerMux.Handler says:
If there's an open question here, the question is around the definition of "canonical path". Does the canonical path convert double slashes to single slashes? If so, does it also convert %2F%2F to "/"? If yes to both questions, there's no bug. Otherwise, there's a bug. AFAICT, these questions are not answered in any documentation. In net/http/server_tests.go, serverMuxTests does not have a case for double slashes, so I suspect this question hasn't come up until now. |
@tombergan Thank you for the clear explanation. I'll investigate this problem again. |
As a countermeasure against this similar problem, there is nginx And then, I have take a look at RFC-3986 for confirming the encoded double slashes validity.
Therefore, I think, if we follow RFC-3986, the current behavior is buggy. |
@bradfitz ping? If my survey is reasonable, I'm going to try to improve the patch based on this survey result. |
@bradfitz @tombergan ping? |
The current implementation of ServeMux incorrectly returns a 301 status code when the path contains URL-encoded data, and especially URL-encoded URLs. Fixes golang#21955
Change https://golang.org/cl/234657 mentions this issue: |
To expand on @tombergan's comment (#21955 (comment)), the
The documentation is not explicit on whether I believe the current behavior is consistent with the documentation and probably can't be changed without violating compatibility. Perhaps the documentation should explicitly mention the treatment of escaped path components. |
I'm suffering the same problem trying to use an encoded full URL in the path. For example I'm trying to use this URL (an image from Wikimedia):
Once encoded we get the following URL:
And this is the request to my server using the previous URL as path:
I'm receiving a
I understand that Apart from the possible bug, anybody knows any solution/workaround that doesn't involve creating from scratch a custom serve mux or using another one available? Any possible way to avoid that cleaning? |
This is clearly a bug. The encoding method can encode arbitrary data in a Uniform Resource Identifier (URI), which is the point of the encoding. "/" is the reserved character slash. "%2f" is an arbitrary string. Is "%2f" is a slash? |
What version of Go are you using (
go version
)?go version go1.9 linux/amd64
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?What did you do?
What did you expect to see?
404 page not found
What did you see instead?
<a href="/path:a/google.com/">Moved Permanently</a>.
NOTE: this does not happen if alice was used instead of the
http.DefaultServeMux
The text was updated successfully, but these errors were encountered: