RE: multipart/byteranges
Yaron Goland (yarong@microsoft.com)
Mon, 4 Aug 1997 17:48:32 -0700
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