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.
-
issue a HEAD request on the URL in question to retreive
the last-modified date.
- 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.
- 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