- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 20 Feb 96 17:08:10 PST
- To: http-caching@pa.dec.com
Ari and I have agree on the following, and Ari will be submitting
a revised draft-luotonen-http-url-byterange-XX.txt by the cutoff
date (Thursday).
-Jeff
------- Forwarded Message
Return-Path: mogul
Received: by acetes.pa.dec.com; id AA22205; Fri, 16 Feb 96 15:36:08 -0800
Message-Id: <9602162336.AA22205@acetes.pa.dec.com>
To: luotonen@netscape.com (Ari Luotonen)
Cc: mogul
Subject: range proposal revisions
Date: Fri, 16 Feb 96 15:36:08 PST
From: Jeffrey Mogul <mogul>
Pretty much the only part of draft-luotonen-http-url-byterange-02.txt
that I think needs changing is this section:
----------------------------------------
3.2. The Unless-Modified-Since HTTP request header
Guaranteeing that individual parts are all up-to-date and in sync
with each other is crucial. This can be made easier by providing a
way to tell the server to send the byte range only if it hasn't
changed since the time of the retrieval of the other ranges. If it
has, the entire document is transferred instead.
The Unless-Modified-Since header will be sent by the client to the
server (or the proxy), carrying the date and time received in the
Last-Modified header from the previously received parts. If at any
point the last-modified date or time mismatch is detected by the
client, the older parts should be discarded. The last-modified date
and time must match exactly.
The server will send the requested byte range (as a 206 Partial
Content response, as described below) if and only if the document has
not changed since that date and time. If it has, the server will
send the entire document to the client instead (as a normal 200
response).
Example:
Unless-Modified-Since: Wed, 15 Nov 1995 06:25:15 GMT
As for Last-Modified-Since header in practice, there may be
additional parameters in the end of this field, separated by a
semicolon, to make additional checksums possible. The most basic one
is the size of the file as the length parameter:
Unless-Modified-Since: Wed, 15 Nov 1995 06:25:15 GMT; length=12045
----------------------------------------
How about this proposal:
(1) There are three cases of Range retrievals:
(A) Unconditional ... always returns the
selected range (if it exists).
Servers that do not support Range: return entire
resource.
(B) Insertion ... returns the selected
range if the request-validator is valid,
otherwise returns entire resource.
Servers that do not support Range: return entire
resource if the validator is valid, else return
nothing + "306 Modified".
case (B) is for filling in a hole in a cached resource,
perhaps after an interrupted retrieval, or perhaps after
a previous Unconditional or Tentative Range: request.
Note that if the server does not support Range:, it requires an
extra round-trip to update a cached resource with a hole in it.
I think your original "Unless-modified-since:" proposal has a
similar inefficiency; there's probably not much that can be
done about that.
(C) Tentative ... returns the selected
range if the request-validator is NOT valid,
otherwise returns nothing + "304 Not Modified"
Servers that do not support Range: return entire
resource if the validator is not valid, else return
nothing + "304 Not Modified".
case (C) is a way of asking only for a specified range, but in
a way that reloads it only if the client's cache is stale. For
example, you may have a large GIF image in your cache, and you
may want to know if its GIF header has changed (so that you can
do an early rendering of the enclosing HTML file), but you do
not want to retrieve the whole image right away.
My message to the http-wg list in December,
http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q4/0454.html
has this last case different (I instead had "returns selected
range if validator is valid, else returns nothing"), but I don't
think that's a useful feature.
(2) The three cases are implemented in HTTP/1.1 using
some combination of these three headers
Range:
If-invalid:
If-valid:
or
Range:
If-Modified-Since:
Unless-Modified-Since:
See (3) below for more about using *-Modified-Since.
Case A (Unconditional) is done using
GET /image.gif
Range: bytes=0-128
Case B (Insertion) is done using
GET /image.gif
Range: bytes=0-128
If-valid: "xxxyxxyx"
or perhaps
GET /image.gif
Range: bytes=0-128
Unless-modified-since: Wed, 15 Nov 1995 06:25:15 GMT
Case C (Tentative) is done using
GET /image.gif
Range: bytes=0-128
If-invalid: "xxxyxxyx"
or perhaps
GET /image.gif
Range: bytes=0-128
If-modified-since: Wed, 15 Nov 1995 06:25:15 GMT
(3) We can get rid of "Unless-modified-since:" if we adopt
the rule that the "If-valid:" header either takes a quoted
string (in which case it is an opaque validator) or a string
that does not include quotes (in which case it must be an
HTTP-date value). This saves a few header bytes.
(4) I would remove the stuff about including other "validator"
information, such as length, from the {Unless,If}-Modified-Since:
headers. These are of dubious value, and they make the
protocol more complex.
Comments?
-Jeff
------- End of Forwarded Message
Received on Wednesday, 21 February 1996 01:16:43 UTC