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

Re: [XHR] Redirects

From: Joćo Eiras <joao.eiras@gmail.com>
Date: Thu, 12 Aug 2010 23:13:16 +0100
To: "Anne van Kesteren" <annevk@opera.com>, public-webapps@w3.org
Message-ID: <op.vhcioepvjz3wb9@coruscant>
On , Anne van Kesteren <annevk@opera.com> wrote:

> On Thu, 12 Aug 2010 15:07:50 +0200, Joćo Eiras <joao.eiras@gmail.com>
> wrote:
>> Hi !
>>
>> a)
>> If a XHR follows a redirection chain, does the API provide a way to
>> retrieve the final url?
>
> Apart from document.responseXML.URL I do not think so. And I'm not sure if
> document.responseXML.URL is supposed to work.
>

It might not be an xml file, hence resonseXML is not defined and that's no good.

>
>> b)
>> Could there be a way to opt-in into not following redirection chains ?
>>
>> For instance, a redirectCount property, default value would be
>> something like Infinity (the user agent could then cap the maximum
>> amount of redirects), and setting it to 0 would prevent any redirect,
>> and setting to something greater than 0 would then limit the redirect
>> chain to that number.
>> If the last http request was 302 and the redirection prevented, then
>> the 302 status code and the last response headers would be returned by
>> the XHR obj.
>
> What is the use case?
>
> We might add something like this at some point (probably by way of a
> followRedirects boolean) but so far the use cases have not been really
> strong so it has not been given much priority.
>

In my specific case, I had an url to a media file which I needed to feed to a plugin. But the plugin did not handle redirects. So I needed to do a HEAD request, and check if it returned 302 and read the Location header. But due to the implicit redirecting handling, and no way to access the final url, that was impossible. So, two problems in one.
Between the boolean and an integer, the integer is more useful, although seeing long redirection chains is somewhat rare and overkill.
Received on Thursday, 12 August 2010 22:13:52 GMT

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