18

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.

richb-hanover
  • 1,015
  • 2
  • 12
  • 23
  • 1
    Setting `req.setRequestHeader('Access-Control-Allow-Origin', url);` in the request is useless. – epascarello Nov 06 '15 at 15:07
  • I have heard that it's important: can you say why it would be useless? Thanks for helping me understand this – richb-hanover Nov 06 '15 at 15:44
  • Because the server can only set it. – epascarello Nov 06 '15 at 15:45
  • Ahah! Yes, now I understand. Thank you. For the record, here's how CORS works: Client/browser simply sends the request. If it's to another origin, the client/browser also includes an "Origin: ..." header. If the **server** wants to accept the request, it responds with the "Access-Control-Allow-Origin" header of the *origin*. The browser also checks for that header in the response, and if it's not present, it conceals all the header info of the response. – richb-hanover Nov 06 '15 at 16:04
  • BTW: do you have any thoughts on detecting ERR_NAME_NOT_RESOLVED? – richb-hanover Nov 06 '15 at 16:06
  • You get what the XMLHttpRequest gives to you. – epascarello Nov 06 '15 at 16:42
  • 1
    You can check for `req.status == 0 && req.readyState == 4`. Unfortunately, as far as I can tell, there's no way to find out why it returned a zero status. – MarkPlewis Nov 06 '15 at 17:06
  • Possible duplicate of [How to detect if a request was aborted?](https://stackoverflow.com/questions/3648309/how-to-detect-if-a-request-was-aborted) – Paul Sweatte Jun 21 '17 at 14:46
  • Not really the same question. See my answer below. – richb-hanover Jun 22 '17 at 21:26

2 Answers2

19

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...)

richb-hanover
  • 1,015
  • 2
  • 12
  • 23
  • my problem is that the error terminates my whole script and the page needs reloading. Haven't figured out how to handle those exceptions in async flow... – wick Jul 26 '22 at 16:06
  • I don't have a firm answer, but I believe you should start a new question with your symptoms as a base. (Maybe a subject of "Error in XMLHttpRequest aborts entire script" and describe what you're doing, and what you see...) Good luck – richb-hanover Jul 27 '22 at 18:09
4

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.

Nitsew
  • 3,612
  • 1
  • 15
  • 20