Bug 17046 - Implement redirect audit functionality for XHR
Implement redirect audit functionality for XHR
Status: RESOLVED DUPLICATE of bug 12607
Product: WebAppsWG
Classification: Unclassified
Component: XHR
unspecified
All Windows 3.1
: P2 enhancement
: ---
Assigned To: Anne
public-webapps-bugzilla
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-14 13:48 UTC by Alexey Baranov
Modified: 2013-02-19 14:05 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Baranov 2012-05-14 13:48:23 UTC
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.
Comment 1 Julian Reschke 2012-05-15 07:50:37 UTC
(In reply to comment #0)
> 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*}?}

... status code ...

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

I appreciate the attempt to simplify the problem. However I don't think it's sufficient. I really believe we either need the ability to veto a redirect (callback + information similar to what you proposed above), or a simple switch that turns of following redirects completely (that latter would be useful for UAs that still do not get method rewriting in redirects right, such as Opera and Safari.
Comment 2 Anne 2012-05-15 08:33:59 UTC
Julian, FYI, introducing a new feature to work around a bug is not a valid argument for the new feature.
Comment 3 Julian Reschke 2012-05-15 09:13:10 UTC
(In reply to comment #2)
> Julian, FYI, introducing a new feature to work around a bug is not a valid
> argument for the new feature.

It's not just to workaround a bug; there are cases where it's just simpler to tell XHR not to follow redirects (in fact, that should have been the default).

That being said, I'll remind you of this comment once Opera supports new XHR features but still has broken redirect handling :-)
Comment 4 Anne 2013-02-19 14:05:36 UTC

*** This bug has been marked as a duplicate of bug 12607 ***