---

Date: Fri, 24 May 2013 14:55:04 +0200

---

Quote:

techno weenie - Home
IE9 DELETES stuff
http://techno-weenie.net/2011/8/19/ie9-deletes-stuff

---

Text:

So, Kyle and I discovered some interesting IE9 behavior. Redirect responses from DELETE requests are followed with another DELETE. How is this surprising?



Using more of the HTTP methods lets us keep the URLs cleaner. Web browsers don't understand PUT/PATCH/DELETE in forms, so a workaround was needed. Rails looks at a _method GET parameter on POST requests to determine what HTTP verb it should be recognized as. The GData API supports this behavior through the X-HTTP-Method-Override header.

A typical Rails controller might look like this:

class WidgetsController < ApplicationController
  # DELETE /widgets/1
  def destroy
    @widget.destroy
    redirect_to '/widgets'
  end
end

If you don't like Rails, just close your eyes and think of your favorite web framework...

This action works great for a simple form in a browser. You click "Submit", it POSTs to the server, and then you end up back at the root page. Then, you can add some jQuery to spice things up for newer browsers. Progressive enhancement and all that.

$('.remove-widget').click(function() {
  $.del(this.href, function() {
    // celebrate, disable a spinner, etc
  })
  return false
})

This works great in all modern browsers, except IE9. We discovered that not only does IE9 send a real DELETE request, it also follows the redirect with another DELETE. If that redirect points to another resource, you can get a dangerous cascading effect.

RFC 2616 is not clear about what to do in this case, but strongly suggests that redirects are not automatically followed unless coming from a safe method.

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

Standard practice for browsers over the years is that redirects from POST requests are followed with a GET request. GET/HEAD requests are usually safe, so this seems like reasonable behavior. It's expected by web developers, and consistent across browsers.

I can't imagine that this behavior in IE9 was on purpose. It feels like an edge case that slipped through an if statement because "DELETE" != "POST". I've submitted feedback to the IE9 team about this issue. I'm curious to see what they say.

So, if your application might be responding to ajax requests with redirects, you should probably start sending back 200 OK...



Update: Eric Law on the IEInternals blog responded to one of Kyle's tweets. Apparently the behavior is correct according to HTTP 1.0, and IE has been following DELETE redirects since at least IE6.

Here's the breakdown of browser behavior when receiving a 302 redirect from a DELETE request:

IE 6-10	DELETE method is preserved
Chrome 13	Converts to GET
Firefox 6	Converts to GET
Safari 5.1	Converts to GET
Opera 11.5	Converts to GET

We didn't see the behavior in IE8, so we assumed it was new to IE9. At least, no one was sending in crazy bug reports from other browsers. This is another example why developers hate dealing with IE. Kudos to the standards compliance, though!

Discuss this post on Hacker News.

---

Via FeedShow.com