Question: Is it possible to prevent the browser from following redirects when sending XMLHttpRequest-s (i.e. to get the redirect status code back and handle it myself)?

Answer: 
The new [Fetch API](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) supports different modes of redirect handling: `follow`, `error`, and `manual`, but I can't find a way to view the new URL or the status code when the redirection has been canceled. You just can stop the redirection itself, and then it looks like an error (empty response). If that's all you need, you are good to go. Also you should be aware that the requests made via this API are not cancelable [yet](https://github.com/whatwg/fetch/issues/27). *They [are](https://stackoverflow.com/a/46785332) now.*

As for XMLHttpRequest, you can `HEAD` the server and inspect whether the URL has changed:

```
var http = new XMLHttpRequest();
http.open('HEAD', '/the/url');
http.onreadystatechange = function() {
    if (this.readyState === this.DONE) {
        console.log(this.responseURL);
    }
};
http.send();

```

You won't get the status code, but will find the new URL without downloading the whole page from it.
I extended user's answer to include an `abort()` call. It seems like this prevents the server from sending too much data when all you want is the redirect url.

```js
var url = 'the url'
var http = new XMLHttpRequest();
http.open('GET', url);
http.onreadystatechange = function() {
    if (this.readyState === this.DONE) {
        console.log(this.responseURL)
        this.abort() // This seems to stop the response
    }
}
http.send()

```

In real life I wrapped the above code in a promise, but it made the code hard to read.

Also, I don't understand why getting the redirect url needs to be this difficult, but that is a question for another time and place.