- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 24 Jan 2013 12:14:38 +1100
- To: Yves Lafon <ylafon@w3.org>
- Cc: Julian Reschke <julian.reschke@gmx.de>, ietf-http-wg@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 UTC