W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [XHR] Redirects

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 15 Sep 2010 12:07:23 +0200
Message-ID: <4C909ADB.9090207@gmx.de>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: WebApps WG <public-webapps@w3.org>
On 15.09.2010 11:56, Boris Zbarsky 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.

For XHR I'd argue that once the caller requests control over redirects, 
he's responsible to do it right.

With respect to 2616 and the text you quoted above: the WG is aware of 
this problem, see <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/238>.

Best regards, Julian
Received on Wednesday, 15 September 2010 10:08:01 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:40 GMT