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

Re[2]: Bad browser behaviour?

From: Adrien W. de Croy <adrien@qbik.com>
Date: Tue, 20 Mar 2012 05:36:48 +0000
To: "Amos Jeffries" <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <em42deddc9-8590-4244-8e60-dc512d4fbaa4@BOMBED>

------ Original Message ------
From: "Amos Jeffries" <squid3@treenet.co.nz>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 20/03/2012 6:29:41 p.m.
Subject: Re: Bad browser behaviour?
>On 20/03/2012 3:20 p.m., Adrien W. de Croy wrote: 
>>Hi all 
>>we're seeing some (IMO) undesirable behaviour for all tested current 
>>browsers (we tested FF, Chrome, IE and Opera). 
>>It relates to abortive closes on chunked transfers. In this case, I'm 
>>talking about a server close prior to the final 0 chunk. 
>>All the browsers we tested ignore this and display the content with 
>>no warning whatsoever. 
>>For our proxy to treat it as an abortive close is therefore a problem 
>>in our customers' eyes. 
>>So what's the deal? Should we allow this behaviour in the spec? Or 
>>should browser vendors be encouraged to break the page / download? 
>>Isn't it a potential security issue? 
>Why is it a problem? Abortive close does not necessarily mean the sky 
>is falling. It just means incomplete transfer. Happens all the time. 
several problem scenarios.
1. intermediary with AV scanning which can only do an abortive close if 
it detects a virus since it already drip-fed a portion of the resource 
to the client to stop it timing out.  Client can receive an infected 
file and execute it without any warning.
2. intermediary spooling content for scanning (without drip-feeding any 
to client) aborts without sending anything to client.
We could fix 2. by making the intermediary just pass whatever it had on 
an abortive close from the server, but if it was chunking, should it 
send a 0 chunk or just close?
>Chunked transfer just offers the possibility of automatic recovery by 
>the client UA by informing that it *was* incomplete/aborted instead of 
>complete/terminated. The proxy should be relaying that information 
>along with an early abort on the client connection. 
many chunking scenarios the server doesn't have a length, which is why 
it was chunked in the first place, so range won't work.
Received on Tuesday, 20 March 2012 05:37:23 UTC

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