Does unsubscribe link need to be idempotent? [closed]

Question

So we have an unsubscribe link - this is by it's nature an HTTP GET.

The appropriate RFC says this should be idempotent but to my mind the user expectation will be that they are clicking a link to take an action.

I've implemented this so that the link takes you to a page that has a big confirm button which then updates your subscription, confirms that and displays the final state of your account (we have more than one type of subscription)

But I wonder if it would not be a better UX if the person simply skipped the confirm button stage...

The answer to the question "Am I overthinking this?" is definitely yes but I wondered what people's views were on balancing the best practice of an idempotent GET with the best practice of not confounding user's expectations...

Neckwear

The GET link to your unsubscribe page is idempotent, because it always produces the same unsubscribe page (provided you have no unintended side effects like counting the click twice). Yes, you're overthinking it. – Outstanding

@Robert it would be dangerous to have a unsubscribe action on a link, software that prefetch sites (should be possible) assume that nothing is lost on GET (as the standard says, see Ross's answer). E.g. see Google Accelerator – Semen

@Jonas: That's not what I said. To clarify, the unsubscribe link should produce an unsubscribe page, which uses POST to take the unsubscribe action, not GET. – Outstanding

@Robert: Ah, I get it, I misunderstood your first comment. Thanks for the clarification. – Semen

I'm surprised this has been closed... how is it not about software development?? – Heavenward

Answer 1

I'd say it doesn't matter what RFC2616 section 9.1.2 says, because you're already violating the much more important definition in seciton 9.1.1:

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.

Imagine the effect of a web-crawler (e.g., Google) following all the links from one of your pages that contains this link. Do you really want that to cause an unsubscribe operation? That would certainly be a bad user experience!

Brasilein

The links are in emails. Not online. You can't crawl to any page that would contain a confirm button. Additionally the links don't identify the user numerically so someone can't just loop through every int trying to unsubscribe people. – Heavenward

"You can't crawl to any page that would contain a confirm button". I suppose, in fairness, that's not strictly true. The URLs with GET allowed are in the format web.web.co.uk/[subscription-type]/[email-address] and URLs with POST allowed are in the format web.web.co.uk/[sub-type]/[action]/[email address]. So you could take a gigantic list of email addresses and attempt to subscribe/unsubscribe them maliciously but you're super unlikely to guess email addresses that are really in our DB – Heavenward

@Paul: Ross is right (+1), it's dangerous to remove stuff with a link (GET), e.g. latest chrome browser can prefetch sites from google, and it could be the case a custom email client e.g. on andriod, prefetch all the links in the email to get a better user experience, and this should work per HTTP protocol. See also Google Accelerator that prefetch web pages to get a faster Internet. – Semen

We seem to be at cross purposes... I'm not removing with a GET - but I am being pushed to improve the UX by doing so. I'm just fishing for confirmation (and learning) – Heavenward

But I didn't know what prefetching was... that seems to be the killer argument there! So if 70,000 have a particular custom email client then boom 70k unwitting unsubscribes. Ouch! – Heavenward

@Paul: GET request can also be cached, POSTs are not. So if a user unsubscribe, then subscribe again, and finally want to unsubscribe again, that request may be cached so the user isn't unsubscribed this time since the request isn't sent to the server. – Semen

Answer 2

Idempotent means, in this context, that no matter how many times you click on the link it will do the same thing, i.e. unsubscribe you. There have been some solutions that will resubscribe you if you return, a kind of flip-flop approach, i.e. non-idempotent. Whether you implement this as an immediate unsubscribe (my preferred approach as a user who's motivated enough to click the link is sure that's what they want to do) or a page with a confirm is up to you. Just make sure that no matter how many times a user clicks your link and completes the process that they are, at the end of it, still unsubscribed from your list.

Rhombohedral

Answer 3

The interesting question is not whether it's idempotent, but whether it's safe. It is not, thus a simple GET (which, for instance, might be prefetched), is wrong.

Kreiner

You've lost me there. Do you mean that to unsubscribe via GET isn't safe? – Heavenward

Yup, that's what he means. Imagine that the email containing this link is being read in a web-based email client (e.g., GMail). When the user opens the mail item, some browsers will pre-fetch the pages that links point to, so that if the user clicks on them, they appear to load faster. Unfortunately, your URL would qualify as pre-fetchable, and the action would be triggered. – Brasilein

"Safe" in this context is the meaning from RFC 2616 section 9.1.1, which I quoted in my answer. – Brasilein