Subject: RE: "205" status code

From: "Joris Dobbelsteen" <[email-masked]>
Date: Sun, 19 Sep 2004 17:19:04 +0200

The 205 status MUST NOT contain a entity body and this includes NO
"content-length" and "transfer-encoding" headers.

Referencing RFC2616.
It is stated in 10.2.6 "205 Reset Content" as you described.

4.4 "Message Length"
Condition 1 states:
Any response message which "MUST NOT" include a message body (...) is
always terminated by the first empty line after the header fields,
regradless of the entity-header fields present in the message.

(...) gives examples of such responses, it does NOT specify them.

The behaviour of the Apache httpd proxy code conforms to the
specificion.

- Joris

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Joe Orton
>Sent: zondag, 19 september 2004 10:42
>To: [email-masked]
>Subject: "205" status code
>
>
>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?
>
>joe
>
>
>

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 19 Sep 2004 17:01:03 +0100

> (...) gives examples of such responses, it does NOT specify them.

4.3 "Message Body" DOES specify them completely:

   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.

Note, "ALL OTHER responses...".

Also if you look at the texts for 204, 304 and 205 responses, you see
that 204 and 304 say "MUST NOT include a message-body", whereas 205
says "MUST NOT include an entity".  204 and 304 go on to say that the
message is terminated at the first empty line, but 205 does not say
that.

It's clear that the text for 205 was added at a different time and
perhaps written by a different author.

The important thing is, are there any servers which send 205 responses
and if so, what do they send?

It's a potential security hole if Apache and some other proxies
disagree over where to parse 205 message boundaries, because a
malicious server could generate 205s with a message-body.
Disagreement among proxies over how to parse boundaries could result
in response headers from a different (non-malicious) server being
forwarded to the wrong client, in other words one malicious
client-server pair could trigger unwanted effects or gain access to
private information between another client-server pair, if both pairs
share a common path between two proxies which disagree over 205
message boundaries.

-- Jamie

---

From: Roy T. Fielding <[email-masked]>
Date: Sun, 19 Sep 2004 13:06:16 -0700

> perhaps written by a different author.

No.  Think about it a little.  There are existing status codes that
everyone knows about, and then there are extension codes that were
added later.  How are the existing, deployed systems going to know
about the semantics of 205 when they were deployed prior to its
definition?  They can't.  That is why there are exceptions for old,
pre-existing, abnormal status codes, and no other exceptions because
later extensions must be self-descriptive.

> and if so, what do they send?

If they don't send "Content-length: 0", they are broken.

> share a common path between two proxies which disagree over 205

Only if the proxy had pipelined requests from different clients
on the same connection, which is a pretty far-fetched theory.
It certainly isn't a security hole, since the HTTP messages are
already being sent in the clear over the Internet for anyone to see
(TLS/SSL connections are never shared).

....Roy

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 19 Sep 2004 22:33:42 +0100

> later extensions must be self-descriptive.

Good point.  I hadn't thought to look for 205 in the old RFCs.

You are absolutely correct, and Apache is absolutely BUGGY to treat
205 the same as 204.

> If they don't send "Content-length: 0", they are broken.

Or they can close the connection after the headers.
Or they're maliciously trying to break a proxy (see below).

A specification problem is that the language for 205 in RFC 2616 says
"The response MUST NOT include an entity", and technically that
doesn't mean anything: "Content-Length: 0" IS specifying a zero-length
entity-body, according to definitions earlier in the text.

Equally, "Transfer-Encoding: chunked" with a zero-length chunk is the
same.  Yet, using that would break with Apache's proxy.

We can see that the language is not as clear as it should be from the
simple fact that Apache interpreted it wrongly.

> on the same connection, which is a pretty far-fetched theory.

Why not?  That's how I would implement a proxy if I didn't know about
all these flaws, and I've not seen any standard which warns against it.

More to the point, it's how the obvious implementation of a proxy
works if it is written as a server forwarding requests to it's
internal generic client.  E.g. a CGI script doing what's necessary
with headers for a proxy, and calling libcurl's HTTP client.  Or an
ASP or .NET service calling it's generic client.  Such clients share
connections automatically between different requests.

> (TLS/SSL connections are never shared).

No, they may be sent over a private network or VPN where it is managed
so that nodes can only see traffic to/from themselves.  On such a
managed network, a malicious node on the network should still not be
able to access information that it can't see directly.

It's reasonable to assume that HTTP messages between independent
client/server pairs do not interfere, period, even when one of the
pairs is malicious.

Yet if there's a common path between two proxies, and a proxy chooses
to multiplex requests over a single connection to the other proxy (is
there any specified reason not to?), and there's any disagreement over
205 (in other words, one of the proxies is Apache), there is
interference that shouldn't occur.

(Also, while TLS/SSL connections aren't shared, if a single client
(e.g. Mozilla or JVM) contains multiple "sandboxed" applications
(e.g. applets and Javascript) accessing resources over TLS/SSL, I bet
some of those clients forward requests from separate sandboxes over
common connections.  It's the same problem within a complex client,
but caused by a bug in the downstream (Apache) proxy not the client).

To summarise: this is an Apache bug, and a potential security weakness
if Apache is used as a proxy in conjunction with another proxy in some
obscure scenarios.  Simple solution: Apache's bug should be fixed,
then we can forget about it.

-- Jamie