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 : Monday, 7 December 2009 10:38:23 GMT