- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 15 Sep 2010 02:56:13 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- CC: WebApps WG <public-webapps@w3.org>
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
Received on Wednesday, 15 September 2010 09:56:52 UTC