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

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

From: Jasper Bryant-Greene <jasper@album.co.nz>
Date: Sat, 22 Oct 2005 19:39:30 +1300
Message-ID: <1129963170.15734.11.camel@jasper.local>
On Fri, 2005-10-21 at 23:34 -0700, S. Mike Dierken wrote:
> > 
> > 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.

See below.

> > [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 think the issue is how this action can possibly be unsafe.

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

It has no effect on them. It merely allows the website owner to track
their clicks in the same way they already do with redirects.

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

I would certainly hope that Flickr requires authentication before an URL
like that had any effect, in which case the developer of the website
would only be able to delete their own photos, or photos of those whom
they had stolen the authentication details for. This is not exactly a
new problem.

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

Exactly. If Flickr wanted to delete your photos, I don't think they'd
bother to try to fool you into clicking on a link. They'd just delete
them.

-- 
Jasper Bryant-Greene
General Manager
Album Limited

e: jasper at album.co.nz
w: http://www.album.co.nz/
p: 0800 4 ALBUM (0800 425 286) or +64 21 232 3303
a: PO Box 579, Christchurch 8015, New Zealand
Received on Friday, 21 October 2005 23:39:30 UTC

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