Re: [XHR] Redirects

On Wed, Sep 15, 2010 at 3:07 AM, Julian Reschke <julian.reschke@gmx.de>wrote:

> 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
>
>
>
Adding a .followRedirect method means that developers can choose to use it
or not.  If they want to manually construct the redirected request, then
they can do so using a new XHR object.  However, if the use case is only
auditing redirects, then being able to call .followRedirect on the existing
XHR is quite convenient and minimizes the chances of making some common
mistakes.

-Darin