フロントエンド開発者が知っておくべき http プロトコルに関する知識-htmlチュートリアル-php.cn

http (ハイパーテキスト転送プロトコル) は、要求および応答モードに基づいたステートレスなアプリケーション層プロトコルであり、多くの場合、TCP 接続方法に基づいています。この記事ではフロントエンド開発者が知っておくべきhttpプロトコル関連の知識について解説しますので、これからフロントエンドをやりたい、または現在フロントエンドをやっている友人は必ず知っておくべき内容です。

#1. コンセプト

## http (ハイパーテキスト転送プロトコル) は、リクエストとレスポンスのモデルに基づいています。、

ステートレス、およびアプリケーション層プロトコルで、多くの場合、TCP 接続メソッドに基づいています。HTTP1.1 バージョンは、継続的な接続メカニズムを提供します。Web 開発の大部分は、このプロトコルに基づいた HTTP Web アプリケーション上に構築されています。

2. 開発

バージョン 0.9 (get のみサポート) - 1.0 - 1.1 - 2.0 (開発中)

バージョン 0.9 は試用版とみなされ、導入されません。主に1.0と1.1の違いについて話します。

2.1 永続的接続と非永続的接続

バージョン 1.0 は非永続的接続をサポートします。これは、TCP プロトコルを通過することを意味します (http はアプリケーション層プロトコルベースです) TCP) スリーウェイハンドシェイク接続が確立された後、サーバーは 1 つのオブジェクトのみをブラウザーに送信できるため、リンクは切断されます。Web ページに画像、js ファイル、css ファイルなどの他のインラインオブジェクトが含まれている場合、など、複数のリンクを確立する必要があり、複数回の確立/切断によるオーバーヘッドが発生します。バージョン 1.1 は連続リンクをサポートしています。接続が確立された後、複数のオブジェクトを送信できます。したがって、理論的には、バージョン 1.1 は 1.0 よりもリソースが節約され、高速になります。しかし、一部のネチズンは 1.0 の方が高速であると主張しており、これは受け入れられません。それ。

2.2 ホストドメイン

Host ヘッダーフィールドは、要求されたリソースのインターネットホストとポート番号を指定し、要求された URL の元のサーバーまたはゲートウェイの場所を示す必要があります。 HTTP/1.1 リクエストにはホストヘッダーフィールドが含まれている必要があります。そうでない場合、システムは 400 ステータスコードを返します。おそらく速度を上げるために、このフィールドは不可欠であるように感じられます。やはり、HOST を直接指定したほうが、対応するホストを早く見つけることができますし、ホストが存在しない場合でも、早く見つけることができます。

2.3 帯域幅の最適化

バージョン 1.1 は部分的なリソース要求をサポートしており、リソースの一部のみを要求できます。同時に、バージョン 1.1 では 100 ステータスコードがサポートされています。リクエストエンティティが大きい場合、最初に 100 ステータスコードを含むヘッダーフィールドを送信して、サーバーがリクエストに応答するかどうかを確認できます。応答できる場合、リクエストエンティティはが再送信されるため、特定の時点で応答しない状況でも帯域幅が節約されます。

具体的な処理: クライアント - 100 個のステータスコードを含むリクエストヘッドを送信 - サーバーは応答できるかどうかを確認し、応答できない場合は対応するステータスコード (401、未認証など) を返します。100 個のステータスコードを返す -クライアントは、返されたステータスコードに基づいてリクエストの送信を続行するかどうかを確認します。

2.4 リクエストメソッドとステータスコード

HTTP1.1 では、OPTIONS、PUT、DELETE、TRACE、CONNECT およびその他のリクエストメソッドが追加されます

HTTP/1.0 ステータスでは 16 個のみが定義されています応答コードは、エラーや警告に対して十分具体的ではありません。 HTTP/1.1 では、エラーまたは警告情報の説明を追加するための Warning ヘッダーフィールドが導入されました。

HTTP/1.1 には、要求されたリソースがリソースの現在のステータスと競合していることを示す 409 (競合)、サーバー上のリソースが競合していることを示す 410 (Gone) など、24 の新しいステータス応答コードが追加されました。性的削除は完全に削除されます。

3.http 通信プロセス

(1) URL に従って DNS にクエリを実行し、Web サーバーを見つけて、TCP 接続を確立します。それ（http下位層合意）。

(2) 次に、Web ブラウザがサーバーにリクエストを送信します。

リクエストには通常、次が含まれます: |リクエストメソッド uri http バージョン番号|リクエストヘッダー|リクエストテキスト例:

GET /hello.jpg HTTP/1.1

受け入れる:image/gif.image/jpeg

Accept-Language:zh-cn

## 接続:Keep-Alive

# ホスト:127.0.0.1

ユーザーエージェント:Mozila/4.0(互換; (3) Web サーバーの応答。通常、応答パッケージには次のものが含まれます: |プロトコルバージョンステータスコードの説明|応答ヘッダー|応答テキスト

HTTP/1.1 200 OK

サーバー:Apache Tomcat/5.0 12

## Date:Mon,6 Oct 2017 13:23:42 GMT

Content-Length:188

#4. http ヘッダーフィールド

## コンテンツのこの部分は詳細すぎるため、表に直接リストされています。

リクエストヘッダー:

#ヘッダー説明例承諾クライアントが受信できるコンテンツタイプを指定しますAccept: text/plain, text/htmlAccept-Charsetブラウザは次のことを行うことができます。文字エンコードセットを受け入れます。 Accept-Charset: iso-8859-5Accept-EncodingWeb サーバーから返されるコンテンツの圧縮エンコードタイプを指定します。サポートできる。 Accept-Encoding: compress、gzipAccept-LanguageAccept-Language: en,zhAccept-RangesWeb ページエンティティの 1 つ以上のサブ範囲フィールドをリクエストできますAccept-Ranges: bytes認可HTTP 認可認可証明書認可: 基本 QWxhZGRpbjpvcGVuIHNlc2FtZQ==#Cache-Control リクエストに続くキャッシュメカニズムを指定しますおよび応答Cache-Control: no-cacheConnection永続的な接続が必要かどうかを示します。 (HTTP 1.1 はデフォルトで永続的な接続を使用します) Connection: closeCookieHTTP リクエストが送信されると、リクエストされたディレクトリの下に情報が保存されます。ドメイン名はすべての Cookie 値が一緒に Web サーバーに送信されます。 Cookie: $Version=1; Skin=new;Content-Length要求されたコンテンツの長さContent-Length : 348Content-Typeエンティティに対応する要求された MIME 情報Content-Type: application/x-www-form-urlencoded リクエストが送信された日時リクエストされた特定のサーバー動作電子メールリクエストを行ったユーザーの名前リクエストされたサーバーのドメイン名とポート番号を指定します要求コンテンツがエンティティと一致する場合のみ有効ですリクエストされた部分が指定された時間後に変更された場合、リクエストは成功します。変更されていない場合、リクエストは成功します。、304 コードが返されますコンテンツが変更されていない場合は 304 コードを返します。パラメータはサーバーから以前に送信された Etag です。サーバーから応答された Etag と比較して、変更されたかどうかを判断します。エンティティが変更されていない場合、サーバーはクライアントから欠落している部分を送信します。それ以外の場合は、エンティティ全体が送信されます。このパラメーターも Etagエンティティがその後変更されていない場合のみです。指定された時間リクエストは成功しました #If-Unmodified-From: Sat, 29 Oct 2010 19:43:31 GMTMax-Forwards渡される制限情報プロキシとゲートウェイによって送信される時間 #Max-Forwards: 10Pragma : no-cacheProxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Range: bytes=500-999Referer: http://www.zcmhi.com /archives/71.htmlTE: trailers,deflate;q=0.5アップグレード変換のためにサーバーへのトランスポートプロトコルを指定します (サポートされている場合) アップグレード: HTTP/2.0、SHTTP/1.3、IRC/6.9、RTA/ x11User-AgentUser-Agent のコンテンツにはユーザーの情報が含まれていますリクエストを行った人ユーザーエージェント: Mozilla/5.0 (Linux; X11 )Via中間ゲートウェイまたはプロキシサーバーのアドレスを通知します。通信プロトコル経由: 1.0 fred、1.1 nowhere.com (Apache/1.1) Warningメッセージエンティティに関する警告情報警告: 199 その他の警告

応答ヘッダー:












		#Date
Date: 火曜日、2010 年 11 月 15 日 08:12:31 GMT		Expect
Expect: 100- continue		From
From: user@email.com		Host
ホスト: www.zcmhi.com		If-Match
If -Match: "737060cd8c284d8af7ad3082f209582d"		If-Modified-Since
If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT		If-None-Match
If-None-Match: “737060cd8c284d8af7ad3082f209582d”		If-Range
If-Range: “737060cd8c284d8af7ad3082f209582d”		If-Unmodified-Since

	Pragma	実装固有の命令を含めるために使用されます
	Proxy-Authorization	プロキシに接続するための認証証明書
	Range	エンティティの一部のみをリクエストし、範囲を指定します
	Referer	前の Web ページのアドレスと、その後に現在要求されている Web ページ、つまりソース
	TE	クライアントが受け入れ可能な転送エンコードであり、末尾とヘッダー情報を受け入れるようにサーバーに通知します。

##ヘッダー説明例Accept-Rangesサーバーが指定された範囲リクエストをサポートしているかどうか、およびセグメント化されたリクエストのタイプを示しますAccept-Ranges: bytes年齢オリジンサーバーからプロキシキャッシュ形成までの推定時間(秒単位) 年齢: 12 許可A特定のネットワークリソースに対する有効なリクエスト動作。許可されない場合、405Allow: GET、HEADCache-Control## が返されます。すべてのキャッシュメカニズムに、キャッシュできるかどうか、およびそのタイプを通知します。Cache-Control: no-cacheContent-Encoding 返されるコンテンツWeb サーバーがサポートする圧縮エンコーディングのタイプ。 Content-Encoding: gzipContent-Language応答本文の言語Content-Language: en, zhContent-Length応答本文の長さContent-Length: 348Content-Location リソースの代替アドレスを要求しますリソースの MD5 チェック値を返します戻り値全体のこの部分body バイト位置コンテンツの MIME タイプを返します元のサーバーメッセージが送信された時刻リクエスト変数のエンティティタグの現在の値##Expires有効期限: Thu, 01 Dec 2010 16:00:00 GMTLast-Modified: 火曜日, 15 Nov 2010 12:45:26 GMTLocation: http: //www.zcmhi.com/archives/94.html Pragma: no-cacheプロキシ認証: 基本更新: 5; url=Retry-After: 120サーバー: Apache/1.3.27 (Unix) (Red-Hat/Linux)Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1##Trailerチャンク転送エンコーディングの最後にヘッダーフィールドが存在することを示しますTrailer: Max-ForwardsTransfer -Encodingファイル転送エンコーディング Transfer-Encoding:chunkedVaryキャッシュされたファイルを使用するかどうかをダウンストリームプロキシに指示します。オリジンサーバーからの応答またはリクエスト可変: *Viaクライアント応答が送信されたプロキシに通知します経由: 1.0 fred、1.1 nowhere.com (Apache/1.1) 警告警告エンティティに問題がある可能性があります警告: 199 その他の警告##WWW-Authenticate: Basic#

5. http リクエストメソッド

GET Request-URI
で特定されるリソースを取得するリクエスト POST Request で特定されるリソース内-URI リソースの後に新しいデータを追加します。
HEAD Request-URI で識別されるリソースの応答メッセージヘッダーの取得を要求します。
PUT サーバーにリソースを保存し、Request-URI をその識別子として使用するように要求します。
DELETEサーバーに削除を要求します。要求 - URI によって識別されるリソースです。
TRACE 受信した要求情報を返送するようサーバーに要求します。主にテストまたは診断に使用されます。
CONNECT 将来の使用のために予約されています。
OPTIONS クエリを実行する要求サーバーのパフォーマンスを確認するか、リソース

#6 に関連するオプションと要件を問い合わせます。ステータスコード

応答最初のメッセージ内の行はステータス行と呼ばれ、HTTP プロトコルのバージョン番号とステータスコードで構成されます。ステータスメッセージは 3 つの部分で構成されます。

ステータスコードは、HTTP サーバーが予期した応答を生成したかどうかを HTTP クライアントに伝えるために使用されます。

HTTP/1.1 では 5 種類のステータスコードが定義されており、ステータスコードは 3 桁の数字で構成されます。数値は応答のカテゴリを定義します。

1XX プロンプトメッセージ - 要求が正常に受信され処理が継続されていることを示し、要求を完了するにはデータの受信を継続する必要があることを示します。

2XX 成功 - リクエストが正常に受信、理解、受け入れられたことを示します

3XX リダイレクト - リクエストを完了するにはさらに処理を実行する必要があります

4XX クライアントエラー -リクエスト構文エラーがあるか、リクエストを実装できません。

5XX サーバー側エラー - サーバーは正当なリクエストを実装できませんでした。

ステータスコードリスト

表 1 (簡単な紹介表、概要紹介簡潔でわかりやすいです。最初にこの表を確認することをお勧めします。理解できない場合は、次の表を確認してください 2)









#Content-Location: /index.htm		Content-MD5
Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==		#Content-Range
Content-Range: バイト 21010-47021/47022		Content-Type
Content-Type: text/html; charset=utf-8		Date
日付: 火曜日、15 11 月 2010 08:12:31 GMT		ETag
ETag : "737060cd8c284d8af7ad3082f209582d"		#応答の有効期限日時
	Last-Modified	リクエストされたリソースの最終変更時刻
	Location	は、受信者をリクエストされていない URL の場所にリダイレクトして、リクエストを完了するか、新しいリソースを識別するために使用されます
	Pragma	応答チェーン上の任意の受信者に適用できる実装固有のディレクティブが含まれます
	Proxy-Authenticate	プロキシに適用できる URL の認証スキームとパラメータを示します
	refresh	リダイレクトに適用するか、新しいリソースが作成され、5 秒後にリダイレクトします (Netscape によって提案され、ほとんどのブラウザでサポートされています) )
		http://www.zcmhi.com/archives/94.html Retry-After エンティティが一時的に利用できない場合は、指定された時間の経過後に再試行するようにクライアントに通知します。
	サーバー	Webサーバーソフトウェア名
	Set-Cookie	Set Http Cookie





#WWW- Authenticate	#クライアント要求エンティティが使用する必要がある認可スキームを示します

で始まる新しいバージョンの HTTP プロトコル 2 に切り替えることができます。 #202AcceptedAccepted。リクエストは受け入れられましたが、処理されていません#2032042052063 で始まるステータスコードは 300 です。 301302##303See Other を引き続き使用する必要があります。 301と同じですね。 GET リクエストと POST リクエストを使用して、304未変更未変更を表示します。要求されたリソースは変更されていません。サーバーがこのステータスコードを返した場合、リソースは返されません。通常、クライアントは、指定された日付以降に変更されたリソースのみを返したいことを示すヘッダーを提供することによって、アクセスされたリソースをキャッシュしますプロキシを使用する未使用一時的なリダイレクトBad Request#401Unauthorizedリクエストにはユーザー認証が必要です402支払いが必要です今後の使用のために予約されています403禁止サーバーは理解しましたクライアントのリクエストがリクエストされましたが、リクエストの実行は拒否されました 404Not Foundサーバーは、クライアントのリクエストに基づいてリソース (Web ページ) を作成します。このコードを使用すると、Web サイトのデザイナーは、「要求したリソースが見つかりませんでした」というパーソナライズされたページを設定できます。顧客クライアントリクエストのメソッドは禁止されていますサーバーは、次のコンテンツの特性に基づいてリクエストを完了できません。クライアント要求リクエストには 401 と同様にプロキシ認証が必要ですが、要求者は承認にプロキシを使用する必要がありますサーバーはクライアントから送信されたリクエストを待機しすぎたため、タイムアウトになりました#409競合#410Goneクライアントが要求したリソースはもう存在しません。 410 は 404 とは異なります。リソースが完全に削除されている場合は、410 コードを使用できます。Web サイトのデザイナーは、301 コード#411# を使用してリソースの新しい場所を指定できます。 ## 長さが必要です##412前提条件が失敗しましたクライアント要求情報の前提条件エラー413要求エンティティが大きすぎます要求されたエンティティが大きすぎるため拒否されましたサーバーに問い合わせて処理されます。クライアントからの継続的なリクエストを防ぐために、サーバーは接続を閉じることがあります。サーバーが一時的に処理できないだけの場合は、Retry-After 応答メッセージ #414Request-URI Too Large415416#クライアントによってリクエストされた範囲は無効です417Expectation Failedサーバーは Expect リクエストヘッダー情報で始まるステータスコードを満たすことができません 5500内部サーバーエラー内部サーバーエラー、リクエストを完了できません501未実装サーバーはサポートしていません要求された関数はリクエストを完了できません502不正なゲートウェイゲートウェイまたはプロキシとして機能するサーバーが、リモートサーバーから無効なリクエストを受信しました。リクエスト503サービスが利用できません過負荷またはシステムのためメンテナンス中、サーバーは一時的にクライアントのリクエストを処理できません。遅延の長さはサーバーの Retry-After ヘッダー情報に含めることができます504ゲートウェイタイムアウトゲートウェイとして機能するサーバーまたはプロキシ、リクエストは時間内にリモートサーバーから取得されませんでした505HTTP バージョンがサポートされていませんサーバーはリクエストされたリクエストをサポートしていませんHTTP プロトコルのバージョンがあり、対処を完了できません#

表 2 詳細な紹介表

ステータスコード	ステータスコードの英語名	中国語の説明
1 で始まるステータスコード
#100	Continue	続行します。クライアントは、リクエスト
101	プロトコルの切り替え	プロトコルの切り替えを続行する必要があります。サーバーはクライアントの要求に基づいてプロトコルを切り替えます。より高いレベルのプロトコルにのみ切り替えることができます。たとえば、ステータスコードが

200	OK	リクエストは成功しました。通常、GET および POST リクエストに使用されます。
201	Created	が作成されました。新しいリソースのリクエストと作成が正常に完了しました

非権限情報	非権限情報。リクエストは成功しました。ただし、返されたメタ情報は元のサーバー上にあるのではなく、コピー
コンテンツなし	コンテンツがありません。サーバーは正常に処理されましたが、コンテンツが返されませんでした。 Web ページを更新せずに、ブラウザーが現在のドキュメントを表示し続けるようにします。
コンテンツをリセット	コンテンツをリセットします。サーバーの処理は成功し、ユーザー端末 (ブラウザなど) はドキュメントビューをリセットする必要があります。このリターンコードは、ブラウザのフォームフィールド
部分コンテンツ	部分コンテンツをクリアするために使用できます。サーバーは一部の GET リクエストを正常に処理しました。

Multiple Choices	複数の選択肢。要求されたリソースには複数の場所が含まれる場合があるため、ユーザー端末 (ブラウザーなど) の選択のためにリソースの特性とアドレスのリストが返される場合があります。
Moved Permanently	永久に移動します。要求されたリソースは新しい URI に永続的に移動され、返される情報には新しい URI が含まれ、ブラウザーは自動的に新しい URI にリダイレクトされます。今後の新しいリクエストでは、
Found	Temporarily Moved の代わりに新しい URI を使用する必要があります。 301と同じですね。ただし、リソースは一時的にのみ移動されます。クライアントは、他のアドレスを表示するには、元の URI

		#305
プロキシを使用します。要求されたリソースにはプロキシ経由でアクセスする必要があります		306
非推奨の HTTP ステータスコード		307
一時的なリダイレクト。 302と同じですね。 GET リクエストを使用して、		4
400
customers で始まるステータスコードをリダイレクトします。リクエストの構文が正しくないため、サーバーがそれを理解できません



	#405	メソッドは許可されていません
	406	受け入れられません
	407	プロキシ認証が必要です
	408	リクエストのタイムアウト
		#サーバーは、クライアントの PUT リクエストを完了するときにこのコードを返す可能性があります。サーバーがリクエストを処理したときに競合が発生しました

#サーバーは、Content-Length がないとクライアントから送信されたリクエスト情報を処理できません

	## が含まれます。 #要求された URI が長すぎるため (URI は通常 URL)、サーバーは処理できません
サポートされていないメディアタイプ	サーバーは処理できませんリクエストに添付されたメディア形式
リクエストされた範囲は満足できません

#ステータスコード意味##100101102200201202203204#205サーバーはリクエストを正常に処理しましたが、何も返しませんでした。ただし、204 応答とは異なり、このステータスコードを返す応答では、要求者がドキュメントビューをリセットする必要があります。この応答は主に、ユーザー入力を受け入れた直後にフォームをリセットして、ユーザーが別の入力を簡単に開始できるようにするために使用されます。 204 応答と同様に、この応答にはメッセージ本文を含めることが禁止されており、メッセージヘッダーの後の最初の空白行で終わります。 206サーバーは GET リクエストの一部を正常に処理しました。 FlashGet や Thunder などの HTTP ダウンロードツールは、このタイプの応答を使用して、中断されたダウンロードを再開したり、大きなドキュメントを複数のダウンロードセグメントに分割して同時ダウンロードしたりします。リクエストには、クライアントが取得したいコンテンツの範囲を示す Range ヘッダーを含める必要があり、リクエスト条件として If-Range を含めることもできます。応答には次のヘッダーフィールドが含まれている必要があります: Content-Range は、この応答で返されるコンテンツの範囲を示すために使用されます。Content-Type multipart/byteranges のマルチパートダウンロードの場合、各マルチパート各段落には、この段落のコンテンツ範囲を示す Content-Range フィールドが含まれている必要があります。 Content-Length が応答に含まれる場合、その値は返されるコンテンツ範囲の実際のバイト数と一致する必要があります。同じリクエストが 200 レスポンスを返す必要がある場合は、日付 ETag および/または Content-Location。 Expires、Cache-Control、および/または Vary (その値が、同じ変数に対する以前の他の応答に対応する値と異なる可能性がある場合)。この応答リクエストが If-Range の強力なキャッシュ検証を使用する場合、この応答には他のエンティティヘッダーを含めるべきではありません。 If-Range の弱いキャッシュ検証では、この応答に他のエンティティヘッダーを含めることが禁止され、これにより、キャッシュされたエンティティコンテンツと更新されたエンティティヘッダー情報の間の不一致が回避されます。それ以外の場合、この応答には、200 応答で返されるすべてのエンティティヘッダーフィールドが含まれている必要があります。 ETag ヘッダーまたは Last-Modified ヘッダーが正確に一致しない場合、クライアントキャッシュは 206 応答によって返されたコンテンツを以前にキャッシュされたコンテンツと組み合わせるべきではありません。 Range ヘッダーと Content-Range ヘッダーをサポートしていないキャッシュは、206 応答によって返されたコンテンツをキャッシュすることを禁止されています。


クライアントは送信を続ける必要がありますリクエスト。この暫定応答は、要求の一部がサーバーによって受信され、まだ拒否されていないことをクライアントに通知するために使用されます。クライアントはリクエストの残りを送信し続けるか、リクエストがすでに完了している場合はこのレスポンスを無視する必要があります(SHOULD)。サーバーは、リクエストが完了した後、クライアントに最終応答を送信する必要があります。
サーバーはクライアントのリクエストを理解し、別のプロトコルを使用してリクエストを完了するようにアップグレードメッセージヘッダーを通じてクライアントに通知します。この応答の最後の空白行を送信した後、サーバーは Upgrade ヘッダーで定義されたプロトコルに切り替えます。同様の措置は、新しいプロトコルに切り替える方が有益である場合にのみ実行する必要があります。たとえば、古いバージョンよりも新しい HTTP バージョンに切り替えたり、そのような機能を利用してリソースを配信するためにリアルタイム同期プロトコルに切り替えたりすることには利点があります。
WebDAV (RFC 2518) によって拡張されたステータスコード。処理が続行されることを示します。
リクエストは成功し、リクエストで予期される応答ヘッダーまたはデータ本体がこの応答とともに返されます。
リクエストは実行され、リクエストのニーズに基づいて新しいリソースが作成され、その URI が Location ヘッダー情報とともに返されました。必要なリソースを時間内に作成できない場合は、「202 Accepted」が返される必要があります。
サーバーはリクエストを受け入れましたが、まだ処理していません。リクエストが拒否される場合があるのと同様に、リクエストは最終的に実行される場合もあれば、実行されない場合もあります。非同期操作の場合、このステータスコードを送信するより便利な方法はありません。 202 ステータスコード応答を返す目的は、バッチ操作が実行されるまでクライアントをサーバーに接続したままにすることなく、サーバーが他のプロセス (1 日に 1 回だけ実行されるバッチベースの操作など) からのリクエストを受け入れることができるようにすることです。完成されました。リクエスト処理を受け入れて 202 ステータスコードを返す応答には、返されたエンティティに処理の現在のステータスを示す情報と、処理ステータスモニタまたはステータス予測へのポインタが含まれている必要があります。これにより、ユーザーは操作が適切かどうかを推測できます。完成しました。
サーバーはリクエストを正常に処理しましたが、返されたエンティティヘッダーのメタ情報は、元のサーバーで有効であると決定されたセットではなく、ローカルから取得されたものです。またはサードパーティサードパーティのコピー。現在の情報は、元のバージョンのサブセットまたはスーパーセットである可能性があります。たとえば、リソースのメタデータを含めると、オリジンサーバーがメタデータに関する詳細な情報を知ることになる場合があります。このステータスコードの使用は必須ではなく、このステータスコードがなければ応答が 200 OK を返した場合にのみ適切です。
サーバーはリクエストを正常に処理しましたが、エンティティコンテンツを返す必要はなく、更新されたメタ情報を返すことを望んでいます。応答は、エンティティヘッダーの形式で新しいメタ情報または更新されたメタ情報を返す場合があります。これらのヘッダーが存在する場合、要求された変数に対応する必要があります。クライアントがブラウザの場合、ドキュメントビューの仕様に従って新規または更新されたメタ情報がユーザーのブラウザアクティビティに適用される必要がある場合でも、ユーザーのブラウザはドキュメントビューを変更することなく、リクエストが行われたページを保持すべきです(SHOULD)。 204 応答にはメッセージ本文を含めることが禁止されているため、常にメッセージヘッダーの後の最初の空白行で終わります。

207	WebDAV (RFC 2518) によって拡張されたステータスコード。後続のメッセージ本文が XML メッセージであり、前のメッセージの数に応じて変化する可能性があることを示します。一連の独立した応答コードを含むサブリクエスト。
300	要求されたリソースには一連のオプションの応答があり、それぞれに独自の特定のアドレスとブラウザドライバーのネゴシエーション情報が含まれます。ユーザーまたはブラウザは、リダイレクト用の優先アドレスを選択できます。これが HEAD リクエストでない限り、応答には、ユーザーまたはブラウザが最適なリダイレクトアドレスを選択できるリソース属性とアドレスのリストを含むエンティティが含まれている必要があります。このエンティティの形式は、Content-Type で定義された形式によって決まります。ブラウザは、応答の形式とブラウザ自体の機能に基づいて、最も適切な選択を自動的に行う場合があります。もちろん、RFC 2616 仕様では、そのような自動選択がどのように実行されるべきかについては規定されていません。サーバー自体に優先フィードバックオプションがすでにある場合は、 Location は、このフィードバックの URI を示す必要があります。ブラウザは、この Location 値を自動リダイレクトのアドレスとして使用できます。さらに、特に指定がない限り、この応答はキャッシュ可能です。
301	要求されたリソースは新しい場所に永久に移動されました。今後このリソースを参照する場合は、この応答で返されたいくつかの URI の 1 つを使用する必要があります。可能であれば、リンク編集機能を持つクライアントは、要求されたアドレスをサーバーから返されたアドレスに自動的に変更する必要があります。特に指定がない限り、この応答もキャッシュ可能です。新しい永続 URI は、応答の Location フィールドで返される必要があります。これが HEAD リクエストでない限り、応答エンティティには新しい URI へのハイパーリンクと簡単な説明が含まれている必要があります。これが GET または HEAD リクエストではない場合、リクエストの条件がそれに応じて変更される可能性があるため、ユーザーが確認しない限りブラウザは自動リダイレクトを禁止します。注: HTTP/1.0 プロトコルを使用する一部のブラウザでは、送信した POST リクエストが 301 レスポンスを受信すると、後続のリダイレクトリクエストは GET メソッドになります。
302	要求されたリソースは、別の URI からの要求に一時的に応答するようになりました。このようなリダイレクトは一時的なものであるため、クライアントは今後も元のアドレスにリクエストを送信し続ける必要があります。この応答は、Cache-Control または Expires で指定されている場合にのみキャッシュ可能です。新しい一時 URI は、応答の Location フィールドで返される必要があります。これが HEAD リクエストでない限り、応答エンティティには新しい URI へのハイパーリンクと簡単な説明が含まれている必要があります。これが GET または HEAD リクエストではない場合、リクエストの条件がそれに応じて変更される可能性があるため、ユーザーが確認しない限りブラウザは自動リダイレクトを禁止します。注: RFC ではありますが、 1945 および RFC 2068 の仕様では、クライアントがリダイレクト時にリクエストメソッドを変更することを許可していませんが、多くの既存のブラウザは 302 レスポンスを 303 レスポンスとして認識し、元の URL に関係なく、Location で指定された URI に GET メソッドを使用してアクセスします。リクエスト方法です。ステータスコード 303 および 307 は、サーバーがクライアントからどのような応答を期待しているかを明確にするために追加されました。
303	現在のリクエストに対応するレスポンスは別の URI で見つかるため、クライアントは GET を使用してそのリソースにアクセスする必要があります。このメソッドは主に、スクリプトによってアクティブ化された POST リクエストの出力を新しいリソースにリダイレクトできるようにするために存在します。この新しい URI は、元のリソースへの代替参照ではありません。同時に、303 応答のキャッシュは禁止されます。もちろん、2 番目のリクエスト (リダイレクト) はキャッシュされる可能性があります。新しい URI は応答の Location フィールドで返される必要があります。これが HEAD リクエストでない限り、応答エンティティには新しい URI へのハイパーリンクと簡単な説明が含まれている必要があります。注: HTTP/1.1 より前のブラウザの多くは 303 ステータスを正しく理解できません。これらのブラウザとの対話を考慮する必要がある場合は、302 ステータスコードで十分です。これは、ほとんどのブラウザが、上記の仕様でクライアントに 303 応答の処理を要求しているのとまったく同じ方法で 302 応答を処理するためです。
304	クライアントが条件付き GET リクエストを送信し、そのリクエストが許可された場合、ドキュメントのコンテンツ (最後のアクセス以降、またはリクエスト条件に従って) ) が変更されていない場合、サーバーはこのステータスコードを返す必要があります。 304 応答にはメッセージ本文を含めることが禁止されているため、常にメッセージヘッダーの後の最初の空白行で終わります。応答には、次のヘッダー情報が含まれていなければなりません: サーバーに時計がない場合は、日付。クロックのないサーバーがこれらのルールに従う場合、プロキシサーバーとクライアントは (RFC 2068 で指定されているように) 受信した応答ヘッダー自体に Date フィールドを追加でき、キャッシュメカニズムは正常に動作します。 ETag および/または Content-Location (同じリクエストが 200 応答を返す必要がある場合)。 Expires、Cache-Control、および/または Vary (その値が、同じ変数に対する以前の他の応答に対応する値と異なる可能性がある場合)。この応答リクエストが強力なキャッシュ検証を使用する場合、この応答には他のエンティティヘッダーを含めるべきではありません。それ以外の場合 (たとえば、条件付き GET リクエストが弱いキャッシュ検証を使用する場合)、この応答には他のエンティティヘッダーを含めることが禁止されます。これにより、キャッシュされた間の不一致の解決が回避されます。エンティティのコンテンツと更新されたエンティティヘッダー情報。エンティティが現在キャッシュされていないことを 304 応答が示している場合、キャッシングシステムはその応答を無視し、制限なしで要求を繰り返す必要があります。キャッシュエントリの更新を必要とする 304 応答を受信した場合、キャッシュシステムはエントリ全体を更新して、応答で更新されたすべてのフィールドの値を反映する必要があります。
305	要求されたリソースには、指定されたプロキシを通じてアクセスする必要があります。 Location フィールドには、指定されたプロキシが配置されている URI 情報が表示されます。受信者は、このプロキシを通じて対応するリソースにアクセスするには、別のリクエストを繰り返し送信する必要があります。オリジンサーバーのみが 305 応答を確立できます。注: RFC 2068 では、305 応答が単一の要求をリダイレクトすることを目的としており、オリジンサーバーによってのみ確立できるとは指定されていません。これらの制限を無視すると、安全上に重大な影響が生じる可能性があります。
306	仕様の最新バージョンでは、306 ステータスコードは使用されなくなりました。
307	要求されたリソースは、別の URI からの要求に一時的に応答するようになりました。このようなリダイレクトは一時的なものであるため、クライアントは今後も元のアドレスにリクエストを送信し続ける必要があります。この応答は、Cache-Control または Expires で指定されている場合にのみキャッシュ可能です。新しい一時 URI は、応答の Location フィールドで返される必要があります。これが HEAD リクエストでない限り、応答エンティティには新しい URI へのハイパーリンクと簡単な説明が含まれている必要があります。一部のブラウザは 307 応答を認識しないため、ユーザーが新しい URI を理解し、アクセス要求を行えるように、上記の必要な情報を追加する必要があります。これが GET または HEAD ではない場合リクエストに応じてリクエストの条件が変更される可能性があるため、ユーザーが確認しない限り、ブラウザは自動リダイレクトを禁止します。
400	1. セマンティクスが正しくないため、現在のリクエストをサーバーが理解できません。クライアントは、変更されない限り、このリクエストを再送信しないでください。 2. リクエストパラメータが間違っています。
401	現在のリクエストにはユーザー認証が必要です。応答には、ユーザー情報を要求する、要求されたリソースに適切な WWW-Authenticate ヘッダーが含まれなければなりません (MUST)。クライアントは、適切な Authorization ヘッダーを含むリクエストを繰り返し送信できます。現在のリクエストにすでに認証証明書が含まれている場合、401 応答はサーバー検証でそれらの証明書が拒否されたことを示します。 401 応答に前の応答と同じ認証クエリが含まれており、ブラウザが少なくとも 1 回認証を試みた場合、ブラウザは応答に含まれるエンティティ情報をユーザーに表示する必要があります。このエンティティ情報には関連する診断情報が含まれている可能性があるためです。 RFC 2617 を参照してください。
402	このステータスコードは、将来のニーズに備えて予約されています。
403	サーバーはリクエストを理解しましたが、実行を拒否しました。 401 応答とは異なり、認証は何の助けも提供しないため、要求を再送信する必要はありません。これが HEAD リクエストではなく、サーバーがリクエストを実行できない理由を説明できるようにしたい場合は、拒否の理由をエンティティに記述する必要があります。もちろん、クライアントに情報を取得させたくない場合、サーバーは 404 応答を返すこともできます。
404	リクエストは失敗しました。リクエストされたリソースがサーバー上に見つかりませんでした。この状態が一時的なものなのか永続的なものなのかをユーザーに伝える情報はありません。サーバーが状況を認識している場合は、410 ステータスコードを使用して、内部構成メカニズムの問題により古いリソースが永続的に利用できず、ジャンプアドレスがないことを通知する必要があります。 404 ステータスコードは、サーバーがリクエストが拒否された理由を明らかにしたくない場合、または他の適切な応答が利用できない場合に広く使用されます。
405	リクエスト行で指定されたリクエストメソッドを使用して、対応するリソースをリクエストすることはできません。応答は、現在のリソースが受け入れることができるリクエストメソッドのリストを示す、Allow ヘッダー情報を返す必要があります。 PUT メソッドと DELETE メソッドはサーバーにリソースを書き込むため、ほとんどの Web サーバーはデフォルト設定では上記のリクエストメソッドをサポートしていないか許可しておらず、そのようなリクエストに対して 405 エラーが返されます。
406	要求されたリソースのコンテンツ特性がリクエストヘッダーの条件を満たすことができないため、応答エンティティを生成できません。これが HEAD リクエストでない限り、応答は、ユーザーまたはブラウザが最も適切なものを選択できるエンティティ属性とアドレスのリストを含むエンティティを返す必要があります。エンティティの形式は、Content-Type ヘッダーで定義されたメディアタイプによって決まります。ブラウザは、形式とその機能に基づいて独自の最適な選択を行うことができます。ただし、仕様では、そのような自動選択を行うための基準は定義されていません。
407	は 401 応答と似ていますが、クライアントがプロキシサーバーで認証する必要がある点が異なります。プロキシサーバーは、ID クエリに対して Proxy-Authenticate を返す必要があります。クライアントは検証のために Proxy-Authorization ヘッダーを返すことができます。 RFC 2617 を参照してください。
408	リクエストがタイムアウトしました。クライアントは、サーバーが待機する準備ができている時間内にリクエストの送信を完了しませんでした。クライアントは、変更を加えることなく、いつでもこのリクエストを再送信できます。
409	要求されたリソースの現在の状態と競合するため、要求を完了できません。このコードは、ユーザーが競合を解決して新しいリクエストを再送信できると思われる場合にのみ使用してください。応答には、ユーザーが競合の原因を発見するのに十分な情報が含まれている必要があります。競合は通常、PUT リクエストの処理中に発生します。たとえば、バージョンチェックを使用する環境では、PUT によって送信された特定のリソースの変更リクエストに添付されたバージョン情報が以前の (サードパーティの) リクエストと競合する場合、サーバーはこの時点で 409 エラーを返す必要があります。リクエストを完了できないことをユーザーに通知します。現時点では、ユーザーがマージ後に新しいバージョンを再送信できるように、応答エンティティには競合する 2 つのバージョン間の相違点の比較が含まれる可能性があります。
410	要求されたリソースはサーバー上で利用できなくなり、既知の転送アドレスがありません。このような状況は永続的であると考えるべきです。可能であれば、リンク編集機能を持つクライアントは、ユーザーの許可を得て、このアドレスへのすべての参照を削除する必要があります。サーバーが状態が永続的であるかどうかを知らない、または判断できない場合は、404 ステータスコードを使用する必要があります。特に明記されていない限り、この応答はキャッシュ可能です。 410 応答の目的は主に、Web サイト管理者が Web サイトを維持し、リソースが利用できなくなったことをユーザーに通知し、サーバー所有者はこのリソースを指すすべてのリモート接続も削除されることを望んでいることを支援することです。この種のインシデントは、期間限定の付加価値サービスでよく見られます。同様に、410 応答は、もともと個人に属していたリソースが現在のサーバーサイトで利用できなくなったことをクライアントに通知するためにも使用されます。もちろん、永久に利用できないリソースをすべて「410」としてマークする必要がありますか? 「Gone」、そしてこのマークをどのくらいの期間維持する必要があるかは、完全にサーバー所有者次第です。
411	サーバーは、Content-Length ヘッダーを定義せずにリクエストの受け入れを拒否しました。リクエストメッセージ本文の長さを示す有効な Content-Length ヘッダーを追加した後、クライアントはリクエストを再度送信できます。
412	サーバーは、リクエストのヘッダーフィールドに指定された 1 つ以上の前提条件を満たせませんでした。このステータスコードを使用すると、クライアントはリソースを取得するときにリクエストのメタ情報 (リクエストヘッダーフィールドのデータ) に前提条件を設定できるため、リクエストメソッドが予期したもの以外のリソースに適用されるのを防ぐことができます。
413	リクエストによって送信されたエンティティデータのサイズが、サーバーが処理できるサイズまたは処理できるサイズを超えているため、サーバーは現在のリクエストの処理を拒否しました。この場合、サーバーは接続を閉じて、クライアントがこのリクエストを送信し続けるのを防ぐことができます。状況が一時的な場合、サーバーは Retry-After 応答ヘッダーを返し、クライアントに再試行までの待ち時間を通知する必要があります。
414	要求された URI はサーバーが解釈できる長さを超えているため、サーバーは要求の処理を拒否します。これは比較的まれですが、一般的な状況は次のとおりです: POST メソッドを使用するはずだったフォーム送信が GET メソッドになり、クエリ文字列が長すぎます。リダイレクト URI の「ブラックホール」。たとえば、各リダイレクトで古い URI が新しい URI の一部として使用されるため、数回リダイレクトすると長すぎる URI が生成されます。クライアントは、一部のサーバーのセキュリティホールを悪用してサーバーを攻撃しようとしています。このタイプのサーバは、リクエストされた URI の読み取りや操作に固定長のバッファを使用するため、GET 以降のパラメータが一定の値を超えるとバッファオーバーフローが発生し、任意のコードが実行されることがあります [1]。このような脆弱性がないサーバーは 414 ステータスコードを返すはずです。
415	現在のリクエストメソッドとリクエストされたリソースでは、リクエストで送信されたエンティティはサーバーでサポートされている形式ではないため、リクエストは拒否されます。。
416	リクエストに Range リクエストヘッダーが含まれており、Range で指定されたデータ範囲が現在のリソースの使用可能な範囲と一致しない場合、リクエストに含まれる If-Range リクエストヘッダーが定義されていない場合、サーバーは 416 ステータスコードを返す必要があります。Range でバイト範囲を使用する場合、この状況は、リクエストで指定されたすべてのデータ範囲の最初のバイト位置が現在のリソースの長さを超えていることを意味します。サーバーには、416 ステータスコードを返すときに現在のリソースの長さを示す Content-Range エンティティヘッダーも含める必要があります。この応答では、Content-Type として multipart/byterange を使用することも禁止されています。
417	リクエストヘッダー Expect で指定された期待内容がサーバーによって満たされないか、サーバーがプロキシサーバーであり、それを示す明白な証拠があります。現在のルートでは使用されていません。次のノードでは、Expect の内容を満たすことができません。
421	現在のクライアントの IP アドレスからサーバーへの接続数が、サーバーの最大許容範囲を超えています。通常、ここでの IP アドレスは、サーバーから見たクライアントアドレス (ユーザーのゲートウェイやプロキシサーバーのアドレスなど) を指します。この場合、接続数には複数のエンドユーザーが関与する可能性があります。
422	現在のクライアントの IP アドレスからサーバーへの接続数が、サーバーの最大許容範囲を超えています。通常、ここでの IP アドレスは、サーバーから見たクライアントアドレス (ユーザーのゲートウェイやプロキシサーバーのアドレスなど) を指します。この場合、接続数には複数のエンドユーザーが関与する可能性があります。
422	リクエストの形式は正しいですが、セマンティックエラーのため応答できません。 (RFC 4918 WebDAV) 423 Locked 現在のリソースはロックされています。 (RFC 4918 WebDAV)
424	現在のリクエストは、PROPPATCH など、前のリクエストで発生したエラーのため失敗しました。 (RFC 4918 WebDAV)
425	WebDav Advanced Collections ドラフトで定義されていますが、WebDAV Sequence Collection Protocol (RFC 3658) には記載されていません。
426	クライアントは TLS/1.0 に切り替える必要があります。 (RFC 2817)
449	Microsoft によって拡張され、適切なアクションを実行した後にリクエストを再試行する必要があることを示します。
500	サーバーで予期しない状況が発生したため、リクエストの処理を完了できませんでした。一般に、この問題はサーバーのプログラムコードにエラーがある場合に発生します。
501	サーバーは、現在のリクエストに必要な機能をサポートしていません。サーバーが要求されたメソッドを認識せず、リソースに対するその要求をサポートできない場合。
502	ゲートウェイまたはプロキシとして動作しているサーバーが、リクエストを実行しようとしたときに、上流のサーバーから無効な応答を受け取りました。
503	サーバーは、一時的なサーバーのメンテナンスまたは過負荷のため、現在リクエストを処理できません。この状態は一時的なもので、一定時間が経過すると元に戻ります。遅延が予想される場合は、応答に遅延を示す Retry-After ヘッダーを含めることができます。この Retry-After メッセージが与えられない場合、クライアントは 500 応答を処理するのと同じ方法でそれを処理すべきです (SHOULD)。注: 503 ステータスコードの存在は、サーバーが過負荷になったときにそれを使用する必要があることを意味するものではありません。一部のサーバーは、単にクライアントからの接続を拒否したいだけです。
504	ゲートウェイまたはプロキシとして機能するサーバーがリクエストを実行しようとすると、上流のサーバー (識別されたサーバー) からリクエストを時間内に取得できません。 HTTP、FTP、LDAP などの URI によって応答を受け取るか、セカンダリサーバー (DNS など) が応答を受け取ります。注: 一部のプロキシサーバーは、DNS クエリがタイムアウトすると 400 または 500 エラーを返します。
505	サーバーは HTTP をサポートしていないか、サポートを拒否しています。リクエストで使用されるバージョン。これは、サーバーがクライアントと同じバージョンを使用できない、または使用したくないことを意味します。応答には、そのバージョンがサポートされない理由とサーバーがサポートするプロトコルを説明するエンティティが含まれている必要があります。
506	「透過コンテンツネゴシエーションプロトコル」(RFC 2295) によって拡張され、サーバーに内部構成エラーがあることを示します: 要求されたネゴシエーション引数リソースが構成されていますto be in 透過的なコンテンツネゴシエーションでそれ自体を使用するため、ネゴシエーションプロセスでは適切な焦点ではありません。
507	サーバーはリクエストを完了するために必要なコンテンツを保存できません。この状態は一時的なものと考えられます。 WebDAV (RFC 4918)
509	サーバーは帯域幅の制限に達しました。これは正式なステータスコードではありませんが、依然として広く使用されています。
510	リソースを取得するために必要な戦略が満たされていません。 (RFC 2774)