New server-side fetch implementation introduces new CORS errors

[bothness]

Describe the bug

This new implementation of server-side fetch is causing at least one of my Svelte Kit apps to break.
#6550

I am now receiving a 500 CORS error when fetching a Google spreadsheet as CSV, which does not give me CORS errors when loaded using browser fetch (or with the previous Svelte Kit server side fetch).

Reproduction

Fetch any Google spreadsheet as a CSV in a load() function within a +layout.js or a +page.js file, eg.

const url = "https://docs.google.com/spreadsheets/d/1mTdWRKo8AnJhKjBkqlonWlHoxIrdtZoqMnOkj_KMYvA/gviz/tq?tqx=out%3Acsv&sheet=Sheet1";

export async function load({ fetch }) {
	let response = await fetch(url);
	return true;
}

Logs

CORS error: No 'Access-Control-Allow-Origin' header is present on the requested resource
Error: CORS error: No 'Access-Control-Allow-Origin' header is present on the requested resource
    at fetch (.../node_modules/@sveltejs/kit/src/runtime/server/page/fetch.js:100:15)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async fetcher (.../node_modules/@sveltejs/kit/src/runtime/server/page/fetch.js:63:20)
    at async Module.getPlaces (/src/lib/utils.js:4:12)
    at async load (/src/routes/+layout.js:8:15)
    at async load_data (.../node_modules/@sveltejs/kit/src/runtime/server/page/load_data.js:109:15)
    at async .../node_modules/@sveltejs/kit/src/runtime/server/page/index.js:165:13

System Info

System:
    OS: Linux 4.19 Ubuntu 20.04.1 LTS (Focal Fossa)
    CPU: (4) x64 Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
    Memory: 4.73 GB / 6.08 GB
    Container: Yes
    Shell: 5.0.17 - /bin/bash
  Binaries:
    Node: 16.17.0 - ~/.nvm/versions/node/v16.17.0/bin/node
    npm: 8.15.0 - ~/.nvm/versions/node/v16.17.0/bin/npm
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.64 
    @sveltejs/adapter-static: ^1.0.0-next.31 => 1.0.0-next.39 
    @sveltejs/kit: ^1.0.0-next.476 => 1.0.0-next.476 
    svelte: ^3.46.0 => 3.49.0 
    vite: ^3.1.0 => 3.1.0

Severity

blocking an upgrade

Additional Information

The response from Google doesn't seem to include an 'Access-Control-Allow-Origin' header, but this has never caused problems before (I guess there is something else in the settings/headers that's preventing a CORS error in the browser?). Obviously, I don't have a way to control the headers that Google returns, and not being able to use the sheet as a data source would basically break my app.

[bothness]

An update... Looking at this further, Google's headers include a lowercase 'access-control-allow-origin' header, so it might be as simple as making the CORS check case insensitive in the fetch function.

[aradalvand]

This is likely a duplicate of #6608, did you try setting an Origin header manually?

[bothness]

Yes. This looks like it's probably a duplicate. Sorry for missing it.

I haven't tried setting the origin manually, but I'm not sure that's a solution, since I need it to work both on localhost (for dev/testing) and in production.

For me, the expected behaviour would be that it shouldn't cause errors that don't exist when using the browser's fetch function.

[bothness]

But... I think the Origin header not getting forwarded is probably the actual issue here (not the case sensitive thing), because Google's response header 'access-control-allow-origin' returns the origin domain rather than '*'.

[bummzack]

Some services return the Origin from the request in the access-control-allow-origin response header instead of just setting it to *. Therefore it is important to set the Origin for the request.
Headers are not case-sensitive by definition, so this is not the issue

[aradalvand]

I haven't tried setting the origin manually, but I'm not sure that's a solution

Well of course, it isn't, it should be set automatically, that's what #6608 is about.

For me, the expected behaviour would be that it shouldn't cause errors that don't exist when using the browser's fetch function.

You're exactly right.

But... I think the Origin header not getting forwarded is probably the actual issue here (not the case sensitive thing)

HTTP headers case-insensitive by specificaiton, so that can't be the problem.

[bothness]

Okay. I can confirm that this works in dev if I explicitly set the request origin header to "http://localhost:5173", so the SK fetch function not passing/accounting for the origin header seems to be the source of the bug I'm experiencing also.

[elliott-with-the-longest-name-on-github]

Closing this in favor of #6608 since they're both the same root cause.