- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 17 Feb 2010 14:59:49 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, public-html@w3.org
On Feb 17, 2010, at 1:31 PM, Julian Reschke wrote: > On 17.02.2010 22:17, Maciej Stachowiak wrote: >> >> On Feb 17, 2010, at 7:41 AM, Julian Reschke wrote: >> >>> On 17.02.2010 16:30, Tab Atkins Jr. wrote: >>> >>>> .. >>>> It's possible that we could define a new method for @ping, call it >>>> PING. It would still be "unsafe", that is, not idempotent, by >>>> definition. I'm not sure what possible benefits this could bring >>>> over >>>> just using POST, though. >>>> ... >>> >>> "safe" and "idempotent" are different things. >> >> Aren't all "safe" methods also "idempotent" by definition? > > Almost. > > Except for the side effects that a safe method is allowed to have, > such incrementing hit counters etc.: > > "Naturally, it is not possible to ensure that the server does not > generate side-effects as a result of performing a GET request; in > fact, some dynamic resources consider that a feature. The important > distinction here is that the user did not request the side-effects, > so therefore cannot be held accountable for them." > > If you ignore those potential side effects as self-inflicted by the > server (and not requested by the user), then yes, a safe method is > also idempotent. Those self-inflicted side effects are ignored by HTTP in its definition, right? All I meant to say is that any method that is "safe" by HTTP's definition is also "idempotent" by HTTP's definition. Conversely, any method that is not "idempotent" is automatically not "safe". So even though they are different concepts, due to the way they are related, Tab's point quoted above was valid. Regards, Maciej
Received on Wednesday, 17 February 2010 23:00:21 UTC