[whatwg] <a href="" ping="">

[S. Mike Dierken]

> 
> It definitely should be a POST, because the action performed by it is not
idempotent. See [1].
I agree is seems logical to use POST - the actual URI being visited by the
user likely would be in the content body (although a request header similar
to Referer could be used) and no state from the server is being retrieved,
but it still bugs me. Maybe I'm just reacting to the (lack of) privacy
issue.

> 
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2

Section 9.1.1 - "...allow the user to be aware of any actions they might
take which may have an unexpected significance..."
"...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."

Will the user-agent represent these links in a special way, so the user is
made aware of the fact that a possibly unsafe action is being requested?


> 
> I would say it's OK to send a POST as a side effect because 
> it's going to an URL where the developer expects a POST. 
But that's not what the user clicking the link expects.


> If you can come up with a reason why it's not safe, I'd like to hear it.
My initial reaction was to be concerned about a malicious link that
triggered a POST for a resource that becomes modified or deleted - like
href="http://www.flickr.com/photos/dierken/?delete=39177102&magic_cookie=528
479cac210fc6z837c0ac708334fe6" (Those freaking blockheads at Flickr just
deleted my picture when I pasted that URI into the browser window. Losers -
when will they realize that an anchor is not a UI widget. Thank goodness
that I don't have a pre-fetch utility running or I'd lose all my vacation
photos.)

But of course anybody that can cause that extra attribute to appear on an
anchor, likely has enough control to do some damage anyway.