A song for the lovers

Didn’t you heard about 37Signals rants about Google Web Accelerator?

I quoted some posts/comments/interesting points of view (you’ll be the judge):

The problem The accelerator scours a page and prefetches the content behind each link. This gives the illusion of pages loading faster (since they’ve already been pre-loaded behind the scenes). Here’s the problem: Google is essentially clicking every link on the page — including links like “delete this” or “cancel that.” And to make matters worse, Google ignores the Javascript confirmations. So, if you have a “Are you sure you want to delete this?” Javascript confirmation behind that “delete” link, Google ignores it and performs the action anyway. — Jason Fried, 37signals.com

Comments of the above post It’s always a bad idea to put critical, data-damaging functions behind a regular old a-tag and http GET. It would be safer to do these operations with a POST. — Andrew

Yea but if you follow web standards you won’t have to worry about this and it’s all upside. GET requests should be safe and idempotent. If you can delete items with a GET request, you mind as well use tables for layout and Active X controls too. Unless google is following links with a POST, then they are following web standards and the issue is on your side. Caching proxies are an important part of the web and the HTTP specification lays out exactly what is respectful and disrespectful. — Ryan Tomayko

Quoting from section 9.1.1 Safe Methods of the HTTP 1.1 RFC (2616):

Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others. 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.

Put simply, GET requests should be idempotent and safe. — Mark Rowe

David Heinemeier Hansson (the creator of Rails) replies in the comments So while you may rail on application developers for diverging with reasons you don’t deem to be good enough, it’s hardly news that this is the fact. Just like web developers can’t disregard the browser bugs in IE6, we have to work with and deal with what’s real.

Google is disregarding real and are thus blatantly disrespecting precedence. That’s where the problem is. Moreover, there’s no warning here. Shit will just start breaking left and right leaving users and application developers lost.

Having a standard is not an excuse for not looking out the windows.

DHH on his blog When car companies produce faulty vehicles that cause horrible accidents or aggravated injuries on regular mishaps, they do a recall. Google’s Web Accelerator is causing death and destruction on an admitted much lower level of criticality, but it too is in need of an immediate recall.

Comments of the above post This problem could be turned into a win for Rails. Just modify the link_to helper method to optionally specify whether to use GET or POST. If the developer wants to use a link to destroy a post, they’d enter something like . The result would be a link with a Javascript handler that simply sends the request as POST rather than GET. — Scott Raymond

Google didn’t screw this one up. The blame for this debacle lies with the programmers and designers who used GET-based links to trigger destructive events in ignorance/spite of the standards. — Tom Moertel

Be sure to read:

• Simon Willison’s “Fighting RFCs with RFCs“
• Sam Ruby’s “This Stuff Matters“
• Ian Bicking’s “Breaking the Web We Have“
• O’Reilly’s “Google Web Accelerator considered overzealous“
• Franklin Mint Robert Sayre’s “You were warned.“

A Rails “patch”: http://david.backpackit.com/pub/37983

Have a look at mine REST tag in delicious too: http://del.icio.us/rhymes/rest

update: Tim Lucas in comments point at this: http://www.squarefree.com/securitytips/web-developers.html#CSRF.

David Heinemeier Hansson says: Rails will ship its next version with a link_to that looks just like a GET, but uses Javascript, or some other way, to do a POST. Since the HTML isn’t moving forward, we’ll just have to build on top and make it no harder than not to. We’re doing that with Ajax, we can do it with REST. — Google: Recall, Developers: Improve

Sam Ruby points at three ways to take the unsafe GETs out of Rails