Subject: Feedback on ISSUE 27 (PUT idempotency)

From: Julian Reschke <[email-masked]>
Date: Wed, 03 Jan 2007 11:08:43 +0100

(see <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i27>)

This topic was just discussed over on rest-discuss, and I think the 
recommendation is to relax/rephrase the definition of idempotency.

See: <http://tech.groups.yahoo.com/group/rest-discuss/message/7387>

Best regards, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 03 Jan 2007 15:16:36 +0100

> See: <http://tech.groups.yahoo.com/group/rest-discuss/message/7387>

Hmm.. PUT indeed is a odd beast in this discussion. 2616 in this quite
clearly does not consider much servers using revision control or similar
where each executed PUT has irreversible and unique sideeffects (i.e.
new revision created), only focusing on blind store of PUT entities.

It can be argued that such applications of HTTP should also use
'If-Match: "OldEtag"' on update, and 'If-None-Match: *' on create to
guard themselves if those side-effects is important to the application.
But this scheme fails is the server application can not use strong
ETag:s.

It's unfortunately hard to get this down into good writing, as to many
applications those side-effects is of no importance at all. I.e.
consider a revision controlled server used as dumb file storage by the
clients. To the clients the PUT requests is probably idempotent as it
does not matter that multiple revisions of the same content got created
on the server so adding restrictions on when PUT is idempotent based on
conditionals like above is not quite appropriate.

Maybe rewriting 9.1.2 to read "the <ins>significant</ins> side-effects
of N > 0 ..." would do? Leaving it up to each application to define
whats 'significant'.

Regards
Henrik

---

From: Paul Leach <[email-masked]>
Date: Wed, 3 Jan 2007 11:05:55 -0800

The definition of idempotent is a little too strict.

A better definition would say that if there are two identical PUTs to a
URI and then a GET to the _same_ URI, it should behave the same as just
one PUT and then a GET to that URI. It is overly restrictive to talk
about GETs to _other_ URIs (such as the ones that contain version
numbers).

However, even the above is tricky -- concurrent writers can intervene
between a PUT and a GET, so the client can't in general actually count
on using the above definition. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Henrik Nordstrom
Sent: Wednesday, January 03, 2007 6:17 AM
To: Julian Reschke
Cc: [email-masked]
Subject: Re: Feedback on ISSUE 27 (PUT idempotency)

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 04 Jan 2007 08:16:41 +0100

> about GETs to _other_ URIs (such as the ones that contain version

Agreed.

> on using the above definition.

The problem with concurrent writer cases should be obvious to most
implementers, and is additionally covered in "14.24 If-Match" and "14.26
If-None-Match". Only significant problem there related is that it's not
trivial for a client to differentiate between a missing response to PUT
where the action had actually been carried out, or other concurrent
write access to the same URI. Perhaps adding a reference to these would
clarify things a bit.

But still, most often concurrent access does not change the idempotence
property of the request as such. idempotence is about the effects on the
server state of this request, not the lost update problem.

Regards
Henrik

---

From: "Mark Baker" <[email-masked]>
Date: Thu, 4 Jan 2007 08:27:41 -0500

> > about GETs to _other_ URIs (such as the ones that contain version

I dunno, I think it would be better to avoid mention - let alone
definition - of idempotence, and remove 9.1.2, as the word already has
a definition outside the context of RFC 2616.  What's important is the
meaning of PUT, and though I suppose what's there now implies
idempotence via the use of "store", it's not a great definition
(because "store" is too specific and can be interpreted to describe
implementation behaviour rather than message semantics).  IMO, it need
say little more than "The PUT method requests that the resource
identified by the Request-URI have its state set to that represented
by the enclosed entity".

Perhaps that's too large a change for the scope of this work though.

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com