Re: POST vs. separate methods

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