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 22:33:42 +0100
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: ietf-http-wg@w3.org, Joe Orton <joe@manyfish.co.uk>, Joris Dobbelsteen <joris.dobbelsteen@mail.com>
Message-ID: <20040919213342.GD28786@mail.shareable.org>

Roy T. Fielding wrote:
> 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.

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.

> >The important thing is, are there any servers which send 205 responses
> >and if so, what do they send?
> 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.

> >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.
> Only if the proxy had pipelined requests from different clients
> 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.

> 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).

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
Received on Sunday, 19 September 2004 21:33:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:35 GMT