- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 17 Feb 2010 14:33:53 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Maciej Stachowiak <mjs@apple.com>, public-html@w3.org
On Wed, Feb 17, 2010 at 2:03 PM, Julian Reschke <julian.reschke@gmx.de> wrote: > On 17.02.2010 22:51, Tab Atkins Jr. wrote: >> >> 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. > > Of course it is done in practice. People are accustomed to the fact that > buttons mean "put in shopping basked"/"buy"/"delete", while blue underlined > terms are links. > > I'm aware that these things are styled, and hacked around, but please don't > claim that this is not the *default* way to present things. This is only partially true. <form>s have a different UI than links, yes. However only most of the time. For example a <input type=image> has the same UI as an <a><img></a>. And <form>s have the same UI no matter if they use POST or GET. Additionally XMLHttpRequest has no UI at all, no matter if it uses GET, POST or DELETE. The fact of the matter is that unsafe requests happen all the time today without the browser enforcing any UI on the user. We don't put up UI when POSTs happen. Instead we rely on websites to honor the HTTP spec and use methods for their intended purpose. I don't see what is wrong with following this pattern and relying on websites to use the new PING method for its intended purpose. Ultimately we are all here to improve the web. Arguing that something doesn't follow the letter of a spec is a fairly uninteresting argument to me. What matters is if it causes problems or not. Websites changing from using redirects to do tracking, to using PING to do tracking doesn't change what happens in the real world as far as side effects for a given UI goes. It in fact only *reduces* the amount of abuse of HTTP. / Jonas
Received on Wednesday, 17 February 2010 22:34:50 UTC