This post originated from an RSS feed registered with Ruby Buzz by David Heinemeier Hansson. Original Post: How Rails is prepared for GWA II: Vengeance Feed Title: Loud Thinking Feed URL: http://feeds.feedburner.com/LoudThinking Feed Description: All about the full-stack, web-framework Rails for Ruby and on putting it to good effect with Basecamp Latest Ruby Buzz Posts Latest Ruby Buzz Posts by David Heinemeier Hansson Latest Posts From Loud Thinking

So the Google Web Accelerator is back and twice as lethal as before. It no longer reports its pre-fetching intentions, so now you can't detect whether its either or. In other words, you can't block the fucker.

This time around, though, Rails is a lot better prepared. Not only does Rails ship with two different methods of easily creating POST actions without the drudgery of the manual form, but also makes it easy to guard actions against unsupported verbs.

If you want to be a real pretty momma's boy, you can use the new button_to, which just makes it easy to create a mini-form that'll submit to the chosen URL as POST. But that generates a real, visible form, which despite being subject to styling, is often not something that's easy to fit into an application design of your choice.

More interesting for most applications, especially those already requiring Javascript to do Ajax, is the addition of :post => true to link_to. This will add a onclick attribute on the ahref, which generates a dynamic, invisible form that again turns the GET into a POST. It looks, feel, and smell like a real ahref. And if the client doesn't have Javascript turned on, we'll still submit the request (just as GET).

On top of making it easy to generate POST links and buttons, we've added easy guards to the controllers in form of verify. You can now very easily guard certain actions from being accessed by anything but posts. Example:

class WeblogController < ActionController::Base
  verify :method => :post, :only => %w( delete update create )
 
  def delete
    # a GET request will never gain access to me
  end
end

There you have it. A complete package to Do The Right Thing And Look Pretty While You Do It. So that means that we should welcome our new Google Web Accelerator overlords with a cheer and a smile, right? Wrong!

The problem with the GWA is not that you can protect against it. It's not whether Rails makes it easy or not to do so. It's the fact that we know the Real Web doesn't behave uniformly like this. It's the fact that we know that the world of applications that exist with state-altering GETs out there is huge and not going to change tomorrow.

To willfully release an application that wrecks havoc, potentially wiping data left and right, is malicious. Especially when you consider the gains: Your web experience may or may not get a little bit faster. Are you kidding?! The sense of proportions, of gain vs risk, of price vs reward, is completely and utterly out of whack.

If Google doesn't retract and profess their sins. I will pull out the juggernaut of all arguments on public policy. Don't make me do it. I swear I will: Won't somebody please, please think of THE CHILDREN!