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

Re: P1: Content-Length SHOULD be sent

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Tue, 27 Nov 2012 10:34:19 -0500
Message-ID: <CAMm+LwgmGYvViiev4H=-DgvyGLcWR-9gkCjOv9o87QKLcoa4xA@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: ietf-http-wg@w3.org
On Tue, Nov 27, 2012 at 4:32 AM, Amos Jeffries <squid3@treenet.co.nz> wrote:
> If I'm reading that right any recipient MUST consider a request with no
> Content-Length or Transfer-Encoding header as being 0-length.
>   That opens a request smuggling loophole when overly zealous
> privacy/anonymizer config has been implemented. When proxy-A is known to
> erase CL headers (but obeys them) it can be sent a POST with smuggled
> request and victim request in pipeline. Proxy-A duly erases the CL and
> passes what server X is now required to interpret as three requests,
> resulting in proxy-A getting the smuggled requests response stored as the
> victums reply - and some garbage at the end of the pipeline.
>  Bit rare, but I have seen people erasing every header they thought was
> optional because "some requests dont have it".

Why isn't the answer to the above corner case simply 'you lose' ?

Seems to me that a lot of potential for forward progress in the HTTP world
is being blocked by people dredging up the most bizarre corner cases
imaginable. Often times corner cases that probably should not be fixed.

What is a privacy proxy anyway? And why would a person be using it? And why
would it be a good idea for the HTTP protocol to provide a way to
circumvent the control?

If people write proxies that break on very frequent cases such as the POST
request then they are going to be broken no matter what we write in the

I don't think it is worth any working group spending time on a
non-conforming implementation that has less than a 5% deployed base. For
HTTP that is a LOT of deployed base.

Website: http://hallambaker.com/
Received on Tuesday, 27 November 2012 15:34:47 UTC

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