What does it mean when an HTTP request returns status code 0?

Viewed 344405

What does it mean when JavaScript network calls such as fetch or XMLHttpRequest, or any other type of HTTP network request, fail with an HTTP status code of 0?

This doesn't seem to be a valid HTTP status code as other codes are three digits in HTTP specification.

I tried unplugging the network completely as a test. It may be unrelated, but that resulted in status code 17003 (IIRC), which cursory searching suggests means "DNS server lookup failed".

The same code works fine from some locations and systems, however within certain environments it fails with status code 0 and there is no responseText provided.

This is a typical HTTP POST to an Internet URL. It does not involve file:// which I understand may return 0 indicating success in Firefox.

15 Answers

I believe the error code indicates that the response was empty, (as not even headers were returned). This means the connection was accepted and then closed gracefully (TCP FIN). There are a number of things which could cause this, but based off of your description, some form of firewall seems the most likely culprit.

wininet.dll returns both standard and non-standard status codes that are listed below.

401 - Unauthorized file
403 - Forbidden file
404 - File Not Found
500 - some inclusion or functions may missed
200 - Completed

12002 - Server timeout
12029,12030, 12031 - dropped connections (either web server or DB server)
12152 - Connection closed by server.
13030 - StatusText properties are unavailable, and a query attempt throws an exception

For the status code "zero" are you trying to do a request on a local webpage running on a webserver or without a webserver?

XMLHttpRequest status = 0 and XMLHttpRequest statusText = unknown can help you if you are not running your script on a webserver.

Workaround: what we ended up doing

We figured it was to do with firewall issues, and so we came up with a workaround that did the trick. If anyone has this same issue, here's what we did:

  1. We still write the data to a text file on the local hard disk as we previously did, using an HTA.

  2. When the user clicks "send data back to server", the HTA reads in the data and writes out an HTML page that includes that data as an XML data island (actually using a SCRIPT LANGUAGE=XML script block).

  3. The HTA launches a link to the HTML page in the browser.

  4. The HTML page now contains the javascript that posts the data to the server (using Microsoft.XMLHTTP).

Hope this helps anyone with a similar requirement. In this case it was a Flash game used on a laptop at tradeshows. We never had access to the laptop and could only email it to the client as this tradeshow was happening in another country.

I found a new and undocumented reason for status == 0. Here is what I had:

XMLHttpRequest.status === 0
XMLHttpRequest.readyState === 0
XMLHttpRequest.responseText === ''
XMLHttpRequest.state() === 'rejected'

It was not cross-origin, network, or due to cancelled requests (by code or by user navigation). Nothing in the developer console or network log.

I could find very little documentation on state() (Mozilla does not list it, W3C does) and none of it mentioned "rejected".

Turns out it was my ad blocker (uBlock Origin on Firefox).

If you are testing on local PC, it won't work. To test Ajax example you need to place the HTML files on a web server.

In my case, the error occurred in a page requested with HTTP protocol, with a Javascript inside it trying to make an HTTPS request. And vice-versa.

After page loading, press F12 (or Ctrl + U) and take a look at the HTML code of your page. If you see something like that in your code:

<!-- javascript request inside the page -->
<script>
var ajaxurl = "https://example.com/wp-admin/admin-ajax.php";
(...)
</script>

And your page was requested this way:

http://example.com/example-page/2019/09/13/my-post/#elf_l1_Lw

You certainly will face this error.

To fix it, set the protocol of the Javascript request equal to the protocol of page request.

This situation involving different protocols, for page and js requests, was mentioned before in the answer of Brad Parks but, I guess the diagnostic technique presented here is easier, for the majority of users.

Related