HEAD reported as an invalid request handler

[poppa]

Describe the bug

VS Code is reporting exporting a HEAD request handler with the following error:

Invalid export 'HEAD' (valid exports are prerender, trailingSlash, config, GET, POST, PUT, PATCH, DELETE, OPTIONS, or anything with a '_' prefix)ts(71001)

The HEAD handler is properly called when a HEAD request is issued, and svelte-check doesn't complain about it either, so my guess is that this is an error related to the language tools.

I also noted that HEAD is not listed as a valid verb at the documentation (https://kit.svelte.dev/docs/routing#server)

Reproduction

export const HEAD = (() => new Response(null, { status: 200 })) satisfies RequestHandler

Expected behaviour

I don't expect an error here

System Info

• Svelte v3.57.0
• SvelteKit v1.13
• Svelte Check v3.1.4
• Svelte for VS Code v107.2.5
• VSCode
  Version: 1.76.2
  Commit: ee2b180d582a7f601fa6ecfdad8d9fd269ab1884
  Date: 2023-03-14T17:54:09.061Z
  Electron: 19.1.11
  Chromium: 102.0.5005.196
  Node.js: 16.14.2
  V8: 10.2.154.26-electron.0
  OS: Darwin x64 22.1.0
  Sandboxed: Yes

Which package is the issue about?

Svelte for VS Code extension

Additional Information, eg. Screenshots

No response

[dummdidumm]

The error is correct, HEAD is not a valid export. During build or when it's invoked during dev you'll also see that SvelteKit throws an error saying that HEAD is not a valid export.

[poppa]

No, it doesn't throw an error during build, nor when invoked during dev.

[dummdidumm]

If I create a src/routes/foo/+server.js with a HEAD in it and then visit localhost:../foo I see the error message inside the terminal where I started the dev server.

[poppa]

Hm, I created a new route where I get the same behaviour. My old route still works though, which is super-concerning!

Well, I guess this can be labelled as a bug in SvelteKit then, so I'm perfectly fine with this issue being closed.

[dummdidumm]

Transfering to the SvelteKit - it shouldn't happen that HEAD is somehow called IMO. Could you provide a minimum reproducible where HEAD is called?

[poppa]

Then the question is: Why isn't HEAD a valid request handler?

(this issue discusses the HEAD verb as if nothing strange about it?!: #9164)

[eltigerchino]

it shouldn't happen that HEAD is somehow called IMO

The current logic seems to allow for any exported endpoint to be called as long as it matches the request method name.
All the checks are bypassed.

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

Lines 11 to 22 in c0612a8

	export async function render_endpoint(event, mod, state) {
	const method = /** @type {import('types').HttpMethod} */ (event.request.method);
	let handler = mod[method];
	if (!handler && method === 'HEAD') {
	handler = mod.GET;
	}
	if (!handler) {
	return method_not_allowed(mod, method);
	}

I think the exported endpoint is only validated when a +page co-exists with the +server.js file.

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

Lines 366 to 367 in c0612a8

	} else if (route.endpoint && (!route.page || is_endpoint_request(event))) {
	response = await render_endpoint(event, await route.endpoint(), state);

and even then it seems as if it would return true in most cases after negotiating the content type

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

Lines 72 to 86 in c0612a8

	export function is_endpoint_request(event) {
	const { method, headers } = event.request;
	if (method === 'PUT' || method === 'PATCH' || method === 'DELETE' || method === 'OPTIONS') {
	// These methods exist exclusively for endpoints
	return true;
	}
	// use:enhance uses a custom header to disambiguate
	if (method === 'POST' && headers.get('x-sveltekit-action') === 'true') return false;
	// GET/POST requests may be for endpoints or pages. We prefer endpoints if this isn't a text/html request
	const accept = event.request.headers.get('accept') ?? '*/*';
	return negotiate(accept, ['*', 'text/html']) !== 'text/html';
	}

[dummdidumm]

Giving this the enhancement label - I think we should add official support for having a HEAD export in +server.js