Re: draft-ietf-httpbis-p5-range-21, "3.2 416 Requested Range Not Satisfiable"

I've always considered multipart/byteranges to be less than optimal 
design for the problem.

A server should be able to send the byte ranges coalesced in a single 
message body, since it advertised the ranges coming back it's possible 
to unpick it, and doesn't then require the part separators etc.

that way you don't need to overload the Content-Type which then removes 
your ability to transfer the actual content type (although presumably 
this has been communicated earlier).

Does anyone actually use multiple ranges?  


------ Original Message ------
From: "Zhong Yu" <zhong.j.yu@gmail.com>
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 25/10/2012 4:52:03 a.m.
Subject: Re: draft-ietf-httpbis-p5-range-21, "3.2 416 Requested Range 
Not Satisfiable"
>Wouldn't "Content-Type: multipart/byteranges" cause confusions if it's
>used anywhere other than in a 206 response?
>
>Suppose a representation itself has the content type of "multipart/byteranges"
>
>   Get /slivers HTTP/1.1
>
>
>   HTTP/1.1 200 OK
>   Content-Type: multipart/byteranges
>
>That's pretty confusing for observers. Even more confusingly
>
>   Get/slivers HTTP/1.1
>   Range: bytes=0-499
>
>
>   HTTP/1.1 206 Partial Content
>   Content-Type: multipart/byteranges
>   Content-Range: bytes 0-499/1234
>
>Maybe we should strongly discourage the use of multipart/byteranges in
>any application except in a HTTP 206 response.
>
>Zhong Yu
>
>
>
>On Wed, Oct 24, 2012 at 7:21 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
>
>>
>><http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p5-range-21.html#status.416>:
>>
>>"When this status code is returned for a byte-range request, the response
>>SHOULD include a Content-Range header field specifying the current length of
>>the representation (see Section 5.2). This response MUST NOT use the
>>multipart/byteranges content-type. For example,"
>>
>>What is this "MUST NOT" about? Are there clients that will ignore the status
>>code and assume success if they see the expected content-type?
>>
>>Best regards, Julian
>>
>>
>

Received on Wednesday, 24 October 2012 19:59:27 UTC