If the link you are trying to send is just some kind of harmless confirmation link (e.g. subscribe/unsubscribe from a newsletter), then at least use a form inside the web page to do the actual confirmation through a POST request (possibly also using a CSRF token), otherwise you will unequivocally end up with false positives.

Drupal use a HTTP GET to change data witch is not how HTTP protocol is supposed to be work. A HTTP POST request should be used to change an account from blocked to active. It's a bug and a ugly one.

If you want to be (relatively) sure that any action is triggered only by a (specific) human user, then use URLs in emails or other kind of messages over the internet only to lead them to a website where they confirm an action to be taken via a form, using method=POST

Links (GETs) aren't supposed to "do" anything, only a POST is. For example, your "unsubscribe me" link in your email should not directly unsubscribe th subscriber. It should "GET" a page the subscriber can then post from.

The purpose of distinguishing between safe and unsafe methods is to allow automated retrieval processes (spiders) and cache performance optimization (pre-fetching) to work without fear of causing harm.

Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource.

But anti- spam software often fetches all resources in mail header fields automatically, without any action by the user, and there is no mechanical way for a sender to tell whether a request was made automatically by anti-spam software or manually requested by a user. To prevent accidental unsubscriptions, senders return landing pages with a confirmation step to finish the unsubscribe request. A live user would recognize and act on this confirmation step, but an automated system would not. That makes the unsubscription process more complex than a single click.

This document describes a method for signaling a one-click function for the List-Unsubscribe email header field. The need for this arises out of the actuality that mail software sometimes fetches URLs in mail header fields, and thereby accidentally triggers unsubscriptions in the case of the List-Unsubscribe header field.

> I should have used "side-effect-free" instead of "idempotent" in my tweetsThe HTTP term is "safe method".

So long as the filters are only using GET requests to pull down links, there’s nothing fundamentally wrong with them. It’s a basic (though oft-ignored) tenet of web development that GET requests should be idempotent; that is, they shouldn’t somehow change anything important on the server. That’s what POST is for. A lot of people ignore this for convenience’s sake, but this is just one way that you can get bitten. Anyone remember the Google Web Accelerator that came out a while ago, then promptly disappeared? It’d pre-fetch links on a page to speed up things if you clicked them later on. And if one of those links happened to delete something from a blog, or log you out… well, then you begin to see why GET shouldn’t change things. So yes, the perfect solution to this is a 2-step unsubscribe link: the first step takes to you a page with a form on it, and that form then POSTs something back that finalizes the unsubscribe request.

Idempotent just means that following a link twice has exactly the same effect on persistent state as clicking it once. It does not mean that following the link must not change state, just that after following it once, following it again must not change state further. There are good reasons to avoid GET requests for changing state, but that’s not what idempotent means.

Arguably any link that performs such an action via GET is fundamentally broken. A proper unsubscribe should direct to a page with a form that requires a POST submission. (Of course, in the real world, few things are proper.)

This is not advice. A GET is defined in this way in the HTTP protocol. It is supposed to be idempotent and safe.

An HTTP method is safe if it doesn't alter the state of the server. In other words, a method is safe if it leads to a read-only operation.