Short Answer
It’s not a HTTP response code, but it is documented by WhatWG as a valid value for the status attribute of an XMLHttpRequest or a Fetch response.
Broadly speaking, it is a default value used when there is no real HTTP status code to report and/or an error occurred sending the request or receiving the response. Possible scenarios where this is the case include, but are not limited to:
- The request hasn’t yet been sent, or was aborted.
- The browser is still waiting to receive the response status and headers.
- The connection dropped during the request.
- The request timed out.
- The request encountered an infinite redirect loop.
- The browser knows the response status, but you’re not allowed to access it due to security restrictions related to the Same-origin Policy.
Long Answer
First, to reiterate: 0 is not a HTTP status code. There’s a complete list of them in RFC 7231 Section 6.1, that doesn’t include 0, and the intro to section 6 states clearly that
The status-code element is a three-digit integer code
which 0 is not.
However, 0 as a value of the .status attribute of an XMLHttpRequest object is documented, although it’s a little tricky to track down all the relevant details. We begin at https://xhr.spec.whatwg.org/#the-status-attribute, documenting the .status attribute, which simply states:
That may sound vacuous and tautological, but in reality there is information here! Remember that this documentation is talking here about the .response attribute of an XMLHttpRequest, not a response, so this tells us that the definition of the status on an XHR object is deferred to the definition of a response’s status in the Fetch spec.
But what response object? What if we haven’t actually received a response yet? The inline link on the word “response” takes us to https://xhr.spec.whatwg.org/#response, which explains:
An
XMLHttpRequesthas an associated response. Unless stated otherwise it is a network error.
So the response whose status we’re getting is by default a network error. And by searching for everywhere the phrase “set response to” is used in the XHR spec, we can see that it’s set in five places:
-
To a network error, when:
- the
open()method is called, or - the response’s body‘s stream is errored (see the algorithm described in the docs for the
send()method) - the timed out flag is set, causing the request error steps to run
- the
abort()method is called, causing the request error steps to run
- the
-
To the response produced by sending the request using Fetch, by way of either the Fetch process response task (if the XHR request is asychronous) or the Fetch process response end-of-body task (if the XHR request is synchronous).
Looking in the Fetch standard, we can see that:
A network error is a response whose status is always
0
so we can immediately tell that we’ll see a status of 0 on an XHR object in any of the cases where the XHR spec says the response should be set to a network error. (Interestingly, this includes the case where the body’s stream gets “errored”, which the Fetch spec tells us can happen during parsing the body after having received the status – so in theory I suppose it is possible for an XHR object to have its status set to 200, then encounter an out-of-memory error or something while receiving the body and so change its status back to 0.)
We also note in the Fetch standard that a couple of other response types exist whose status is defined to be 0, whose existence relates to cross-origin requests and the same-origin policy:
An opaque filtered response is a filtered response whose … status is
0…An opaque-redirect filtered response is a filtered response whose … status is
0…
(various other details about these two response types omitted).
But beyond these, there are also many cases where the Fetch algorithm (rather than the XHR spec, which we’ve already looked at) calls for the browser to return a network error! Indeed, the phrase “return a network error” appears 40 times in the Fetch standard. I will not try to list all 40 here, but I note that they include:
- The case where the request’s scheme is unrecognised (e.g. trying to send a request to madeupscheme://foobar.com)
- The wonderfully vague instruction “When in doubt, return a network error.” in the algorithms for handling ftp:// and file:// URLs
- Infinite redirects: “If request’s redirect count is twenty, return a network error.”
- A bunch of CORS-related issues, such as “If httpRequest’s response tainting is not “cors” and the cross-origin resource policy check with request and response returns blocked, then return a network error.”
- Connection failures: “If connection is failure, return a network error.”
In other words: whenever something goes wrong other than getting a real HTTP error status code like a 500 or 400 from the server, you end up with a status attribute of 0 on your XHR object or Fetch response object in the browser. The number of possible specific causes enumerated in spec is vast.
Finally: if you’re interested in the history of the spec for some reason, note that this answer was completely rewritten in 2020, and that you may be interested in the previous revision of this answer, which parsed essentially the same conclusions out of the older (and much simpler) W3 spec for XHR, before these were replaced by the more modern and more complicated WhatWG specs this answers refers to.