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

From: Mark Nottingham <[email-masked]>
Date: Thu, 15 Nov 2012 17:07:16 +1100

Now <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/407>

On 24/10/2012, at 11:21 PM, Julian Reschke <[email-masked]> 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
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Yves Lafon <[email-masked]>
Date: Thu, 15 Nov 2012 05:30:49 -0500 (EST)

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 <[email-masked]> wrote:
>> "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

---

From: Yves Lafon <[email-masked]>
Date: Thu, 15 Nov 2012 05:37:35 -0500 (EST)

> code and assume success if they see the expected content-type?

It was present also in rfc2616, so nothing new. This is to enforce the 
fact that multipart/byteranges contains a Content-Range header for each 
part; An extra Content-Range would be like having two C-R with different 
values, an error.

         ~~Yves

---

From: Zhong Yu <[email-masked]>
Date: Thu, 15 Nov 2012 10:39:17 -0600

> 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

> (This also address Thomas' first observation about MUST NOT in ticket #405)
> [1]
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Nov 2012 17:47:10 +0100

> server has no choice but to respond like that.

Exactly. We should remove all special-casing with respect to this. We 
could keep a warning that some clients might be confused by the presence 
of that type, though.

> ...

Best regards, Julian