NOTICE:
This content is in the "archives" of a retired blog called Gadgetopia. It has been moved to this subdomain as it is no longer considered relevant to the site. It is being hosted here for a indeterminate period of time. Its existence at this URL is not guaranteed, and it may be removed at any time. If you would like to refer to this content in the future, you are encouraged to save it to your local file system.

Some content from Gadgetopia was moved to the technical blog on deanebarker.net

GWA: I’m Back and More Evil Than Before!

Originally published by "dbarker" on 2005-10-25 14:24:00Z

The Google Web Accelerator is back with a vengeance: The Google Web Accelerator is back in a more brutal form than before.

In version 1.0, web masters at least had a fighting chance as the GWA identified its requests with a “X-moz: prefetch” header (as prescribed by Mozilla). Sure, everyone in the world had to change their web applications to fit Google’s vision of a perfect world, but at least they could.

Not so for version 2.0 of this virus. It ships with a brand new mutation: The header is gone! There’s now no way to identify a pre-fetch from a regular request, which means that it’s no longer possible to block the GWA.

But this has prompted people to be aware of something: GET requests should only retrieve data, they should never modify it. This means that URLs like this…

/delete_article.php?id=35

…are bad (unless you have a confirmation screen that POSTs the request instead). Bad, bad, bad. POST that stuff, even if you just have a form with one hidden field (the article ID) and a submit button.

I can’t say I’ve always followed my own advice here, but I should have. GET requests should be harmless. If you modify data, use POST.

Comment by "Uri" on 2005-10-26 13:58:00Z
"GET requests should only retrieve data, they should never modify it." Err... Why?
Comment by "Deane" on 2005-10-26 15:21:00Z
>Err... Why? Because of exactly the problems people are having with GWA. It's related to something called "REST" -- Representational State Transfer. It's a theory of mapping resources and actions to HTTP requests. GET is for, well, getting something. POST is for putting or doing something.