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

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.

Many of the answers here are wrong. It seems people figure out what was causing status==0 in their particular case and then generalize that as the answer.

Practically speaking, status==0 for a failed XmlHttpRequest should be considered an undefined error.

The actual W3C spec defines the conditions for which zero is returned here: https://fetch.spec.whatwg.org/#concept-network-error

As you can see from the spec (fetch or XmlHttpRequest) this code could be the result of an error that happened even before the server is contacted.

Some of the common situations that produce this status code are reflected in the other answers but it could be any or none of these problems:

1. Illegal cross origin request (see CORS)
2. Firewall block or filtering
3. The request itself was cancelled in code
4. An installed browser extension is mucking things up

What would be helpful would be for browsers to provide detailed error reporting for more of these status==0 scenarios. Indeed, sometimes status==0 will accompany a helpful console message, but in others there is no other information.

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.

For what it is worth, depending on the browser, jQuery-based AJAX calls will call your success callback with a HTTP status code of 0. We've found a status code of "0" usually means the user navigated to a different page before the AJAX call completed.

Not the same technology stack as you are using, but hopefully useful to somebody.

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.

An HTTP response code of 0 indicates that the AJAX request was cancelled.

This can happen either from a timeout, XHR abortion or a firewall stomping on the request. A timeout is common, it means the request failed to execute within a specified time. An XHR Abortion is very simple to do... you can actually call .abort() on an XMLHttpRequest object to cancel the AJAX call. (This is good practice for a single page application if you don't want AJAX calls returning and attempting to reference objects that have been destroyed.) As mentioned in the marked answer, a firewall would also be capable of cancelling the request and trigger this 0 response.

XHR Abort: https://stackoverflow.com/questions/446594/abort-ajax-requests-using-jquery

var xhr = $.ajax({
    type: "POST",
    url: "some.php",
    data: "name=John&location=Boston",
    success: function(msg){
       alert( "Data Saved: " + msg );
    }
});

//kill the request
xhr.abort()

It's worth noting that running the .abort() method on an XHR object will also fire the error callback. If you're doing any kind of error handling that parses these objects, you'll quickly notice that an aborted XHR and a timeout XHR are identical, but with jQuery the textStatus that is passed to the error callback will be "abort" when aborted and "timeout" with a timeout occurs. If you're using Zepto (very very similar to jQuery) the errorType will be "error" when aborted and "timeout" when a timeout occurs.

jQuery: error(jqXHR, textStatus, errorThrown);
Zepto:  error(xhr, errorType, error);

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.

As detailed by this answer on this page, a status code of 0 means the request failed for some reason, and a javascript library interpreted the fail as a status code of 0.

###To test this you can do either of the following:

1. Use this chrome extension, Requestly to redirect your url from the https version of your url to the http version, as this will cause a mixed content security error, and ultimately generate a status code of 0. The advantage of this approach is that you don't have to change your app at all, and you can simply "rewrite" your url using this extension.

2. Change the code of your app to optionally make your endpoint redirect to the http version of your url instead of the https version (or vice versa). If you do this, the request will fail with status code 0.

In my case the status became 0 when i would forget to put the WWW in front of my domain. Because all my ajax requests were hardcoded http:/WWW.mydomain.com and the webpage loaded would just be http://mydomain.com it became a security issue because its a different domain. I ended up doing a redirect in my .htaccess file to always put www in front.

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

In my case, it was because the AJAX call was being blocked by the browser because of the same-origin policy. It was the least expected thing, because all my HTMLs and scripts where being served from 127.0.0.1. How could they be considered as having different origins?

Anyway, the root cause was an innocent-looking <base> tag:

<base href='<%=request.getScheme()%>://<%=request.getServerName() + ":" + request.getServerPort() + request.getContextPath()%>/'/>

I removed the <base> tag, which I did not need by the way, and now it works fine!

In addition to Lee's answer, you may find more information about the real cause by switching to synchronous requests, as you'll get also an exception :

function request(url) {
	var request = new XMLHttpRequest();
	try {
		request.open('GET', url, false);
		request.send(null);
	} catch (e) {
		console.log(url + ': ' + e);
	}
}

For example :

> NetworkError: A network error occurred.

In case anyone else comes across this problem, this was giving me issues due to the AJAX request and a normal form request being sent. I solved it with the following line:

<form onsubmit="submitfunc(); return false;">

The key there is the return false, which causes the form not to send. You could also just return false from inside of submitfunc(), but I find explicitly writing it to be clearer.

It should be noted that an ajax file upload exceeding the client_max_body_size directive for nginx will return this error code.

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.