Re: [XHR] Redirects

On , Anne van Kesteren <annevk@opera.com> wrote:

> On Fri, 13 Aug 2010 00:13:16 +0200, Joćo Eiras <joao.eiras@gmail.com>
> wrote:
>> Between the boolean and an integer, the integer is more useful, although
>> seeing long redirection chains is somewhat rare and overkill.
>
> I went for a boolean followRedirects attribute as that gives sufficient
> low-level control that people can implement whatever behavior they want on
> top of that. (Including every use case mentioned in this thread.) This is
> an XMLHttpRequest Level 2 feature now:
>
> http://dev.w3.org/2006/webapi/XMLHttpRequest-2/
>

Thank you. But there is one thing missing: the final url in case of a redirect chain. Currently that is not possible to guess for non xml requests or HEAD requests. My use case was about doing a HEAD and reading the Location header to know if was going to be redirected. Now I could set followRedirects to false and read it, but for cases where the redirection chain is followed, then new url is not available.

Something like finalUrl which when readyState is <= 1 it would have the value passed to open() and after, when the value is >= 2 (headers received) it would have the value of the final url.

> Another issue that concerns me is redirect loops.  The proposed API
> gives us know way to know that the application is following a redirect
> chain, which means that we have little way to know if the application
> is following an endless redirect chain.

Following redirects is the default behavior, and user agents abort after N iterations regardless of whether it's XHR or a regular request. The new followRedirects feature is for opting into disabling it.

> 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.

Quite an edge case, but setting followRedirects to false and then creating individual XHRs for each 302 response explicitly should work.

Received on Tuesday, 31 August 2010 22:47:19 UTC