XMLHttpRequest() & net::ERR_NAME_NOT_RESOLVED

Question

I am writing a javascript app that makes an HTTP request of a remote server. The user will enter the host name.

I want to offer a diagnostic message if they enter a DNS name that cannot resolve. Here's the current code:

var req, t, url;
url = 'http://definitelydoesntexist0x314159.com';
req = new XMLHttpRequest();
req.open('GET', url, true);
req.onreadystatechange = function() {
  if (req.readyState == 4) {
    t = req.statusText;
  }
};
req.send();

In the onreadystatechange function, the req has status=0, response is "", so there's not much indication of what went wrong. Yet the Console shows "Failed to load resource: net::ERR_NAME_NOT_RESOLVED" so the browser (Chrome) was able to figure out what happened.

How can I get an indication of ERR_NAME_NOT_RESOLVED?

Update: I have come back to this question, using the strategy that any response that isn't 'timeout' means that the name resolved, the host answers, etc.

The answer to my original question seems to be: It appears that the browser itself (Chrome, in this case) detects the failure to resolve and displays it in the Console, but the XMLHttpRequest API isn't rich enough to indicate the cause. So the poor Javascript programmer is stuck with the timeout as a workaround.

I also removed the CORS header, as one of the commenters correctly noted was of no value.

Answer 1

After a great deal more research, I understand the problem more clearly, and understand the answer (No, it's not possible to get the reason - e.g., ERR_NAME_NOT_RESOLVED - in the error status).

This is by design. The Javascript error handling routines do not, and must not, return more information about the reason for the failures. Browsers do this to prevent malicious Javascript code from running port scanners on the local network and sending that information to a remote server.

This is borne out quite clearly by my report on the Chromium bug reporter and the response from one of the developers, at: https://bugs.chromium.org/p/chromium/issues/detail?id=718447 especially Comment #2.

Thus, the javascript in the window runs in a sandbox, that only has access to load, timeout, abort, and error status, without any further granularity. (The browser's debugging environment, though, can display this information, so you can figure out what went wrong...)

Answer 2

I had this issue this morning when I was trying to hit a server running on my local machine and I was able to resolve it by doing the following.

1. Switch your request URL to http://127.0.0.1:3000
2. Make a network request with the new request URL
3. Switch back to http://localhost:3000
4. Make another network request and it should work

I think it cleared some cache by forcing it to use the IP address directly. Hopefully, it works for others experiencing this issue.