kit
kit copied to clipboard
sveltejs
Server loader with cache headers can't cache first load
Describe the bug
If I have cache headers set in my server load function
export async function load(params) {
console.log('LOADING');
// const val = params.url.searchParams.get('val');
const val = params.url.search;
const result = {
searchProps: 'Value ' + val + ' ' + ' CACHE TEST VALUE === ' + i++
};
params.setHeaders({
'cache-control': 'max-age=60'
//Vary: 'Cookie'
});
return result;
}
the headers work, and the page is cached, but if I start on this page, browse elsewhere, and then hit the back button, the loader re-runs.
The reason appears to be that the initial load of my site renders the entire page (which does have the correct headers), but subsequent navigations fetch a __data.js with the right url attached, so browsing back to it fetches that, which isn't (yet) cached.
Reproduction
The minimal repro is here: https://github.com/arackaf/booklist/tree/special/bug-repro/svelte-kit
the directory above that has a huge project around it, but that directory I've linked to contains a minimal SvelteKit app that reproduces this (ostensible) bug.
It's currently deployed here: https://booklist-svelte-kit.vercel.app/
As you navigate, you'll see fresh calls to fetch __data.json, even when you click back to the starting page, which, again, is not (yet) cached.
Logs
No response
System Info
System:
OS: macOS 12.6
CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
Memory: 149.78 MB / 16.00 GB
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 16.14.2 - /usr/local/Cellar/nvm/0.38.0/versions/node/v16.14.2/bin/node
Yarn: 1.22.17 - /usr/local/Cellar/nvm/0.38.0/versions/node/v16.11.1/bin/yarn
npm: 8.18.0 - ~/Documents/node_modules/.bin/npm
Browsers:
Chrome: 107.0.5304.110
Firefox: 107.0
npmPackages:
@sveltejs/adapter-auto: next => 1.0.0-next.89
@sveltejs/kit: next => 1.0.0-next.557
svelte: ^3.44.0 => 3.53.1
vite: ^3.1.0 => 3.2.4
Severity
serious, but I can work around it
Additional Information
No response
This sounds like #4625, which is supposed to have been already fixed in #6461, but perhaps not.
It's related to #4625, but that was only about shared load functions. We would need to add a similar-but-different mechanism for the __data.json case.
@dummdidumm and as I've been discussing with Rich, you'd probably need to NOT serve cached results on subsequent load if a custom vary header were present (or else find some creative way to respect the vary header ... ie record all the Vary'd values along side the ttl, and check them on second request)