response from OPTIONS returns 204 status code by default

[lnfel]

elysia: 0.7.12
nodejs: 18.14
@bogeychan/elysia-polyfills: 0.6.1
browser: Google Chrome Version 116.0.5845.187 (Official Build) (x86_64)

Reading MDN docs about OPTIONS gives an example that uses 204 as the response status code, other browser implementations expect OPTIONS response to return status code of ok or 200 as mentioned in the same document.

Furthermore RFC9110 section 15.3.1 states that a response status code of 200 can be used for OPTIONS response. With that said a CORS error pops up when using default elysia-cors options.

import { Elysia } from 'elysia'

const routes = new Elysia()
  .use(cors())
  .post('/test', async ({ body }) => {
    console.log(body)
    return {}
  })

When sending a post request to /test, the browser receives a response status of 204 and decides to block the request due to CORS policy:

Access to XMLHttpRequest at 'https://api.website.com/test' from origin 'https://app.website.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status.

Also receives a TypeError:

TypeError: Response constructor: Invalid response status code 204
-- at webidl.errors.exception (node:internal/deps/undici/undici:1265:14)
-- at initializeResponse (node:internal/deps/undici/undici:6845:31)
-- at new Response (node:internal/deps/undici/undici:6654:9)

There's a work around with this by using Elysia instance's .options method:

import { Elysia } from 'elysia'

const routes = new Elysia()
  .use(cors())
  .options('/test', ({ set }) => {
    set.status = "OK"
  })
  .post('/test', async ({ body }) => {
    console.log(body)
    return {}
  })

It works but it is quite cumbersome. What do you guys think? Perhaps we should we default to status 200 instead.

[rhkdgns95]

Hi
I also had the same cors problem as you, so I left an issue.

elysiajs/elysia#184 (comment)

For method options, a header value must be returned along with code 204.

[lnfel]

From what I experienced, elysia cors removes Access-Control-Allow-Headers whenever schema validation returns error against the payload sent. If validation is successful, then the headers will be present but elysia cors will return 204 status code which Google Chrome does not like, hence the error. The browser expect a 200 status code response from preflight response. It won't matter even if we add the headers manually if the code is 204 because chrome does not find it acceptable.

[dodas]

+1
The preflight request should be responded to with status 200 instead of 204, which Chrome will reject.