W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2005

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

From: S. Mike Dierken <mike@dierken.com>
Date: Fri, 21 Oct 2005 23:34:03 -0700
Message-ID: <20051022063400.6911F107AED@legolas.dreamhost.com>
> 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

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

But of course anybody that can cause that extra attribute to appear on an
anchor, likely has enough control to do some damage anyway.
Received on Friday, 21 October 2005 23:34:03 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:43 UTC