OPTIONS http calls trigger loader functions

[arackaf]

Describe the bug

This is a tricky one to explain.

When you push commits to non-Main branches, Vercel creates deployments off of those branches. When you run those deployments, for some reason there's a network request fired off on all requests (as far as I can tell) with the http verb OPTIONS. This happens only with non-main (ie feature branch) deployments, not with the main deployment off of Master (Main).

When these OPTIONS requests happen, the loader functions run. @Rich-Harris tells me the loaders should not run under these circumstances, and asked me to repro. Here's the repro. (whether the OPTIONS request itself is supposed to happen at all I'm still not clear on).

This is a straight clone of the default SvelteKit project. I added a shared loader to the root page (and shut off prerender).

https://github.com/arackaf/sveltekit-options-loader-bug

After deploying to Vercel, and then pushing to some non-Main branch, opening that deployment, and then looking at the logs, I see those OPTIONS requests, and logging happening from the loader on them.

Reproduction

See above

Logs

See above

System Info

System:
    OS: macOS 13.2.1
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
    Memory: 33.35 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
    npm: 8.18.0 - ~/Documents/node_modules/.bin/npm
  Browsers:
    Chrome: 110.0.5481.177
    Firefox: 110.0
  npmPackages:
    @sveltejs/adapter-auto: ^2.0.0 => 2.0.0 
    @sveltejs/kit: ^1.5.0 => 1.8.5 
    svelte: ^3.54.0 => 3.55.1 
    vite: ^4.0.0 => 4.1.4

Severity

annoyance

Additional Information

No response

[Rich-Harris]

This isn't specific to OPTIONS requests — it turns out we're erroneously allowing all methods for pages. It's unusual enough behaviour that it managed to evade our issue tracker and test suite thus far, but it's definitely a bug.

For DELETE, PATCH etc we should be able to respond with a 405 with the appropriate Allow header (we currently do this for API routes, although incorrectly: we don't handle the case where an API route doesn't expose a GET or POST handler but has a sibling page, meaning our Allow header erroneously omits GET and — if the page has actions — POST).

For OPTIONS the correct response would be a 204, though that's insufficient for preflight requests. Automatically constructing those responses would be a departure from #8731, where we decided to leave it up to users. @Conduitry and @s3812497 might have thoughts on the most appropriate course of action.

[arackaf]

@Rich-Harris can you lend any clarity as to why Vercel's feature branch deployments are making these OPTIONS calls, but not the main deployment (even when run on the auto-generated, similar Vercel domain)

[eltigerchino]

I think any http method not exported in +server.js or covered by a page or form action should return a 405 Method not allowed and a list of currently allowed methods in the Allow header.

Alternatively, I've read that a 404 could be returned to hide allowed methods and reduce attack surface area.

[eltigerchino]

Created a reproducible here. Run npm run build && node build to test.
Entering anything as a request method will incorrectly return a 200 and the rendered page after pressing the test button and checking the browser inspector Network tab.

We could add a GET / HEAD / POST request method check before rendering the page to prevent the load function from always running. If it doesn't pass this check, we finally return a 405 or 404.

kit/packages/kit/src/runtime/server/respond.js

Lines 368 to 369 in c0612a8

	} else if (route.page) {
	response = await render_page(event, route.page, options, manifest, state, resolve_opts);

[dummdidumm]

@Rich-Harris can you lend any clarity as to why Vercel's feature branch deployments are making these OPTIONS calls, but not the main deployment (even when run on the auto-generated, similar Vercel domain)

I was scratching my head why this happens, too - turns out that OPTIONS request is coming from preview comments. I can't tell you why exactly though.