- From: Adam Barth <w3c@adambarth.com>
- Date: Thu, 16 Sep 2010 00:55:22 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: WebApps WG <public-webapps@w3.org>
On Wed, Sep 15, 2010 at 2:56 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > 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. There's an open issue in the HTTPbis WG to remove that nonsense: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/238 If you're interested in this topic, I'd encourage you to share your perspective with the httpbis working group. Adam
Received on Thursday, 16 September 2010 07:56:23 UTC