FollowRedirects in XMLHttpRequest

I know the answer is likely to be no; however I feel I would not be doing my job if I did not raise this here. Back in November I wrote an article on following redirects in AJAX requests: Give the World Back FollowRedirects XMLHttpRequest

My proposal is to add back in the optional flag into XMLHttpRequest which would let the developer opt out of following redirects; perhaps allowing them to get an optional follow callback/promise.

The other option would be allowing the developer to see the call stack of URL’s that had been called.

The merits from a front end perspective is clarity on what the server is doing; which at the moment is only is available when using CORS requests.

Either way, I am quite happy to hear your feedback on reimplementing this into the specification.

responseURL (http://xhr.spec.whatwg.org/#the-responseurl-attribute) may address some of these concerns.

@josh that is good to see things have evolved a little since when I wrote the article; That certainly solves one of the use cases of being able to see where the server has finally sent the client to. Which for example in a URL based single page application could indicate to the client which controller to render perhaps or some form of behaviour based upon the URL.

I think however it still leaves a few issues:

• Clients can’t see the full set of URL’s used in the request
• Clients are not in control if they choose to allow the redirect
  • Think in a banking application perhaps where they might explicitly want to prevent any behaviour that was not expected; you know where paranoia is rife.
  • Besides HTTPS, to my knowledge there is no protection against a man in the middle redirect to a an external server (mostly though a defence in depth approach):
  • Client requests mysite.org
  • mysite.org 302: hacker.org (to my knowledge if they serve Access-Control-Allow-Origin; they can then serve your application harmful content)

You can enforce that with CSP connect-src whitelisting. The new CSP 1.1 goes further to block redirects unless you opt in "unsafe-redirect".

I doubt the redirect control would be added to XHR at this point.

But good news! @annevk working out some awesome new APIs for the fetch spec. Maybe the full request/response change could be exposed somehow. I don’t know. I remember there was some tricky CORS permission stuff it’d have to be careful about.

http://fetch.spec.whatwg.org/#fetch-api

From a XHR feature set perspective the following two statements are a little contradictory as responseURL appears to only have been in the specification since February. I know that there appears to be issues with the redirection however from an API perspective adding new features that are optionally off should never be an issue.

However with that being said; I wasn’t quite aware of the far reaching goals of fetch however I guess the following covers it:

@annevk perhaps you would be able to clear up some of the CORS issues; I did quite a bit of digging before writing the above article back in November however its not always clear the motives and issues causes whilst trying to implement features into the spec - hence this discourse I guess.

Some of my reasons for wanting full granularity of the request redirection and also control are:

1. Headers are currently not visible for redirected requests
2. Visibility of the redirected hops through for debug and also security reasons
3. Josh has outlined CSP for a security perspective to prevent internal redirecting however for a per request granularity prevention this would need to be done at code time (Lets say for example an external agency owned a certain directory, subdomain or script on the same server)
4. A way in which the browser can verify the server behaved exactly as expected.
5. As mentioned for single applications; it is useful to behave in the same way for different content type responses from the server HTML/XML/JSON in the same manner; from a client perspective having a full trace of where they have landed is key to displaying the correct template (Assuming a design pattern where front and back end match in URL’s and behaviour).

Thank you both for your time.

http://fetch.spec.whatwg.org/#atomic-http-redirect-handling is why there is no such feature. I could see us providing a feature which returns a network error if there’s a redirect and the response otherwise, perhaps, but even that seems somewhat dangerous.

Brilliant; that makes sense and I like the explicit call outs in the specification.

The responseURL combined with the CSP certainly covers most of the use cases that I realistically needed from a client side perspective. It certainly appears that it should be possible to allow developers to basically return a null error handler or similar for a redirect - as you mention passing the response through is potentially dangerous… Essentially the followRedirects support back; is this likely something that might be added to the Fetch API?

You mean the ability to get a network error returned if you stumbled upon a redirect rather than having the redirect followed? I think we might be able to add that at some point. I recommend filing a bug so we can keep track of the request. Probably better to wait a bit for now and have service workers et al get in browsers first.

@annevk will do thank you for all your information.

Are you suggesting that raising bugs would hold up browser implementation or whatwg should wait for service workers to solidify in browsers to make changes?

I’m suggesting you file a bug and that I will wait with fixing it until at least service workers v1 is out of the door.

Finally submitted the issue: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26238

Let me know if there are any issues.

Thanks again.