Document counter-intuitive difference for dynamic routes on SSR and SSG

[Fryuni]

Just a small little detail about routing on this example:

/src/pages
└── [...locale]/
    └── [...slug].astro

That would not work as expected in on-demand pages (SSR). Rest parameters ([...name]) can match any number of path segments and as a consequence using two rest parameters in the same routes makes parsing the path ambiguous. For example, a request to /en/blog/amazing-article could be parsed in any of the following ways:

• {locale: undefined, slug: 'en/blog/amazing-article'}
• {locale: 'en', slug: 'blog/amazing-article'}
• {locale: 'en/blog', slug: 'amazing-article'}
• {locale: 'en/blog/amazing-article', slug: undefined}

It can be used to generate the page, so for prerendered pages, this is fine since the routes are generated from getStaticPaths. Astro provides no guarantees about which of those interpretations will be used during parsing. We use a library to turn the file path into a parsing function, which also doesn't guarantee the behavior when facing this ambiguity (in fact, the behavior changed during a patch release earlier this year).

So if you do want to have an optional locale in the URL and use SSR the recommendation would be to have the entire tree twice, once on src/pages and once on src/pages/[locale]

Originally posted by @Fryuni in #9256 (comment)

[sarah11918]

So the issue here is that https://docs.astro.build/en/guides/routing/#server-ssr-mode says "routing works the same as for SSG" when it doesn't exactly work the same, and you can't have two parameters.

[delucis]

You can have two parameters if they’re not using the ... spread syntax.

src/pages/[locale]/[...slug].astro or src/pages/[locale]/[slug].astro would both be fine.

[Fryuni]

Yeah, this is specifically about having two rest parameters ([...locale]/[...slug]). Which was recommended as a workaround on that issue and multiple times over Discord.