Re: Cache validators

Jeffrey Mogul:
>    Since it is unlikely that anyone will ever implement a system which
>    only changes the validator for "significant" changes, I think it
>    would be silly to lose the additional functionality gained from a
>    guaranteed change indicator.
>Well, here's one example: supposing that a busy site with
>slowly-varying content wants to maintain a hit-count image on
>its home page.  (Whether you yourself think this is something worth
>doing, clearly a lot of people want to do it.)  It's probably not
>all that important if a user sees a hit-count that is slightly
>inaccurate, nor is it worth using up a lot of network bandwidth
>to provide accurate hit counts.
>So supposing that the server constructed an opaque validator
>for a hit-count GIF that is simply an encoding of the hit-counter
>mod 10 (or mod 100, or mod 128, or whatever).  Then a large
>fraction of the GET+If-Valid: requests on this GIF would return
>304 Not Modified, even though the count might have increased

The correct thing to do in this case is to make the comparison function used
for servicing the GET+If-Valid requests a mod 10 comparison, not to make the
validator the mod 10 of the version number.

If 10 subsequent (but semantically almost equal) versions of the .gif get
the same opaque validator, this means that the validator is useless for
safely contining an interrupted GET with a GET+If-Valid+Range request.

I see safe continuation of interrupted GETS as the main reason for having an
opaque validator in the first place.



Received on Tuesday, 12 March 1996 07:31:03 UTC