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

Re: spec review: ping attribute

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 26 Oct 2007 23:20:31 +0000 (UTC)
To: Julian Reschke <julian.reschke@gmx.de>
Cc: HTML WG <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0710262315200.7001@hixie.dreamhostps.com>

On Fri, 26 Oct 2007, Julian Reschke wrote:
> Ian Hickson wrote:
> >
> > POST is "unsafe" because invoking the method is allowed to have 
> > side-effects, like charging money, whereas GET requests are safe 
> > because they are supposed to be idempotent, meaning that no 
> > side-effects are supposed to happen.
> And thus the UA never ever should invoke POST without the consent of the 
> user.

We're long past that. It's trivial for a page to trigger a POST without 
the user knowing.

> > In the case of ping="", a major use case is informing a site when a 
> > sponsored link is followed, to enable the site to transfer money with 
> > a third party. This is a side-effect, and can only happen if the 
> > request is not an idempotent (GET, HEAD) request. POST is the most 
> > appropriate method for this use case.
> That's incorrect. GET and HEAD can have any side effects you want, as long as
> they do not affect the party issuing the POST. Citing
> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.1.1>:
> "The important distinction here is that the user did not request the
> side-effects, so therefore cannot be held accountable for them."

You omitted the earlier paragraph:

# 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.
 -- RFC2616:9.1.1:2

> > What do you think are the risks of using POST?
> There are some, as with GET/HEAD. Due to the nature of POST, the effects 
> may be more grave -- as you just cited ("charging money").

You are suggesting using GET to make money change hands. If we go that 
route, then what's the difference between GET and POST? You can't 
simultaneously say that POST is dangerous because it lets X happen and 
then say we should therefore use GET to let X happen. That's inconsistent.

> I personally think that the attribute in itself is a Very Bad Idea, but 
> if it stays in, by all means do not use POST for it.

We can't use GET... what other method would be appropriate?

> BTW: I just checked, and the Google Ads on www.google.de work with GET 
> and a Redirect (302). Only safe methods from the user's point of view. 
> Are you saying this is a problem?


> > > The spec continues with:
> > > 
> > > "When the ping attribute is present, user agents should clearly 
> > > indicate to the user that following the hyperlink will also cause 
> > > secondary requests to be sent in the background, possibly including 
> > > listing the actual target URIs."
> > > 
> > > This is good, but it's probably not clear enough -- at least FF3 is 
> > > ignoring this.
> > 
> > It's not clear to me how to make it clearer.
> You could say "must" instead of "should", for a start. You could also 
> propose one acceptable way to fulfill that requirement.

We shouldn't use "MUST" for issues that don't result in interoperability 
problems, that just weakens the other "MUST"s.

> > In the case of Firefox 3, the developers were very aware of the above 
> > requirement, as well as its implications, and intentionally decided to 
> > violate the SHOULD for the time being. It isn't clear to me that there 
> > is anything I could do to the _spec_ to change their mind. (It's not 
> > like they just missed the above paragraph or didn't understand it.)
> Well, they ignored it, yet made the functionality the default. It's a 
> very clear signal that we have a problem here.

We could remove the paragraph.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 26 October 2007 23:20:44 UTC

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