Re: #90: multipart/byteranges

I agree that all necessary information is already in the spec. For  
whatever reason, however, people are being confused by it.

I think that the core of the issue is that the current text --  
intentionally or not -- leaves the door open for use of multipart/ 
byteranges as a delimiter in other situations, provided that the  
sender "knows" that the receiver can parse it (one way of knowing this  
is specified, but others may exist).

As such, the question is whether we want to leave that door open.  
Either way, the intent should be clearly stated.

Separately, the requirements are structured in an odd way that's  
difficult to read; I'm concerned that this will only be more  
pronounced, since message parsing and byterange operation are being  
split into separate sections. I  don't see why preserving this  
confusing language is desirable.



On 11/12/2008, at 8:37 AM, Henrik Nordstrom wrote:

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


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

Received on Thursday, 11 December 2008 00:55:03 UTC