Fix truncated basepath

[Rich-Harris]

Supersedes #3337. Ensures that requests for /basepath (where paths.base === '/basepath) resolve correctly (the existing tests didn't catch this because of trailingSlash: 'always').

This doesn't fix static asset handling, which is a bit finicky — will open a separate PR for that.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

[changeset-bot]

🦋 Changeset detected

Latest commit: 291c4f6

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[netlify]

✔️ Deploy Preview for kit-demo canceled.

🔨 Explore the source changes: 291c4f6

🔍 Inspect the deploy log: https://app.netlify.com/sites/kit-demo/deploys/61e1fbabd05510000739039c

[Conduitry]

Do we need to decode first before checking this?

[andrewsoutar]

In a couple of other places, it seems to be checked without decoding. paths.base doesn't seem to be documented one way or the other (whether it's encoded or decoded); on the other hand, the encoded form isn't canonical, so e.g. even with a "normal"-looking base of /foo, someone visiting via /%66%6f%6f might not match, even though it's the "same" URL. (The same issue, I would imagine, applies to the other places where it's checked as well - including probably in adapters - and behavior would vary depending on whether whatever is upstream canonicalizes the URL.) Honestly, not sure how much of a problem that is.

[Rich-Harris]

updated the PR

[andrewsoutar]

Getting static assets to work with svelte-kit dev is indeed tricky. What I've tried:

• In my original changes, I simply set $app/paths.assets to be empty in the build; Vite was already serving the assets from the root path, so as long as every asset use is prefixed by $app/paths.assets, everything works. Of course, this breaks if asset paths are hardcoded, relative, etc. These cases were already broken.
• Change Vite's base path - right now it's hardcoded to /. Changing it to config.kit.paths.base + '/' seems to work (in my limited testing) if I hack the base path back in before sending it to the router for SSR - assets are correctly served from paths.base. But it fails if the user has a custom paths.assets, because the app is built with the asset path as /_svelte_kit_assets, but the assets are served from paths.base/svelte_kit_assets. We could change the asset path in the app build, but then it breaks parity with svelte-kit preview. We could also use a combination of that scheme and the existing one, depending on whether paths.assets is set, but that sounds like a mess.
• Serve the static assets "by hand", rather than having Vite do it for us. svelte-kit preview already does this. Honestly, I don't know enough about Vite to know what the tradeoffs are here.