-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
+page.server.js no longer uses/respects setHeaders #6477
Comments
I noticed this in particular when trying to overwrite some headers with example setHeaders({
'sec-fetch-mode': 'navigate',
'sec-fetch-dest': 'document',
})
...
throw redirect(301,'/todos') Doesn't work, actual headers
|
This is very frustrating as it means making an unnecessary request to the page endpoint when going 'back' a page. As a workaround is there a way to intercept this somehow and prevent it happening (using an in memory store somewhere instead)? |
Not sure how to solve this with regards to cache headers. Other headers seem easy, just add them back. Cache headers however are in conflict with other feature such as |
The issue right now is that we can't add headers at all (we also seemingly can't prevent calling the page endpoint unnecessarily even if the data is held in memory). I think it's sensible not to add cache headers by default and leave that to the developer. Caching is, in general, a nightmare of complexity but I just want a simple 15min max-age to make the once-a-day visitor to this portfolio site have a slightly better experience. Side note, but also now that the request goes to |
Cache headers won't work with The solution here is for SvelteKit to read cache headers when generating the window.__sveltekit_ttl = 300; The client can read that value and cache the data for 300 seconds, reusing it if the user navigates back to the same URL. (Though there is a footgun here — if the data was mutated, the mutation would persist.) |
Would this solution work per page? Where would SvelteKit read the headers from exactly? Could we add I'm basically looking to avoid requesting/importing the data if I've already visited the page. I hope I'm understanding this correctly - but it seems like we're on the same page (no pun intended : ) |
Another thought I just had: What if the const urlId = map.get(url) ?? id++; // maybe we can even use event.routeId here and spare us the map?
//...
__data.js?__id={uniqueId}_{urlId} This then enables us to store the cache header on the request. |
If you call kit/packages/kit/src/runtime/server/page/serialize_data.js Lines 78 to 84 in 2c6f537
fetch to be aware of cache headers applied to responses that are inlined into the HTML.
This would only re-use data for back/forward navigations — it wouldn't help if you visited @dummdidumm that wouldn't work because the data would be stale when revisiting a URL — you wouldn't be loading data from the server, you'd be loading it from the module cache (except you wouldn't, because we delete |
Great. If I'm understanding correctly this seems to solve my issue/goal precisely. In a real world scenario I wouldn't expect a visitor to refresh the page/start a new session and even if they I think it's fine to not use the browser cache. But I'm still wondering if this works per page/route? For instance there may be some pages that I would like to be "refreshed" each time (although I guess it might be possible to manually trigger an update onmount for example each time the page is visited). Does the __sveltekit_ttl value get applied/removed each navigation? |
It would apply per-URL, and data would be reused until it was stale. Manual invalidation would override |
...using the Vary header, which allows on cached response for each variation of the x-sveltekit-invalidated header, ensuring we cache matching responses for all invalidation scenarios Closes #6477
* [feat] enable caching for __data.json requests ...using the Vary header, which allows on cached response for each variation of the x-sveltekit-invalidated header, ensuring we cache matching responses for all invalidation scenarios Closes #6477 * Update .changeset/clean-sheep-run.md * use append Co-authored-by: Rich Harris <richard.a.harris@gmail.com>
Describe the bug
Since this commit the
+page.server.js
endpoints return a js file rather than json. This js file response no longer uses the headers set with thesetHeaders
function. This means we can't use cache-control etc.Reproduction
To reproduce, hover over the 'TODOS' menu item and observer the '__data.js' response headers. There should be a header as defined in
routes/todos/+page.server.js
;https://stackblitz.com/edit/sveltejs-kit-template-default-8tt4be?file=src/routes/todos/+page.server.js
Logs
No response
System Info
Severity
annoyance
Additional Information
No response
The text was updated successfully, but these errors were encountered: