Post request via fetch gets overriden/replaced in `load()`

[lukasIO]

Describe the bug
Two parallel (?) fetch POST requests (one from $layout.svelte, and one from index.svelte) with different contents end up having the same response on the client side.

Logs
nothing interesting happening in the logs

To Reproduce
I set up a repro repository here https://github.com/neesh-studio/sk-fetch-override-repro which loads two festival objects from a graphQL api.
One Festival is called "First Festival", the other "Another Festival".

The SSR implementation seems to work as there is a short flash of the "Another Festival" title on page refresh. But it get's replaced on the client with "First Festival".
What i get to see:

Expected behavior
what I expect to see:

I expect the fetch api to work the same on server and client and the client not overriding another (POST) request. (A quick test shows the behaviour seems fine for GET requests)

The problem goes away if I uncomment line 21 in api.ts

  if (typeof window !== "undefined") fetchApi = fetch;

Information about your SvelteKit Installation:

• The output of npx envinfo --system --npmPackages svelte,@sveltejs/kit --binaries --browsers

System:
    OS: Linux 5.4 Ubuntu 20.04.2 LTS (Focal Fossa)
    CPU: (4) x64 Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz
    Memory: 10.16 GB / 12.35 GB
    Container: Yes
    Shell: 5.0.17 - /bin/bash
  Binaries:
    Node: 14.15.5 - ~/.nvm/versions/node/v14.15.5/bin/node
    npm: 6.14.11 - ~/.nvm/versions/node/v14.15.5/bin/npm
  npmPackages:
    @sveltejs/kit: next => 1.0.0-next.58 
    svelte: ^3.29.0 => 3.35.0 

• Your browser
  Chrome: Version 89.0.4389.90 (64-Bit)

• Your adapter (e.g. Node, static, Vercel, Begin, etc...)
  dev server

Severity
Minor, there is a workaround (as described) but I wanted to post the issue early in case this is somehow connected to #591

[Rich-Harris]

Two options that I can see:

1. Add a hash of the body as an attribute on the <script type="svelte-data"> containing the inlined response, so that POST requests can be disambiguated
2. only inline GET requests

I prefer 1 over 2 even though 2 is simpler; any reason you can think of that we shouldn't do that?

[Conduitry]

What sort of hash? I'm assuming we'd have to ship code to the browser to perform the hash?

[Rich-Harris]

https://github.com/sveltejs/svelte/blob/ddf13211afcc33f8601133aad9ca270cd1df017f/src/compiler/compile/utils/hash.ts#L1-L9

// https://github.com/darkskyapp/string-hash/blob/master/index.js
export default function hash(str: string): string {
	str = str.replace(/\r/g, '');
	let hash = 5381;
	let i = str.length;

	while (i--) hash = ((hash << 5) - hash) ^ str.charCodeAt(i);
	return (hash >>> 0).toString(36);
}

[lukasIO]

Apart from the few additional bytes, I personally can't think of anything that speaks against the hash solution, but I also don't have a very deep understanding of all possible requirements that people might have when using POST requests.

One thing from the top of my head: what about POST requests that include files/blobs - could that become a problem?

[Rich-Harris]

Possibly... though I don't think there's a good reason anyone would have for POSTing to anything that wasn't a GraphQL endpoint in load

[benmccann]

I don't really understand the issue. If you have the body to be able to calculate the hash then don't you already have the response? I would think the key would need to be calculated off the request URL or something.

Edit: Ohhh... request body. Not response body. Nevermind

[benmccann]

Hashing the post body generally makes sense to me. The one thing that I wonder about is if you're posting a JSON body it could be stringified with the keys in a different order on different executions

[Rich-Harris]

It shouldn't be, key enumeration order is standardised. If it did happen like that, it just means SvelteKit would fall back to making the request instead of using the inlined data.

[Conduitry]

In any case, I don't think it's safe to assume that two requests with different POST bodies would have the same response anyway, even if they happened to be JSON encodings of equivalent objects. That sounds like a place we don't want to go.