- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Mon, 19 Aug 96 15:54:18 MDT
- To: Alexei Kosut <akosut@nueva.pvt.k12.ca.us>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
But... I dunno. What precisely are the odds that someone will modify a
file more than once per second, and leave the file the exact same
length? Pretty low, one would think.
Danger! Danger! I think it would be foolish to make this assumption.
Certainly the part about leaving the file length the same, since many
frequently-modified files only change a few bytes.
For example, imagine a stock-quote page where the quoted price of,
say, EDS goes from "52 7/8" to "51 1/8". That doesn't change the
length of the file at all. OK, this is bad example; nobody in their
right heads would cache stock-quote values, but my point is that
relying on file-length is a really bad idea.
Actually, it brings up an interesting point: when matching ETags for
ranges, one must use a strong validator comparison. But you can also
use dates. Namely, this is perfectly valid:
GET /filename HTTP/1.1
Range: bytes=30-500
If-Range: Thu, 15 Aug 1996 06:35:59 GMT
Surely a date is a much weaker validator than the hashes that we are
implementing? Yet as I read the spec, it is valid in this
application.
"Surely" not. If you are doing this comparison at a proxy cache,
and you have the Date of the response as well as the Last-modified
time, then 13.3.3 explains rules for both the client and the proxy
to follow so that there is no actual "weakness."
And, if the server is actually able to determine that it not handed
out the same last-modified time for two different versions of the
resource, then you can also support your example at the origin server.
When you write, of your example, "Namely, this is perfectly valid"
you are only correct if you also know the Date: value for the cached
responses, and if that Date value is sufficiently later than the
Last-Modified value. Read the spec.
Of course, if we discover that client implementors aren't reading
section 13.3.3, then we'll have to prohibit servers from doing this.
But 13.3.3 is cross-referenced from several places, so there is
really no excuse for not reading it.
-Jeff
Received on Monday, 19 August 1996 15:59:25 UTC