W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 1997

RE: multipart/byteranges

From: Yaron Goland <yarong@microsoft.com>
Date: Mon, 4 Aug 1997 13:56:50 -0700
Message-Id: <11352BDEEB92CF119F3F00805F14F4850354E10D@RED-44-MSG.dns.microsoft.com>
To: "'David W. Morris'" <dwm@xpasc.com>, Jeffrey Mogul <mogul@pa.dec.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, Rajeev Dujari <rajeevd@microsoft.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4076
David has absolutely hit the nail on the head. 

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

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.


> -----Original Message-----
> From:	David W. Morris [SMTP:dwm@xpasc.com]
> Sent:	Monday, August 04, 1997 11:36 AM
> To:	Jeffrey Mogul
> Cc:	Yaron Goland; http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com; Rajeev
> Dujari; http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> Subject:	Re: multipart/byteranges 
> 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 14:02:09 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:03 UTC