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

Rev81: byte range inconsistencies

From: Dave Kristol <dmk@allegra.att.com>
Date: Mon, 3 Jun 96 16:51:18 EDT
Message-Id: <9606032051.AA04758@zp.tempo.att.com.tempo.att.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/755
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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC