W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

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

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 24 Jan 2013 12:14:38 +1100
Cc: Julian Reschke <julian.reschke@gmx.de>, ietf-http-wg@w3.org
Message-Id: <FA42CDF7-B411-4A6B-B5B8-FF653C60FF17@mnot.net>
To: Yves Lafon <ylafon@w3.org>
Digging this up...

On 07/01/2013, at 9:53 PM, Yves Lafon <ylafon@w3.org> wrote:

> 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 <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?
> 
> 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/
Received on Thursday, 24 January 2013 01:15:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 24 January 2013 01:15:16 GMT