W3C home > Mailing lists > Public > public-html@w3.org > November 2007

Re: Feedback on the ping="" attribute (ISSUE-1)

From: Mark Baker <distobj@acm.org>
Date: Sun, 4 Nov 2007 15:05:22 -0400
Message-ID: <e9dffd640711041105j1a330743g9a06e25a3e51f8da@mail.gmail.com>
To: "Ian Hickson" <ian@hixie.ch>
Cc: "Julian Reschke" <julian.reschke@gmx.de>, "HTML WG List" <public-html@w3.org>

On 11/3/07, Ian Hickson <ian@hixie.ch> wrote:
> > So it seems it would be good to clarify whether following an audited
> > link is safe (in HTTP terminology) or not.
> >
> > If it is, it should use a safe method.
> If the entire HTTP request and response transaction is safe, then it
> doesn't matter what method we use, since using an explicitly "safe" method
> wouldn't make the transaction any safer (in the HTTP sense).

You appear to be confusing two different things, Ian.  When we say
that an HTTP message is "safe", we're using the word to refer to the
meaning of the message.  In the paragraph above, you seem to be using
it to refer to the behaviour of the recipient.  Those are two
completely different things ("orthogonal", as Julian states).  HTTP,
as a protocol, is concerned almost entirely about the former meaning,
and hardly at all about the latter.

This is key to understanding why the use of POST is actively harmful
for this feature.

> > Following that line of argument you need a method which is safe and
> > idempotent, which is not defined in RFC2616.
> Indeed. In the absence of such a method, though, "POST" with a semantic
> that is defined to be safe in the HTTP sense seems to satisfy our needs.

(assuming you both mean "non-idempotent" there)

> > Of course you could define one.
> It seems out of scope for HTML to define new HTTP methods.

Also, you couldn't define a safe and non-idempotent method.  All safe
methods are idempotent by definition.

Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com
Received on Sunday, 4 November 2007 19:05:36 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:28 UTC