THANKS TO:-
http://techno-weenie.net/2011/8/19/ie9-deletes-stuff (FROM WHERE I GOT THIS INFORMATION)
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!
