Rev81: byte range inconsistencies

As I try to implement byte ranges, I've stumbled on some inconsistencies
in Rev81.

1) 10.2.7 206 Partial Request
is worded to apply only to responses that contain a *single* byte
range, and a Content-Range header.  ("The response MUST include a
Content-Range header....")  Does that mean I should use 200 (OK) for
responses with multiple byte ranges?

2) 19.2 MIME multipart/byteranges Content-type
a) The example shows a 206 Partial Content response and
multipart/byteranges, which is inconsistent with 10.2.7 (because the
response has no Content-Range header).

b) The words ("...includes two or more parts...") imply that
multipart/byteranges cannot be used to send just a single byterange.

3) 14.17 Content-Range
The words here (and in 19.2) say "... multiple non-overlapping ranges...".
That implies that a server
	a) will detect and coalesce overlapping ranges in Range.
	b) will use multipart/byteranges only when it sends more than
		one distinct range.

I believe these observations are contrary to the intent of the byte
ranges stuff.  Specifically, I think:

1) 206 should be used with either Content-Range or multipart/byteranges.
2) multipart/byteranges can be used to send just a single range.
3) if a client asks for overlapping ranges, it should get them.

As Rev81 stands, I think the only safe (dependably interoperable)
implementation of byte ranges is for a server to punt if there are
multiple ranges in Range, and to send the entire entity.  Before I
craft new words to match what I think was intended (those last three
points that clarify multiple byte ranges), though, I'm looking for
agreement on them.

Dave Kristol

Received on Monday, 3 June 1996 13:56:35 UTC