HTTPステータスコード0は意味がありますか？

ブラウザーでスクリプトからXMLHttpRequestを作成するとき、ブラウザーがオフラインで動作するように設定されているか、ネットワークケーブルが抜かれている場合、リクエストはエラーで完了し、ステータス= 0になります。0は許容範囲内にリストされていませんHTTPステータスコード。

ステータスコード0はどういう意味ですか？すべてのブラウザ、およびすべてのHTTPクライアントユーティリティで同じことを意味しますか？それはHTTP仕様の一部ですか、それとも他のプロトコル仕様の一部ですか？サーバーアドレスを解決できなかったためか、HTTP要求をまったく送信できなかった可能性があります。

ユーザーに表示するのに適切なエラーメッセージはどれですか。「インターネットに接続していないか、Webサイトで問題が発生しているか、アドレスに入力ミスがある可能性があります。」

「オフラインで作業」に設定するとFireFoxでの動作が表示されるが、「オフラインで作業」に設定するとMicrosoft Internet Explorerでは表示されないことをこれに追加する必要があります。IEでは、ユーザーは、オンラインにするオプションを示すダイアログを受け取ります。FireFoxはエラーを返す前にユーザーに通知しません。

「より適切なエラーメッセージを表示する」という要求に応えてこれを求めています。Internet Explorerの機能は優れています。問題の原因をユーザーに通知し、問題を修正するオプションを提供します。FireFoxで同等のUXを提供するには、問題の原因を推測してユーザーに通知する必要があります。では、ステータス0から何を推測できるでしょうか。それは普遍的な意味を持っていますか、それとも私に何も教えませんか？

短い答え

これはHTTP応答コードではありませんが、WhatWGによって、XMLHttpRequestまたはFetch応答のステータス属性の有効な値として文書化されています。

大まかに言って、これは、レポートする実際の HTTPステータスコードがない場合や、リクエストの送信中またはレスポンスの受信中にエラーが発生した場合に使用されるデフォルト値です。これが当てはまる可能性のあるシナリオには以下が含まれますが、これらに限定されません。

• リクエストはまだ送信されていないか、中止されました。
• ブラウザは応答ステータスとヘッダーの受信をまだ待っています。
• リクエスト中に接続が切断されました。
• 要求がタイムアウトしました。
• リクエストで無限リダイレクトループが発生しました。
• ブラウザは応答ステータスを認識していますが、Same-origin Policyに関連するセキュリティ制限のため、アクセスは許可されていません。

長い答え

まず、繰り返しますが、0はHTTPステータスコードではありません。RFC 7231のセクション6.1にそれらの完全なリストがあり、0は含まれていません。セクション6の紹介では、

status-code要素は3桁の整数コードです

これは0ではありません。

ただし、.statusXMLHttpRequestオブジェクトの属性の値として0 が文書化されていますが、関連するすべての詳細を追跡するのは少し難しいです。https://xhr.spec.whatwg.org/#the-status-attributeから始めて、.status属性をドキュメント化します。

status属性は返さなければなりませんレスポンスのステータスを。

それは空想的でトートロジーに聞こえるかもしれませんが、実際にはここに情報があります！このドキュメントでは、レスポンスではなくの.response属性について説明しているXMLHttpRequestため、XHRオブジェクトのステータスの定義は、Fetch仕様のレスポンスのステータスの定義に委ねられていることを思い出してください。

しかし、どの応答オブジェクトですか？実際にまだ応答がない場合はどうなりますか？「応答」という単語のインラインリンクにより、https：//xhr.spec.whatwg.org/#responseに移動します。

にXMLHttpRequest関連付けられた応答があります。特に明記しない限り、これはネットワークエラーです。

したがって、ステータスが返されるのは、デフォルトではネットワークエラーです。XHR仕様で「set response to」という語句が使用されている場所をすべて検索すると、次の5か所に設定されていることがわかります。

• ネットワークエラーが発生した場合：

  • open()メソッドが呼ばれるか、または
  • 応答者の身体のストリームがされているエラーの発生（のためのドキュメントに記載されたアルゴリズムを参照方法）send()
  • タイムアウトしたフラグが原因とセットでリクエストエラーの手順を実行するために
  • abort()この方法は、原因、と呼ばれるリクエストエラーの手順を実行します

• Fetchを使用して要求を送信することによって生成された応答に対して、Fetch プロセス応答タスク（XHR要求が非同期の場合）またはFetch プロセス応答のボディ終了タスク（XHR要求が同期の場合）のいずれか。

見るとフェッチの標準、我々はそれを見ることができます：

ネットワークエラーがあるレスポンスその状況は常にあります0

XHR仕様で応答にネットワークエラーを設定する必要があると示されている場合は、XHRオブジェクトのステータスが0になることがすぐにわかります。（興味深いことに、これには、ボディのストリームが「エラー」になるケースが含まれます。Fetch仕様は、ステータスを受け取った後、ボディの解析中に発生する可能性があることを示しています。つまり、理論的には、XHRオブジェクトがそのステータスを持つ可能性がある200に設定すると、ボディの受信中にメモリ不足エラーなどが発生するため、ステータスを0に戻します。

また、Fetch標準では、ステータスが0と定義されている他のいくつかの応答タイプが存在し、その存在がクロスオリジンリクエストと同一オリジンポリシーに関連していることにも注意しています。

不透明なフィルタリングされた応答は、...ステータスが... であるフィルタリングされた応答です0。

不透明なリダイレクトフィルター応答は、...ステータスが...のフィルター応答です0。

（これらの2つの応答タイプに関するその他のさまざまな詳細は省略されています）。

しかし、これらを超えて、Fetchアルゴリズム（すでに見てきたXHR仕様ではなく）がブラウザーにネットワークエラーを返すよう要求するケースも多くあります。実際、「ネットワークエラーを返す」というフレーズは、Fetch標準で40回出現します。ここでは40をすべてリストするつもりはありませんが、次のものが含まれています。

• リクエストのスキームが認識されない場合（例：madeupscheme：//foobar.comにリクエストを送信しようとしている）
• 不明確で不明確な指示「疑わしい場合は、ネットワークエラーを返す」。ftp：//およびfile：// URLを処理するアルゴリズム
• 無限リダイレクト：「リクエストのリダイレクト数が20の場合、ネットワークエラーを返します。」
• 「httpRequestの応答の汚染が「cors」ではなく、要求と応答を含むクロスオリジンリソースポリシーチェックがブロックされた場合、ネットワークエラーを返す」など、CORS関連の一連の問題。
• 接続の失敗：「接続が失敗した場合は、ネットワークエラーを返します。」

言い換えれば、何かがうまくいかない時はいつでも、他のサーバーからの500や400のような実際のHTTPエラーステータスコードを取得するよりも、あなたはXHRオブジェクトに0の状態属性で終わるか、ブラウザで応答オブジェクトを取得します。スペックに列挙されている考えられる特定の原因の数は膨大です。

最後に：あなたはこの答えは完全に2020年に書き直され、あなたがに興味がある可能性がありということであったことを何らかの理由で、ノートのスペックの歴史に興味があれば、この答えの前のリビジョンのうち、本質的に同じ結論を解析され、XHRの古い（そして非常に単純な）W3仕様。これらが、この回答が参照するより近代的でより複雑なWhatWG仕様に置き換えられる前。

ステータス0は、ページを更新するか到達不能なURLを要求して応答を取得する前にajax呼び出しがキャンセルされた場合に表示されます。

このステータスは文書化されていませんが、gadget.ioからのajaxとmakeRequest呼び出しの上に存在します。

ドキュメントからhttp://www.w3.org/TR/XMLHttpRequest/#the-status-attribute は、どこかに行く前にリクエストがキャンセルされたことを意味します

古い投稿であることを確認してください。しかし、これらの問題はまだ存在しています。

ここでは、この件に関する私の発見の一部を、大まかに説明します。

「ステータス」0は、XMLHttpRequest仕様に従って、次の3つのいずれかを意味します。

• DNS名前解決に失敗しました（ネットワークプラグが抜かれた場合など）

• サーバーが応答しなかった（別名到達不能または応答しない）

• CORSの問題のため、リクエストは中止されました（中止はユーザーエージェントによって実行され、失敗したOPTIONSプリフライトに従います）。

さらに詳しく知りたい場合は、XMLHttpRequestの内部について詳しく説明します。準備状態の更新シーケンスを読むことをお勧めします（[0,1,2,3,4]は通常のシーケンスです。[0,1,4]はステータス0に対応します。[0,1,2,4]はコンテンツがないことを意味しますエラーの可能性があります）。詳細を把握するために、リスナーをxhr（onreadystatechange、onabort、onerror、ontimeout）にアタッチすることもできます。

仕様から（XHR Living spec）：

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;

iOS 9以降、安全でないHTTP Webサービスにリクエストを行う前に、info.plistファイルに「App Transport Security Settings」を追加し、「Allow Arbitrary Loads」を許可する必要があります。私のアプリの1つでこの問題が発生しました。

はい、ajax呼び出しが途中で中止された方法もあります。原因は以下の可能性があります。

1. ajaxリクエストが完了する前に、ユーザーは他のページに移動しました。
2. Ajaxリクエストにタイムアウトがあります。
3. サーバーは応答を返すことができません。