Hacker News Reader

Comment by henning | Hacker News Reader

Furthermore, links which appear to perform non-idempotent actions (voting) which are sent as GET requests seem kind of sketchy.

Ever hear the horror story about what happens when Google rolls through your CMS that has the "delete" button as a link?

View on HN

Voting and deletion are both idempotent, they just aren't side-effect free. The weaker condition of idempotence is all you need for GET, because it's sufficient for guaranteeing that caching won't break things. The solution to the problem with Google is to not let anonymous users delete pages irrevocably.

That's a good distinction. I had to look up the HTTP 1.1 RFC, 2616 and read section 9.1.1 "Safe Methods" to note that while what you're saying is correct, the RFC does strongly discourage... well, here:

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". 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.

Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

unless the search indexer has registered, logged in, and posting stories and comments, its a non-issue

Yes, that's fine as long as your logged in users don't use some form of "web accelerator" that pre-fetches "delete" links.

Using get instead of post for these kind of actions is just asking for trouble.

I take the BOFH outlook on this: that problem is isomorphic to the problem of a user leaking his account credentials to a malicious third party and should be dealt with in the same manner.

thats true. [adding to the TODOs for my web app. :sigh:]

You can just add rel="nofollow" to those links, by the way.

Edit: Or so I thought. I'm wrong.

It turns out there's no standard for this, so who knows what you can do today. But practically, Google Web Accelerator doesn't prefetch links with a query string, at least currently. So Paul's voting links are A-OK with GWA. And that's the only one that you need to worry about, at least today.

do all web accelerators obey that?

All the good ones follow specifications and good practices religiously. But I've never met a good one.

Thanks for asking, I double-checked and there are of course not even any informal standards for web accelerators, apart from their common appeal to the HTTP 1.1 standard when the issue of link following safety comes up:

http://webaccelerator.google.com/webmasterhelp.html#prefetch...

I've edited my post. Thanks for your reply.

Using some form of "web accelerator" is asking for trouble. I consider Paul's method better than requiring Javascript to vote or making the voting links some wacky kind of button element.

If HTML had a method="post" option on <a>'s then it would be no problem to always use the proper HTTP verb, but we have to satisfice with what we've got.

I, too, have often wished for the method attribute you describe.

That said, if you're already using javascript (as news.YC is), I really don't see why you wouldn't make use of xhr. In which case you could submit the request as a post.

Note: I haven't poked around enough to see if news.YC works without javascript. If they degrade gracefully, more power to them, and I can almost understand the decision to do it the way they have.

Reply on news.ycombinator.com