Method Options - HTTP

[RogerioBorba]

Describe the problem

I didn't see the Options method for building APIs. Is it possible to have it?

Describe the proposed solution

It is important to query the server capacity and the Options method, it provides for us

Alternatives considered

No response

Importance

would make my life easier

Additional Information

No response

[rmunn]

In addition to the OPTIONS method, HTTP also defines CONNECT and TRACE. TRACE means "please send my request back to me", and if it's going to be handled at all, should be handled by Svelte-Kit itself rather than by page endpoints. CONNECT means "please open a connection to this remote destination and then forward packets for me" and should only be implemented by proxies with appropriate security, and not by Svelte-Kit.

Which leaves only OPTIONS, which could indeed be useful for Svelte-Kit projects that are implementing APIs, and should be added. Currently the node-adapter handles OPTIONS requests and doesn't pass them on to the site. Repro:

• Create a brand-new Svelte-Kit project with the demo app and Typescript
• Create src/routes/something.ts containing the following:

import type { RequestHandler } from './__types';

export const get: RequestHandler = async ({ locals }) => {
    return { status: 200, body: 'get' }
}

export const options: RequestHandler = async ({ locals }) => {
    return { status: 200, body: 'options' }}

• Run pnpm run dev
• Run curl -D - http://localhost:3000/something to verify that the GET method works (and prints "get")
• Run curl -D - -X OPTIONS http://localhost:3000/something and see that the response comes from Svelte-Kit's server, not the options method you just defined in something.ts
• Run curl -D - -X OPTIONS http://localhost:3000/about and see that you get the same response

[tsriram]

I'd like to give this a shot

[tsriram]

I'm still figuring this out. Wonder if #5748 has any impact?

Would appreciate if someone could give some pointers on where to fix this.

[cleaton]

Has there been any discussion around adding a generic “onRequest” function instead of splitting one function per HTTP method? That would also add compatibility with fetch based api frameworks like trpc and similar.

[MohamedElshazly]

Any workaround to access the options request?