- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Mon, 04 Mar 96 15:23:36 PST
- To: Shel Kaphan <sjk@amazon.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Shel writes:
Dave Long writes:
>
> >>semantically equivalent to a CREATE. For now I'm using a "magic"
> >
> >Why isn't put of a non-existent object good enough?
>
> It *is* good enough.
>
> I was referring to a problem which arose in the context of
> version-control, where one might wish a PUT request to fail
> if there was an existing (possibly very recently created)
> object.
>
> That problem is probably outside the scope of this working-group;
> perhaps I shouldn't have piggy-backed it upon my reply to a
> different issue.
>
> -Dave
It seems to me to be very much in the domain of this working group,
and has been discussed before, in connection with conditional requests
of all sorts. There was a discussion about "unless-modified-since"
(or "if-valid") headers some time back, to make the action of PUT
conditional on the server's version still being the same as the most
recent one the PUTter had received. I don't think this has been
fully worked out yet.
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.
-Jeff
Received on Monday, 4 March 1996 15:37:41 UTC