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

On Wed, 24 Oct 2012, Zhong Yu wrote:

> 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.

Note that you can't have Content-Range and Content-Type: 
multipart/byteranges in a 206
From 3.1
<<
Either a Content-Range header field (Section 5.2) indicating the range 
included with this response, or a multipart/byteranges Content-Type 
including Content-Range fields for each part.
>>
Which is a XOR.
(This also address Thomas' first observation about MUST NOT in ticket 
#405) [1]

[1] <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/405>

> 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
>>
>
>

[1] <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/405>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Thursday, 15 November 2012 10:30:51 UTC