W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1996

Re: POST vs. separate methods

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
Message-ID: <Pine.SGI.3.95.961029082505.9227A-100000@shellx.best.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:09 UTC