W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2007

i90: status of multipart/byteranges

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 27 Nov 2007 21:21:19 -0800
Message-Id: <D4EA71B6-2B0B-421A-8E9F-68AB1A00FD47@mnot.net>
Cc: ietf-http-wg@w3.org
To: Bjoern Hoehrmann <derhoermi@gmx.net>

Now i90; <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i90>.


On 18/11/2007, at 5:51 AM, Bjoern Hoehrmann wrote:

>
> Hi,
>
>   There appears to be some confusion as to when multipart/byteranges
> bodies have to be inspected to determine the message length. It seems
> that is widely considered optional and sometimes limited to ...
>
>   In general, HTTP treats a multipart message-body no differently than
>   any other media type: strictly as payload. The one exception is the
>   "multipart/byteranges" type (appendix 19.2) when it appears in a 206
>   (Partial Content) response ...
>
> ... this particular case, even though the specification suggest the
> opposite, I read it to say, all implementations have to support that
> and support it in all messages, like requests and non-206 responses.
> Apache 2.2.6 for example treats
>
>   POST / HTTP/1.1
>   Host: example
>   Content-type: multipart/byteranges;
>     boundary=THIS_STRING_SEPARATES
>
>   --THIS_STRING_SEPARATES
>   ...
>
> as two requests, a zero-length POST and a --THIS_STRING_SEPARATES to
> the root which it does not support (which seems to be a bug in  
> itself).
> Would it be possible, for example, to discourage implementations to
> ever generate messages where the message length is determined by this
> type, and limit having to read it to 206 responses, as the text above
> suggests?
>
> regards,
> -- 
> Björn Höhrmann · mailto:bjoern@hoehrmann.de · http:// 
> bjoern.hoehrmann.de
> Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http:// 
> www.bjoernsworld.de
> 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http:// 
> www.websitedev.de/
>


--
Mark Nottingham     http://www.mnot.net/
Received on Wednesday, 28 November 2007 05:21:31 GMT

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