Skip to content

[Routing] dont redirect routes with greedy trailing vars with no explicit slash #30013

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

Merged
merged 1 commit into from
Jan 29, 2019

Conversation

nicolas-grekas
Copy link
Member

@nicolas-grekas nicolas-grekas commented Jan 29, 2019

Q A
Branch? 4.1
Bug fix? yes
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets #29673 #29734 #29575 #29924
License MIT
Doc PR -

From the linked issue:

The current logic is the following:

  • when a route is declared with a trailing slash, the trimmed-slash url is redirected to the one with the slash
  • when a route is declared with no trailing slash, the slashed url is redirected to the trimmed-slash one

That includes routes with slash-greedy requirements: when the same greedy requirement matches both the slashed and the trimmed-slash URLs, only one of them is considered the canonical one and a redirection happens.

We could fine tune this logic and make an exception when a trailing slash-greedy requirement is declared with no explicit trailing slash after it. (ie disable any redirections for /foo/{.*} but keep it for /foo/{.*}/. That would mean /foo/bar and /foo/bar/ wouldn't trigger the redirection for route /foo/{.*}, breaking the "not-semantics" property of trailing slashes for catch-all routes. Which might be legit afterall.

This PR implements this fine tuning, as that's the most BC behavior (and thus the correct one).
See #30012 for testGreedyTrailingRequirement in action on 3.4 as a proof.

@stloyd
Copy link
Contributor

stloyd commented Jan 29, 2019

@nicolas-grekas IIRC this (or really similar one) issue exists on 3.4 as well & was blocking update to recent versions: #29734 (comment)

@nicolas-grekas
Copy link
Member Author

Please provide a test case. The ones I added didn't highlight any similar issues.

@nicolas-grekas nicolas-grekas merged commit 2bb8890 into symfony:4.1 Jan 29, 2019
nicolas-grekas added a commit that referenced this pull request Jan 29, 2019
…ith no explicit slash (nicolas-grekas)

This PR was merged into the 4.1 branch.

Discussion
----------

[Routing] dont redirect routes with greedy trailing vars with no explicit slash

| Q             | A
| ------------- | ---
| Branch?       | 4.1
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #29673 #29734 #29575
| License       | MIT
| Doc PR        | -

From the linked issue:

> The current logic is the following:
> - when a route is declared with a trailing slash, the trimmed-slash url is redirected to the one with the slash
> - when a route is declared with *no* trailing slash, the slashed url is redirected to the trimmed-slash one
>
> That includes routes with slash-greedy requirements: when the same greedy requirement matches both the slashed and the trimmed-slash URLs, only one of them is considered the canonical one and a redirection happens.
>
> We could fine tune this logic and make an exception when a trailing slash-greedy requirement is declared with no explicit trailing slash after it. (ie disable any redirections for `/foo/{.*}` but keep it for `/foo/{.*}/`. That would mean `/foo/bar` and `/foo/bar/` wouldn't trigger the redirection for route `/foo/{.*}`, breaking the "not-semantics" property of trailing slashes for catch-all routes. Which might be legit afterall.

This PR implements this fine tuning, as that's the most BC behavior (and thus the correct one).
See #30012 for `testGreedyTrailingRequirement` in action on 3.4 as a proof.

Commits
-------

2bb8890 [Routing] dont redirect routes with greedy trailing vars with no explicit slash
@fabpot fabpot mentioned this pull request Jan 29, 2019
@nicolas-grekas nicolas-grekas deleted the route-greedy41 branch January 29, 2019 10:51
@ghost
Copy link

ghost commented Jan 31, 2019

Will this be merged into 4.2 as well? symfony/routing 4.2.2 has the same bug

@chalasr
Copy link
Member

chalasr commented Jan 31, 2019

@fantomas662 Yes it will, bugs are first merged into the lowest branch where they apply, then merged up to master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants