- From: Ted Hardie <hardie@merlot.arc.nasa.gov>
- Date: Thu, 15 Feb 1996 13:45:03 -0800 (PST)
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
In the Working group issues list, one of the comments on data integrity confused me a bit. The second of the two positions asserts that it is perfectly reasonable for a cache to do integrity checks, to avoid the cache serving nonsense to the end user. So far, I understand and agree. It goes on to say, however, that if the cache serves nonsense to the end user, the end user may re-request the document, thus correcting the problem in the cache. I'm not clear from the text whether this is meant to apply to the condition where integrity checks exist between proxy and server or whether it is meant to apply to the condition where they do not. If the former, then the integrity check would presumably be applied the first time the cache stored the item; if it passed somehow or was corrupted later, re-requesting the item won't clear the problem unless the proxy goes beyond current practice in re-checking the resource. Any time-based check, for example, won't fail until the resource has expired or changed. A really aware client might still get the correct resource despite the cache by reloading with a Pragma: request, but I can't see why the cache would take that as a signal to update its copy (rather than simply pipelining the request on to the origin server). Do we wish to suggest additions to current practice for the case where integrity checks are applied between proxy and server? If so, should these include: a method for the client to explicitly request a cache update, and/or recommendations for additional checks by the proxy when integrity checks are available? Ted Hardie NASA Science Internet
Received on Thursday, 15 February 1996 13:42:18 UTC