- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Thu, 15 Nov 2012 10:39:17 -0600
- To: Yves Lafon <ylafon@w3.org>
- Cc: Julian Reschke <julian.reschke@gmx.de>, ietf-http-wg@w3.org
On Thu, Nov 15, 2012 at 4:30 AM, Yves Lafon <ylafon@w3.org> wrote: > 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 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 > 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 <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? >>> >>> Best regards, Julian >>> >> >> > > [1] <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/405> > > -- > Baroula que barouleras, au tiéu toujou t'entourneras. > > ~~Yves >
Received on Thursday, 15 November 2012 16:39:44 UTC