ajax 0 的 HTTP 状态代码有什么意义吗？

Does an HTTP Status code of 0 have any meaning?

提问by Mark Lutton

It appears that when you make an XMLHttpRequest from a script in a browser, if the browser is set to work offline or if the network cable is pulled out, the request completes with an error and with status = 0. 0 is not listed among permissible HTTP status codes.

看来，当您从浏览器中的脚本发出 XMLHttpRequest 时，如果浏览器设置为脱机工作或拔掉网线，则请求会以错误完成且状态 = 0。0 未列在允许范围内HTTP 状态代码。

What does a status code of 0 mean? Does it mean the same thing across all browsers, and for all HTTP client utilities? Is it part of the HTTP spec or is it part of some other protocol spec? It seems to mean that the HTTP request could not be made at all, perhaps because the server address could not be resolved.

状态码 0 是什么意思？对于所有浏览器和所有 HTTP 客户端实用程序，这是否意味着相同的事情？它是 HTTP 规范的一部分还是其他协议规范的一部分？好像是根本无法发出HTTP请求，可能是因为无法解析服务器地址。

What error message is appropriate to show the user? "Either you are not connected to the internet, or the website is encountering problems, or there might be a typing error in the address"?

什么错误消息适合向用户显示？“您没有连接到互联网，或者网站遇到问题，或者地址中可能存在输入错误”？

I should add to this that I see the behavior in FireFox when set to "Work Offline", but not in Microsoft Internet Explorer when set to "Work Offline". In IE, the user gets a dialog giving the option to go online. FireFox does not notify the user before returning the error.

我应该补充一点，当设置为“脱机工作”时，我在 FireFox 中看到了行为，但在设置为“脱机工作”时在 Microsoft Internet Explorer 中看不到。在 IE 中，用户会收到一个对话框，提供在线选项。FireFox 在返回错误之前不会通知用户。

I am asking this in response to a request to "show a better error message". What Internet Explorer does is good. It tells the user what is causing the problem and gives them the option to fix it. In order to give an equivalent UX with FireFox I need to infer the cause of the problem and inform the user. So what in total can I infer from Status 0? Does it have a universal meaning or does it tell me nothing?

我问这个是为了响应“显示更好的错误消息”的请求。Internet Explorer 的功能很好。它告诉用户是什么导致了问题，并为他们提供了修复它的选项。为了使用 FireFox 提供等效的 UX，我需要推断问题的原因并通知用户。那么我总共可以从状态 0 推断出什么？它有一个普遍的意义还是什么都没告诉我？

回答by Mark Amery

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 XMLHttpRequestor a Fetch response.

它不是 HTTP 响应代码，但 WhatWG 将其记录为 anXMLHttpRequest或 Fetch 响应的状态属性的有效值。

Broadly speaking, it is a default value used when there is no realHTTP 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:

从广义上讲，它是当没有真正的HTTP 状态代码报告和/或发送请求或接收响应发生错误时使用的默认值。这种情况的可能场景包括但不限于：

• 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

首先，重申：0 不是 HTTP 状态代码。在RFC 7231 Section 6.1 中有一个完整的列表，其中不包括 0，并且第 6 节的介绍清楚地指出

The status-code element is a three-digit integer code

status-code 元素是一个三位数的整数代码

which 0 is not.

其中 0 不是。

However, 0 as a value of the .statusattribute 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 .statusattribute, which simply states:

但是，.status文档中记录了0 作为XMLHttpRequest 对象的属性值，尽管跟踪所有相关细节有点棘手。我们从https://xhr.spec.whatwg.org/#the-status-attribute开始，记录该.status属性，其中简单说明：

The statusattribute must return the response's status.

该status属性必须返回响应的状态。

That may sound vacuous and tautological, but in reality there is information here! Remember that this documentation is talking here about the .responseattribute 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.

这可能听起来很空洞和同义反复，但实际上这里有信息！请记住，本文档在这里讨论的.response是 an的属性XMLHttpRequest，而不是响应，因此这告诉我们 XHR 对象上的状态定义推迟到 Fetch 规范中响应状态的定义。

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:

但是什么响应对象呢？如果我们实际上还没有收到回复怎么办？“响应”一词的内联链接将我们带到https://xhr.spec.whatwg.org/#response，其中解释了：

An XMLHttpRequesthas an associated response. Unless stated otherwise it is a network error.

AnXMLHttpRequest有一个关联的响应。除非另有说明，否则为网络错误。

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:

所以我们得到的响应状态默认是网络错误。通过搜索XHR 规范中使用短语“set response to”的所有地方，我们可以看到它被设置在五个地方：

• To a network error, when:

  • the open()methodis called, or
  • the response's body's streamis errored(see the algorithm described in the docs for the send()method)
  • the timed out flagis set, causing the request error stepsto run
  • the abort()methodis called, causing the request error stepsto run

• To the response produced by sending the request using Fetch, by way of either the Fetch process responsetask (if the XHR request is asychronous) or the Fetch process response end-of-bodytask (if the XHR request is synchronous).

• 对于网络错误，当：

  • 该open()方法被调用，或
  • 响应的主体的流是差错（见文档所描述的算法的send()方法）
  • 设置了超时标志，导致请求错误步骤运行
  • 该abort()方法被调用时，使得所述请求错误的步骤来运行

• 通过 Fetch进程响应任务（如果 XHR 请求是异步的）或 Fetch进程响应 end-of-body任务（如果 XHR 请求是同步的）来使用 Fetch 发送请求所产生的响应。

Looking in the Fetch standard, we can see that:

查看Fetch 标准，我们可以看到：

A network erroris a responsewhose statusis always 0

一个网络错误是一个响应，其状态始终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 afterhaving 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.)

所以我们可以立即知道，在 XHR 规范说响应应该设置为网络错误的任何情况下，我们都会在 XHR 对象上看到状态 0。（有趣的是，这包括主体的流“出错”的情况，Fetch 规范告诉我们在收到状态后解析主体的过程中可能会发生这种情况 - 所以理论上我认为 XHR 对象有可能拥有它的状态设置为 200，然后在接收正文时遇到内存不足错误或其他问题，因此将其状态更改回 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:

我们还在 Fetch 标准中注意到存在一些其他响应类型，其状态定义为 0，它们的存在与跨域请求和同源策略有关：

An opaque filtered response is a filtered responsewhose ... status is 0...

An opaque-redirect filtered response is a filtered responsewhose ... status is 0...

一个不透明的过滤响应是一个过滤的响应，它的 ... 状态是0...

不透明重定向过滤响应是一个过滤响应，其 ... 状态为0...

(various other details about these two response types omitted).

（省略了有关这两种响应类型的各种其他详细信息）。

But beyond these, there are also many cases where the Fetchalgorithm (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 timesin the Fetch standard. I will not try to list all 40 here, but I note that they include:

但除此之外，还有很多情况下Fetch算法（而不是我们已经看过的 XHR 规范）要求浏览器返回网络错误！事实上，“返回网络错误”这句话在 Fetch 标准中出现了40 次。我不会尝试在这里列出所有 40 个，但我注意到它们包括：

• 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 connectionis failure, return a network error."

• 请求的方案未被识别的情况（例如尝试向 madeupscheme://foobar.com 发送请求）
• 非常含糊的指令“如有疑问，返回网络错误。” 在处理 ftp:// 和 file:// URL 的算法中
• 无限重定向：“如果请求的重定向计数为 20，则返回网络错误。”
• 一堆与CORS相关的问题，例如“如果httpRequest的响应污染不是“ cors”并且请求和响应返回的跨域资源策略检查被阻止，则返回网络错误。
• 连接失败：“如果连接失败，则返回网络错误。”

In other words: whenever something goes wrong otherthan 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.

换句话说：每当出现问题而不是从服务器获取真正的 HTTP 错误状态代码（如 500 或 400）时，您的 XHR 对象或浏览器中的 Fetch 响应对象的状态属性最终都会为 0。规范中列举的可能具体原因的数量是巨大的。

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 muchsimpler) W3 spec for XHR, before these were replaced by the more modern and more complicated WhatWG specs this answers refers to.

最后：如果您出于某种原因对规范的历史感兴趣，请注意此答案已在 2020 年完全重写，并且您可能对此答案的先前修订版感兴趣，该修订版从本质上解析了相同的结论旧的（和很多简单）W3规格为XHR，这些之前被更现代，更复杂的WHATWG规范这个答案取代指。

回答by mnk

status 0 appear when an ajax call was cancelled before getting the response by refreshing the page or requesting a URL that is unreachable.

在通过刷新页面或请求无法访问的 URL 获得响应之前取消 ajax 调用时，状态 0 出现。

this status is not documented but exist over ajax and makeRequest call's from gadget.io.

此状态未记录在案，但存在于 ajax 和来自 gadget.io 的 makeRequest 调用中。

回答by Loki

from documentation http://www.w3.org/TR/XMLHttpRequest/#the-status-attributemeans a request was cancelled before going anywhere

来自文档http://www.w3.org/TR/XMLHttpRequest/#the-status-attribute表示请求在去任何地方之前被取消

回答by Obotor

Know it's an old post. But these issues still exist.

知道这是一个旧帖子。但是这些问题仍然存在。

Here are some of my findings on the subject, grossly explained.

以下是我对这个主题的一些发现，粗略地解释了。

"Status" 0 means one of 3 things, as per the XMLHttpRequest spec:

根据 XMLHttpRequest 规范，“Status” 0 表示以下三种情况之一：

• dns name resolution failed (that's for instance when network plug is pulled out)

• server did not answer (a.k.a. unreachable or unresponding)

• request was aborted because of a CORS issue (abortion is performed by the user-agent and follows a failing OPTIONS pre-flight).

• dns 名称解析失败（例如拔出网络插头时）

• 服务器没有回答（又名无法访问或无响应）

• 由于 CORS 问题，请求被中止（中止由用户代理执行，并遵循失败的 OPTIONS 预检）。

If you want to go further, dive deep into the inners of XMLHttpRequest. I suggest reading the ready-state update sequence ([0,1,2,3,4] is the normal sequence, [0,1,4] corresponds to status 0, [0,1,2,4] means no content sent which may be an error or not). You may also want to attach listeners to the xhr (onreadystatechange, onabort, onerror, ontimeout) to figure out details.

如果您想更进一步，请深入研究 XMLHttpRequest 的内部结构。建议阅读就绪状态更新序列（[0,1,2,3,4]为正常序列，[0,1,4]对应状态0，[0,1,2,4]表示无内容发送这可能是一个错误或没有）。您可能还想将侦听器附加到 xhr（onreadystatechange、onabort、onerror、ontimeout）以找出详细信息。

From the spec (XHR Living spec):

来自规范（XHR Living 规范）：

const unsigned short UNSENT = 0;
const unsigned short OPENED = 1;
const unsigned short HEADERS_RECEIVED = 2;
const unsigned short LOADING = 3;
const unsigned short DONE = 4;

回答by Nirav

Since iOS 9, you need to add "App Transport Security Settings" to your info.plist file and allow "Allow Arbitrary Loads" before making request to non-secure HTTP web service. I had this issue in one of my app.

从 iOS 9 开始，您需要在 info.plist 文件中添加“App Transport Security Settings”并在向非安全 HTTP Web 服务发出请求之前允许“Allow Arbitrary Loads”。我在我的一个应用程序中遇到了这个问题。

回答by Vinayak

Yes, some how the ajax call aborted. The cause may be following.

是的，ajax 调用是如何中止的。原因可能如下。

1. Before completion of ajax request, user navigated to other page.
2. Ajax request have timeout.
3. Server is not able to return any response.

1. 在 ajax 请求完成之前，用户导航到其他页面。
2. Ajax 请求超时。
3. 服务器无法返回任何响应。