catch-all method for +server.js

[karimfromjordan]

Describe the problem

Astro's way of creating endpoints is almost identical to how it works in Svelte Kit (apart from the fact they use lowercase function names). But they also allow you to:

export an all function to match any method that doesn’t have a corresponding exported function.

See the Astro docs

I'm honestly not sure how niche this feature is but I found it to be very handy for building completely custom routing and APIs within the same SvelteKit Astro project without having to export multiple request handlers or running a separate Node server.

Describe the proposed solution

Add an ALL (or all?) request handler that does the same thing.

Alternatives considered

No response

Importance

nice to have

Additional Information

No response

[theetrain]

Allowing custom HTTP methods may help folks using SvelteKit as an API layer build and potentially generate docs for their APIs. Building docs (such as with Open API Schema) is solvable with community plugins, though I wonder if there's demand for custom HTTP methods such as those in the allowed method registry.

I'm unsure of the complexity, though since export async function POST () {} works today, then perhaps any named function can be compiled into allowed server methods, such as export async function LABEL () {} without SvelteKit having to maintain a growing list. It's neat how ALL helps cover these cases as well, and I understand if "custom methods" is out of scope of this ticket.

[Rich-Harris]

Yeah, this would be a good add — better than export const { GET, POST } = myAuthLibrary() etc. I prefer all to ALL since ALL isn't an HTTP verb (the main reason we're using uppercase, besides the fact that delete is a reserved word), though I'd be interested to hear other naming suggestions.

Alternatively we could use a default export:

export function GET() {...}
export function POST() {...}
export default function() {...}

[Conduitry]

What's our current handling of HEAD? Do we do anything special for that? (I think some libraries/frameworks/servers will, if there's no explicit HEAD handler, transparently turn it into a GET, and then drop the response body.) Is that a good idea? Do any of our serverless deployment targets already do something similar?

Does any of this change if we introduce a catch-all method?

[Rich-Harris]

I think some libraries/frameworks/servers will, if there's no explicit HEAD handler, transparently turn it into a GET, and then drop the response body.

Kit will use the GET handler if no HEAD is specified:

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

Lines 17 to 19 in b3c31a1

	if (!handler && method === 'HEAD') {
	handler = mod.GET;
	}

Though it doesn't actually discard the body — not sure if that's because it's unnecessary or because some code got deleted at some point. Feels like an oversight tbh.

I think catch-all should probably mean catch-all, i.e. Kit bails out of doing anything special on your behalf

[karimfromjordan]

Not sure which name would be really better (ALL, all, default) but I actually like the idea of just using the default export for this. It would match the naming convention of form actions too.

[dummdidumm]

Personally I despise default exports, so I would be in favor of all

[dominikg]

mixed named and default exports :close_snape:

+1 for a named export, not sure if i like "all" as the language doesn't make it clear which one gets called for a HEAD request it the case where GET and ALL are exported (imho HEAD should fall back to GET first and only if that does not exist use the generic fallback)

Maybe "other" or "fallback" works?

re. HEAD not disarding body when using GET. It's needed to be able to calculate content-length iirc, but the response won't return the actual body if method is HEAD.

[Conduitry]

the response won't return the actual body if method is HEAD

Where does this happen? In Node's HTTP libraries? In the Response implementation? Internally in each serverless platform someone might deploy to? I'd feel more comfortable if this happened somewhere we could see it, rather than relying on every platform to do it for us.

[dominikg]

the response won't return the actual body if method is HEAD

Where does this happen? In Node's HTTP libraries? In the Response implementation? Internally in each serverless platform someone might deploy to? I'd feel more comfortable if this happened somewhere we could see it, rather than relying on every platform to do it for us.

it used to happen (or rather not happen) inside kit itself but might have been lost in a refactoring. Currently trying to find it.

edit:

was added here 012850e#diff-7a5a1441a4765c525635c31466bc75c520fb481ec56d1606894270a73986ff86R100

still tested by this route https://github.com/sveltejs/kit/blob/master/packages/kit/test/apps/basics/src/routes/endpoint-output/body/%2Bserver.js
in this test https://github.com/sveltejs/kit/blob/master/packages/kit/test/apps/basics/test/server.test.js#L74