- From: Adrien de Croy <adrien@qbik.com>
- Date: Thu, 10 Mar 2011 13:40:28 +1300
- 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. Regards Adrien > 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