- From: Alexei Kosut <akosut@nueva.pvt.k12.ca.us>
- Date: Wed, 14 Aug 1996 23:42:30 -0700 (PDT)
- To: Daniel DuBois <dan@spyglass.com>
- Cc: Jeffrey Mogul <mogul@pa.dec.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, swingard@spyglass.com
On Tue, 13 Aug 1996, Daniel DuBois wrote:
> Warning: Everything that follows is an implementor's issue, and not
> technically a protocol specification issue.
>
> Initially, I felt a hash of {the full pathname (to distinguish variants),
> the size of the file, and the OS-reported last-modification time} would be
> sufficient to be a strong validator. But, technically, that doesn't
> guarantee that a file that has changed twice in the same second has a
> different ETag value, which the spec says is a must.
Hmm. I must admit, I never even *thought* of this. In implementing
ETag support for Apache 1.2 (which should be released sometime before
the turn of the century - I promise!), I used a hash of inode number,
size and last-modified date, which amounts to the same thing as yours,
and I didn't see anything wrong with calling it a strong validator,
either.
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.
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.
[...]
> Certainly reading in the file and doing an MD5 or checksum of its contents
> each time we serve it is out of the question for performance reasons.
Agreed there.
> I would think with our file-based web server, numerous changes per second
> aren't as much of an issue as a database back-end that was generating
> content dynamically. I'm thinking that said dynamic application was the
> focus and intent of the restrictions on the strong validators, so maybe I
> can slide by?
I would think that a database application would have to come up with a
better way of making ETags, yes. But presumably that's something the
database is capable of doing. For a file-based web server such as
Spyglass Server or Apache, I think that we can certainly "slide
by".
But that's just my opinion.
--
________________________________________________________________________
Alexei Kosut <akosut@nueva.pvt.k12.ca.us> The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/ http://www.apache.org/
Received on Wednesday, 14 August 1996 23:58:21 UTC