Google Web Accelerator == Pitiless Enforcer of Web Design Patterns

Posted on May 9, 2005

This one goes out to all my homies who design Web applications. You know who you are.

How many of you have apps that fire events which change the underlying data — things like deleting stuff from the database, say — when the user clicks a link indicating they want to do so? Raise your hands.

OK. Now, those of you with your hands up — how many of you prevent the user from accidentally deleting stuff this way by putting a JavaScript confirm dialog box on the link? Something like “Are you sure you want to delete this?”

All of you, eh?

Then you’ll be interested to know that the minute one of your users installs the new Google Web Accelerator, you’re going to be in for some serious problems.

Here’s the deal. When you submit an action from a link, you’re using the HTTP GET method. The alternate way to submit the action would be to put the action in a form, rather than a link — that way you’re using the HTTP POST method.

In practical terms, there’s not much difference — both GET and POST allow you to pass information to the server, which can then act on it. The only difference many developers see is that GET puts all the parameters in the URL, while POST embeds them in the headers.

But — and this is the key point — even though there may not be a practical difference between the two, there is an important distinction made in the RFC that defines them:

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.

Let me put this into English. According to The Specification, any action sent via GET should be “safe” — it should make no permanent changes to the underlying application or its data. The app should be no different after the GET than it was before it. GET is for retrieving data, not writing it.

Of course, the common usage of GET has diverged considerably from this. But this is an RFC, so if it conflicts with common usage, it’s common usage that’s wrong.

Now, what does this have to do with Google Web Accelerator?

As it turns out, a lot. See, the way GWA “speeds up the Web” is by using an approach called prefetching. This means that, when you’re on a page, it scans through that page, pulls out all the links, and downloads all the pages the links point to in the background while you’re reading the first page. That way, when you click the link, the page is right there — no need to wait for it to download, it’s already come down the wire.

Pretty clever, eh? Yeah — too clever.

See, when a user armed with GWA is browsing your Web app, GWA is gonna hit that link that says “Delete row in database” when it does its prefetch. When it clicks through all the links it found, it’s gonna click this one too. But you’ve protected it with a JavaScript dialog! you cry out, right? Wrong — GWA doesn’t understand JavaScript. So it merrily clicks the link and deletes the record in your database.

Depending on how many of these links there are in your app, this could be Very Bad.

The thing is, though, in this case it’s not Google that’s in the wrong. Their app makes the naïve assumption that every page out there uses GET in a way that follows the RFC. Now, any Web developer with 10 minutes’ experience could tell you that’s not the case; but it’s hard to fault them for following the rules.

The upshot, though, is that 10 years’ worth of Web apps are going to have to be reviewed — and fast! — to make up for our longstanding common misconception of how HTTP GET is to be used. In this way GWA is kind of like an RFC Robocop — forcing us to get right with the law tuit suite.

Pleasant? No. But don’t blame Google. The lesson here is to pay attention to the RFCs.

(Read more on this from Phil Ringnalda, 37Signals, O’Reilly Radar, Simon Willison.)