Sure, the code is sloppy. For whatever reason, that action wasn't using "newer" rails practices to return different responses to form and ajax requests. r

Sure, the code is sloppy. For whatever reason, that action wasn't using "newer" rails practices to return different responses to form and ajax requests. respond_to do |format| format.js { head 200 } format.xml { head 200 } format.html { redirect_to '/' } end We do something like this in every other case in the code base. This is actually what's more encouraged to Rails developers. There was another similar issue with Rails and the Google Web Accelerator: http://37signals.com/svn/archives2/google_web_accelerator_hey_not_so_fast_an_alert_for_web_app_designers.php http://37signals.com/svn/archives2/google_web_accelerator_he.... In this case, the GWA was "clicking" links on the page to pre cache them. Sucks to be you if your application's delete links are straight GET links! In this situation, the community encountered the problem and immediately started advocating better practices to get around these problems. Such as using form buttons (and later, ajax-enabled links) for unsafe actions. There's a clear standard practice in the web development community here, and these early Rails apps weren't following it. However, every other browser with XHR support for years has handled redirects the same way. Even though the spec is ambiguous, it certainly suggests being cautious and only automatically redirecting with safe HTTP methods. IE9 breaks this trend for some reason. I'd feel much differently about this if every version of IE worked this way. At least there would be some consistency with itself. And it surely would've been encountered and added to the encyclopedia of weird IE behavior that web developers have to deal with.