[Bug 17046] New: Implement redirect audit functionality for XHR

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17046

           Summary: Implement redirect audit functionality for XHR
           Product: WebAppsWG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: XHR
        AssignedTo: annevk@annevk.nl
        ReportedBy: baranovich@yandex-team.ru
         QAContact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, public-webapps@w3.org


Most of the time people talk (e.g. Stackoverflow) about controlling XHR
redirect, they don't mean really _controlling_ redirects, they mean 2 simple
things:
 - figure out, whether it was redirect or was not.
 - get final redirect url (or maybe interstitial).

From
http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/thread.html#msg474
it is seen that everything is not so simple with implementation of
user-controlled redirects. But also, there was a phrase 

> However, if the use case is only
> auditing redirects, then
> ...

So maybe for most of the needs there it will be enough to implement such audit,
without touching current redirect behaviour. It may satisfy more than 90% of
the requests about "controlling redirects".

For example XMLHttpRequest object may have a property called "redirects" or
smth, containing array of objects:
{url: "whatever-no-matter-relative-or-absolute", {headers*}?}
Semantically this array will be a linked list, i.e. first element will be
initial resource request details and last - final one's.

Full implementation of XHR redirects is not so straightforward, but
implementation of such "redirect audit" is quite simple although very useful,
and it will be good to have such thing in XHR standard.

Problem:
As almost always, the problem rose from chrome extensions development. We have
to follow redirect and detect that fact as well as the final URL.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Monday, 14 May 2012 13:48:30 UTC