httphttp-headersstring

How to interpret empty HTTP Accept header?

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

It's syntax is given like this:

   Accept         = "Accept" ":"
                    #( media-range [ accept-params ] )

# without any number states zero or more according to section 2.1. However, section 14.1 doesn't make any statement about how to interpret an empty Accept header. This is in contrast to section 14.2, which talks about Accept-Encoding, where not only 1# is used (one or more), but also the case for an empty Accept-Encoding header is specified, which is kind of weird. Some other sections dealing with request headers are also specific on the special case of an empty value.

Should one treat an empty Accept header equivalently to a non-existent Accept header? Are there any official resources on this I missed?

Solution

  • 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:

    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.