-
Notifications
You must be signed in to change notification settings - Fork 1.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
URL Encoded Parameters Still Not Working in Go 1.5.1 #132
Comments
The problem is that the mux matches the fully decoded path in req.URL.Path. This issue can be fixed by changing the mux to match req.RequestURI, but that change might break existing applications. RequestURI has been available since Go 1. A workaround is to change the pattern to:
This pattern matches "/foo/bar%2ftest" and "/foo/bar/test". If you don't want "/foo/bar/test" to match, the modify the handler to check req.RequestURI or the req.URL.RawPath and return status 404 as appropriate. |
@garyburd thanks for the speedy response and getting me unstuck! Okay, while this isn't exactly ideal, it should at least work. How then would I handle: |
I am also running into this (last issue in this thread) and have made the following unit tests and changes to use EscapedPath() instead of Path directly and it now works great for my needs. Is this something that might be considered for a pull request? |
Note that using the The alternative would be to implement our own function that takes a |
Thanks much! Aha, I was not aware of that :) Seems like a solid reason. I can try to Also, I currently return the encoded variable, it's probably better to On Tue, Nov 24, 2015 at 4:00 PM, Matt Silverlock notifications@github.com
|
Would using URL.RawPath instead of URL.Path at this line: https://github.com/gorilla/mux/blob/master/mux.go#L71 be an option? I guess if support for pre-Go 1.5 is required then probably not. It was mentioned that using RequestURI might break existing apps, but couldn't treating %2F as / be considered a bug and therefore the change in behavior needed/expected? We're running into a similar issue: moby/moby#16577 |
Ah, never mind about RawPath - I see that EscapedPath() is the proper way to get the same info. |
@elithrar is this now fixed? |
No - I'm open to a PR, but as this has been quiet I'd intepreted the feature wasn't required. I'm not entirely convinced it's a "bug". The fix is: either break compat for all users pre Go-1.5 (not an option) or add in logic to handle that ourselves. |
@vaikas-google were you going to submit a PR? |
+1. I'm also in need of this |
@elithrar in re: "I'm not entirely convinced it's a bug" see rfc3986#section-2.2 |
@chrisdostert Alright—that's all I needed. Are you able to submit a PR? Happy to work with you on it/review, but I don't have time to fix this any time in the near future. Any fix must be backwards compat. |
hey guys, do we have any update here? I also hit into this. |
Open to any pull requests to fix this.
|
#184 created, does not break backwards compatibility. |
#184 merged. This issue can be closed? |
Done. |
So as a follow up to #77, I'm running Go 1.5.1 which claims to have been the cause of that issue: #77 (comment) and I am still seeing issues with uriEncoded paths.
Example:
If I use
url1
I get a 404, if I useurl2
I get a 200. Thoughts? I am using Ember-Data to generate API calls so short of performing a huge hack on both ends which doesn't seem reasonable.The text was updated successfully, but these errors were encountered: