問題描述

似乎當您從瀏覽器中的腳本發出 XMLHttpRequest 時，如果瀏覽器設置為脫機工作或拔出網線，則請求完成并出現錯誤并且狀態 = 0.0 不是列在允許的 HTTP 狀態代碼中.

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.

狀態碼 0 是什么意思?對于所有瀏覽器和所有 HTTP 客戶端實用程序，這是否意味著相同的事情?它是 HTTP 規范的一部分還是其他協議規范的一部分?似乎是根本無法發出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.

什么錯誤信息適合向用戶顯示?要么您沒有連接到互聯網，要么網站遇到問題，或者地址輸入錯誤"?

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"?

我應該補充一點，當設置為脫機工作"時，我在 FireFox 中看到了該行為，但在設置為脫機工作"時，在 Microsoft Internet Explorer 中看不到.在 IE 中，用戶會看到一個對話框，提供在線選項.FireFox 在返回錯誤之前不會通知用戶.

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.

我問這個是為了響應顯示更好的錯誤消息"的請求.Internet Explorer 的功能很好.它告訴用戶是什么導致了問題，并為他們提供了修復它的選項.為了提供與 FireFox 等效的 UX，我需要推斷問題的原因并通知用戶.那么我總共可以從狀態 0 中推斷出什么?它有普遍意義還是什么也沒告訴我?

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?

推薦答案

簡答

這不是 HTTP 響應代碼，但 WhatWG 將其記錄為 XMLHttpRequest 或 Fetch 響應的狀態屬性的有效值.

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.

廣義上講，它是在沒有真實 HTTP 狀態代碼要報告和/或發送請求或接收響應時發生錯誤時使用的默認值.出現這種情況的可能場景包括但不限于:

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:

• 請求尚未發送或已中止.
• 瀏覽器仍在等待接收響應狀態和標頭.
• 請求期間連接斷開.
• 請求超時.
• 請求遇到無限重定向循環.
• 瀏覽器知道響應狀態，但由于與 同源政策.

首先，重申一下:0 不是 HTTP 狀態碼.RFC 7231 第 6.1 節 中有完整的列表'不包括 0，第 6 節的介紹清楚地指出

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

status-code 元素是一個三位整數代碼

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

哪個不是 0.

然而，記錄了作為 XMLHttpRequest 對象的 .status 屬性的值的 0，盡管跟蹤所有相關細節有點棘手.我們從 https://xhr.spec.whatwg.org/#the-status 開始-attribute，記錄 .status 屬性，簡單說明:

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:

status 屬性必須返回 響應狀態.

這聽起來可能很空洞且重復，但實際上這里有信息！請記住，本文檔在這里討論的是 XMLHttpRequest 的 .response 屬性，而不是響應，因此這告訴我們 XHR 對象上的狀態定義是延遲的到 Fetch 規范中響應狀態的定義.

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.

但是什么響應對象呢?如果我們實際上還沒有收到回復怎么辦?響應"一詞上的內聯鏈接將我們帶到 https://xhr.spec.whatwg.org/#response，其中解釋:

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:

XMLHttpRequest 具有關聯的響應.除非另有說明，否則這是一個網絡錯誤.

所以我們得到的響應狀態默認是網絡錯誤.通過搜索在 XHR 規范中使用的短語 set response to"，我們可以看到它被設置在五個地方:

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:

• open() 方法 被調用，或者
• 響應的 body 的 stream 是 errored (請參閱 send() 方法)
• 設置了 超時標志，導致 請求錯誤步驟運行
• abort() 方法 被調用，導致 請求錯誤步驟 運行

• 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

對于使用 Fetch 發送請求產生的響應，通過 Fetch 處理響應 任務(如果 XHR 請求是異步的)或 Fetch 處理響應體結束 任務(如果 XHR 請求是同步的).

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

查看Fetch 標準，我們可以看到:

網絡錯誤是response 其 status 總是 0

因此，在 XHR 規范規定響應應設置為網絡錯誤的任何情況下，我們都可以立即知道 XHR 對象的狀態為 0.(有趣的是，這包括正文的流被錯誤"的情況，Fetch 規范告訴我們，在收到狀態之后解析正文時可能會發生這種情況 - 所以理論上我認為這是可能的將 XHR 對象的狀態設置為 200，然后在接收主體時遇到內存不足錯誤或其他問題，因此將其狀態更改回 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.)

我們還注意到在 Fetch 標準中存在一些其他響應類型，它們的狀態定義為 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:

不透明的過濾響應是 過濾響應，其 ...狀態是 0...

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

不透明重定向過濾響應是 過濾響應，其 ... 狀態為 0...

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

(省略了有關這兩種響應類型的其他各種詳細信息).

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

但除此之外，還有很多情況是 Fetch 算法(而不是我們已經看過的 XHR 規范)要求瀏覽器返回網絡錯誤！實際上，短語return a network error"很重要.在 Fetch 標準中出現 40 次.我不會嘗試在這里列出所有 40 個，但我注意到它們包括:

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:

• 請求的方案無法識別的情況(例如，嘗試向 madeupscheme://foobar.com 發送請求)
• 非常模糊的指令如有疑問，請返回網絡錯誤."在處理 ftp://和 file://URL 的算法中
• 無限重定向:如果請求的重定向計數為 20，則返回網絡錯誤."
• 一堆與CORS相關的問題，例如如果httpRequest的響應污染不是cors"；并且請求和響應返回阻塞的跨域資源策略檢查，然后返回網絡錯誤."
• 連接失敗:如果連接失敗，返回網絡錯誤."

• 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."

換句話說:每當出現問題時其他除了從服務器獲取真正的 HTTP 錯誤狀態代碼(如 500 或 400)之外，您最終會在 XHR 對象上獲得狀態屬性 0 或在瀏覽器中獲取響應對象.規范中列舉的可能的具體原因數量眾多.

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.

最后:如果您出于某種原因對規范的歷史感興趣，請注意此答案已在 2020 年完全重寫，您可能對 此答案的先前修訂版，在將這些被替換為此答案所指的 WhatWG 規范越現代、越復雜.

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.

這篇關于HTTP 狀態碼 0 是否有任何意義?的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！