As someone not too familiar with HTTP -- given that you're redirecting them to a an actual page and not some user-associated resource the page needs to grab, why would the redirected DELETE request be honored in the first place? Or am I misunderstanding what's going on here?
I think what you are suggesting is that a DELETE request to a resource that should not (in the application developer's mind) be deleted should be disallowed by said developer.
While this protection is a good idea, it doesn't change the fact that a redirect to a resource that is DELETEable would have an unexpected and unpleasant side-effect if the application developer was expecting the browser to issue a GET request.
Think about, e.g., a "delete this message and go to the next in your inbox" kind of functionality being implemented like this. Not that such an implementation would be the best idea, but it's a thought experiment.
Request method specificity in defining API endpoints is common because it allows the re-use of the same URI for different purposes.
So in some cases you could get a 404, or the endpoint treats everything as a GET request, or as you say the redirect URI actually has its own delete method that you assume won't be used after a redirect.
It seems easy to blame the browser, not least because it's also IE, but your code should take stuff like that into account, especially when dealing with destructive requests.
To be honest though, and this may be through ignorance on my part, I don't get why you'd issue a redirect on an AJAX request after performing a delete or whatever.
If I sent an AJAX request to delete a widget I wouldn't expect to get any data back, because I'm not asking for it. I'd want at least an empty 200 OK response for a successful delete or a relevant error code. And then I could react accordingly based on the result.
The design that allows IE9 to do this appears to just cut corners.
