The gist of it is, just use
A little more generally: You should just send back the same status code for the CORS preflight
OPTIONS request that you’d send back for any other
OPTIONS request. The relevant specs don’t require or recommend anything more than that.
What the specs say: The Fetch spec at https://fetch.spec.whatwg.org/ is where requirements for the CORS protocol are defined, and it says the status can be anything in the range
That’s from the CORS-preflight fetch algorithm, in a step saying it can be any “ok status”:
If a CORS check for request and response returns success and response’s status is
an ok status, run these substeps: …
And as far as what an “ok status” is, the spec says this:
An ok status is any status in the range
Beyond that though, the Fetch spec doesn’t recommend any particular status within
The other relevant spec here is the HTTP 1.1 spec, which has a section defining semantics of all HTTP response status codes, and within that, a section that defines Successful 2xx codes.
And within that section there’s a specific section for 200 OK, which says this:
The 200 (OK) status code indicates that the request has succeeded.
The payload sent in a 200 response depends on the request method.
For the methods defined by this specification, the intended meaning
of the payload can be summarized as:
OPTIONS a representation of the communications options;
So a response to a CORS preflight OPTIONS just needs to be:
- an indication that the request has succeeded
- a representation of the communication options (which in this case includes the
200 OK is defined by the HTTP spec to be, so you can stop right there.
But if you read through the rest of the
2xx codes in that section, you can confirm the semantics of none of them make sense for an
OPTIONS response—except for
204 No Content.
Now as far as
204 No Content goes, there’s nothing wrong with using it for
OPTIONS responses—but there’s also not really any point. That’s because:
- unlike for some other methods, the HTTP spec defines no use for an
- therefore in practice, clients don’t expect any payload (content) to come back for an
OPTIONS(and wouldn’t do anything with any payload that did come back)
…so there’s no practical purpose in using a specific
204 status code in an
OPTIONS response to explicitly tell clients there’s no payload.
Should the status code be different in case origin is allowed (and corresponding headers will be set) or not allowed (and CORS headers will not be set or will not match the origin)?
No. There’s no standard-defined code other than
204 you could use anyway—but regardless of that, the specs don’t require it to be any different and don’t define any different use if it is. And think about it: What is any existing client code going to do any differently due to any difference in the status codes for those two cases?
If the answer to that is, “Nothing”, then there’s no point in making it different.
Given all the above, the bottom line is: just send
200 OK for CORS preflight
OPTIONS responses. Sending any code other than just
200 OK isn’t necessary or useful.