- From: Gregory J. Woodhouse <gjw@wnetc.com>
- Date: Tue, 29 Oct 1996 08:38:31 -0800 (PST)
- To: Larry Masinter <masinter@parc.xerox.com>
- cc: ejw@kleber.ics.uci.edu, w3c-dist-auth@w3.org
On Mon, 28 Oct 1996, Larry Masinter wrote: [...] > > A secondary issue (which doesn't actually affect the choice) is the > question of cache invalidation, e.g., after copy(a, b), any cache > entries for B should be invalidated even if are otherwise fresh, if > we're going to require sequential transparency of information > delivered through the same set of proxies. > > E.g., if you do copy(a, b) and then ask for b, then YOU see the > version you copied even if others who use a different cache might be > updated later. > > This is already an issue for POST, PUT and DELETE, but http-wg didn't > (yet) create any mechanism for doing this. > > Larry > This is actually an issue in which I have an interest. At present, the approach I am contemplating is to 1. Require that the resource have a validator which is guaranteed to be replaced with a new value upon update. I.e., an update to a resource cannot result in a new validator which is equal to the validator for an earlier version of the same resource. 2. Perform conditional GETs using If-Match on the validator. This is not yet an alorithm and there are certainly issues with HTTP/1.1 caches, but I think that a HEAD request will return the current entity tag in all cases, and once this value is retrieved a conditional GET using If-Match will fail in the case of a race condition (an intervening PUT, POST or DELETE that modifies the resource). I hope you'll forgive the preliminary nauture of my thoughts here. --- Gregory Woodhouse gjw@wnetc.com home page: http://www.wnetc.com/ resource page: http://www.wnetc.com/resource/
Received on Tuesday, 29 October 1996 11:38:56 UTC