-
Notifications
You must be signed in to change notification settings - Fork 11.1k
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
[Bug] Failure to properly parse all valid URLs #27133
Comments
My case is a bit complicated, but very common examples may include when putting blog post titles in URL's or something for SEO. I've seen other places (stack overflow, closed issues) where a lot of users have come across this issue as well Blog ex: Which is the URL format for "Why laravel’s routing should allow urlencoded/hexencoded data" as the final param of http://blog.com/2018/10/01/{NAME}
|
It also seems to partially urldecode incorrectly. If we use our example from above but remove the /, then the arguments our action would get would be the following:
I have no idea why but it appears to have parsed the hex codes but not the encoded spaces. Easily fixed though:
That replaces the + with ' ' properly. |
Duplicate of #22125 |
The encoded There is a documented way to circumvent this though: https://laravel.com/docs/5.7/routing#parameters-encoded-forward-slashes |
@driesvints It's a duplicate of a couple issues all of them are "closed", and many don't seem to be getting any attention despite dozens of 👍 . The one you linked has 32 👍 on the statement that it shouldn't be intended behavior. This is an annoying issue that confuses developers all the time so they end up spending an hour or two thinking "What the heck is going on" until they realize "Oh laravel is being dumb" This also breaks base64 encoded parameters because base64 uses / (of course you would anticipate making it URL safe before putting it in a param. Your work around didn't work for me. Admittedly maybe that's because I'm on laravel 5.3 but I don't have time to upgrade the project right now just to apply a workaround - and really I think this is about making your library make "sense" and not make developers scratch there heads over something stupid before traversing docs and issue stuff. |
@driesvints |
If you “don’t have time” to upgrade your project to the latest security and patches that have solutions to your problem; that’s a problem within itself. I would recommend using https://laravelshift.com/ to upgrade your project to the latest version. It’s quick and painless. |
And ignore any other good point made here. It's not a great solution and actually does not solve my problem because I'm using two arugments, and is there even a guarantee the version is why it's not working? |
Description:
When doing routing based on the URL Laravel parses hex values in the URL which should not happen. Other frameworks like Symfony don't have this issue. This means that your routing system isn't using the "URL" for routing you're "decoding" the URL, so it's routing is done on the string produced when the the entire URL has been decoded (which makes no sense, why would you ever want to urldecode an entire URL rather than it's individual parameters separately?).
Steps To Reproduce:
Pass url encoded strings are parameters in a URL and your route will note match
Ex:
Navigate to
http://app.com/pdf_header/johnsmith/123%2F123
The text was updated successfully, but these errors were encountered: