Hacker News Reader

Comment by EricLaw-MSFT | Hacker News Reader

Please see http://blogs.msdn.com/b/ieinternals/archive/2011/08/19/under... for a complete discussion of behavior.

We didn't see the issue in IE8 when we developed the feature, or this week when we tracked down the IE bug.

Something changed with IE9. Maybe jQuery detected it supports DELETE requests? I have no idea.

So I guess everything is really fine: This behavior mentioned in the last section was likely even more surprising because Internet Explorer does convert POST to GET for HTTP/301 and HTTP/302, like all other browsers

Its funny that you can trot out the standard in your defense, cut and pasting a relavent paragraph, yet seem unable to read the immediately preceding paragraph of the spec:

If the 302 status code is received in response to a request using the POST method, 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.*

http://www.ietf.org/rfc/rfc1945.txt

IE does redirect automatically. So IE isn't doing it right either. Since nobody is doing it right, I'd pick the guys doing it wrong that make the most sense. What a surprise: that's not microsoft.

I would wonder what the proper thing to do in this case is anyhow. As a user I'd hope I'd not be asked with a random interface to repost when some background JS runs XHR asynchronous from my interaction. That's obviously not workable. In this case the user of the agent is more like the application code and XHR doesn't really have the API to support this sort of event AFAIK.

Regardless, that is a separate issue to what is being discussed, and the article does mention it; I'm sure it's not that it was forgotten. Standards documents aren't always perfect in predicting every possible scenario so there must always be room for practical implementation and I think IE has a very good argument to make in its favor for this specific case.

Its pretty standard that "MUST NOT" in specs really means "MUST NOT".

I think IE has a very good argument to make in its favor for this specific case

Great. What is it?

... and magically breaking 10 years of web applications is also a big MUST NOT. Why else would the spec itself dedicate an entire paragraph and add two response codes just for legacy cases? The article, if you read it, also explains why. All old browsers map POST so they stuck to that for forms and XHR's broader capabilities map to the standard when possible. That's a pretty good argument, unless you have better ideas, again, make your suggestions heard.

Reply on news.ycombinator.com