Re: spec review: ping attribute

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.

> 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."

> 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"). 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.

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.

> 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.

Best regards, Julian

Received on Friday, 26 October 2007 21:11:16 UTC