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

Re: required behaviour of client when abortive disconnect

From: Adrien de Croy <adrien@qbik.com>
Date: Mon, 09 Mar 2009 19:22:34 +1300
Message-ID: <49B4B5AA.6030401@qbik.com>
To: Robert Siemer <Robert.Siemer-httpwg@backsla.sh>
CC: HTTP Working Group <ietf-http-wg@w3.org>

for the record I've also been testing Opera, and it behaves a bit 
differently.

If Content-Length is set and the response is not complete, it marks the 
download as incomplete.  However if chunking is used it doesn't.

I'm not sure if this case warrants an automatic retry - perhaps just 
one.  This is a common scenario with gateway AV scanning.  Proxy just 
closes the connection if a virus is detected and a response has been 
sent (usually required to stop humans from timing out).

We also no longer send Proxy-Connection thanks to being kindly educated 
by the good folk at Opera.

Regards

Adrien


Robert Siemer wrote:
> On Mon, 2009-03-09 at 13:24 +1300, Adrien de Croy wrote:
>   
>> Hi
>>
>> I've been testing several clients to see what they do when downloading a 
>> resource and the connection is closed "abortively".
>>
>> In this case, "abortively" means that either
>>
>> a) transfer-encoding chunked is used, yet no final '0' chunk is sent - 
>> the connection is simply closed (Proxy-connection: Keep-alive was sent)
>> b) Content-Length is set, yet the connection is terminated prior to this 
>> amount of resource data being transferred.
>>
>> I tested Firefox, Chrome and IE7. 
>>
>> In all cases, the browser simply considered the transfer to be complete 
>> (even though it was terminated at 75%), and made the downloaded file 
>> available as if it had downloaded properly.  No warning or any message 
>> was presented.
>>
>> I find this more than a little disturbing, is this intended or desired 
>> behaviour?  I would expect at least some message from the browser saying 
>> the connection was closed prior to the file completing download.
>>     
>
> I consider this a serious bug in the clients. I would even go so far and
> say that the client SHOULD retry to get a complete response. [the
> standard blabla for safe/unsafe methods applies]
>
> There is a narrow use case in RFC2616 where it recommends retrying in
> case of a premature connection close. In my opinion this should be
> changed to cover the general case.
>
> Robert
>
>
>   

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Monday, 9 March 2009 06:20:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:01 GMT