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