W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

Re: clarify some MUST requirements in HTTPbis part 1 section 3.3

From: Willy Tarreau <w@1wt.eu>
Date: Fri, 2 Dec 2011 00:14:57 +0100
To: Patrick McManus <mcmanus@ducksong.com>
Cc: ietf-http-wg@w3.org
Message-ID: <20111201231457.GA22493@1wt.eu>
Hi Patrick,

On Thu, Dec 01, 2011 at 05:32:46PM -0500, Patrick McManus wrote:
> On Thu, 2011-12-01 at 09:17 -0700, Alex Rousskov wrote:
> 
> > Absolutely, but the question paused by this thread remains: Are proxies
> > _required_ to fix messages they forward?
> 
> proxies are clients, and I'd like to think the spec aspires to requiring
> all clients to send well formed messages. so I would favor mandatory
> cleanup.

I see it from a different angle. In my opinion, proxies are not client
in that they don't author requests but forward what they understood from
what they received. It's much easier to be a clean sender when you're a
client than when you're a proxy. If we brought the multiple content-length
issue here, it's precisely because proxies were facing it. There are many
situations where proxies are expected to perform some cleanup based on
protocol compliance, and expected to act differently based on client or
server bugs that end-users expect them to ignore.

I have a recent example. About 2 months ago, I got a report that a haproxy
user was sometimes seeing haproxy reject bad requests. Upon investigation,
it appeared that a buggy client software was cumulating headers between
each request to the point where some headers were sent 37 times before
being blocked due to too large a request. Very few users reached this
limit and were affected. Fortunately for them, haproxy is not able to
fold multiple headers when forwarding, otherwise they would have come to
a complete stop because the server-side software's parser was unable to
handle a comma in the affected header.

I'm not saying that it's better not to fix, and in other circumstances,
the opposite could have been true. I'm just saying that in this specific
case it was fortunate that the forwarded stream was as little mangled as
possible. My principle has always been to strictly control inputs, then
don't touch what you don't absolutely need to. From my experience, it
has always resulted in the least breakage.

However, just like a client, a proxy which is adding or mangling headers
has absolutely no excuse for emitting them in a wrong format.

Regards,
Willy
Received on Thursday, 1 December 2011 23:15:31 GMT

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