Is an HTTP application that sends a Content-Length or Transfer-Encoding with a 204 No Content response broken?

Question

I can't tell from RFC 2616 whether an HTTP client should accept a 204 No Content response that includes Content-Length: 0 or Transfer-Encoding: chunked headers. These headers seem to break some HTTP clients and proxies, which apparently attempt to read the empty response body, but the spec reads:

1. Any response message which "MUST NOT" include a message-body (such as the 1xx, 204, and 304 responses and any response to a HEAD request) is always terminated by the first empty line after the header fields, regardless of the entity-header fields present in the message.

To me "regardless of the entity-header fields" implies that clients should tolerate this state of affairs. The Erlang HTTP library chose this interpretation. However, lighthttpd and IBM chose the opposite interpretation -- that the server should not include these headers for responses that are prohibited from having bodies.

So should the web application remove those headers from the response, or should the network infrastructure and clients tolerate those headers on 204 No Content, 304 Not Modified, etc. ?

Indebted

Answer 1

According to the RFC7230 (please see https://www.rfc-editor.org/rfc/rfc7230#section-3.3.1) at the end of Page 29 it states:

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

Therefore the web application should not send those headers with the response.

Hypogeal

Nice -- six years on, you've got the correct answer! – Indebted

Answer 2

I can't tell you what is correct, in that I don't know the HTTP protocol in that detail.

However, you got to ask yourself:

1. Can I change my application to remove those headers?
2. or can I change the consumers of my application to ignore those headers?

In my opinion, the application should not send those headers in that case.

Reveal