Re: Zero-edits Counter Proposal for Issues 1 and 2 (Ping)

On Wed, Feb 17, 2010 at 8:18 AM, Julian Reschke <> wrote:
> On 15.02.2010 16:48, Tab Atkins Jr. wrote:
>> ...
>>> Also, as described in ISSUE-1, ping's use of POST causes an
>>> unsafe method to be used in response to a safe activation request,
>>> in violation of the method constraints that have been part of
>>> Web architecture since 1992.
>> POST is the correct method to use to reflect @ping's semantics.
>> ...
> It's not! It is!
> Not helpful.
> Citing Roy again:
> "The actions generated by a user agent should be consistent
> with the actions selected by the user.  That is why TimBL had an axiom
> about GET being safe -- clicking on a link (or a spider wandering
> around) must be translated into a safe network action because to do
> otherwise would require every user to know the purpose of every
> resource before the GET.  It follows, therefore, that the UI for a
> user action that is safe (a link) must be rendered differently from
> all other actions that might be unsafe.
> In short, if the UI is being presented as a normal link, then the
> HTTP methods resulting from the user's selection must all be safe
> (GET/HEAD/OPTIONS/etc.).  While some user agents may already fail
> to protect the user in that regard, that is not an excuse to add
> another broken feature to the standard. Implementors are responsible
> for their own implementations.  We are only responsible for the
> standards by which those implementations are judged broken."
> So, *if* you want to "ping" a server, better use a method defined to be
> safe. BTW: this doesn't rule out defining a new method.

A ping url causes a change on the server.  That's it's entire purpose;
it *must* be unsafe to follow multiple times.  So you can't ever try
and call a ping url "safe", because *by definition* it isn't.

The argument that @ping should use a safe method is based solely on
user interface concerns (that is, the argument that a UA should always
make it clear to the user that a given request-initiating interaction
will result in a safe or unsafe request), and the fact that it
piggybacks on normal link-following, which triggers a safe request.
That argument has never been true in practice, and since the invention
of CSS it's been *extra* untrue.  UAs make only *one* distinction
between safe and unsafe methods (or rather, between GET and POST - I
don't know if they distinguish for any other methods), and that is
when you attempt to refresh a page requested via an unsafe method.
That distinction isn't relevant for @ping.

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.


Received on Wednesday, 17 February 2010 15:31:24 UTC