3 ms·

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

by ldar15 15y ago

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 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.

strmpnk 15y ago
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.
- ldar15 15y ago
  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?
  - strmpnk 15y ago
    ... 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.

by ldar15 15y ago

strmpnk 15y ago

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.

ldar15 15y ago
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?
- strmpnk 15y ago
  ... 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.