- From: Koen Holtman <koen@win.tue.nl>
- Date: Tue, 12 Mar 1996 16:24:14 +0100 (MET)
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: fielding@avron.ICS.UCI.EDU, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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 >slightly. 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. >-Jeff Koen.
Received on Tuesday, 12 March 1996 07:31:03 UTC