Skip to content

OPTIONS requests always return hardcoded CORS headers, breaking PATCH preflight #5356

@AlessioBernesco-REG

Description

@AlessioBernesco-REG

Current Behavior

All HTTP requests sent to "http in" endpoints with the OPTIONS method are intercepted and always return the following generic CORS headers:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,PUT,POST,DELETE

This behavior breaks CORS handling for PATCH requests: when the browser performs the preflight check, the response does not include "PATCH" in the allowed methods, causing the request to fail.

All other HTTP methods (GET, POST, PUT, DELETE) correctly return the methods configured in httpNodeCors inside settings.js.

Expected Behavior

The OPTIONS handler should respect the configuration provided in httpNodeCors and return all allowed methods, including "PATCH" if it is defined.

No hardcoded CORS headers should override or bypass the user-defined CORS configuration.

Preflight requests should succeed whenever the configured CORS rules allow the incoming method.

Steps To Reproduce

Use any HTTP client (e.g., Postman, curl, or a browser) to call an http in endpoint with a standard method (GET, POST, PUT, DELETE, PATCH).
The CORS response reflects the configuration defined in httpNodeCors.

Make a request to the same endpoint using the OPTIONS method (typically triggered by browsers during CORS preflight).
The response returns a hardcoded CORS configuration:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,PUT,POST,DELETE

Notice that "PATCH" is missing from the allowed methods, even if it is configured in httpNodeCors.

Example flow

paste your flow here

Environment

  • Node-RED version: latest

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions