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 

> 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 

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