- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Mon, 04 Aug 97 10:27:20 MDT
- To: Yaron Goland <yarong@microsoft.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, Rajeev Dujari <rajeevd@microsoft.com>
A question has come up, is it legal for a server to send a
multipart/byteranges with a single range? This apparently causes some
very ugly code on the client side if it is legal. The following is an
excerpt from section 19.2 of RFC 2068:
19.2 Internet Media Type multipart/byteranges
When an HTTP message includes the content of multiple ranges (for
example, a response to a request for multiple non-overlapping
ranges), these are transmitted as a multipart MIME message. The
multipart media type for this purpose is called
"multipart/byteranges".
My reading of this section is that a multipart/byteranges can only be
sent if there are byte rangeS but there has still been some question.
1) Is it correct that multipart/byteranges can only be used if there are
multiple, as in more than one, byteranges?
2) Either way, can we put in a sentence to clarify the matter?
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?
Can you perhaps explain a bit more about why this makes the client
code so ugly? I'm not strongly opposed to changing the HTTP spec to
prohibit 1-part "multipart/byteranges" values, but I think doing
so would add complexity to the spec, and isn't really consistent
with the robustness principle. Also, I'm certainly not a MIME
expert, and I don't know if MIME has a rule that either explicitly
requires or prohibits N = 1 in multipart types.
Have other client implementors found this hard? easy? didn't realize
until now that it might be a real problem?
-Jeff
Received on Monday, 4 August 1997 10:32:31 UTC