RE: multipart/byteranges

I would just say "YES" but I'm not sure anyone would know what I'm
saying yes to. =)

However Jeff, you understand the situation completely. All I am asking
for is a clearer statement of the painfully obvious.

		Thanks,
			Yaron

> -----Original Message-----
> From:	Jeffrey Mogul [SMTP:mogul@pa.dec.com]
> Sent:	Monday, August 04, 1997 2:48 PM
> To:	http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> Subject:	Re: multipart/byteranges 
> 
>     We don't handle multipart/byteranges. We NEVER ask for more than
>     one range. Having to put in a parser for multipart/byteranges into
>     the level of the stack which handles generic HTTP (in our case
> that
>     would be WinInet) would be extremely difficult. That level in the
>     stack doesn't do the sort of heavyweight parsing needed for
>     multipart. It is really designed for quick and dirty parsing on
> the
>     level of "Identify headers and body, return."
> 
> Aha, I misunderstood your question.  Certainly if a client only
> makes requests for single contiguous ranges, it shouldn't have
> to be able to parse multipart/byteranges responses.
> 
> I misunderstood your question because I thought you were talking
> about a case where the server might coaelesce two requested
> (and overlapping) ranges into a one-part "multipart" response.
> 
>     Given that others are in the same situation it would seem
>     reasonable to put in language requiring that multipart/byteranges
>     not be used if a single range is being returned.
>     
> The language is already there, although in a different part of the
> spec (quoting from RFC2068, not draft -08, which I don't have handy):
> 
>    4.4 Message Length:
> 
>    When a message-body is included with a message, the length of that
>    body is determined by one of the following (in order of
> precedence):
> 
>    [...]
> 
>    4. If the message uses the media type "multipart/byteranges", which
> is
>      self-delimiting, then that defines the length. This media type
> MUST
>      NOT be used unless the sender knows that the recipient can parse
> it;
>      the presence in a request of a Range header with multiple
> byte-range
>      specifiers implies that the client can parse multipart/byteranges
>      responses.
> 
> One could argue that this "MUST" ought to be more obvious (although
> I found it quickly using a text-search on "multipart/byteranges").
> But I think this is exactly what you want, right?
> 
> I.e., what matters to you is NOT that a multipart/byteranges have
> more than one subrange (since one could, in principle, break up
> a single range into multiple contiguous subranges), but that the
> server never send any multipart/byteranges responses to a client
> that isn't prepared to parse them.  Right?
> 
> -Jeff

Received on Monday, 4 August 1997 17:51:02 UTC