W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2004

Re: "205" status code

From: Jamie Lokier <jamie@shareable.org>
Date: Sun, 19 Sep 2004 16:46:49 +0100
To: Joe Orton <joe@manyfish.co.uk>
Cc: ietf-http-wg@w3.org
Message-ID: <20040919154649.GA24675@mail.shareable.org>

Joe Orton wrote:
> The section on the 205 status code text includes the text:
>     "The response MUST NOT include an entity"
> The Apache httpd proxy code treats 205 like 204 or 304: implicitly no
> message body, regardless of any Content-Length/Transfer-Encoding headers
> sent. 
> It wasn't entirely clear whether this was correct from 2616: neither
> section 4.3 or 4.4 mentions 205 alongside 1xx, 204 and 304 as responses.
> Can anyone clarify?

For 204 and 304, it says

    the 204[304] response MUST NOT include[contain] a message-body,
    and thus is always terminated by the first empty line after the
    header fields.

For 205, it says

    The response MUST NOT include an entity.

Spot the difference?  (Message-body vs. entity).

Section 4.3 is quite precise:

   All 1xx (informational), 204 (no content), and 304 (not modified)
   responses MUST NOT include a message-body.  All other responses do
   include a message-body, although it MAY be of zero length.

Section 4.4 is less precise (it says "such as"):

   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,

If we assume that there aren't any errors in RFC 2616 (ha! :) then
it's clear that the 205 response DOES include a message body, of
possibly zero length, and it MUST NOT include an entity.

Whatever that means.

Just when you thought "message-body" and "entity" might be slightly
different things, section 7 introduces "entity-body":

   An entity-body is only present in a message when a message-body is
   present, as described in section 4.3. The entity-body is obtained
   from the message-body by decoding any Transfer-Encoding that might
   have been applied to ensure safe and proper transfer of the

All I can conclude is that if a server generates a 205 response, the
only _safe_ thing for it to do is include "Content-Length: 0" in the
headers and certainly not any transfer-encoding, or to close the
connection after that respones.  That way, the message is parsed
correctly regardless of which interpretation the client or proxy

For Apache, I think it shouldn't treat 205 the same as 1xx, 204 and
304.  That's because it should never see a 205 response that requires
that logic: a 205 MUST NOT include headers indicating an entity.  That
is different from  204 and 304, which may include those headers.

Therefore if Apache or any other proxy _did_ see a 205 response which
had headers indicating a non-zero content-length or a
transfer-encoding, then it indicates the server is not compliant with
RFC 2616, but most importantly, it indicates the following octets are
a message-body and not the headers of a following pipelined respones.
To parse the message boundary in that case

My conclusion: it should not treat 205 specially the way it treats 204
and 304, unless it is required as a workaround for some known buggy
server.  Treating 205 specially causes no harm for compliant servers,
though - it makes no difference how 205 is treated from a compliant
server - so it is not a serious fault.

There is a serious fault, however: if Apache's proxy is forwarding 205
responses which _might_ have non-zero content-length or
transfer-encoding, without a message-body, triggered by a
non-compliant server, then it is _generating_ non-compliant messages
in the client direction whose boundaries may be mis-parsed by the
client.  That's a potential security hole because it violates message
separation from potentially different sources.

-- Jamie
Received on Sunday, 19 September 2004 15:46:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:25 UTC