On Wed, 22 Feb 2012, unkadoug_at_gmail.com wrote:

> /* On HTTP 1.1, when connection is not to get closed, but no Content-Length
> nor Content-Encoding chunked have been received, according to RFC2616
> section 4.4 point 5, we assume that the server will close the connection to
> signal the end of the document. */
>
> This assumption is invalid.

Yes you're right! But still...

> If the message uses the media type "multipart/byteranges", and the
> transfer-length is not otherwise specified, then this self- delimiting media
> type defines the transfer-length. This media type MUST NOT be used unless
> the sender knows that the recipient can parse it; the presence in a request
> of a Range header with multiple byte- range specifiers from a 1.1 client
> implies that the client can parse multipart/byteranges responses.
>
> If the curl client sends a range header with mulitple byte-range specifiers,
> and gets a multipart/byteranges reply that does not explicitly close the
> connection, it improperly awaits a signal:

In the HTTPbis work which will eventually end up in a refreshed HTTP 1.1 spec,
this mentioning of the special (and IMHO very odd and confused) way of
detecting the end of a body is removed:

Here's the ticket:

   http://trac.tools.ietf.org/wg/httpbis/trac/ticket/90

Here's the new HTTP range section:

   http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-18

I would agree that since RFC2616 did state that, we could indeed add code to
acknowledge this in 206 responses and detect the end of a body this way but it
seems to be used extremely rarely ("it is believed that no implementation
currently uses them" as the ticket says) and won't exist soon. As we've
survied this far without implementing it, is there really any good reason for
us to implement it *now*?

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html