The gist of it is, just use 200.
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.
As far the relevant specs: 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 200-299.
That’s from the CORS-preflight fetch algorithm, which has 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 200 to 299, inclusive.
Beyond that though, the Fetch spec doesn’t recommend any particular status within 200-299.
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 specific 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:
That’s what 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 as far as I can see, there’s also not really any point. That’s because:
- unlike for some other methods, the HTTP spec defines no use for an
OPTIONS payload
- 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 as far as I can see there’s no practical purpose in using a specific 204 status code in an OPTIONS response to explicitly tell clients there’s no payload.
It’s possible I could be wrong, though, and there’s some nuance I’m missing. But I don’t think so.
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, I don’t think it should be different. I don’t know what standard-defined code other than 200 or 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 question is, “Nothing”, as far as I can see 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.
