- 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
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 message. 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 applies. 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