Can an HTTP OPTIONS request return a 204 or should it always return 200?

Question

According to https://www.rfc-editor.org/rfc/rfc9110.html#name-options the only response ever mentioned regarding an HTTP OPTIONS request is a 200. However, there seem to be cases such as when the content-length is 0 that a 204 would be more appropriate. Is it appropriate for an HTTP OPTIONS request to return a 204?

Silvie

As far as what the proper status code is for responses to the CORS preflight OPTIONS request, see the answer at #46026909. The gist of it is, you can return a 204 for that if you want, but with regard to the CORS protocol, browsers don’t care if it’s a 200, 204 or some other 2xx response — anything in the 200 to 299 range is treated exactly the same as far as CORS-protocol handling by browsers. – Denationalize

Answer 1

Yes, it can return 204. Or 400. Or 404. There is no general restriction as to what status codes a method can return.

Also note that it's time to stop looking at RFC 2616. See https://httpwg.org/.

Legend

Presumably the second, "Or 400", should be, "Or 404" (or something else non-400). – Resistencia

What do you think of the other answer here? Though it seems in practice browsers are "OK" with 204 FWIW...de facto standard, for the win! :) – Wendeline

@Wendeline I thought the same thing, but we've just had to make the change from 204 to 200 in an app due to Firefox being strict about the Content-Length header missing, so it's not true today that "in practice browsers are "OK" with 204"! So the other answer by amichair is correct, while this one is incorrect. – Binoculars

@Wendeline - fwiw, the answer isn't incorrect just because some browser doesn't implement HTTP correctly. If you believe you found a browser bug, you should open a ticket. – Legend

The link seems to be outdated – Pico

Answer 2

RFC 2616 says:

A 200 response SHOULD...

...

If no response body is included, the response MUST include a Content-Length field with a field-value of "0".

which indeed makes it unclear whether the 200 applies to the whole paragraph or only the first sentence. If you wanted to play it safe, you'd let the MUST take precedence (and it wouldn't cost you much).

RFC 7231, which obsoletes RFC 2616, changed the wording to

A server generating a successful response to OPTIONS SHOULD...

...

A server MUST generate a Content-Length field with a value of "0" if no payload body is to be sent in the response.

which makes the last sentence apply in the general sense to 2xx statuses, and the MUST prevails.

So, Content-Length MUST be sent. But a Content-Length cannot be sent with a 204:

RFC 2616 says it like so:

The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field...

... All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a message-body.

And RFC 7230 clarifies this as well:

A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content).

That's how I understand it, anyway.

Cummings

The OPTIONS should always return 2xx code otherwise 1. there is no Content-Length in the response 2. your preflight request fails and you are unable (for example) PUT new files into webdav Unfortunately, nginx and lighttpd has it wrong today and I am despair to find a good substitute for them. – Tussore

Answer 3

Within the existing language, the only resolution to the apparent contradiction between RFC 7230 §3.3.2 Content-Length:

“A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content).”

and RFC 7231 §4.3.7 OPTIONS:

“A server MUST generate a Content-Length field with a value of "0" if no payload body is to be sent in the response.”

is to disallow all 204 responses to OPTIONS requests. Because this does not seem to have been the intention, I submitted an erratum report. The latter statement was removed from RFC 7231 in draft-ietf-httpbis-semantics-06, now published as RFC 9110, so a 204 response (without a Content-Length field) is now unambiguously allowed.

Wortman

Woo, nice work! – Pico

Answer 4

Ideally 200 is for success and response details and 204 is success with out any response.

e.g. get employee e1 : 200 with Employee details on response get employee e2 : 204 with out Employee details on response

Rouault