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 12:43:37 +0100
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1228909417.19672.13.camel@localhost.localdomain>

ons 2008-12-10 klockan 12:08 +1100 skrev Mark Nottingham:

> Ignoring the missing characters (which should be fixed by now), a few  
> things strike me;
> 1) the most direct way to address the immediate concern would be to  
> restrict the use of multipart/byteranges *as a delimiter*; e.g.,
> "If a 206 Partial Content response message uses the media type  
> "multipart/byteranges", ..."

In 2616 it's already restricted to 206 responses to multirange requests,
as that's the only case where support for multipart/byteranges is

> 2) The "This media type MUST NOT be used..." requirement is a non- 
> sequitur here, and probably belongs in the appendix that defines the  
> media type, or possibly in 206 Partial Content. Doing so will  
> necessitate reformulating the note into something like "Servers MUST  
> NOT use multipart/byteranges to delimit the message when sending to  
> HTTP 1.0 clients."

There is already in 4.4 .4 "This media type (M)UST NOT be used unless
the sender knows that the recipient can (p)arse it;"

> Beyond that, there's still an open question of whether we want to  
> discourage its use as a delimiter (without disallowing it); Henrik,  
> you say as much in  <http://lists.w3.org/Archives/Public/ietf-http-wg/2007OctDec/0202.html 
>  > -- is this still the case?

Yes. There is absolutely no reason to broaden the scope of
multipart/byteranges as delimiter wihin HTTP/1.1. If the length isn't
known use chunked, period.

Anyone thinking of using this as delimiter outside multirange 206
responses must first make sure to negotiate this support on a hop-by-hop
basis (it's a transport feature, not a message property)

Received on Wednesday, 10 December 2008 11:44:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:47 UTC