- From: Dave Long <dave@navisoft.com>
- Date: Mon, 04 Mar 1996 22:10:18 -0800
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: Shel Kaphan <sjk@amazon.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Jeffrey writes:
> This should be possible to do with the opaque-validator mechanism
> I described in draft-mogul-http-caching-00.txt (and probably with
> modification-date-based validators, or logic bags, as well).
>
> Two similar situations:
>
> (1) PUT should fail if resource already exists
> PUT /foo HTTP/1.1
> If-valid: ""
>
> The null validator ("") is defined to never match the actual
> validator, so if the resource /foo exists, this PUT fails.
> We would need to add a few words explaining what the server
> should do for a non-existent resource (i.e., treat it as if
> it had a null validator).
>
> (2) PUT should fail if the underlying resource has been
> changed since the last time that the client retrieved it:
> PUT /foo HTTP/1.1
> If-valid: "asdka123897"
> assuming that "asdka123897" was the validator returned from
> a previous GET, this request succeeds if the resource is
> unchanged, fails otherwise.
These are the situations which I alluded to; I am pretty sure
that my use of Derived-From with the magic Content-Version ("nonexistent")
is isomorphic to If-Valid with the magic null validator ("")
-Dave
Received on Monday, 4 March 1996 22:11:49 UTC