Support plan

Community

• is this issue currently blocking your project? (yes/no): no
• is this issue affecting a production system? (yes/no): no

Context

• node version: v12+
• module version: v19+
• environment (e.g. node, browser, native): node
• used with (e.g. hapi application, another framework, standalone, ...): hapi application
• any other relevant information: PR fix(cors): emptyStatusCode not being taken into account for OPTIONS requests #4024 was originally opened to address the same underlying issue.

What problem are you trying to solve?

Users would like to be able to control the status code used to respond to CORS preflights. Currently the only way to do this is to configure the global server setting routes.response.emptyStatusCode. This has two drawbacks:

1. It is not necessarily desirable to couple the response code of preflights with the empty response code used by other endpoints. One reason for this is that browser quirks over time have shifted what an ideal preflight response code should be (200 vs 204). The client for preflights is the browser, and the client for other endpoints is likely the user's application.
2. It is not possible to configure this on a per-route basis. The main downside here is that it is confusing that routes.response.emptyStatusCode configured on the server takes effect, but the analogous route-level setting options.response.emptyStatusCode does not.

Do you have a new or modified API suggestion to solve the problem?

In order to address both points above my recommendation is to introduce a new route option cors.preflightStatusCode to control the preflight status code, which is respected both by global server settings and on a per-route basis. This would be a breaking change, as users are currently using the global routes.response.emptyStatusCode setting to control this, a workaround provided by @kanongil in #4024. I propose the two be totally decoupled, however there are backwards-compatible ways to introduce this feature prior to decoupling the two options.