W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Comments on Byte range draft

From: Ted Hardie <hardie@merlot.arc.nasa.gov>
Date: Thu, 9 Nov 1995 15:50:18 -0800 (PST)
Message-Id: <199511092350.PAA11145@merlot.arc.nasa.gov>
To: ari@netscape.com
Cc: john@math.nwu.edu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
In the range specification section it says:

* In the case that the second integer is smaller than the first
  one, an empty range is returned.

Since the specification says just above that point that:

* The first integer must always be less than or equal to the second
  one.


I would suggest that in cases where the second integer is smaller than
the first, an error message indicating a malformed header should be
returned (rather than an empty range).  An empty range doesn't tell
the requester what went wrong; an error message might.

In the section on the return of multiple ranges as multipart MIME
messages, the draft says "A server may send also a single byte range
as a multipart message."  Why should a server send a single byte
range in a multipart message, and would that break any clients expecting,
not unreasonably, multiple parts to a multi-part message?

I also note that the draft gives the response Range header as
Range: bytes x-y/z .  Is z in use to handle situations where a
new version has occurred between the clients request of one byte
range and another, and, if so, isn't that already handled by the 
other headers (you note that the if-modified-since works with
this)?  I also assume that the Last-modified header and if-modified
since header will generally be applied to the document as a whole, 
not to the individual byte-ranges, but I'm afraid I didn't find
the draft to be too clear on this point.

				Regards,
					Ted Hardie
					NAIC
Received on Thursday, 9 November 1995 15:50:03 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:35 EDT