Subject: Changing PUT's idempotency after the fact [was: WebDav methods and idempotency]

From: Mark Nottingham <[email-masked]>
Date: Wed, 16 Mar 2005 12:50:56 -0800

It *appears* that RFC3253 changes the idempotency of PUT; is this 
allowed? RFC3253 doesn't update or obsolete 2616...

I can see a situation where a 3253-naive client decides to retry a 
timed-out PUT (after all, it's idempotent) and gets some side effects 
it didn't bargain for. Not a *huge* problem that happens every day, but 
it's a bit worrisome.

Thoughts?

Begin forwarded message:

> From: Mark Nottingham <[email-masked]>
> Date: March 6, 2005 9:43:11 PM PST
> To: Julian Reschke <[email-masked]>
> Cc: [email-masked]
> Subject: Re: WebDav methods and idempotency
>
> Hmm, that seems to be revising the semantics of PUT to be 
> non-idempotent; doesn't seem like a good idea...
>
>
> On Feb 26, 2005, at 12:27 AM, Julian Reschke wrote:
>
>> RFC3253 allows PUT and COPY (target resource) to be auto-versioned. 
>> That is, everytime you PUT to a URI, you may be -- as a side effect 
>> -- creating a new version (and the DeltaV live properties on the 
>> resource will reflect this). Can we still consider this idempotent. 
>> RFC3253bis should say something about this..
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>

--
Mark Nottingham     http://www.mnot.net/

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 16 Mar 2005 21:30:32 +0000

> it didn't bargain for. Not a *huge* problem that happens every day, but 

Hopefully there's an ETag and such clients use it, in these scenarios.

-- Jamie

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 16 Mar 2005 14:19:27 -0800

Well, that's a potential workaround, if both clients and servers know 
to use it. I don't know enough about WebDAV autoversioning; is that a 
specified behaviour (e.g., submit an ETag and then do INM in a 
subsequent retry)?

My concern is more regarding the process; having one RFC change the 
semantics of a protocol element in another, widely-deployed RFC seems 
like a no-no, at least without explicitly updating the other spec.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Mar 2005 00:58:28 +0100

Mark Nottingham wrote:
> 
> Well, that's a potential workaround, if both clients and servers know to 
> use it. I don't know enough about WebDAV autoversioning; is that a 

If you do two PUTs with If-Match request header specifying the same 
Etag, the second one will fail if the first one succeeded (that's HTTP, 
any RFC3253 server that doesn't behave that way would be non-compliant).

> like a no-no, at least without explicitly updating the other spec.

Agreed. The question is: does it? Note that it only applies to a very 
specific auto-versioning behaviour and it's impact on the resource's 
live properties.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760