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

On Wed, Feb 17, 2010 at 7:41 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 17.02.2010 16:30, Tab Atkins Jr. wrote:
>>
>> 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.
>> ...
>
> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.1.1>:
>
> "9.1.1 Safe Methods
>
> Implementors should be aware that the software represents the user in their
> interactions over the Internet, and should be careful to allow the user to
> be aware of any actions they might take which may have an unexpected
> significance to themselves or others.
>
> In particular, the convention has been established that the GET and HEAD
> methods SHOULD NOT have the significance of taking an action other than
> retrieval. These methods ought to be considered "safe". This allows user
> agents to represent other methods, such as POST, PUT and DELETE, in a
> special way, so that the user is made aware of the fact that a possibly
> unsafe action is being requested.
>
> 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."
>
> Note the last paragraph - what's relevant is whether the *user* is
> requesting side-effects; and this is *clearly* not the case when navigating
> to another document.

The fact that the HTTP spec mandates UI is a really bad idea.

First of all it's something that has never been followed by any
mainstream browser completely. And in the random places where it has
been followed, it has resulted in a terrible user experience that
hasn't helped users in any way with the problems the HTTP spec is
attempting to solve.

The HTTP spec simply needs to be fixed here. I really hope that is
happening in HTTPbis? If people want to wait with building other specs
that rely on HTTP being fixed then so be it, though I can't really say
I agree with the logic.

I'm fine with punting the ping attribute to the "future developments"
stuff that WhatWG is doing. I don't think that will affect the
implementation schedule in Firefox in either direction (i.e. neither
slow it down or speed it up).

/ Jonas

Received on Wednesday, 17 February 2010 21:26:12 UTC