W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2008

Re: #90: multipart/byteranges

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Wed, 10 Dec 2008 22:37:13 +0100
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1228945033.5871.58.camel@hlaptop>

On Thu, 2008-12-11 at 00:10 +1100, Mark Nottingham wrote:

> Even if your interpretation is the latter one, a much simpler  
> formulation is that it can't be used for message delimitation with  
> HTTP/1.0 receivers (next hop).

No, it MST NOT be used for message delimitation to ANY recipient
including HTTP/1.1 clients unless they indicate they support the media
type (where the only method doing so in 2616 is multirange requests).
And MUST NOT be used as delimiter if there is reason to suspect you are
talking to a HTTP/1.0 proxy.

Additionally the media type as such SHOULD NOT be used in contexts where
it does not make sense, but that's a pretty minor and obvious to anyone
I'd say.

The text in 4.4 ยง4 is mainly about delimiting. The fact that it also by
sideeffect restricts when multipart/byteranges may at all be sent is
coincidental and not the main purpose of that text. It can not be moved
out from 4.4 without loosing context, but I am quite fine with having
4.4 narrowed down to only limit when multipart/byteranges is valid as
delimiter. It's already covered sufficiently at other places how it
should be used as media type in it's normal intended use (see
Content-Range), and there is not really any reason why 4.4 should limit
other applications of the media type as such, only it's property as
delimiter.

Proposed updated text:

   4.If the message uses the media type "multipart/byteranges", and the
     transfer-length is not otherwise specified, then this self-
     delimiting media type defines the transfer-length. This media type
     MUST NOT be used as delimiter unless the sender knows that the
     next hop recipient can parse it; the presence in a request of a
     Range header with multiple byte-range specifiers from a 1.1
     client implies that the client can parse multipart/byteranges
     responses.

       A range header might be forwarded by a 1.0 proxy that does not
       understand multipart/byteranges; in this case the server MUST
       delimit the message using methods defined in items 1,3 or 5 of
       this section.

Note: I am not entirely happy with the language in "the presence in a
request of a Range ..." but that may just be my limited english.. kept
the original text as much as possible and that text do say the right
thing.

Regards
Henrik
Received on Wednesday, 10 December 2008 22:37:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:58 GMT