On , Anne van Kesteren <ann...@opera.com> wrote:
On Fri, 13 Aug 2010 00:13:16 +0200, João Eiras <joao.ei...@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.
