Range: validators

Re: byte-range proposal in http://www.ics.uci.edu/pub/ietf/http/draft-luotonen-http-url-byterange-02.txt (the URL listed in the HTTP-WG home page, which now results in "Forbidden"!) and Jeff's somewhat less formal proposal in: http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q4/0458.html

Jeff pointed out that Ari Luotonen's proposal depended on a new "Unless-modified-since:" header that doesn't integrate well with opaque validators, and that the proposal left out a form of conditional retrieval that might be useful. Ari agreed, and since Netscape (nor any other vendor?) has not deployed anything that depends on Ari's proposal, Ari and Jeff will work together to integrate the two proposals into one.

I would like to see explicitly addressed the case where I am requesting a byte-range from a huge, say 20 MB, file when the file has been modified and I _never_ want the whole file to be sent to me. In my opinion, there should be the option to trigger a "3xx Modified" response (see Jeff Mogul's suggestions in response to my note) rather than have the server attempt to dump the whole file on the network.

complaint: "Simply leaving the Unless-modified-since header out and using only If-modified-since the entire file will not be returned." doesn't work in that it doesn't work if the file hasn't changed (assuming you want the range you're asking for) and it doesn't work if the file has changed (since the range you're asking for might well be invalid.)

Response: The following steps should be taken.

  1. issue a HEAD request on the URL in question to retreive the last-modified date.
  2. compare the last-modified date returned by the HEAD to the last-modified date of the previous GET of the URL. If the dates are different stop, otherwise go on to step 3.
  3. Issue a byte-range GET request on the URL.

Roy:
Issue: "The byteranges draft still has some garbage (e.g., Accept-Ranges) which is no longer needed."
http working group issues