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

Question

According to http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2 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?

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 http://trac.tools.ietf.org/wg/httpbis/trac/wiki.

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.

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, so a 204 response (without a Content-Length field) is now unambiguously allowed.