HTML の決定版ガイド: 第 3 章-htmlチュートリアル-php.cn

HTTPメッセージ概要

この記事では主にメッセージの流れと内容の理解について紹介します。以下の内容が含まれます:

メッセージの流れ
メッセージのコンポーネント (開始行、ヘッダー、エンティティの主要部分)
メッセージの違い (応答メッセージとメッセージの間)リクエストメッセージ時間)
メソッドの紹介
ステータスコードはじめに
HTTPヘッダー関数

ここで強調したいのは、これはせいぜい本のコピーについての私の理解であるということですそしてそれは包括的ではありません。ご自身の目で見て判断してください。

1. メッセージの流れ

HTTPメッセージは、HTTPアプリケーション間で送受信されるデータブロックを指します。これは、メッセージの内容と意味を説明するテキスト形式のメタ情報で始まり、その後にオプションの部分が続きます。ここには 3 つの用語があります:

インバウンド
アウトバウンド
トランザクション (transaction)

流入とは、クライアントからサーバーへのトランザクション処理の方向を指します。サーバーからクライアントへの処理。ただし、フローの種類に関係なく、すべてのメッセージは下流に流れ、メッセージの送信者は受信者の上流にあります。ここで上流と下流は送信者と受信者にのみ関係し、サーバーとクライアントは両方とも下流ノードであるため、メッセージの送信方向を区別できないことに注意してください。

2. メッセージ

のコンポーネントは、リクエストメッセージとレスポンスメッセージに分けられます。

ヘッダー:
本文: オプション、
データ
開始行とヘッダーは行区切りの ASCII テキストで、どちらもキャリッジリターン文字とラインフィード文字を含み、CRLF として書き込むことができます。ただし、一部の HTTP アプリケーションは常に CRLF を送信するとは限らないため、HTTP アプリケーションは終了として 1 つの改行文字を受け入れる必要があります。本文にはテキストまたはバイナリデータを含めることも、空にすることもできます。

HTTP メッセージは 2 つのカテゴリに分類されますが、構文は異なります。リクエストメッセージの形式は次のとおりです:

 <method> <request-URL> <version>
    <headers>
    
    <entity-body>

ログイン後にコピー

応答メッセージの形式は、開始行が異なるだけです:

    <version> <status> <reason-phrase>

ログイン後にコピー

内容のほとんどは次に詳しく紹介され、エンティティについては将来的に詳しく説明します。エンティティについて簡単に説明します

2. スタートライン

スタートラインはリクエストラインとレスポンスラインに分かれています。

2.1. リクエスト行

メソッドとリクエスト URL を含むリクエストメッセージの開始行。メソッドは実行する必要がある操作を記述し、リクエスト URL は操作

オブジェクト

を記述します。リクエスト行には、クライアントの HTTP プロトコルのバージョンも含まれます。これらのフィールドはスペース文字「」で区切られます。 HTTP/0.9 では、リクエストに HTTP バージョン番号を含める必要がないことに注意してください。

2.2. 応答行応答メッセージの開始行。HTTP プロトコルのバージョン、デジタルステータスコード、応答メッセージで使用される理由フレーズが含まれます。すべてのフィールドはスペース「」で区切られます。

2.3. メソッド

はサーバーに何をすべきかを指示します。 HTTP 仕様には一連のメソッドが記述されており、HTTP 仕様の外にあるメソッドは、HTTP 仕様の拡張である拡張メソッドです。一般的に使用される HTTP メソッドは次のとおりです:

MethodDescriptionサーバーからドキュメントを取得するからサーバーはは処理が必要なデータを送信しますはリクエストの本文プロキシサービスを介して配信される可能性がありますサーバー上のメッセージを追跡しますクエリドキュメントを削除からのサーバー

本文が含まれているかどうか

GET

HEAD

いいえ

POST

は

PUT

をサーバーに保存します

は

トレース

いいえ

オプション

サーバーによってサポートされているメソッド

いいえ

DELETE

いいえ

2.4. ステータスコード

クライアントの操作結果に対するサーバーの応答。ステータスコードには 5 つのカテゴリがあり、現在の HTTP バージョンではそのうちの一部のみが指定されています。拡張ステータスコードを受信した場合、それが属するスコープに従って分類され、分類の通常のメンバーに従って処理されます。ステータスコードの分類は次のとおりです:

100, 101情報プロンプト200~ 299200~206 成功300~305リダイレクト400~499400~415クライアントエラー500~599500~505サーバーエラー

現在使用されているすべてのステータスコードについては後で説明するため、ここではリストしません。

2.5. 理由フレーズ

はステータスコードと同時に表示され、テキスト形式ですが、HTTP 仕様にはこれに関する規定がありません。

2.6. バージョン番号

は HTTPx.y として表示され、HTTP クライアントとサーバーが両方の機能とメッセージを理解できるようにします。バージョン番号は 10 進数として扱われず、各数値が個別に比較されることに注意してください。

3. ヘッダー

その機能は、基本的に名前と値のペアのリストであり、名前と値を区切るために次の 5 つのタイプに分類されます。ヘッダー、リクエストヘッダー、レスポンスヘッダー、エンティティヘッダー、拡張ヘッダー。ヘッダーの構文は次のとおりです。

4. エンティティ

の主要部分は、HTTP メッセージの準拠、つまり送信されるコンテンツです。 HTTP メッセージは、HTML ドキュメント、画像、ビデオなどを含む、さまざまな種類のデジタルデータを運ぶことができます。

5. HTTP0.9 メッセージ

これは HTTP プロトコルの初期バージョンであり、リクエストとレスポンスで構成されますが、リクエストには メソッドとリクエスト URL のみが含まれ、レスポンスには エンティティ のみが含まれます。。その柔軟性のため、ここで説明したメソッドのほとんどは使用できませんが、一部のアプリケーションでは依然として使用されているため、開発者はその制限に注意する必要があります。 3. メソッド

このパートでは、前の基本的なメソッドについて詳しく説明します。以下の点に注意してください:

安全な

メソッドこれは、

GETメソッドとHEAD

メソッドを含むHTTPプロトコルによって定義されます。安全な方法とは、何もアクションが実行されないことを意味しますが、これは Web 開発者によって決定されます。同様に、安全でないメソッドを使用する場合、HTTP アプリケーション開発者は ユーザーに通知することが許可されます。 2.GETメソッド

一般的に使用されるメソッドで、サーバーに特定のリソースの送信を要求するために使用されます。HTTP/1.1では、サーバーはこのメソッドを実装する必要があります。

3. HEAD メソッド

は GET メソッドに似ていますが、応答は

ヘッダー

のみを返します。目的は、クライアントがリソースのヘッダーを検査できるようにすることです。このメソッドには以下の機能があります:

同じ

。 4. PUT メソッド

は、サーバーにドキュメントを書き込みます。そのメソッドのセマンティクスにより、サーバーは、リクエストの本文で指定された新しいドキュメントを作成または上書きできます。ユーザーがファイルを変更できるようにするため、通常は

パスワード認証

が必要です。この方法にはストレージリソースが必要です。 5. POST メソッド

はもともとデータを入力するために使用されていましたが、現在では主に HTTP フォームをサポートするために使用されています。フォーム本体で取得したデータはサーバーに送信され、サーバーが送信先を決定します。この方法ではストレージリソースは必要ありません。

6.TRACEメソッド

クライアントがリクエストを開始した後、他のアプリケーションの中間ノードを通過するときにリクエストが変更される場合があります。 TRACE メソッドを使用すると、クライアントは最終的にリクエストをサーバーに送信できます。

このリクエストは「ループバック」診断を実行します。つまり、TRACE レスポンスがサーバーからバウンスバックされ、受信したメッセージが伝送されるため、クライアントは元のメッセージの変更を確認できます。 TRACE メソッドは、リクエストがリクエスト/レスポンスチェーンを通過したかどうかを検証する

診断
に使用されますが、中間アプリケーションがさまざまな種類のリクエストを同じように処理することを前提としているため、HTTP プログラムの処理メカニズムを区別することができませんさまざまな方法の違いについて。 TRACE リクエスト にはエンティティ本体を
含めることはできません。応答本文には、受信したリクエスト本文の正確なコピーが含まれます。 7.OPTION メソッド

これらのメソッドは、サーバー上のすべてのリソースに共通です。これにより、クライアントはリソースをリクエストする最適な方法を決定できるようになります。 (それが

最適化です)

8.DELETEメソッド

は、リクエストURLで指定されたリソースの削除をサーバーに要求しますが、クライアントプログラムは、削除操作が実行されることを保証しません

。

9. 拡張方法

HTTP はフィールド拡張可能に設計されているため、新旧の機能に互換性があります。拡張メソッドとは、HTTP/1.1 仕様で定義されていないメソッドを指します。一般的な拡張メソッドの例は次のとおりです。

全体範囲	定義範囲	分類
100~199

300~399

メソッド説明 LOCK ユーザーが編集中に他の人によって変更されないようにリソースを「ロック」できるようにします。 MKCOLユーザーにリソースの作成を許可しますCOPYMOVEサーバー上のリソースを移動

上記の拡張メソッドはWebDAV HTTP拡張で定義されている拡張メソッドです。すべての拡張メソッドを理解したり適用したりできるわけではないため、エンドツーエンドの動作を壊さない限り、拡張メソッドを許容することが最善であることに注意してください。ダウンストリームサーバーが壊れている可能性がある場合は、501 Not Implemented を渡して応答します。規則は次のとおりです: 「送信されるコンテンツについては厳しい要件、受信されるコンテンツについては緩やかな要件」。

4. ステータスコード

目的は、クライアントがトランザクション処理結果を理解しやすくすることであり、5 つのカテゴリに分類され、5 つのカテゴリの各ステータスコードには HTTP/1.1 で推奨される理由フレーズが含まれています。

1. 情報ステータスコード 100~199

HTTP/1.1 で導入されましたが、議論と制限があります。その主な内容は次のとおりです。




サーバー上のリソースをコピー

ステータスコード	理由フレーズ	意味
100	Continue	説明リクエストの最初の部分が受信され、クライアントは続行するように求められます。このステータスコードを送信した後、サーバーはリクエストを受信してから応答する必要があります。
101	プロトコルの切り替えは、サーバーがクライアントの仕様に従って、Update ヘッダーにリストされているプロトコルにプロトコルを切り替えていることを示します

ここで、ステータスコード 100 について説明する必要があります。対象とするシナリオは次のとおりです。クライアントはエンティティをサーバーに送信する必要がありますが、送信する前にサーバーがエンティティを受け入れるかどうかを確認する必要があります。そして、クライアント、サーバー、プロキシの間で次のように通信します:

クライアントと 100 ステータスコード

クライアントは、値 100Continue を含む Expect リクエストヘッダーを送信できるため、エンティティ応答を送信する前に 100Continue を待つことができます。これは、大きすぎて処理できないエンティティがサーバーに送信されることを避けるために使用されます。待機がタイムアウトした場合、クライアントは予期しない応答に備えてエンティティを直接送信する必要があることに注意してください。

サーバーと 100 ステータスコード

サーバーが値 100Continue の Expect ヘッダーを持つリクエストを受信すると、100Continue またはその他のエラーステータスコードで応答する必要があります。ただし、クライアントが要求しなかった場合、サーバーはこの応答を送信すべきではありません。
100Continue を送信する前にサーバーがいくつかのエンティティを受信した場合、つまりクライアントがタイムアウトした場合、サーバーは 100 ステータスコードを送信する必要はありませんが、リクエストを読み取った後、最終ステータスコード (100ステータスコードはスキップできます)。

エージェントと 100 ステータスコード

エージェントが 100Continue の Expect リクエストを受信した場合、エージェントが実行できることは次の状況に分けられます:

ネクストホップサーバーが HTTP/1.1 互換であることがわかっている (または互換している)わかりません)、ネクストホップサーバーが HTTP/1.1 とのみ互換性を持つまで、Except ヘッダーは下向きに転送されます
。その後、417Exception Failed エラーで応答する必要があります (または、最初にクライアントに 100Continue を返します)。その後、リクエストをサーバーに転送するときに、Except ヘッダーを削除します)。
HTTP/1.0 以前のバージョンと互換性のあるクライアントを表すプロキシは、Except ヘッダーと 100Continue 値をリクエストに含めることができますが、ステータスコードをクライアントに転送することはできません。
そのため、プロキシには、ネクストホップサーバーとそのバージョン情報を維持するという利点があります。つまり、100Continue の予想されるリクエストの処理が向上します。

2. 成功ステータスコード 200~299

成功したリクエストにはさまざまな種類があるため、以下に成功を示すさまざまなステータスコードがあります。

ステータスコード	理由フレーズ	意味
200	OK	リクエストはOKです。エンティティの本体部分にはリクエストされたリソースが含まれています。
201	Created	サーバーオブジェクトを作成するリクエストに対する応答。エンティティの主要部分には、作成されたリソースのさまざまな referencesURL が含まれている必要があり、Location ヘッダーには最も具体的な参照が含まれています。
202	Accepeded	リクエストは受け入れられましたが、実行されなかった場合でも、リクエストの実行は保証されません。サーバーは、エンティティの本文にリクエストのステータスの説明と、リクエストが完了するまでにかかる時間の推定 (または、この情報を取得できる場所へのポインタ) を含めるべきです(SHOULD)。
203	非権限情報	エンティティヘッダーに含まれる情報は、(サーバーではなく) リソースのコピーから取得されます。これは、中間ノードがリソースのコピーを持っているが、送信するリソース関連のヘッダーを検証できない、または検証しない場合に発生します。
204	Not Content	応答メッセージにはヘッダーとステータス行が含まれていますが、エンティティ本文はありません。ブラウザを明示的に切り替えることなく、新しいドキュメントを更新するために使用されます。
205	Reset CONtent	は、現在のページ内のすべての HTML フォーム要素をクリアするようにブラウザーに指示するためにブラウザーによって使用されます。
206	部分コンテンツ	部分リクエストまたはRangeリクエストが正常に実行されました。 Content-RangeDate ヘッダーまたは Content-Location ヘッダーが含まれている必要があります。

3. リダイレクトステータスコード 300~399

代替の場所を使用してリソースにアクセスするか、リソースのコンテンツの代わりに代替の応答を提供するようにユーザーに通知します。リソースが移動した場合は、リダイレクトステータスコードとオプションの Location ヘッダーを送信して、リソースが移動したことと現在の場所をクライアントに通知できます。これにより、ブラウザは透過的に新しい場所に遷移できるようになります。
リダイレクトステータスコードを通じてローカルリソースとサーバーリソースを検証し、サーバーリソースへの変更を表示し、ローカルコピーの適時性を維持することもできます。
リダイレクトステータスコードを含む非 HEAD リクエストに対する応答には、情報とリダイレクト URL への接続を説明するエンティティが含まれます。

307一時リダイレクト 301 に似ています。ただし、Location ヘッダーで指定された URL はリソースを一時的に見つけることしかできないため、後続のリクエストでは古い URL を使用する必要があります

ステータスコード 302、303、および 307 の間には交差および微妙な違いがあり、これらは HTTP/1.0 アプリケーションと HTTP/1.1 アプリケーションの違いに起因します。
HTTP/1.0 クライアントの場合、POST リクエストが開始されて 302 レスポンスが受信されると、Location ヘッダーのリダイレクト URL が受け入れられ、GET リクエスト が送信されます。
HTTP/1.0 サーバーの場合、クライアントは上記と同じことを行う必要があります。
ただし、HTTP/1.1 は同じ動作を実現するために 303 ステータスコードを使用するため、HTTP/1.1 クライアントの場合は、別の 302 ステータスコードが上書きされるのを避けるために、307 ステータスコードを使用して 302 ステータスコードを代理します。

4. クライアントエラーステータスコード 400~499

サーバーは、処理できないコンテンツを受信すると応答します。

ステータスコード	理由フレーズ	意味
300	複数の選択肢	クライアントが実際に複数のリソースを指す URL をリクエストした場合に返されます。サーバーが戻ると、リクエストされた URL が削除されたときに使用される PreferredURL
301	Moved Permanently	を Location ヘッダーに含めることができます。応答の Location ヘッダーには、リソースの現在の URL
302	Found	が含まれています (301 と同様)。ただし、Location ヘッダーで指定された URL はリソースを一時的に見つけることしかできず、後続のリクエストでは古い URL を使用する必要があります。
303	See Other	は、リソースを取得するために別の URL を使用する必要があることをクライアントに伝えます。新しい URL は Location ヘッダーにあります。その目的は、POST リクエストの応答でクライアントを特定のリソース
304	Not Modified	にリダイレクトできるようにすることです。含まれるリクエストヘッダー。条件ヘッダーの内容は後で確認できます。このステータスコードの応答にはエンティティ本文が含まれません。
305	Use Proxy	プロキシ経由でリソースにアクセスする必要があることを示します。エージェントの場所は Location ヘッダーによって示されます。クライアントは、すべてのリソースがプロキシを経由することを指定するのではなく、特定のリソースに関連して応答を解析します。

ステータスコード	理由フレーズ	意味
401	Bad Request	は、不正なリクエストが送信されたことをクライアントに通知します。
402	Unauthorized	は、適切なヘッダーとともに返され、リソースへのアクセスを取得する前にクライアント自身の認証を要求します。
403	支払いが必要です	未使用ですが、将来の使用のために予約されています。
404	見つかりません	サーバーは、要求された URL を見つけることができません。通常、この URL にはエンティティが含まれており、クライアントに表示されます。
405	メソッドは許可されていません	送信されたリクエストには、URL でサポートされていないメソッドが含まれています。リソースが使用できるメソッドを通知するために、応答にAllowヘッダーを含める必要があります。
406	Not Acceptable	クライアントが受け入れ可能な URL に一致するリソースがない場合に使用され、クライアントは受け入れるエンティティタイプを示すパラメータを指定できます。
407	プロキシ認証が必要	401と似ていますが、リソースの認証を必要とするプロキシサーバーに使用されます。
408	リクエストタイムアウト	クライアントがリクエストを完了するとタイムアウトになり、サーバーはこのステータスコードを送信して接続を閉じます。
409	競合	リクエストがリソース上で引き起こす可能性のある競合について説明します。このステータスコードは、リクエストが競合を引き起こす可能性があるとサーバーが懸念する場合に送信されます。応答には、競合を説明する本文が含まれている必要があります。
410	Gone	は、サーバーがかつてメンテナンスのためにリソースを所有しており、サーバーのリソースが削除されたときにクライアントに通知できることを除いて、404に似ています。
411	長さが必須	サーバーによって要求される
412	Precondition Failed	条件付きリクエストが開始されたが、条件の 1 つが失敗した場合に使用されます。
413	リクエストエンティティが大きすぎます	クライアントによって送信されたエンティティ本体部分が、サーバーが処理できるサイズを超えています。
414	リクエストURIが長すぎます	URLが長すぎます。
415	サポートされていないメディアタイプ	サーバーがクライアントから送信されたエンティティのコンテンツタイプを理解できない、またはサポートできない場合に使用されます。
416	Requested Range Not Satisfiable	リクエストメッセージは、指定されたリソースの特定の範囲を要求していますが、その範囲が無効であるか、満たすことができません。
417	Expectation Failed	期待を含むリクエストをサーバーが実行できませんでした。この応答ステータスコードは、サーバーが予想外の結果を生成したに違いないという明確な証拠をエージェントまたは中間プログラムが持っている場合に送信できます。

403Forbiddenがありますが、サーバーがリクエストの処理を拒否し、その理由が説明されていないようです。

5. サーバーエラーステータスコード 500~599

クライアントのリクエストは有効ですが、サーバーにエラーがある場合に使用できます。これは通常、エージェントとサーバー間の通信の結果です。

ステータスコード	理由フレーズ	意味
500	内部サーバーエラー	サーバーがリクエストを処理できない問題が発生した場合に使用されます。
501	未実装	クライアントによって開始されたリクエストがサーバーの能力を超える場合に使用されます
502	不正なゲートウェイ	プロキシまたはゲートウェイとして使用されるサーバーは、次のリンクからデータを収集しますリクエストレスポンスチェーン疑似レスポンスを受信した場合、
503	Sevice Unavailable	を使用して、サーバーが現在リクエストに対応できないが、将来はリクエストに対応できるようになる（スペアタイヤのような感じです）ことを示します。
504	ゲートウェイタイムアウト	408と似ていますが、応答はゲートウェイまたはプロキシから来ます
505	HTTPバージョンがサポートされていません	受信したリクエストのバージョンが一致しません。

5. ヘッダー

ヘッダーは、サーバーとクライアントのアクションを決定するメソッドと組み合わせて使用されます。ヘッダーには 5 つのタイプがあり、以下で詳しく説明します。

1. 共通ヘッダー

は、メッセージに関連する最も基本的な情報を提供し、両方のタイプのメッセージで使用できます。情報ヘッダーは次のとおりです:

Header	Description
Connection	クライアントとサーバーがリクエスト/レスポンス接続に関連するオプションを指定できるようにします
Date	日付とタイムスタンプ、説明レポートを提供しますメッセージが作成されたとき
MIME-Version	送信者が使用したMIMEバージョンを示します
トレーラー	メッセージがチャンク転送エンコーディングを使用する場合、このヘッダーを使用して、メッセージ ) 最初のコレクションの一部。
Transfer-Encoding	メッセージで使用されているエンコード方式を通知します
Update	送信者が使用するために「アップグレード」する可能性がある新しいバージョンまたはプロトコルを提供します
Via	明示的なメッセージ中間ノードは

を通過しますが、ユニバーサル caching ヘッダーが HTTP/1.0 で導入され、HTTP アプリケーションがヘッダーのローカルコピーを、サーバーから直接フェッチする代わりにキャッシュできるようになりました。基本的なキャッシュヘッダーは次のとおりです:

Header	Description
Cache-Control	は、メッセージとともにキャッシュ命令を送信するために使用されます
Pragma	メッセージとともに命令を送信する別の方法, ただし、リクエストメッセージ内の

2. リクエストヘッダー

の固有のコンテンツのキャッシュには特に使用されません。クライアントに関するより詳細な情報をサーバーに提供します。その情報ヘッダーは次のとおりです:

Header	Description
Client-IP	クライアントを実行しているマシンのIP
From	クライアントユーザーの電子メールアドレス
ホスト	リクエストされたサーバーのホスト名とポート番号
Referer	現在のリクエスト URL のドキュメントの URL が含まれます
UA-Color	クライアントモニターのカラーサポートに関する情報を提供します
UA- CPU	クライアントの CPU タイプまたは製造元を提供します
UA-Disp	クライアントの表示機能に関する情報を提供します
UA-OS	クライアントのオペレーティングシステム情報 - 名前とそのバージョンを提供します
UA -ピクセル	クライアントの表示ピクセルを提供します
ユーザーエージェント	リクエストを開始したアプリケーション名をサーバーに通知します

2.1.ヘッダーを受け入れる

クライアントにアプリケーションの設定と機能を提供します接続の双方に利益をもたらす方法でサーバーに通知します。主な Accept ヘッダーは次のとおりです:

送信できる…受け入れ可能なエンコーディングLang…送信可能な言語これらの拡張転送エンコーディングを使用できます

Header	Description
Accept	は、サーバーに送信できるメディアタイプを伝えます
Accept-Charset	...文字セット
	Accept-Encoding
Accept-	uage
	TE

2.2. 条件付きリクエストヘッダー

はリクエストに制限を追加し、サーバーが応答する前に条件が真であることを確認することを要求します。 HeaderDescriptionExpectクライアントがリクエストに必要なサーバーの動作をリストできるようにしますIf-Matchエンティティタグがドキュメントの現在のエンティティタグと一致するかどうかを取得します指定された日付以降にリソースが変更されていない限り、このリクエストを制限しますエンティティタグがドキュメントの現在のエンティティタグと一致しないかどうかを取得しますドキュメントドキュメントの範囲に対する条件付きリクエストを許可します指定された日付以降にリソースが変更されていない限りリクエストを制限しますIfサーバーは範囲リクエストをサポートしており、リソースの指定された範囲をリクエストします




	If-Modfied-Since
	If-None-match
	If-Range
	If-Unmodified-Since
	範囲

2.3. セキュリティリクエストヘッダー

がリクエストにチャレンジし、後者は認証で応答します。クライアントが特定のリソースを取得する前に慈善活動を行う必要があるため、トランザクションのセキュリティが向上します。 Descriptionクライアントエージェントが自身を認証するためにサーバーに与えるデータが含まれますCookie暗黙的にサーバーに渡されるトークンセキュリティ関数は、リクエスターがサポートするCookieのバージョンを示すために使用されます

	Header
	Authorization

	Cookie2

🎜🎜

2.4. プロキシリクエストヘッダー

プロキシが広く適用されているため。

Header	Description
Max-Forward	TRACE
Proxy で使用される、オリジンサーバーへのパス上の他のプロキシ (ゲートウェイ) にリクエストが転送される最大回数- Authorization	は同名のヘッダーと同じ機能ですが、プロキシに使用されます
Proxy-Connection	は、同名のヘッダーと同じ機能がありますが、プロキシに使用されます

3. 応答ヘッダー

は、クライアントが情報ヘッダー、ネゴシエーションヘッダー、セキュリティ応答ヘッダーなどの追加情報を提供するため、応答メッセージによって使用されます。情報ヘッダーは次のとおりです:

の後

Header	Description
Age	Response Duration
Public	リソースに対してサーバーによって提供されるメソッドのリスト
Retry-	リソースが利用できません。その後、その日または時刻に再試行してください
サーバー	サーバーアプリケーションの名前とバージョン
タイトル	HTML ソースによって指定されたタイトル
警告	警告理由フレーズよりも詳細なメッセージ

ネゴシエーションヘッダーは、ネゴシエーション可能なリソースに関連する情報を伝達するために使用されます。 header

descriptionACCEPT-RANGEclassClassTypeTypeAサーバーが表示できる他のヘッダーのリストこのリソースに使用できるリスト変化に対応する。つまり、サーバーは最適なリソースバージョンを決定し、それをクライアントに送信します。セキュリティレスポンスヘッダーは、HTTP チャレンジ/レスポンス認証メカニズムの応答側です。セキュリティ応答ヘッダーは次のとおりです: Description


	vary
	Header

Procy-Authenticateプロキシからクライアントへのクエリリストクライアントにトークンを設定するクライアントを識別するための上記と同様のサーバーからクライアントへのクエリのリスト 4。エンティティとそのコンテンツに関する大量の情報を提供する 2 種類のメッセージに表示されます。その情報ヘッダーは次のとおりです。エンティティ上で実行されます情報クライアントエンティティの場所。リソースの場所に誘導するために使用されます

	Set-Cookie
	Set-Cookie2
	WWW-Authenticate

	Location

コンテンツヘッダーには、エンティティのコンテンツに関連する特定の情報が含まれます。

Content-Encoding内容-言語

Header	Description
Content-Base	本文内の相対URLを解析するときに使用されるベースURL
本文で実行されるエンコード方法

主題に適した自然言語を理解する

Content-LengthContent-LocationContent-MD5キャッシュヘッダーは、キャッシュされたボディの情報を記述します。 ETagExpiresLast-Modified

Length
Location
	MD5チェックコード
Content-Range	このエンティティによって表されるバイト範囲
Content-Type	オブジェクトタイプ

HeaderDescription
エンティティに関連するエンティティタグ
エンティティは有効ではなくなり、元のオリジンからエンティティの日時を再度取得しますサーバー

エンティティが最後に変更された日時

この章の内容全体は次のとおりです。いくつかの図が欠けていますが、少なくとも HTTP メッセージの内容を理解する必要があります。。問題ない。上記は、HTML の権威あるガイドの第 3 章の内容です。その他の関連内容については、PHP 中国語 Web サイト (www.php.cn) に注目してください。