How to interpret empty HTTP Accept header?

Question

The HTTP/1.1 Accept request header is specified in RFC 2616, section 14.1.

It\'s syntax is given like this:

   Accept         = \"Accept         


        

Answer 1

From RFC2616 Sec4.2:

Each header field consists of a name followed by a colon (":") and the field value.

At first glance, this would seem to put messages that specify empty header values in the malformed, non-compliant category. However, the augmented BNF form outlined in RFC2616 Sec2.1 indicates that

"#element" allows any number, including zero

As this is the declaration used to specify Accept header values, it appears that empty values are valid.

Parsing empty headers and headers with nothing but whitespace can be problematic because of the following direction from the spec:

The field-content does not include any leading or trailing LWS: linear white space occurring before the first non-whitespace character of the field-value or after the last non-whitespace character of the field-value. Such leading or trailing LWS MAY be removed without changing the semantics of the field value. Any LWS that occurs between field-content MAY be replaced with a single SP before interpreting the field value or forwarding the message downstream.

IMHO, sending an empty header is completely pointless. It shouldn't be done, and parsers may not correctly parse these headers. Traditionally, people who want to circumvent such limitations when dealing with non-compliant components have specified "pseudo-empty" values like this:

X-MyCustomHeader: ""

If you simply want to validate that a header field was sent as some form of boolean switch, consider sending a placeholder value like the above instead of an empty value.

---

Update

I guess I wasn't very clear in directly answering the question: in the case of an empty Accept header you really have two options:

• Send a 406 Not Acceptable response to inform the client that you don't offer any content types for an empty Accept value (duh).

This is justified, but not required by RFC2616 Sec14.1:

If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response.

• Or, because this is not required and it's highly unlikely the user doesn't accept any content-types (otherwise, why would they bother to send the request?) ... I would suggest treating an empty Accept: value (if message rejection isn't an option) the same as Accept: */*.

Answer 2

According to http://tools.ietf.org/html/rfc7231#section-5.3.2:

A request without any Accept header field implies that the user agent will accept any media type in response.

You should treat a non-existent Accept header as */*.