- From: S. Mike Dierken <mike@dierken.com>
- Date: Fri, 21 Oct 2005 23:34:03 -0700
> > 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.
Received on Friday, 21 October 2005 23:34:03 UTC