RE: Feedback on ISSUE 27 (PUT idempotency)

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: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org]
On Behalf Of Henrik Nordstrom
Sent: Wednesday, January 03, 2007 6:17 AM
To: Julian Reschke
Cc: ietf-http-wg@w3.org
Subject: Re: Feedback on ISSUE 27 (PUT idempotency)

ons 2007-01-03 klockan 11:08 +0100 skrev Julian Reschke:
> (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>

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

Received on Wednesday, 3 January 2007 19:06:35 UTC