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

Re: required behaviour of client when abortive disconnect

From: Robert Siemer <Robert.Siemer-httpwg@backsla.sh>
Date: Mon, 09 Mar 2009 14:13:27 +0800
To: Adrien de Croy <adrien@qbik.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1236579207.25463.29.camel@asus-1130818068>
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.

Received on Monday, 9 March 2009 06:14:12 UTC

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