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

On Thu, Nov 15, 2012 at 4:30 AM, Yves Lafon <ylafon@w3.org> wrote:
> 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

In my example, the request is for a single range, the selected
representation's own content type is multipart/byteranges. Then the
server has no choice but to respond like that.

Unless, we forbid the general use of multipart/byteranges, and require
that it is specifically designed for carrying HTTP 206 multiple
ranges, not to be used anywhere else.

Zhong Yu

> 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 16:39:44 UTC