The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Don't Let Users Confirm Via HTTP GET

http://www.artima.com/weblogs/viewpost.jsp?thread=152805

"While it may be attractive from the usability perspective to let users click on a link in an email to confirm a registration, it violates one of the cardinal rules of the web: don't change state on HTTP GET requests. This weblog post explains the problem and suggests solutions."

This is just REST philospohy for philosophy sake.

The easiest thing for the user is to confirm directly from the email. That should be the end of it. I don't care if you get/post/send a carrier pidgeon.
son of parnas
Tuesday, March 21, 2006
 
 
I do exactly that with my site - confirm using a GET request.  I've had no complaints and changing it would only hurt my confirmation conversion rate.

But, I can see things going horribly wrong if important functions, say for example within phpMyAdmin, did not require a POST confirm and every link was prefetched for some reason (say, web accellerator product).  Yikes!
Derek
Tuesday, March 21, 2006
 
 
In a get link is there a way to indicate it shouldn't be cached?

Designing around hypothetical web accelerators just seems wierd. You still have to age caches etc so caches can do a lot of bad things. Should I post to get all my images just to make sure they are fresh?
son of parnas
Tuesday, March 21, 2006
 
 
I agree with you in this specific instance.  You can't reliably embed an HTML form in an email, so GET is all you have.

In general, however, I agree that nothing should be changed from a GET.  But no rule stands up to every instance, as evidenced here.
Deane Send private email
Tuesday, March 21, 2006
 
 
It is a good article by Bill Venners, but I tend to agree with the OP here. The article says that logging "a user's GET requests (which changes state on the server)" is okay, but changing the state that the user "agreed to something" is not. This is the weak point in his argument because you are shifting the meaning of this "cardinal rule of the web," proving it is really NOT a cardinal rule of the web, in fact it is just merely a conceptual rule of REST.

The governing rule in this case is user convenience, and sacrificing that would require a much better case. He briefly mentions "prefetching" but it is not a compelling reason to avoid GET for an unsubscribe action.
Ben Bryant
Tuesday, March 21, 2006
 
 
You'd be better off with the link taking you to a confirmation page with a button that POSTs to a confirmation link. 

The problem of pre-fetching exists and I would imagine that we'll see more products prefetching for a variety of reasons, not just accelerators.  I'd love it if my email client followed links silently in the background, compared the end site to a list of identified phishing sites, and flagged the email or trashed it automatically.  But it can't do that if it can't follow all of the links it comes across.

The damage COULD be minimal with an activation link, as long as the user intended to active.  But if it wasn't the user that requested the activation, you've just activated on their behalf without their approval.
Lou Send private email
Tuesday, March 21, 2006
 
 
"better off with the link taking you to a confirmation page"

Lou, that is what Bill Venners said in the article we're discussing. I just don't think prefetch is a valid reason to replace single-click with the click-read-click solution because you will never eradicate the GET confirmation practice on the Internet. If a "prefetch-safe" e-mail attribute standard were introduced so that a particular e-mail could flag itself as safe for prefetches, you might have the result you're after. In that case of course the e-mail would have to be written with that in mind and everyone would have to adhere to the standard. Pretty unrealistic considering the loose application of standards on the Internet.
Ben Bryant
Tuesday, March 21, 2006
 
 
If Google Web Accelerator is automatically following off-site links in web mail, then that's a problem with Google Web Accelerator.  Spammers and other nefarious types aren't going to stop putting GET links in their email because some guy wrote an article saying it violates "one of the cardinal rules of the web".  There's a reason why email clients don't automatically display images in email anymore and having a prefetcher automatically follow links would be just as bad.
SomeBody Send private email
Tuesday, March 21, 2006
 
 
"in a get link is there a way to indicate it shouldn't be cached?"

Well, the HTTP headers of the result can indicate whether or not to cache the link. 

"Designing around hypothetical web accelerators just seems wierd."

Furthermore, if a web accelerator is processing my emails then something is wrong.  I guess the case could be make for web-based email, but still. 

GET for stateful operations is just *too* useful.  For the most part, the only way to get around it is to use Javascript than you have another camp bitching about how sites shouldn't rely on Javascript for user input!  You simply can't win.
Almost H. Anonymous Send private email
Tuesday, March 21, 2006
 
 
The only other option, IMO, is to confirm via a reply to the email itself.

This is a superior method in every way except the fact that it's not the "norm."
Shane Harter Send private email
Tuesday, March 21, 2006
 
 
Except that the feedback from an email reply is not immediate.  If I click a link, I'm verfied and I'm also on the site.

If I reply to an email, god only knows when (or IF) it'll arrive at the site.
Almost H. Anonymous Send private email
Wednesday, March 22, 2006
 
 
One suggestion for e-mail spam filters is that they could follow links in the e-mail and look at the page  returned, to help them decide whether the e-mail is spam or not.
DAH
Wednesday, March 22, 2006
 
 
Isn't it a bit late to start worrying about doing it the right way?

Millions (?) of mailing lists mailing lists, and Billions (?) of mailing list subscriptions have already been (and are done) using GET confirmation. And more significantly thousands (or more) of bits of software use GET confirmation.

I think  the onus on any new bit of software (even if it's by Google) is to work with the net environment as it is (everybody uses Get confirmation), rather than as it should be (Get confirmation isn't ideal technically)

There's also a simple solution right now: Google can change it's software not to prefetch URLs in email, or at least not prefetch URLs in email that might be email confirms (say anything with a ? in it)
S. Tanna
Friday, March 24, 2006
 
 
"Designing around hypothetical web accelerators just seems wierd."

Isn't that the sort of thing that developers do all the time?  Developers always have to imagine the different ways that things can go wrong, the crazy things that some small set of users will do.

Also, as I understand it the Google Web Accelerator is not "hypothetical".  It exists and some users are using it.  In some cases it is likely to cause problems when used with the confirmation GET.

One question then is whether it makes sense to abandon the email confirmation GET merely because of this (currently) small number of users.  The answer may be No.  But some developers might answer this with a Yes.  And this is exactly the sort of decision that developers have to make all the time.  (E.g., not so different from decidng whether to make web app that is not compatible with older browsers used by only small number of users.)
Herbert Sitz Send private email
Friday, March 24, 2006
 
 
Can't you simply mark the link as not-traversable by the accelerator?  That basically solves the problem.
Almost H. Anonymous Send private email
Friday, March 24, 2006
 
 
It "basically" solves the problem, once you achieve the second step of the process, which is to force every accelerator and web spider in existance to be upgraded to correctly respect the new feature in the HTML spec. If you fail to do that, then you'll be ever so proud of solving the problem, but the actual problem won't go away.  You can't just mark the link - you have to teach the software to understand what the mark actually means.


> Also, as I understand it the Google Web Accelerator is not "hypothetical".  It exists and some users are using it.  In some cases it is likely to cause problems when used with the confirmation GET.

Daily WTF: A website with a regular old-fashioned GET style hyperlink to a 'delete page' function vanished overnight, when google indexed the site.

It's been a great many years since web spiders were first created, and it's a stupid web developer who doesn't consider them.

Wednesday, March 29, 2006
 
 
"which is to force every accelerator and web spider in existance to be upgraded to correctly respect the new feature in the HTML spec."

Well, the web spider issue is already solved -- use authentication.  As for accelerators, google already respects some kind of tag in the link.
Almost H. Anonymous Send private email
Thursday, March 30, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz