-
Notifications
You must be signed in to change notification settings - Fork 368
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
Double decoding path parameters #276
Comments
There definitely would be if you're using both |
Have you considered using |
I guess that can help. Thanks. |
Hi, I found a tricky case. Just want to ask what is the correct way to deal with it. How should I set this route? Pattern route: /~:param Expected param: %23 |
This is definitely a very tricky problem. Every character can technically have 2 (or more due to different ways to encode). I can think of a way to work with this. Two initial thoughts:
Option 1 is simplest, but I'm leaning toward option 2 for performance reasons. I'll mull this over this week, but feel free to add your own thoughts on the topic 😄 Option 2 also helps with other routing libraries, since normalization is a common problem between them all. I also think that, conveniently, the same library could be used to normalize the input to |
About 1 option. Each symbol in the path can be represented in the ASCII encoding. If you add this option, that would mean if I want to be sure that my path match in 100% of cases, I will need to add these function 2 option. Can you give me an example of this "normalization"? Or an example of another routing lib, that can it? |
nodejs: new URL('/%7E', 'http://test.c').pathname // /%7E chrome: new URL('/%7E', 'http://test.c').pathname // /~ |
Oh wow, I didn't expect those to act differently, I would have expected both to return For option 2, it'd likely be written by hand. Something that has consistent rules for everything, and does the kind of normalization |
About URLPattern. You can join to the conversation kenchris/urlpattern-polyfill#93 |
About writing own normalization lib. It should normalize but not decode the URL. I’m not sure that it is a good idea. |
Yep, exactly. To avoid these issues we'd need to focus on normalizing the format to something that won't be confused. E.g. always go to the encoded format. |
To clarify your example, the issue is mostly just the |
I think that “~” should be normalized path. |
Encoding all not encoded chars for each request would be expensive. |
If you run both inputs thought the same "encoder/normalization" it technically shouldn't matter. Trivial sample code would be
Not really, but there's also no other solution to what you're asking for. |
Another trivial example is handling of |
For example, it's not as if GitHub supports URL encoding all the random characters in this URL and have it still work. There's only certain normalizations they apply before trying to route. If we're worried about performance it's better to leave that decision up to people's frameworks or applications. |
Hi, I have a question about decoding path params. I have a URL that contains encoded symbols in its static and parametric parts. To match the route, I decode the URL using the decodeURI function, but in the parameter, I have one of these symbols (# $ & + , / : ; = ? @) that doesn't decode by decodeURI. It decodes with the decodeURIComponent function. If someone encodes one of these symbols twice, it will be decoded also twice. I'm wondering if there would be a problem of double decoding in this case?
https://owasp.org/www-community/Double_Encoding
The text was updated successfully, but these errors were encountered: