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

On 2013-01-24 02:14, Mark Nottingham wrote:
> 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).
> ...

+1

Best regards, Julian

Received on Thursday, 24 January 2013 15:11:38 UTC