Re: #90: multipart/byteranges

On 10/12/2008, at 10:43 PM, Henrik Nordstrom wrote:

> 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
> negotiated.

Where?

2616 says

> When an HTTP 206 (Partial Content) response message includes the  
> content of multiple ranges (a response to a request for multiple non- 
> overlapping ranges), these are transmitted as a multipart message- 
> body. The media type for this purpose is called "multipart/ 
> byteranges".

but that doesn't preclude other uses.


>> 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;"

I'm proposing that this requirement be rewritten and relocated because  
it's confusing as it is; taken out of context, the requirement states  
that the media type can only be used when the sender knows that the  
recipient can parse it, which makes sense, given its use to convey  
multiple byteranges.

However, in context, it has a completely different meaning -- that the  
media type must not be used *to delimit messages* unless (...).

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).

"the presence in a request of a Range header with ultiple byte-range  
specifiers from a 1.1 client implies that the lient can parse  
multipart/byteranges responses" isn't true or relevant in the context  
of message delimitation; a HTTP/1.0 proxy with a HTTP/1.1 client  
behind it will send multiple byte-range specifiers and not know  
anything about using multipart/byteranges for message delimitation.


>> 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)


I think we're in agreement here.

--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 10 December 2008 13:11:26 UTC