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

Re: [#95] Multiple Content-Lengths

From: Adrien de Croy <adrien@qbik.com>
Date: Thu, 10 Mar 2011 13:40:28 +1300
Message-ID: <4D781DFC.4000708@qbik.com>
To: Willy Tarreau <w@1wt.eu>
CC: HTTP Working Group <ietf-http-wg@w3.org>

On 10/03/2011 12:10 p.m., Willy Tarreau wrote:
> On Thu, Mar 10, 2011 at 11:55:31AM +1300, Adrien de Croy wrote:
>> What should a proxy do?  It has the task of putting something together
>> to send a client.
>> it seems to me the only safe option is a.  It's also the only option
>> that provides any incentive for people to fix their sites.
> The problem is that it does not work. When you go deploying your
> appliance at a large customer and some applications don't work
> behind it, whatever the bugs on the applications, the customer
> only says your appliance does not work while many other products
> do work there. That's why we got so many diverging workarounds
> for many issues. Everything that is declared illegal will still
> be done in a random way :-/

There's another way to look at it.  If all software bounced the invalid 
response, the problems would soon be fixed.

So, there are some vendors that would choose to bounce, and some would not.

Those that do not may be opening themselves up to security 
vulnerabilities or other problems.

As a vendor of a product that bounces it, you could then argue that your 
software was more secure.  In my experience, bank IT managers are among 
the more security-conscious of customers.

If all the C-L values are the same, it's perhaps not so dangerous to 
strip duplicates, but otherwise choosing the smallest value may result 
in truncation of the entity, and choosing the biggest may result in 
response smuggling.  There's no way of knowing at the time you need to 
formulate a response for a waiting client.  If it's an attempted 
smuggle, it could possibly be detected by looking for something like a 
response at the offset specified by the smallest C-L value.  But if a 
proxy has already sent the larger C-L value on to the client it's 
hosed.  Likewise if the proxy sends the smaller C-L value on to the 
client and the resource keeps coming.

So maybe we need to take a tougher stance.

In the end, we're talking about the spec here.  People sending multiple 
C-Ls are already ignoring the spec.  People who want to not bounce 
multiple C-Ls could likewise ignore the spec.  The spec however should 
be clear on what should happen - what we want as a community the 
direction to be. Otherwise it seems like a slippery slope.



> I even have one example. I had haproxy deployed at a bank and which
> was blocking a few invalid responses which contained a header named
> "Content/type". Guess what ? They disabled HTTP processing and only
> used TCP until I was able to provide an option with a scary name to
> relax the header parser, because fixing the app was expected to take
> 6 months (and it did take more).
> I'd really like that standards propose hints for how to handle
> exceptions when there's no alternative, without creating vulnerabilities
> and without having all products behave differently.
> Content smuggling exists precisely because everyone had to find a
> different solution to an issue that was not considered something
> that had to be handled at one point.
> Regards,
> Willy
Received on Thursday, 10 March 2011 00:41:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:56 UTC