- From: Adam Barth <w3c@adambarth.com>
- Date: Wed, 22 Sep 2010 11:57:51 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: "Roy T. Fielding" <fielding@gbiv.com>, William Chan (陈智昌) <willchan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Sep 22, 2010 at 5:19 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > On 21.09.2010 07:37, Roy T. Fielding wrote: >> On Sep 20, 2010, at 10:28 PM, William Chan (陈智昌) wrote: >>> From the brief discussion amongst the Chrome network developers, we plan >>> to discard the response and display an error. >> >> Thank you. That is a very sensible solution and I am more >> than happy to spec it that way if we can get rough consensus >> (and hopefully some running code). > > I just did a few tests with current versions IE/FF/Op/Saf/Chrome. > > Observations: > > 1) some pick the first Content-Length header (Op/Chr/Saf/IE), FF picks the > second Did you test with three Content-Length headers? I suspect FF is using the last header (not the second) because that's what they usually do. 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. > 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. > 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. Adam
Received on Thursday, 23 September 2010 03:47:33 UTC