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: Adrien de Croy <adrien@qbik.com>
Date: Fri, 02 Dec 2011 14:40:28 +1300
Message-ID: <4ED82C8C.4030808@qbik.com>
To: Willy Tarreau <w@1wt.eu>
CC: Patrick McManus <mcmanus@ducksong.com>, ietf-http-wg@w3.org

we're talking here about the specification for HTTP and Content-Length

I don't see how we can write prose into HTTP that permits any agent to 
send more than one Content-Length header under any circumstances and 
still be compliant with the spec, no matter what you call the software 
that does it or how it operates.

Adrien


On 2/12/2011 12:14 p.m., Willy Tarreau wrote:
> 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
>
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/
Received on Friday, 2 December 2011 01:41:03 GMT

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