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
[symfony/http-foundation] Request parse_url issue with double slashes #29478
Comments
Thank you @arku31 for creating this bug report! This indeed looks A Status: Reviewed |
Have the same issue, took some time to dig down and find it, any ETA on release? |
Thank you @danijelk for your concern, to speed up further you can help to code review the PR #29494. As I see for now it mostly depends on the availability of a merger. |
Also affected by this issue |
…e slashes (alquerci) This PR was merged into the 3.4 branch. Discussion ---------- [HttpFoundation] Fix request uri when it starts with double slashes | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #29478 | License | MIT | Doc PR | ~ When the `REQUEST_URI` starts with a slash no need to `parse_url()`. However to keep the same behaviour regarding the fragment we need to add a logic to remove it. While `parse_url()` handle all cases itself. Commits ------- cf850c1 [HttpFoundation] Fix request uri when it starts with double slashes
Symfony version(s) affected: 3.4.19 (master v4.2.0 v4.2.0-RC1 v4.1.8 v3.4.19 should be affected as well)
Description
This commit causes the problem - symfony/http-foundation@fbf0364#diff-7edb274bc39ed8c493badba7dd278826
In case of the wrong server configuration, REQUEST_URI could equal to "//api/v1/request"
The result of parse_url in this case is [path] => /v1/request, what is wrong ('/api' is missing).
From one point this is definitely the server misconfiguration but from another point - it works fine in 3.4.18. In most cases, it leads to 404 for routes what previously worked fine.
I think this problem could be popular and should be fixed even that it's not really a problem on your side.
How to reproduce
Easy way is to temporarily hardcode $requestUri equal to "//api/v1/request" on line 1840 in Request.php (link below).
The hard way is to do wrong nginx setup :)
Possible Solution
Do not use parse_url :)
The text was updated successfully, but these errors were encountered: