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

On Wed, Feb 17, 2010 at 8:18 AM, Julian Reschke <julian.reschke@gmx.de> 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.

~TJ

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