fix: set revalidate cache header on 404'd static assets

[dummdidumm]

Some adapters (like Vercel) apply a immutable cache header by default to static assets. They respect explicitly set headers though. Therefore apply a "must immediately revalidate" cache header to the 404 response of static assets in the SvelteKit runtime

related to #9089
Alternative to #12526

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 pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

• Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

[changeset-bot]

🦋 Changeset detected

Latest commit: 0f272a4

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

[smart]

I just tested this vs my patch on my app. It works great and is a more generic solution than mine.

[benmccann]

actually, thinking about this some more, I have a couple of thoughts:

• should we be consistent with the 404 headers? there are other places in this file where we return 404
• I wonder if public is correct. It means that an unauthenticated user can get the result from a shared proxy even if that asset it behind a login. That basically reveals the entire structure of your site even if it doesn't reveal any dynamically generated content. But what if someone has a paid-for content site built with mdsvex (i.e. the content is inlined into the JS). You're now making that paid content generally available to anyone regardless of whether or not they are logged in subscribers. I know we already do that in the adapters (search for 31536000 to find these locations) and it's best for performance to allow static assets to be cached by intermediate servers, but I wonder if we should have an option or authentication integration or something that helps sets this appropriately as it seems that public vs private should be set for that particular site. And really even a site-level setting seems too course. It feels like we should have the assets following the structure of the site more closely so that access to them can be better controlled by the directory you're in

[Rich-Harris]

should we be consistent with the 404 headers?

I think it's okay to treat this as a special case, since immutable cache headers on assets is already a special case (we don't automatically set cache headers on anything else)

That basically reveals the entire structure of your site even if it doesn't reveal any dynamically generated content

All assets are public. There's currently no way around that within SvelteKit itself, and I'm not sure it would be desirable to prevent it (you'd basically need to put logic in front of every asset request, which would make sites slower and more expensive to run). If we did change it, that would be an entirely separate discussion to this PR which is narrowly focused on fixing a particular bug