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

From: Yves Lafon <[email-masked]>
Date: Mon, 7 Jan 2013 05:53:42 -0500 (EST)

On Thu, 15 Nov 2012, Mark Nottingham wrote:

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

If a multipart/byteranges can be sent in response to a 416, it can also be 
send in response to a 200, or to a 206.
In the case of a 206, you will have a Content-Range in the response and in 
the multipart/byteranges package, so it will be a partial response of a 
partial response without asking for it. (the restriction is also there for 
206, see discussion around #405).

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

         ~~Yves

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Jan 2013 12:14:38 +1100

Digging this up...

On 07/01/2013, at 9:53 PM, Yves Lafon <[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?
> 
> If a multipart/byteranges can be sent in response to a 416, it can also be send in response to a 200, or to a 206.
> In the case of a 206, you will have a Content-Range in the response and in the multipart/byteranges package, so it will be a partial response of a partial response without asking for it. (the restriction is also there for 206, see discussion around #405).

Why is this a problem? If the 200 response is:

HTTP/1.1 200 OK
Date: Tue, 14 Nov 1995 06:25:24 GMT
Last-Modified: Tue, 14 July 04:58:08 GMT
Content-Length: 2048
Content-Type: multipart-byteranges; boundary=ORIGINAL_BOUNDARY

then the single-range 206 would be something like:

HTTP/1.1 206 Partial Content
Date: Tue, 14 Nov 1995 06:25:24 GMT
Last-Modified: Tue, 14 July 04:58:08 GMT
Content-Range: bytes 1024-2048/2048
Content-Length: 1024
Content-Type: multipart-byteranges; boundary=ORIGINAL_BOUNDARY

while the multi-part 206 would be:

HTTP/1.1 206 Partial Content
Date: Tue, 14 Nov 1995 06:25:24 GMT
Last-Modified: Tue, 14 July 04:58:08 GMT
Content-Length: 449
Content-Type: multipart/byteranges; boundary=OUTER_BOUNDARY

--OUTER_BOUNDARY
Content-Type: multipart-byteranges; boundary=ORIGINAL_BOUNDARY
Content-Range: bytes 3-10/2048

...the first range...
--OUTER_BOUNDARY
Content-Type: video/example
Content-Range: bytes 400-500/2048

...the second range
--OUTER_BOUNDARY--

Note that p5-latest says:

> When a 206 response is generated, the sender must generate the following header fields:
> 
> 	• Either a Content-Range header field (Section 4.2) indicating the single range included with this response, or a multipart/byteranges Content-Type indicating that multiple ranges are enclosed as multipart body-parts.

... which gives clients enough information to determine what kind of response the 206 is.

So, while it's a pathological case, I believe that as long as the recipient dispatches correctly, you can transfer multipart/byteranges just as if it were any other media type on the Web.

Also, I note that Roy removed this requirement in <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2066>. So, I'm going to mark this issue as 'incorporated' for now; if we find that it needs to change, we can reopen (since that state is just a note that an editor has incorporated a proposed fix for the issue).

Regards,

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Jan 2013 16:11:02 +0100

On 2013-01-24 02:14, Mark Nottingham wrote:
> ...

+1

Best regards, Julian

---

From: Zhong Yu <[email-masked]>
Date: Thu, 24 Jan 2013 09:51:27 -0600

Either a Content-Range ... or a multipart/byteranges Content-Type

This does not clearly define a precedence; maybe we should clarify
what if both exist.

And other conflicting texts:

http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-21#section-4.1

   A response to a request for a single range MUST NOT be sent using the
   multipart/byteranges media type.

This forbids your 2nd example, a single range 206 response with a
multipart/bytereanges content type.

http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-21#appendix-A

   When an HTTP 206 (Partial Content) response message includes the
   content of multiple ranges (a response to a request for multiple non-
   overlapping ranges), these are transmitted as a multipart message
   body ([RFC2046], Section 5.1).  The media type for this purpose is
   called "multipart/byteranges".  The following is to be registered
   with IANA [RFC4288].

This apparently limits the use of multipart/byteranges specifically
for http 206 responses.

Zhong Yu

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Jan 2013 16:56:43 +0100

> http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-21#section-4.1

Stop looking at draft 21; it's seriously outdated. -> 
<http://trac.tools.ietf.org/wg/httpbis/trac/wiki>

> multipart/bytereanges content type.

That text is gone already.

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 25 Jan 2013 18:29:34 +1300

> <http://trac.tools.ietf.org/wg/httpbis/trac/wiki>

Speaking of which what timeframe can we expect a -22 ?
Some of us implementing need to be able to point at a reference Draft at 
least.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 25 Jan 2013 16:43:17 +1100

Hopefully within the week; we have very little left to do:
  http://trac.tools.ietf.org/wg/httpbis/trac/report/20

On 25/01/2013, at 4:29 PM, Amos Jeffries <[email-masked]> wrote:

>> Stop looking at draft 21; it's seriously outdated. -> <http://trac.tools.ietf.org/wg/httpbis/trac/wiki>
> 
> Some of us implementing need to be able to point at a reference Draft at least.
> 
> Amos
>