HTTP ヘッダー情報の解釈と分析 (詳細概要)

HTTP ヘッダーの説明

1. Accept: Web サーバーに受け入れるメディアタイプを通知します。 */* は任意のタイプを意味し、type/* はこのタイプのすべてのサブタイプ、つまり type/sub-type を意味します。

2. Accept-Charset: ブラウザは受け入れる文字セットを宣言します
Accept-Encoding: ブラウザは受け入れるエンコード方式を宣言します。通常は圧縮方式、圧縮がサポートされているかどうか、サポートされている圧縮方式 (gzip、deflate) を指定します。
Accept-Language: ブラウザは受け入れる言語を宣言します。言語と文字セットの違い: 中国語は言語であり、big5、gb2312、gbk など、中国語には多くの文字セットがあります。

3. Accept-Ranges: Web サーバーは、エンティティの一部 (ファイルの一部など) を取得する要求を受け入れるかどうかを示します。バイト: は受け入れを示し、なし: は拒否を示します。

4. 経過時間: プロキシサーバーが自身のキャッシュからのエンティティを使用して要求に応答する場合、このヘッダーはエンティティが作成されてから経過した時間を示します。

5. 認証: クライアントが WEB サーバーから WWW-Authenticate 応答を受信すると、このヘッダーは独自の認証情報を WEB サーバーに応答します。

6. Cache-Control: リクエスト: no-cache (エンティティをキャッシュせず、WEB サーバーから取得するように要求します)
max-age: (Age 値が max-age 値より小さく、期限切れになっていないオブジェクトのみを受け入れます)
max-stale: (過去のオブジェクトも受け入れ可能だが、有効期限は
最大古さの値)
min-fresh: (現在の経過時間と min-fresh 値の合計よりも長いキャッシュオブジェクトを受け入れます)
応答: 公開 (キャッシュされたコンテンツを持つすべてのユーザーに応答できます)
非公開（キャッシュされたコンテンツは、以前にコンテンツをリクエストしたユーザーに応答するためにのみ使用できます）
no-cache (キャッシュは可能だが、WEB サーバーで有効性を確認した後にのみクライアントに返すことができる)
max-age: (このレスポンスに含まれるオブジェクトの有効期限)
ALL: no-store (キャッシュは許可されません)

7. 接続: 要求: 閉じる (Web サーバーまたはプロキシサーバーに、この要求への応答を完了した後に切断し、この接続からの後続の要求を待機しないように指示します)。
keepalive (Web サーバーまたはプロキシサーバーに、現在の要求への応答を完了した後も接続を維持し、この接続からの後続の要求を待機するように指示します)。
応答: close (接続が閉じられました)。
キープアライブ (接続は維持され、この接続の後続の要求を待機します)。
キープアライブ: ブラウザが接続の維持を要求した場合、このヘッダーは WEB サーバーが接続を維持する時間 (秒単位) を示します。
例: キープアライブ: 300

8. Content-Encoding: Web サーバーは、応答内のオブジェクトを圧縮するために使用する圧縮方法 (gzip、deflate) を示します。
例: Content-Encoding: gzip
Content-Language: Web サーバーは、応答するオブジェクトの言語をブラウザーに伝えます。
Content-Length: WEB サーバーは、応答するオブジェクトの長さをブラウザーに伝えます。
例: コンテンツの長さ: 26012
Content-Range: Web サーバーは、応答に含まれる部分オブジェクトがオブジェクト全体のどの部分に属するかを示します。
例: Content-Range: バイト 21010-47021/47022
Content-Type: WEB サーバーは、応答するオブジェクトのタイプをブラウザーに伝えます。
例: Content-Type: application/xml

9. ETag: オブジェクト（URLなど）のマーク値です。HTMLファイルなどのオブジェクトの場合、
変更されると、その Etag も変更されます。したがって、ETag の役割は、主に WEB サーバーがオブジェクトが変更されたかどうかを判断するために使用される Last-Modified の役割に似ています。
たとえば、前回HTMLファイルをリクエストしたときに、そのETagを取得しました。今回、再度ファイルをリクエストすると、
ブラウザは以前に取得した ETag 値を WEB サーバーに送信し、WEB サーバーはこの ETag をファイルの現在の ETag と比較して、ファイルが変更されたかどうかを認識します。

10. 期限切れ: Web サーバーは、エンティティの有効期限を示します。期限切れのオブジェクトは、Web サーバーで有効性が検証された後にのみ、クライアントの要求に応答するために使用できます。
HTTP/1.0 ヘッダーです。
例: 有効期限: 2009 年 5 月 23 日 (土) 10:02:12 GMT

11. ホスト: クライアントは、アクセスする WEB サーバーのドメイン名/IP アドレスとポート番号を指定します。
例: ホスト: rss.sina.com.cn

12. If-Match: オブジェクトの ETag が変更されていない場合、実際にはオブジェクトが変更されていないことを意味し、要求されたアクションが実行されます。
If-None-Match: オブジェクトの ETag が変更された場合、実際にはオブジェクトも変更されたことを意味し、要求されたアクションが実行されます。

13. If-Modified-Since: 要求されたオブジェクトがこのヘッダーで指定された時間以降に変更された場合、要求されたアクションが実行されます (オブジェクトを返すなど)。それ以外の場合は、オブジェクトが変更されていないことをブラウザに通知するためにコード 304 が返されます。
例: If-Modified-Since: Thu, 10 Apr 2008 09:14:42 GMT
If-Unmodified-Since: 要求されたアクション (オブジェクトを返すなど) は、要求されたオブジェクトがこのヘッダーで指定された時間以降に変更されていない場合にのみ実行されます。

14. If-Range: ブラウザは WEB サーバーに、要求したオブジェクトが変更されていない場合は不足している部分を返すように、オブジェクトが変更されている場合はオブジェクト全体を返すように指示します。ブラウザはリクエストオブジェクトを送信する
ETag または既知の最終変更時刻が WEB サーバーに渡され、オブジェクトが変更されたかどうかが判断されます。
常に Range ヘッダーで使用されます。

15. Last-Modified: ファイルの最終変更時刻など、WEB サーバーが考慮したオブジェクトの最終変更時刻。
動的ページが最後に生成された時刻など。
例: 最終更新日: 2008 年 5 月 6 日 (火) 02:42:43 GMT

16. 場所: Web サーバーは、アクセスしようとしているオブジェクトが別の場所に移動されたことをブラウザーに通知します。
ヘッドで指定された場所に移動して取得します。
例: 場所:
アップロード/2022/web/sinahome_0803_ws_005_text_0.gif

17. Pramga: 主に Pramga: no-cache を使用します。これは Cache-Control: no-cache と同等です。
例: プラグマ: no-cache

18. プロキシ認証: プロキシサーバーはブラウザーに応答し、プロキシ認証情報を提供するように要求します。
プロキシ認証: ブラウザはプロキシサーバーの認証要求に応答し、独自の ID 情報を提供します。

19. 範囲: ブラウザ (Flashget マルチスレッドダウンロードなど) は、オブジェクトのどの部分を取得するかを WEB サーバーに伝えます。
例: 範囲: バイト=1173546-

20. リファラー: ブラウザは、現在のリクエストの URL をどの Web ページ/URL から取得/クリックしたかを WEB サーバーに伝えます。
例: リファラー: http://www.sina.com/

21. サーバー: WEB サーバーのソフトウェアとバージョン情報を示します。
例: サーバー: Apache/2.0.61 (Unix)

22. ユーザーエージェント: ブラウザは自身を識別します (ブラウザの種類)。
例: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN;
rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

23. Transfer-Encoding: Web サーバーは、応答の本文 (本文内のオブジェクトではない) を担当することを示します。
チャンク化されたかどうかなど、どのようなエンコードが行われたか。
例: Transfer-Encoding: chunked

24. Vary: WEB サーバーはこのヘッダーの内容を使用して、この応答によって返されたオブジェクトがどのような条件で後続の要求に応答するために使用できるかをキャッシュサーバーに伝えます。
ソース Web サーバーが最初の要求メッセージを受信した場合、応答メッセージのヘッダーは次のようになります。
Content-Encoding: gzip; Vary: Content-Encoding その後、キャッシュサーバーは後続のリクエストメッセージのヘッダーを分析し、そのAccept-Encodingが前のレスポンスのVaryヘッダー値と一致しているかどうか、つまり同じコンテンツエンコーディング方法が使用されているかどうかを確認します。これにより、キャッシュサーバーが独自のエンコード方法を使用することを防ぐことができます。
キャッシュ内の圧縮されたエンティティは、解凍機能を持たないブラウザによって応答されます。
例: Vary: Accept-Encoding

25. 経由: クライアントから OCS への応答、またはその逆の応答が通過するプロキシサーバーと、要求の送信に使用されるプロトコル (およびバージョン) を一覧表示します。
クライアントのリクエストが最初のプロキシサーバーに到達すると、サーバーは送信するリクエストに Via ヘッダーを追加し、独自の関連情報を入力します。次のプロキシサーバーが最初のプロキシサーバーからリクエストを受信すると、前のプロキシサーバーのリクエストの Via ヘッダーを自身のリクエストにコピーします。
ヘッダーをチェックし、その末尾に独自の関連情報を追加します。同様に、OCS は最後のプロキシサーバーから要求を受信すると、Via ヘッダーをチェックし、要求がたどったルートを認識します。
例: Via: 1.0 236-81.D07071953.sina.com.cn:80 (squid/2.6.STABLE13)

====================================

HTTP リクエストメッセージヘッダーの例:
ホスト: rss.sina.com.cn
ユーザーエージェント: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
受け入れ可能: text/xml、application/xml、application/xhtml+xml、text/html;q=0.9、text/plain;q=0.8、image/png、*/*;q=0.5
受け入れ言語: zh-cn,zh;q=0.5
Accept-Encoding: gzip、deflate
受け入れ文字セット: gb2312、utf-8;q=0.7、*;q=0.7
キープアライブ: 300
接続: キープアライブ
クッキー: userId=C5bYpXrimdmsiQmsBPnE1Vn8ZQmdWSm3WRlEB3vRwTnRtW <-- クッキー
変更日時: 2008 年 6 月 1 日 (日) 12:05:30 GMT
キャッシュ制御: max-age=0
HTTP 応答メッセージヘッダーの例:
ステータス: OK - 200 <-- Web サーバーの処理の結果を示す応答ステータスコード。
日付: 2008 年 6 月 1 日 (日) 12:35:47 GMT
サーバー: Apache/2.0.61 (Unix)
最終更新日: 2008年6月1日(日) 12:35:30 GMT
受け入れ範囲: バイト
コンテンツの長さ: 18616
キャッシュ制御: max-age=120
有効期限：2008年6月1日（日）12:37:47 GMT
コンテンツタイプ: application/xml
年齢: 2
X-Cache: 236-41.D07071951.sina.com.cn からの HIT <-- リバースプロキシサーバーが使用する HTTP ヘッダー
経由: 1.0 236-41.D07071951.sina.com.cn:80 (squid/2.6.STABLE13)
接続：閉じる
=====================================

HTTPヘッダー情報の簡単な説明

1. HTTP 応答コード応答コードは 3 桁の 10 進数で構成され、HTTP サーバーから送信された応答の最初の行に表示されます。
応答コードには 5 つの種類があり、最初の数字で示されます。
1xx: 情報、リクエスト受信、処理を続行
2xx: 成功。行動は受け入れられ、理解され、採用されました。
3xx: リダイレクト。リクエストを完了するにはさらにアクションを実行する必要があります。
4xx: クライアントエラー、リクエストに構文エラーが含まれているか、リクエストを実装できません
5xx: サーバーエラー。サーバーは明らかに無効な要求を実装できません。次の表に、各応答コードとその意味を示します。
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

2. HTTP ヘッダーヘッダーはキーと値のペアで構成されます。これらは、クライアントまたはサーバーのプロパティ、転送されるリソース、および接続の実装方法を記述します。
ヘッダーには 4 つの種類があります。
1. 一般ヘッダー: リクエストとレスポンスの両方に使用でき、特定のリソースではなくトランザクション全体に関連付けられます。
2. リクエストヘッダー: クライアントが自分自身に関する情報と必要な応答フォームを渡すことを許可します。
3. レスポンスヘッダー: サーバーからの応答で、サーバー自身の情報を伝達します。
4. エンティティヘッダー: 送信されるリソースの情報を定義します。リクエストとレスポンスの両方に使用できます。
ヘッダー形式: <名前>:<値><CRLF>
次の表は、HTTP/1.1 で使用されるヘッダーについて説明しています。
Accept は、クライアントが処理できるメディアタイプを優先順位に従って定義します。複数のタイプを定義したり、コンマ区切りのリストでワイルドカードを使用したりできます。たとえば、Accept: image/jpeg,image/png,*/*Accept-Charset は、クライアントが処理できる文字セットを優先順位順に定義します。複数のタイプを定義したり、ワイルドカードをコンマ区切りのリストで使用したりできます。例: Accept-Charset: iso-8859-1,*,utf-8
Accept-Encoding は、クライアントが理解できるエンコードメカニズムを定義します。例: Accept-Encoding:gzip,compress
Accept-Language は、クライアントが受け入れ可能な自然言語のリストを定義します。例: Accept-Language: en,de
Accept-Ranges は、サーバーが指定されたオフセットと長さでリソースコンポーネントの要求を受け入れることを示すことができる応答ヘッダーです。このヘッダーの値は、要求範囲の測定単位として認識されます。たとえば、Accept-Ranges: bytes または Accept-Ranges: none
Age を使用すると、サーバーがこの応答を生成してから経過した時間の長さを秒単位で指定できます。このヘッダーは主に応答をキャッシュするために使用されます。例: 年齢: 30
リクエスト URI のセカンダリオリジンでサポートされる HTTP メソッドのリストを定義する応答ヘッダーを許可します。例: 許可: GET、PUT
リソースにアクセスするために必要な認証 (領域とエンコードされたユーザー ID とパスワード) を定義する UTHORIZATION 応答ヘッダー。例: 認証: Basic YXV0aG9yOnBoaWw=
Cache-Control キャッシュ命令を定義するために使用される一般的なヘッダー。例: Cache-Control: max-age=30
接続ソケット接続をオープンとして保存するかどうかを示すために使用される一般的なヘッダー。たとえば、Connection: close または Connection: keep-alive
Content-Base エンティティスコープ内の相対 URL を解決するためのベース URI を定義するエンティティヘッダー。 Content-Base ヘッダーが定義されていない場合は、相対 URL を解決するか、Content-Location URI (存在し絶対である場合) を使用するか、または要求 URI を使用します。例: Content-Base:

Content-Encoding エンティティがどのようにエンコードされるかを示すメディアタイプ修飾子。たとえば、Content-Encoding: zipContent-Language は、入力ストリーム内のデータの自然言語タイプを指定するために使用されます。例: Content-Language: en
Content-Length は、リクエストまたはレスポンスに含まれるデータのバイト長を指定します。例: Content-Length:382
Content-Location は、リクエストまたはレスポンスに含まれるリソースの場所 (URI) を指定します。必須の場合。 URL の場合、解決されたエンティティの相対 URL の開始点としても機能します。例: コンテンツの場所: http://www.myweb.com/news
Content-MD5 チェックサムとして使用されるエンティティの MD5 ダイジェスト。送信者と受信者の両方が MD5 ダイジェストを計算し、受信者は計算した値とこのヘッダーで渡された値を比較します。例: Content-MD5: <base64 of 128 MD5 ダイジェスト>
Content-Range はエンティティの一部とともに送信され、挿入されたバイトの下位バイトオフセットと上位バイトオフセットを示し、このエンティティの合計長も示します。例: コンテンツ範囲: 1001-2000/5000
Contern-Type は、送信または受信されるエンティティの MIME タイプを示します。例: Content-Type: text/html
日付 HTTP メッセージが送信された日付。例: 日付: 月、10PR 18:42:51 GMT
ETag 送信されるリソースに一意の識別子を割り当てるエンティティヘッダー。複数の URL を使用して要求できるリソースの場合、ETag を使用して、実際に送信されたリソースが同じリソースであるかどうかを判断できます。例: ETag: '208f-419e-30f8dc99'
有効期限エンティティの有効期限を指定します。例: 有効期限: 2008 年 12 月 5 日 (月) 12:00:00 GMT
ユーザーエージェントを制御する人間のユーザーの電子メールアドレスを指定するフォームリクエストヘッダー。例: 送信者: [email protected]
ホスト要求されたリソースのホスト名。このフィールドは、HTTP/1.1 を使用するリクエストでは必須です。例: ホスト: www.myweb.com
If-Modified-Since が GET リクエストに含まれている場合、リクエストはリソースの最終更新日に基づいて条件付きで依存するようになります。このヘッダーが存在し、指定された日付以降にリソースが変更されている場合は、304 応答コードが返される必要があります。例: If-Modified-Since: Mon,10PR 18:42:51 GMT
If-Match は、リクエストに含まれている場合に 1 つ以上のエンティティタグを指定します。 ETag がリスト内のタグと一致するリソースのみを送信します。例: If-Match: '208f-419e-308dc99'
If-None-Match リクエストに含まれている場合、1 つ以上のエンティティタグを指定します。操作は、リソースの ETag がリスト内のいずれの条件にも一致しない場合にのみ実行されます。例: If-None-Match: '208f-419e-308dc99'
If-Range は、クライアントが既にコピーを持っているリソースのエンティティタグを指定します。 Range ヘッダーと一緒に使用する必要があります。エンティティがクライアントによって最後に取得されてから変更されていない場合、サーバーは指定された範囲のみを送信します。それ以外の場合は、リソース全体を送信します。例: 範囲: バイト=0-499<CRLF> If-Range:'208f-419e-30f8dc99'
If-Unmodified-Since 指定された日付以降に変更されていない場合にのみ、要求されたエンティティを返します。例: If-Unmodified-Since:Mon,10PR 18:42:51 GMT
Last-Modified は、要求されたリソースが最後に変更された日時を指定します。例: Last-Modified: Mon,10PR 18:42:51 GMT
場所移動したリソースの場合、要求者を別の場所にリダイレクトするために使用されます。ステータスコード 302 (一時的に移動) または 301 (永久的に移動) で使用されます。例: 場所: http://www2.myweb.com/index.jsp
Max-Forwards は、TRACE メソッドで使用される要求ヘッダーであり、要求がルーティングされるプロキシまたはゲートウェイの最大数を指定します。プロキシまたはゲートウェイは、リクエストを渡す前にこの数値を減らす必要があります。例: Max-Forwards: 3
プラグマ実装に依存する情報を送信する一般的なヘッダー。例: プラグマ: no-cache
Proxy-Authenticate は WWW-Authenticate に似ていますが、リクエストチェーン内の次のサーバー (プロキシ) からのみ意図的に認証を要求する点が異なります。例: Proxy-Authenticate: Basic realm-admin
Proxy-Proxy-Authorization は authorization に似ていますが、直接のサーバーチェーンより下には渡されないことを意図しています。例: Proxy-Proxy-Authorization: Basic YXV0aG9yOnBoaWw=
パブリックリストには、サーバーでサポートされているメソッドのセットが表示されます。例: パブリック: OPTIONS、MGET、MHEAD、GET、HEAD
範囲は、要求されたリソースの一部分の測定単位とオフセット範囲を指定します。例: 範囲: バイト=206-5513
Refener リクエストを生成した元のリソースを識別するリクエストヘッダーフィールド。 HTML フォームの場合、これにはフォームを含む Web ページのアドレスが含まれます。例: 参照元: http://www.myweb.com/news/search.html
Retry-After 再度要求するまでの待機時間を示すために、ステータスコード 503 (サービスを提供できません) とともにサーバーから送信される応答ヘッダーフィールド。この時間は日付または秒単位のいずれかになります。例: Retry-After: 18
Web サーバーソフトウェアとそのバージョン番号を識別するサーバーヘッダー。例: サーバー: Apache/2.0.46(Win32)
Transfer-Encoding 受信者が実行する変換とは逆方向にメッセージ本文に対して実行される変換のタイプを示す一般的なヘッダー。例: Transfer-Encoding: chunked
アップグレードにより、サーバーは応答コード 101 (スイッチプロトコル) と組み合わせて使用される新しいプロトコルまたは新しいプロトコルバージョンを指定できます。例: アップグレード: HTTP/2.0
User-Agent は、リクエストを行うために使用されるソフトウェアの種類 (通常は Web ブラウザ) を定義します。例: User-Agent: Mozilla/4.0(compatible; MSIE 5.5; Windows NT; DigExt)
Vary サーバー駆動型ネゴシエーションを使用して、使用可能な応答表現の中から応答エンティティを選択する必要があることを示すために使用される応答ヘッダー。例: Vary: *Via 要求を満たすために使用されるすべての中間ホストとプロトコルを含む汎用ヘッダー。例: Via: 1.0 fred.com、1.1 wilma.com
警告は、応答ステータスに関する追加情報を提供するために使用される応答ヘッダーです。例: 警告: 99 www.myweb.com ピアノの調律が必要です
www-Authenticate ステータスコード 401 (Unauthorized) で使用される、ユーザーエージェントにユーザー名とパスワードの入力を求める応答ヘッダー。 Authorization ヘッダーで応答します。例: www-Authenticate: Basic realm=zxm.mgmt

<<: CSSは背景画像の画面適応を実現する

>>: MySQL の group by に関する簡単な説明