HTTPレスポンス「200 OK」は、HTTPリクエストを生成したマシンがドキュメントを受信したことを保証しますか？
AとBの2台のマシンがあります。
AはHTTP要求をBに送信し、ドキュメントを要求します。 Bは応答して要求されたドキュメントを送信し、200 OKメッセージを送信しますが、マシンAはネットワーク障害のためにドキュメントを受信していないと不平を言っています。
HTTPコード200は、ドキュメントが受信されたことの確認としても機能しますか？
HTTP 200コードは、ドキュメントが受信されたことの確認としても機能しますか？
いいえ。まったくありません。
文書が完全に送信されたという保証すらありません。
応答コードは、応答ストリームの最初の行にあります。サーバーは失敗するか、応答の最初の行と最後のバイトを送信する間のクライアントから切断される可能性があります。サーバーは、これが起こったことさえ知らないかもしれません。
実際、クライアントが完全な（または部分的な）HTTP応答を受信したかどうかをサーバーが知る方法はありません。 HTTPプロトコルには確認応答の規定はありません。
これで、クライアントが2つ目のHTTP要求をサーバーに送信して「はい、ドキュメントを取得しました」と言う必要があるHTTPの上部にアプリケーションプロトコルを実装できます。しかし、これにはユーザーのブラウザに実装された「アプリケーションロジック」が含まれます。例えばJavascriptで。
絶対違う。 HTTP 200はサーバーによって生成され、リクエストを理解し、リクエストを処理できると考えていることを意味するだけです（たとえば、ファイルは実際にそこにあります）。すべての種類のエラーは、完全な応答ドキュメント（ネットワーク接続の切断、パケット損失など）の送信中に発生する可能性があり、HTTP応答には表示されませんが、個別に検出する必要があります。
HTTPプロトコルのかなり良いガイドがここにあります： http://blog.catchpoint.com/2010/09/17/anatomyhttp/
HTTPプロトコルと、基になるストリームトランスポートプロトコルを区別する必要があります。これは、HTTPの目的で信頼できるはずです。ストリーム転送プロトコルは、応答を含むすべてのデータ送信を確認し、交換の両端でデータが正しく送信されたことを確認します。トランスポートストリームが失敗すると、「ネットワークエラー」または同様のエラーが発生します。これが発生すると、HTTPプロトコルは続行できません。データの信頼性は失われ、完全ではなくなりました。
HTTPレベルでの200 OKメッセージの意味は、サーバーが目的のドキュメントを持ち、それを送信しようとしているということです。通常、コンテンツ長のヘッダーも取得するため、ストリームプロトコルの追加チェックとして本文が完了したかどうかを確認できます。 HTTPプロトコルの観点からは、応答は確認応答を受信しないため、応答が送信されると検証は行われません。
ただし、ストリーム転送は信頼できるため、応答の送信は成功するか、エラーになります。これは、ドキュメントがネットワークターゲットによって受信されたかどうかを確認します（たとえば、プロキシなどの非直接接続の場合、これは最終ターゲットへの配信を保証するものではありません）。
200 OK応答コードは、応答文書について何の保証もないことを確認するのは非常に簡単です。文書が送信される前に送信されるので、因果関係の違反のみが文書の正常な受信に依存することができます。これは、リクエストが適切に受信されたことを示すインジケータとしてのみ機能し、サーバーはリクエストを処理できると考えています。リクエストが静的ドキュメントを返すだけでなく、追加の処理（スクリプトの実行など）を必要とする場合、通常、これが完了した後に応答コードを送信する必要があります。永続的な接続やプッシュ通知を伴うリクエストなど、実行不可能です。スクリプトは後で失敗する可能性があります。
より一般的なレベルでは、 Two Generals Problem により、すべてのメッセージが任意のプロトコルで受信されたことを絶対的に保証することはできません。ある時点で最後の確認が必要になるため、確認システムはこれを回避できません。これが正常に受信されたかどうかを知る方法はありません。これが最後の確認であるという前提に反して、別の確認が必要になるからです。
HTTPは、さまざまな種類の「ミドルボックス」の可能性を意識して設計されています-クライアントの知識の有無にかかわらず動作するプロキシ。
プロキシが関与している場合、サーバーがすべてのデータを送信し、通常のクローズ接続を受信したことを知っていても、ドキュメントが受信されたかどうかはわかりませんHTTPリクエストを生成したマシンによる =。