Do not distinguish between /page/ and /page

[ehrencrona]

Currently, we're serving the same page on both /url and /url/. It can be confusing because relative links behave differently and it's bad from a caching and SEO perspective. Should we rewrite the latter to the former with a 301?

[Rich-Harris]

There was some tangentially-related discussion in #5. I definitely think we want to canonicalise URLs and 301 from the non-canonical one to the canonical one.

I wonder if it might be slightly more complex than just removing the trailing slash though. If you're on (say) a blog index page, you probably want a relative link like first-post to navigate to /blog/first-post, not /first-post, but that only works if the blog index page is /blog/ and not /blog. Meanwhile, relative links from first-post should probably be resolved relative to /blog/, which means /blog/first-post and not /blog/first-post/.

In other words my hunch is that the default behaviour should be for 'leaf' pages to have the trailing slash removed, but 'branch' pages to keep it. (Stated differently, every page is a leaf page, but we remove the index from the /blog/index leaf.)

The fun part is figuring out

1. do we need to make this configurable somehow?
2. how does this interact with different static file hosts, which might have different expectations around this stuff?
3. since we don't have the ability to serve 301s with static file hosts, we might need to accommodate /blog and /blog/ and /blog/first-post and /blog/first-post/ (particularly since those pages have to be represented by /blog/index.html and /blog/first-post/index.html). This is where a per-page baseURI is potentially quite useful.

[benmccann]

I think that writing links in the app is the responsibility of the application author, so we shouldn't have to worry about that. (I'd not want links written as /blog/ and /blog/first-post since it's inconsistent)

It does make sense to me for the 301 redirects to be configurable (though that perhaps could be done later). We could make it a middleware that removes a trailing slash from any URL containing one via URL. If that middleware can be disabled via configuration then the user can add their own implementation that does whatever behavior they want.

[ehrencrona]

One fairly simple rule could be that if the page is served by an index.*, then the canonical URL should end with a slash. I'd expect that to work well with static file export.

Next.js has some kind of config option for turning this on and off that I don't quite understand.

[Conduitry]

I don't think index.svelte really captures it. I tend to use that, even for leaf pages, if the page is nontrivial and I want to keep its components all together.

[antony]

Next.js has some kind of config option for turning this on and off that I don't quite understand.

Vercel also has configuration for this. I wonder what happens if you set them both to different values?

https://vercel.com/docs/configuration#project/trailing-slash

[Rich-Harris]

The more I think about this, the more I think we should just always remove trailing slashes (i.e. 301 from /blog/ to /blog), until someone shows up with a use case for them. It seems like that's what most websites/frameworks/static webservers do by default

[Conduitry]

Ehhhhhhh I think the legitimate use case is /blog/ and /blog/slug. Preventing people from using nice relative URLs like the framers of the constitution intended sounds bad.

[Rich-Harris]

But are we saying that the behaviour of /src/routes/blog/index.svelte should differ based on whether there is also a /src/routes/blog/[slug].svelte? That was the thing that persuaded me it would be a mistake to try and infer whether or not to add the slash — it'd be weird if URLs changed under your feet while you were developing.

Are there many examples of trailing slashes in the wild?

Also, we have the convention of adding .json to a page to get the corresponding data, and you can't do that with trailing slashes — you can either have /blog and /blog.json or /blog/ and /blog/index.json (or be an absolute madman and have /blog/ and /blog.json). The first seems much nicer to me

[Conduitry]

As I noted in Discord - I think I'm fine with deferring on the decision of how to configure this. No slash is definitely the more sensible default, and we can revisit this later after the public beta.

[benmccann]

Starting with no slashes for the beta and waiting until we get a use case for something else sounds like a sensible plan to me

[Rich-Harris]

closed via #267