W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2005

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

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 16 Mar 2005 14:19:27 -0800
Message-Id: <5ecc3481adff2ebb2f28ca705db763d7@mnot.net>
Cc: HTTP working group <ietf-http-wg@w3.org>
To: Jamie Lokier <jamie@shareable.org>

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.


On Mar 16, 2005, at 1:30 PM, Jamie Lokier wrote:

>
> Mark Nottingham wrote:
>> 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.
>
> Hopefully there's an ETag and such clients use it, in these scenarios.
>
> -- Jamie
>
>
>

--
Mark Nottingham     http://www.mnot.net/
Received on Wednesday, 16 March 2005 22:19:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:39 GMT