- 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