W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: multipart/byteranges

From: David W. Morris <dwm@xpasc.com>
Date: Mon, 4 Aug 1997 11:35:57 -0700 (PDT)
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: Yaron Goland <yarong@microsoft.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, Rajeev Dujari <rajeevd@microsoft.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.GSO.3.96.970804112549.16698A-100000@shell1.aimnet.com>


On Mon, 4 Aug 1997, Jeffrey Mogul wrote:

> I believe that I wrote this section, and it certainly never occurred
> to me that handling a "multipart/byteranges" with only one part would
> cause implementation difficulties.  After all, if the client is
> prepared to deal with N parts in a multipart type, what makes N = 1
> harder than, say, N = 2 or N = 13?

In this case, I think the client determines if it will EVER ask for more
than 1 range in a single request, doesn't it?

As I recall, multipart is more complex to handle than singlepart (which
would simply be the content?) so I expect that a client could decide
to never request > 1 range and hence not need to support multipart at all
(that would likely be my first choice for the kinds of simple clients
I've written.) From what I've read of the motivation for byte ranges,
I would expect the majority of usage to be a single range per request.
Pipelining etc. makes breaking multiple ranges into multiple requests
fairly minimal from a performance perspective.

So assuming my memory is correct and historical byte ranges allow
multipart to be avoided for a single range, I would favor restricting the
use of multipart to N > 1.  Keep simple requests simple.

Yaron will have to comment on whether his case matches mine, if not there
are two reasons...

Dave Morris
Received on Monday, 4 August 1997 11:41:32 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:50 EDT