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

Re: HTTPbis -10 drafts published : Connection header

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 15 Jul 2010 21:33:06 +0200
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Adrien de Croy <adrien@qbik.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20100715193306.GS2717@1wt.eu>
On Thu, Jul 15, 2010 at 12:05:12PM -0700, Roy T. Fielding wrote:
> > And that leaves the question open about what to do if those
> > headers are found. The worst cases I thought about (Host,
> > Content-Length) don't work with Apache at least, but they
> > may cause real trouble on proxies which blindly apply the
> > spec.
> 
> They should not cause any problems, at least no more so than
> receiving invalid messages.  If the software can't handle weird
> things then it doesn't belong on the Internet.

It's not that simple. I have an example of a customer who uses front
Apache reverse-proxies to perform security controls and to only
let "clean" requests pass through. Those Apaches also add some
headers to the requests being forwarded to the servers for logging
purposes, and it is the only way to reach the servers. Due to that
implementation mistake, it is possible (and I've tested) for the
client to make the reverse proxy remove those headers it had just
added, so that the end point finally does not get the information
it should have unconditionally got.

Now, if we want to be fair, there are two points here which are
causing that issue :

  - apache's header removal does not happen in the appropriate
    order.

  - apache is used as a reverse-proxy (and is often used that
    way) but it follows a proxy behaviour instead of a gateway
    behaviour. But I suspect that when they began, the difference
    was not clear yet between the two.

> We don't need to protect implementations from their own stupidity.

I'd not call that stupidity. The spec is huge and very complete,
and as such it's not easy to get it right first, especially since
some information are spread all over it (eg: "all other headers
defined by HTTP/1.1"). It's got *a lot* better since RFC2616, but
still it's sometimes hard to know whether your implementation is
compliant or not, depending how a paragraph is read, and I have a
lot of respect for the persons who spend time trying to follow it
as closely as possible.

Well, maybe those could be some points to add to a separate draft to
try to improve the robustness of new implementations by suggesting
how to handle a bunch of corner cases.

Regards,
Willy
Received on Thursday, 15 July 2010 19:33:44 GMT

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