W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

Re: [#95] Multiple Content-Lengths

From: Willy Tarreau <w@1wt.eu>
Date: Wed, 22 Sep 2010 22:17:13 +0200
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Adam Barth <w3c@adambarth.com>, "Roy T. Fielding" <fielding@gbiv.com>, "William Chan (?????????)" <willchan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20100922201713.GU7522@1wt.eu>
On Wed, Sep 22, 2010 at 09:28:24PM +0200, Julian Reschke wrote:
> >Did you test with three Content-Length headers?  I suspect FF is using
> No.
> >the last header (not the second) because that's what they usually do.
> I agree that this is the likely reason.

I did the test some time ago but unfortunately I lost the results. The
test was quite simple :

  $ printf "HTTP/1.1 200 OK\r\nContent-length: 6\r\nContent-length: 2\r\nContent-length: 8\r\nContent-length: 4\r\n\r\n0123456789" | nc -lp80

Then send your browser at it. If it returns 2 bytes, it takes the min. If it
returns 4, it takes the last. If it returns 6, it takes the first. If it
returns 8, it takes the max, if it returns 10, it takes everything.

And yes, I remember about FF taking the last one.

> >IE usually uses the first header, so that's not surprising.  Chrome
> >usually matches Firefox (in using the last header), so there might be
> >some specific reason it uses the first one here.  We could ask Darin
> >whether he had a specific reason.
> My wild guess is: it doesn't matter. Either there's no content out there 
> relying on this, or both variations exist, and one approach breaks one 
> kind, and the other approach breaks the other kind.
> >>2) some close the connection (Op/IE), some do not
> >>
> >>3) most parse multiple lenghts in a single header just like multiple
> >>headers, except for FF which then ignores the header and reads until EOF
> >>
> >>4) all are ok with multiple header instances having the same value
> >
> >This sounds worth adding to the spec.  There isn't a security problem
> >if all the headers agree.
> Agreed, but it makes the spec more complex, and it's not sure whether 
> it's worth the special case (that's why statistical data would be useful).
> >>I think this is good news in that there's no interop for broken messages,
> >>thus whatever we decide to do is unlikely to break existing content.
> >
> >I wouldn't necessarily draw that conclusion from the data above.  The
> >fact that Chrome matches IE here instead of Firefox is a hint that
> >there might be something more going on.
> Well, you could ask.
> On the other hand, has anybody complained that FF's behavior breaks 
> anything?

in my opinion, these differences don't break anything, they just make
browser-specific smuggling possible in some circumstances, that's all.
Multiple different content-length headers produce so widely different
behaviours across intermediaries that no sane production can stay long
enough in that situation without noticing and fixing.

Received on Wednesday, 22 September 2010 20:18:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:48 UTC