This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
(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.
Julian, FYI, introducing a new feature to work around a bug is not a valid argument for the new feature.
(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 :-)
*** This bug has been marked as a duplicate of bug 12607 ***