On 9/15/10 2:47 AM, Boris Zbarsky wrote:
So it's possible that the original behavior was just an oversight that
then got copied. Someone with access to a browser version control system
from before 1998 would need to look to make sure...
It's also possible that no UA implementor was willing to implement the
MUST NOT requirements below:
If the 301 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.
and
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.
(RFC 2616 sections 10.3.2 and 10.3.3). How do you expect this to work
in the XHR context? Is "user" for purposes of those two clauses the
script that triggered the XHR, or the person actually represented by the
user-agent (browser, say) in question?
Then again, I guess they already ignore that MUST NOT clause for 307
redirects... So maybe they would just do the same thing here. Gotta
love specs that really can't be implemented as written in sane ways.
-Boris
