-
Notifications
You must be signed in to change notification settings - Fork 17
fix double encoded %-signs in request path #30
fix double encoded %-signs in request path #30
Conversation
According to go URL documentation (https://golang.org/pkg/net/url/#URL) URL.Path returns a decoded version of the originally requested URL. Filling this field with a value, but not RawPath causes URL to encode the value of Path and return it when called by URL.EscapedPath() and hence URL.String().
I am not quite sure whether the condition is actually needed. In case the requestURI.RawPath is empty, the outReq.URL.RawPath is going to be empty anyway too. if requestURI.RawPath != "" Please feel free to improve my snippet. |
Could you add tests to prove that you are repairing something and do not create regression? |
Well, I guess I fixed the test 😉 . Other than that, I created my own little test setup with a small python script as back end server and additionally now I have my own Collabora cloud running after applying my own patch. See referenced issue with traefik. |
you have fixed an already working test ? 🤔 Maybe I missed something, could you explains? |
I have seen issue but your test snippet match with nothing in Could you create a PR on Traefik with a failed test? or just add a test in this PR? Thanks. |
From my point of view, the test is testing the wrong thing. According to https://golang.org/pkg/net/url/#URL:
So the test is not really testing what the back end server is receiving, but is testing whether the decoded version is the same as the decoded version from the initial HTTP Request. This is what happens currently:
The set up But the test does not represent what is actually sent over the network. |
I trust you and I understand the problem, but I think we can reproduce the problem with a test. Without testing, we can not preserve ourselves from a regression in the future. |
So I think "fixing" this test should be okay. Short of doing that, you could go one level deeper and tear apart the HTTP protocol yourself instead of using the net/http/httptest library to depend on, but I guess this would be too much effort for to little outcome. Using the correct field of the URL struct seems to be enough in my view. |
How are we going to proceed with this? |
@marco-jantke is this the issue we've been looking at as well? |
Sorry for the late response.. @timoreimann no, it's not the same problem. Especially because this is in the realm of websockets and ours, fixed with traefik/traefik#2382 is about things with the strip prefix middleware. The implementation looks good to me. As I understand @shieldwed explanation, it makes sense to me to adapt the formerly wrong test. My opinion. |
Partially included and enhanced by #44. |
According to go URL documentation (https://golang.org/pkg/net/url/#URL)
URL.Path
returns a decoded version of the originally requestedURL
.Filling this field with a value, but not
RawPath
causesURL
to encode the value ofPath
and return it when called byURL.EscapedPath()
and henceURL.String()
.