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 NAICReceived on Thursday, 9 November 1995 15:50:03 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:42:56 UTC