- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 17 Feb 2010 15:51:53 -0600
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Maciej Stachowiak <mjs@apple.com>, public-html@w3.org
On Wed, Feb 17, 2010 at 3:31 PM, Julian Reschke <julian.reschke@gmx.de> wrote: > On 17.02.2010 22:17, Maciej Stachowiak wrote: >> 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. I think that a potentially important distinction here is that, say, incrementing a hit counter is an incidental side effect of the otherwise-innocuous page request. A @ping-initiated request doesn't have the server change as a side-effect, it's the entire point of the request. The server change can be thought of as a side-effect of the *user interaction*, but as I said (and Jonas has now concurred with), making a user-interaction-level distinction between safe and unsafe methods is *not* done in practice, and experience shows that when it has been attempted it's been a bad idea. It seems to be a harmful mixing of layers. ~TJ
Received on Wednesday, 17 February 2010 21:52:40 UTC