Re: [XHR] Redirects

On Tue, Aug 31, 2010 at 11:26 PM, Anne van Kesteren <annevk@opera.com>wrote:

> On Tue, 31 Aug 2010 22:51:19 +0200, Darin Fisher <darin@chromium.org>
> wrote:
>
>> If instead, we had an API for auditing redirects (perhaps an "onredirect"
>> event), then we could let developers handle that event and call
>> preventDefault if they want to stop redirect processing.  Otherwise, the
>> redirect would be processed normally.  The result being that application
>> authors would be guided away from following redirects manually, and hence
>> they would avoid the problems I've described above.
>>
>
> This does not work for synchronous requests in a worker.


Hmm, good point.  An alternative design might be a flag that causes .send()
to complete once a redirect response is received, but then also provide a
method on the XHR object to tell it to now follow the redirect.  This model
would work for both synchronous as well as asynchronous.



> If we are okay with that it seems an acceptable alternative. However,
> redirects are processed before the object reaches HEADERS_RECEIVED (as
> otherwise it would reach that several times) so HTTP headers et cetera are
> not available yet. Given that, and given that you want that information, you
> would always invoke preventDefault(), defeating the purpose of having an
> event.
>
>
It does seem like you'd want to see the headers corresponding to the
redirect.

I thought of another reason to want the original XHR object to be
responsible for following the redirect:  the value of a Location header may
be a relative URL.  It would be nice if application authors did not have to
take care of resolving that manually.  (In the case of a cross-origin
request, the relative URL should be resolved relative to the URL that was
redirected instead of against the Document.)  This seems like something that
could be easy to mess up.

-Darin