This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Add follow redirects back into WHATWG XHR specification: http://xhr.spec.whatwg.org/ As mentioned on this post: http://discourse.specifiction.org/t/followredirects-in-xmlhttprequest/420/11?u=jonathank The intent is to put back in the followRedirects feature which was a security improvement from the client side to prevent calls following to unexpected URL changes. The expected result when the AJAX request returns a redirect code and followRedirects is disabled then it should return a network error. This should follow the same definition as the original specification: http://www.w3.org/TR/2010/WD-XMLHttpRequest2-20100907/#the-followredirects-attribute However it shouldn't return a response if there is a redirect just a network error to the callbacks.
So the use case here is failing early, right?
That is right, so to prevent scripts that really only want the one resource to be able to turn off the feature of jumping through the redirects. The behaviour should be a browser engineered error code sent to the callbacks. The browser should not follow any redirects at all, only one server call should be made.
If we add this we should probably name it disableRedirectHandling per bug 25791. failOnRedirects or some such could maybe also work.
I found out that with HSTS this could be used to detect whether a user has previously visited a site. It might be that CSP and other features enable the same kind of attack however.
However, if we add this we might add it as a feature for fetch() instead.
fetch() it is. *** This bug has been marked as a duplicate of bug 28343 ***