Server loader with cache headers can't cache first load

[arackaf]

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

[Conduitry]

This sounds like #4625, which is supposed to have been already fixed in #6461, but perhaps not.

[dummdidumm]

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.

[arackaf]

@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)