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

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 UTC