I agree that this is the cleanest and simplest solution. But I fear it's a BC break for some people.
I've seen route definitions like path: ~ and path: '' alot which then get imported with a prefix. So for all of them it will change the URL.

@Tobion yep.

Here is a plan:

• for redirecteable URL matchers, [Routing] Redirect from trailing slash to no-slash when possible #26283 fixes the issue for GET/HEAD. For other methods, we would make the two routes equivalent, ie no redirections and no 404.
• for non-redirecteable matchers, we would disable this behavior and keep the current one

Since the behavior is in RouteCollection, and since RouteCollection doesn't know about the types of the matcher, we would in fact add a constructor argument to it, to opt-in low-level (and we would always pass true via FrameworkBundle.)

@nicolas-grekas your code looks so easy, I tried it last year and stranded.

Thank you very much.

for redirecteable URL matchers, #26283 fixes the issue for GET/HEAD

There is stll alot of potential for BC breaks. Like if someone used hardcoded relative links to assets, it doesn't work anymore. Or if you developed an API and the client does not support redirect, it breaks.
So I don't think it makes sense to base the behavior on the matcher.
The only solution I see is to create a new config on framework.router level that defaults to the old behavior. And for new projects we set the config to the new value in the recipes (which will be the new default in sf 5)

@Tobion I don't understand what you mean.

At the moment, we have this behaviour:
routes:

• /
• /api/
• /api/query

these urls match: /, /api/, /api/query
this url is redirected: /api -> /api/
this url throws an 404: /api/query/

#26283 will fix the last case, in my opinion it is a new feature and a good feature.

The case why I had the problem is, that for api url reasons and / or SEO reasons, I want to replace my custom api controller with a bundle (or subfolder) and leave the url the same.

api_query:
    prefix: /api/query
    resource: ../src/Controller/Api/Query
    type: annotation

and the controller

    /**
     * @Route("")
     */
    public function queryIndexAction() 

doesn't work at the moment.

In a second application (api.domain.com) I can reuse this controller / bundle without prefix and the url will be /

I've seen route definitions like path: ~

Good news, that's actually not true!: loaders do not allow setting null, eg YamlFileLoader::validate() forbids it. And instantiating a Route object directly with a null path fails since 4.0, because the argument is type-hinted string.
Which means we just have to make null behave as we want and done.

PR updated.

#12141 (comment) made me realize that for annotations path="" works if you specify the prefix on the class. But for other use-cases path="" means something else. That inconsistency is unfortunate.

@nicolas-grekas the difference between null and "" is probably hard to see for people. I think it would better in the long run to just use "" for this. Maybe we should reconsider adding a config/env variable to enable the new bahavior for path="". And when the config is not set and someone used an empty path so far, trigger a deprecation.
Implementation wise it would be very easy as we don't need to touch any of the loaders.

Now tested, ready;

(failures unrelated, PR ready)

This looks good to me.

But this needs a doc PR. And it would also be good to update the PR description with the final solution to reduce confusion.

description updated

create a separate method like removeTrailingSlash(string $path)

That is not possible: $trailingSlashOnRoot is really a parameter that configures the prefixing logic. Once prefixing is done, we cannot know which routes where root.

create a separate method like removeTrailingSlash(string $path)

I somehow missed that your proposal has the path as argument. But that requires prior knowledge of which paths are the root, and doesn't work with localized paths (or requires knowledge of all the variants, which is bad coupling.)

Thank you @nicolas-grekas.

Hello,

I am trying to understand why when we have perfixed routes (for example /{_locale} with a default locale) and in this routes, this one :

page:
    path:     /{slug}
    defaults:
        slug: 'homepage'
    ...

The generator remove the ending slash when I try $this->get('router')->generate('page') (and locale is setted to a non-default value).
Eg: _locale is set to en, the router generate /en (and not my|the? expected /en/).

I go deep into the code (in RouteCollection and UrlGenerator) but can't find the explanations.

I am using Symfony since 4.1.

It's because you set a default value for slug. In case you want the trailing slash, you can remove the default value and instead change the requirement for slug to allow an empty value like [^/]*

Thank you for your reply.

It may work, but if I remove the defaults then I can't generate the url. Generate('page') throw "Some mandatory parameters are missing".

Re-reading the doc, I understand the behavior. It is what is expected (last line).

Yes you need to provide the slug param then. Another solution to get the trailing slash is to create two routes:

• /en/
• /en/{slug}

If I do that, I loose my domain page with default locale : / redirect to /default-locale/. And I want to keep it to. And I want to keep it.

I try a few workaround, but I can't find a Solution (my best was to get / and /default-locale/ working and generate /default-locale/).

I will end to do a twig function to correct the URL generator (I am not sur I can override directly the UrlGenerator class from a bundle).