HTTPヘッダーの一覧！どんな種類があるの？

HTTPヘッダーにはさまざまな種類があり、用途に応じていくつかの分類が存在します。

この記事では『HTTPヘッダー』について、以下の内容をわかりやすく解説しています。

• HTTPヘッダーとは
• HTTPヘッダーの分類
• General Header（汎用ヘッダー）の一覧
• Request Header（リクエストヘッダー）の一覧
• Response Header（レスポンスヘッダー）の一覧
• Entity Header（エンティティヘッダー）の一覧

HTTPヘッダーとは

HTTPヘッダーは、HTTPリクエストやHTTPレスポンスに付加される追加情報（メタデータ）です。クライアント（ブラウザなど）とサーバーが通信する際、HTTPヘッダーの情報によって、通信の方法や内容を細かく制御・調整することができます。

HTTPヘッダーは、複数のヘッダーフィールド（Header Field）と呼ばれる行から成り立っており、それぞれのヘッダーフィールドは、以下のように「フィールド名（name）」、「コロン（:）」、「1文字分の空白」、「フィールド値（value）」で構成されています。

構成
フィールド名（name）: フィールド値（value）

例
Content-Type: text/html

HTTPヘッダーの分類

HTTPヘッダーは以下のカテゴリに分類されます。

• 汎用ヘッダー・一般ヘッダー（General Header）
  • HTTPリクエストとHTTPレスポンスの両方で使用されるヘッダー。
  • 例: Cache-Control, Connection, Date
• リクエストヘッダー（Request Header）
  • HTTPリクエストて使用されるヘッダー。
  • クライアントからサーバーに送信される情報を含んでいる。
  • 例: Accept, Authorization, User-Agent
• レスポンスヘッダー（Response Header）
  • HTTPレスポンスにて利用されるヘッダー。
  • サーバーからクライアントに送信される情報を含んでいる。
  • 例: Server, Set-Cookie
• 表現ヘッダー（Representation Header）
  • リソースの表現に関する情報を提供するヘッダー。
  • 例: Content-Length, Content-Range

General Header（汎用ヘッダー）の一覧

Cache-Control

Cache-Controlヘッダーは、HTTP/1.1通信において、ブラウザや中間サーバー（プロキシやCDN）がコンテンツをどのようにキャッシュするかを制御するHTTPヘッダーです。HTTP/1.0ではPragmaヘッダーがキャッシュ制御に使用されていましたが、HTTP/1.1以降ではCache-Controlが推奨されています。

Cache-Controlヘッダーの構文を以下に示します。

Cache-Control: <ディレクティブ>

Connection

Connectionヘッダーは、HTTP通信において現在のTCPコネクションの扱いを制御するHTTPヘッダーです。このヘッダーを使用することで、応答送信後にTCPコネクションを切断するか、維持するかを指定できます。

Connection: keep-alive

Date

Dateヘッダーは、HTTPメッセージが作成または送信された日時を示すHTTPヘッダーです。HTTPリクエストでは使用されることは少なく、HTTPレスポンスにおいて、サーバーがレスポンスを生成した日時を示す際に使用することが多いです。

Dateヘッダーの構文は以下のようになっており、日時はグリニッジ標準時（GMT）で記述されます。

Date: <曜日>, <日> <月> <年> <時>:<分>:<秒> GMT

例えば、2025年1月26日の9時に作成されたHTTPメッセージの場合、Dateヘッダーは以下のようになります。

Date: Fri, 26 Jan 2025 09:00:00 GMT

Pragma

Pragmaヘッダーは、HTTP/1.0でキャッシュ制御を行うために使用されるヘッダーです。HTTP/1.1以降ではCache-Controlヘッダーが推奨されていますが、後方互換性のためにPragmaが引き続きサポートされています。

Pragma: no-cache

Trailer

Trailerヘッダーは、HTTP通信でチャンク転送エンコーディング（chunked transfer encoding）が使用される場合に、メッセージの末尾に含まれる追加ヘッダーを指定するためのHTTPヘッダーです。Trailerヘッダーは、Transfer-Encoding: chunkedが使用される場合にのみ意味を持ちます。

Trailerヘッダーの具体例を以下に示します。

HTTPリクエスト例

以下のHTTPリクエストにおいて、クライアントはTrailer: Content-MD5でメッセージの末尾に Content-MD5 ヘッダーが追加されることを通知しています。

POST /upload HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Trailer: Content-MD5

4
Wiki
5
pedia
0

Content-MD5: 1B2M2Y8AsgTpgAmY7PhCfg==

Transfer-Encoding

Transfer-Encodingヘッダーは、HTTPメッセージボディ部分のエンコード方式を指定するために使用されるHTTPヘッダーです。このエンコード方式は、データをどのように加工して送信するか（圧縮や分割など）を決めます。

Transfer-Encoding: chunked

Upgrade

Upgradeヘッダーは、HTTP/1.1の接続を別のプロトコルにアップグレードしたい場合に使用するHTTPヘッダーです。このヘッダーを使うことで、クライアントがサーバーに対して別のプロトコルへのアップグレードを要求できます。

HTTP/1.1からWebSocketへの切り替えや、HTTP/1.1からHTTP/2（h2c）やHTTP/3に切り替えたい場合に使用されます。ただし、HTTP/2やHTTP/3では、通常ALPN（Application-Layer Protocol Negotiation）が利用されるため、Upgradeヘッダーは主にWebSocketに切り替える場合に使用されれます。

例えば、HTTP/1.1からWebSocketに切り替えたい場合、以下のようなHTTPリクエストとHTTPレスポンスになります。

HTTPリクエスト例

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

Upgrade: websocketでクライアントがプロトコルをWebSocketに切り替えたいことを示しています。Connection: UpgradeでUpgradeヘッダーを有効にすることを示します。Sec-WebSocket-Keyはクライアントが生成したランダムなキーで、サーバーが正しい応答を生成して返すことで通信の正当性を検証します。Sec-WebSocket-VersionはクライアントがサポートしているWebSocketプロトコルのバージョン（通常は13）を指定します。

HTTPレスポンス例

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

サーバーは101ステータスコード（Switching Protocols）を返し、WebSocketへの切り替えを承認します。Upgrade: websocketはプロトコルがWebSocketに切り替えられたことを示します。Sec-WebSocket-Acceptはクライアントから受け取ったSec-WebSocket-Keyに固定文字列258EAFA5-E914-47DA-95CA-C5AB0DC85B11を結合し、SHA-1でハッシュ化した後にBase64エンコードして生成された値です。これにより、クライアントとサーバー間の通信が正当であることを保証します。

Via

Viaヘッダーは、HTTPリクエストやHTTPレスポンスがプロキシサーバーやゲートウェイを経由する際に、経由したノードの情報を記録するためのHTTPヘッダーです。この情報は以下の目的で利用されます。

• ループの防止
  • 経由ノードの情報が追加されることで、同じノードを何度も経由する場合にループを検出可能。
• 透明性
  • クライアントやサーバーが経由ノードの情報を把握できる。
• デバッグとトラブルシューティング
  • 経由したプロキシやゲートウェイの情報から、ネットワーク上の問題箇所を特定可能。

Viaヘッダーの構文を以下に示します。

Via: <received-protocol> <received-by> [<comment>]

Viaヘッダーの具体例を以下に示します。

単一プロキシを経由した場合

Via: 1.1 example.com (Apache/2.4.41)

• 1.1: 経由ノードがHTTP/1.1を使用。
• example.com: 経由ノードのホスト名。
• (Apache/2.4.41): 経由ノードのサーバー情報（コメント部分）。

複数のプロキシを経由した場合

Via: 1.1 example.com, 1.0 proxy1.example.net (Squid/3.5)

• 1.1 example.com: 最初に経由したプロキシがHTTP/1.1を使用。
• 1.0 proxy1.example.net (Squid/3.5): 次に経由したプロキシがHTTP/1.0を使用。

このように、HTTPリクエストやHTTPレスポンスが複数のプロキシサーバーを経由した場合、Viaヘッダーにはすべての経由情報がカンマで区切られて含まれます。

Warning

Warningヘッダーは、HTTPレスポンスに追加情報や警告を提供するために使用されるヘッダーです。主にレスポンスの状態やキャッシュの問題点を示すために利用されます。

Warningヘッダーの構文を以下に示します。

Warning: <コード番号> <エージェント> "<警告テキスト>" [<日付>]

Warningヘッダーの具体例を以下に示します。

Warning: 113 example.net "Heuristic expiration"

• 113: キャッシュの有効期限が切れている場合の警告。
• example.net: 警告を生成したプロキシの情報。
• "Heuristic expiration": デフォルトの期限が切れたことを示すメッセージ。

Request Header（リクエストヘッダー）の一覧

Access-Control-Request-Method

Access-Control-Request-Methodヘッダーは、HTTPリクエストにおいて、CORS（Cross-Origin Resource Sharing）のプリフライトリクエストで使用されるHTTPヘッダーです。クライアント（通常はブラウザ）が、特定のリソースに対してどのHTTPメソッド（例: GET, POST, DELETEなど）を使用する予定であるかを、事前にサーバーへ通知します。

Access-Control-Request-Methodヘッダーの具体例を以下に示します。

HTTPリクエスト例

OPTIONS /api/resource HTTP/1.1
Host: example.com
Origin: https://client.example
Access-Control-Request-Method: DELETE

• OPTIONS: プリフライトリクエストは通常OPTIONSメソッドで送信されます。
• Origin: リクエストを発行しているオリジン。
• Access-Control-Request-Method: DELETE: クライアントが本リクエストでDELETEメソッドを使用する予定であることを通知。

HTTPレスポンス例

HTTP/1.1 204 No Content
Access-Control-Allow-Methods: GET, POST, DELETE
Access-Control-Allow-Origin: https://client.example

• 204 No Content: プリフライトリクエストが成功し、指定されたメソッドが許可されている。
• Access-Control-Allow-Methods: サーバーが許可するHTTPメソッドのリストを示す。
• Access-Control-Allow-Origin: 指定されたオリジン（例: https://client.example）からのリクエストを許可。

Access-Control-Request-Headers

Access-Control-Request-Headersヘッダーは、HTTPリクエストにおいて、CORS（Cross-Origin Resource Sharing）のプリフライトリクエストで使用されるHTTPヘッダーです。クライアント（通常はブラウザ）が、サーバーに対して「実際のリクエストで送信予定のカスタムHTTPヘッダー」を事前に通知するために利用されます。

Access-Control-Request-Headersヘッダーの具体例を以下に示します。

HTTPリクエスト例

OPTIONS /api/resource HTTP/1.1
Host: example.com
Origin: https://client.example
Access-Control-Request-Headers: Authorization, X-Custom-Header

• OPTIONS: プリフライトリクエストは通常OPTIONSメソッドで送信されます。
• Origin: リクエストを発行しているオリジン。
• Access-Control-Request-Headers: クライアントが本リクエストで送信予定のヘッダー（ここではAuthorizationとX-Custom-Header）。

HTTPレスポンス例

HTTP/1.1 204 No Content
Access-Control-Allow-Headers: Authorization, X-Custom-Header
Access-Control-Allow-Origin: https://client.example

• 204 No Content: プリフライトリクエストが成功し、指定されたヘッダーが許可されている。
• Access-Control-Allow-Headers: サーバーが許可するHTTPヘッダーをリストアップ。
• Access-Control-Allow-Origin: 指定されたオリジン（例: https://client.example）からのリクエストを許可。

Accept

Acceptヘッダーは、HTTPリクエストにおいて、クライアントが受け入れ可能なMIMEタイプ（メディアタイプ）をサーバーに通知するHTTPヘッダーです。この情報を元に、サーバーはクライアントが希望する形式でレスポンスを返すことができます。

Acceptヘッダーの構文を以下に示します。

Accept: <メディアタイプ>[;q=<品質値>], ...

Acceptヘッダーの具体例を以下に示します。

JSONを受け入れる場合

Accept: application/json

クライアントはapplication/json形式のデータを希望。

複数のメディアタイプを指定する場合

Accept: text/html, application/json

クライアントはtext/htmlまたはapplication/jsonのいずれかを希望。

優先度を指定する場合

Accept: application/json;q=0.9, text/html;q=0.8, */*;q=0.1

application/json（最優先）、text/html（次点）、その他の形式（最低優先度）の順番で希望しています。

Accept-Charset

Accept-Charsetヘッダーは、HTTPリクエストにおいて、クライアント（通常はブラウザ）が受け入れ可能な文字セット（文字エンコーディング）をサーバーに通知するためのHTTPヘッダーです。この情報を基に、サーバーはクライアントがサポートする文字エンコーディングでレスポンスを返します。

Accept-Charsetヘッダーの構文を以下に示します。

Accept-Charset: <文字セット>[;q=<品質値>], ...

Accept-Charsetヘッダーの具体例を以下に示します。

UTF-8のみを受け入れる場合

Accept-Charset: UTF-8

クライアントはUTF-8エンコーディングのみ受け入れる。

複数の文字セットを指定する場合

Accept-Charset: UTF-8, ISO-8859-1

クライアントはUTF-8またはISO-8859-1のどちらかのみ受け入れる。優先度は明示されていないため、同じ扱い。

優先度を指定する場合

Accept-Charset: UTF-8;q=1.0, ISO-8859-1;q=0.8, *;q=0.1

UTF-8（最優先）、ISO-8859-1（次点）、その他すべての文字セット（最低優先度）の順番で受け入れる。

Accept-Encoding

Accept-Encodingヘッダーは、HTTPリクエストにおいて、クライアントが受け入れ可能なコンテンツエンコーディング形式（gzipなど）をサーバーに通知するためのHTTPヘッダーです。サーバーは、この情報を基にクライアントが対応可能な形式で圧縮したレスポンスを返します。

Accept-Encodingヘッダーの構文を以下に示します。

Accept-Encoding: <エンコーディング形式>[;q=<品質値>], ...

Accept-Encodingヘッダーの具体例を以下に示します。

gzipのみを受け入れる場合

Accept-Encoding: gzip

クライアントはgzip形式の圧縮データのみ受け入れる。

複数のエンコーディング形式を指定する場合

Accept-Encoding: gzip, deflate, br

クライアントはgzip、deflate、brのいずれかのみ受け入れる。優先度は明示されていないため、同じ扱い。

優先度を指定する場合

Accept-Encoding: br;q=1.0, gzip;q=0.8, identity;q=0.5

br（最優先）、gzip（次点）、圧縮なし（identity）の順番で受け入れる。

Accept-Language

Accept-Languageヘッダーは、HTTPリクエストにおいて、クライアント（通常はブラウザ）が受け入れ可能な言語（自然言語）をサーバーに通知するためのHTTPヘッダーです。サーバーはこの情報を基に、クライアントが希望する言語でコンテンツを返すように対応します。サーバが多国語に対応しているときなどに使います。

Accept-Languageヘッダーの構文を以下に示します。

Accept-Language: <言語コード>[;q=<品質値>], ...

Accept-Languageヘッダーの具体例を以下に示します。

日本語のみを受け入れる場合

Accept-Language: ja

クライアントは日本語（ja）のみを受け入れる。

複数のエンコーディング形式を指定する場合

Accept-Language: en, ja

クライアントは英語（en）または日本語（ja）のいずれかのみ受け入れる。優先度は明示されていないため、同じ扱い。

優先度を指定する場合

Accept-Language: ja;q=1.0, en;q=0.8, fr;q=0.6

日本語（ja）、英語（en）、フランス語（fr）の順番で受け入れる。

すべての言語を受け入れる場合

Accept-Language: *

クライアントはどの言語でも受け入れる。

Authorization

Authorizationヘッダーは、HTTPリクエストにおいて、サーバーに対して認証情報を提供するために使用されるHTTPヘッダーです。この情報を基に、サーバーはクライアントのリクエストを許可または拒否します。サーバーがWWW-Authenticateレスポンスヘッダーを通じて認証を要求した場合、クライアントはAuthorizationヘッダーを使用して応答します。

Authorizationヘッダーの構文を以下に示します。

Authorization: <スキーム> <認証情報>

Authorizationヘッダーの具体例を以下に示します。

Basic認証

ユーザー名とパスワードをBase64でエンコードして送信します。

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

dXNlcm5hbWU6cGFzc3dvcmQ=は、username:passwordをBase64でエンコードした文字列です。

Bearerトークン認証

アクセストークンを使用してリソースにアクセスします（OAuth 2.0などで使用）。

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

トークン（eyJhbGciOiJIUzI1NiIs...）は、アクセストークンやJWT（JSON Web Token）などです。

APIキー認証（独自の認証スキーム）

サーバーが特定のキーを認証情報として要求する場合です。

Authorization: ApiKey abc123xyz456

abc123xyz456はAPIキーです。

Cookie

Cookieヘッダーは、HTTPリクエストにおいて、クライアント（通常はブラウザ）に保存されているCookie情報をサーバーに送信するためのHTTPヘッダーです。サーバーはこの情報を利用して、セッション管理やユーザー情報の追跡を行います。

Cookieヘッダーの構文を以下に示します。

Cookie: <キー1>=<値1>; <キー2>=<値2>; ...

Cookieヘッダーの具体例を以下に示します。

単一のCookieを送信

Cookie: sessionId=abc123

クライアントはsessionIdという名前のCookieに値abc123を設定して送信します。

複数のCookieを送信

Cookie: sessionId=abc123; userPref=darkMode

複数のキーと値のペアをセミコロン（;）で区切って送信します。

Expect

Expectヘッダーは、HTTPリクエストにおいて、リクエストボディを送信する前にサーバーがそのリクエストを受け入れるかを確認する際に使用するHTTPヘッダーです。主に大きなリクエストボディを送信する前などに使用されます。サーバーがそのリクエストを受け入れられる場合は、100 Continueステータスコードを返します。

Expectヘッダーの構文を以下に示します。

Expect: <期待する動作>

Expectヘッダーの具体例を以下に示します。

100-Continueを指定する場合

クライアントが大きなリクエストボディを送信する際に、サーバーがそのリクエストを受け入れるか確認したい場合には、以下のようなHTTPリクエストを送ります。

POST /upload HTTP/1.1
Host: example.com
Content-Length: 1048576
Expect: 100-Continue

サーバーが期待が以下に示すように100 Continueを返せば、クライアントはリクエストボディを送信します。サーバーがエラーを返した場合、クライアントはリクエストボディを送信せずに処理を終了します。

HTTP/1.1 100 Continue

From

Fromヘッダーは、HTTPリクエストにおいて、リクエストを送信したユーザーまたはクライアントのメールアドレスを示すために使用されるHTTPヘッダーです。主に、自動化されたクライアント（ボットやクローラーなど）が自らを識別する目的で使用されます。

Fromヘッダーの構文を以下に示します。

From: <メールアドレス>

Fromヘッダーの具体例を以下に示します。

ボットのリクエストにおける例

以下のHTTPリクエストは、bot@example.comというメールアドレスを持つクライアント（ボット）から送信されています。

GET /example HTTP/1.1
Host: example.com
From: bot@example.com

Host

Hostヘッダーは、HTTPリクエストにおいて、リクエスト先のサーバーのホスト名（DNS名またはIPアドレス）とポート番号を指定するHTTPヘッダーです。HTTP/1.1では、すべてのリクエストにおいてこのヘッダーを必須としています。ポート番号は省略可能です。省略した場合、HTTP通信では「80」、HTTPS通信では「443」が適用されます。

Hostヘッダーの構文を以下に示します。

Host: <ホスト名>[:<ポート番号>]

Hostヘッダーの具体例を以下に示します。

ホスト名のみを指定する場合

Host: example.com

ポート番号が省略されているので（HTTP通信では「80」、HTTPS通信では「443」）を使用します。

ホスト名とポート番号を指定する場合

Host: example.com:8080

ポート番号8080を明示的に指定しています。

If-Modified-Since

If-Modified-Sinceヘッダーは、HTTPリクエストにおいて、指定した日時以降にリソースが変更されている場合のみ、そのリソースを取得するようサーバーに指示するHTTPヘッダーです。

If-Modified-Sinceヘッダーはクライアントが、キャッシュ済みのリソースが最新であるかを確認するために使用します。サーバーはリソースの最終更新日時とIf-Modified-Sinceの日時を比較し、リソースが指定した日時以降に更新されていない場合、サーバーは304 Not Modifiedを返し、リソースを再送しません。

If-Modified-Sinceヘッダーの構文を以下に示します。

If-Modified-Since: <日時>

If-Modified-Sinceヘッダーの具体例を以下に示します。

HTTPリクエスト例

以下のHTTPリクエストでは、クライアントは、2025年1月24日12:00:00以降にリソースが変更されていれば、新しいリソースを要求しています。

GET /resource HTTP/1.1
Host: example.com
If-Modified-Since: Wed, 24 Jan 2025 12:00:00 GMT

HTTPレスポンス例

リソースが更新されていない場合、サーバーはリソースを再送せず、304 Not Modifiedを返します。

HTTP/1.1 304 Not Modified

リソースが更新されている場合、サーバーは新しいリソースを返し、Last-Modifiedヘッダーでリソースの最終更新日時を通知します。

HTTP/1.1 200 OK
Content-Type: text/html
Last-Modified: Thu, 25 Jan 2025 14:30:00 GMT

If-Match

If-Matchヘッダーは、HTTPリクエストにおいて、サーバー上のリソースを更新や削除する前に、そのリソースが特定のバージョン（ETag値）と一致しているかを確認するために使用されるHTTPヘッダーです。

If-Matchヘッダーはリソースの競合を防ぐために使用されます。リソースが他のクライアントによって変更されていた場合、リクエストは拒否されます。これにより、データの整合性を保ちつつ、安全なリソース操作が可能になります。

If-Matchヘッダーの構文を以下に示します。

If-Match: <ETag値>[, <ETag値> ...]

If-Matchヘッダーの具体例を以下に示します。

HTTPリクエスト例

以下のHTTPリクエストでは、クライアントは、ETagが"123456789abcdef"であるリソースを更新しようとしています。

PUT /example-resource HTTP/1.1
Host: example.com
If-Match: "123456789abcdef"
Content-Type: application/json

{
  "key": "new-value"
}

HTTPレスポンス例

ETagが一致した場合、リクエストが成功し、新しいETag値が返されます。

HTTP/1.1 200 OK
ETag: "987654321fedcba"

ETagが一致しない場合、リクエストは拒否され、リソースは変更されません。

HTTP/1.1 412 Precondition Failed

If-None-Match

If-None-Matchヘッダーは、HTTPリクエストにおいて、指定したETag値とサーバー上のリソースのETag値が一致しない場合にのみリクエストを実行するよう指示するHTTPヘッダーです。

主にGETリクエストにおいて、キャッシュが最新でない場合にのみ、新しいリソースを取得する場合や、POST/PUT/DELETEリクエストにおいて、特定のリソースが存在しない際にのみ処理を行う場合に使用されます。

If-None-Matchヘッダーの構文を以下に示します。

If-None-Match: <ETag値>[, <ETag値> ...]

If-None-Matchヘッダーの具体例を以下に示します。

HTTPリクエスト例

以下のHTTPリクエストでは、クライアントは、ETagが"123456789abcdef"のリソースが変更されていないかを確認します。

GET /example-resource HTTP/1.1
Host: example.com
If-None-Match: "123456789abcdef"

HTTPレスポンス例

ETagが一致した場合、リソースが変更されていないため、サーバーは本文を送信せず、キャッシュされたリソースが最新であることを示します。

HTTP/1.1 304 Not Modified

ETagが一致しない場合、リソースが変更されているため、サーバーは新しいリソースを返し、最新のETagをレスポンスに含めます。

HTTP/1.1 200 OK
ETag: "987654321fedcba"
Content-Type: application/json

{
  "key": "updated-value"
}

If-Range

If-Rangeヘッダーは、HTTPリクエストにおいて、条件付き範囲リクエストを行うために使用されるHTTPヘッダーです。リソースが変更されていない場合、範囲リクエスト（Rangeヘッダー）で指定された範囲を取得し、リソースが変更されている場合は、リソース全体を再取得します。サーバーはクライアントから送られたETag値または最終更新日時（Last-Modified）を基にリソースの変更有無を判断します。

If-Rangeヘッダーの構文を以下に示します。

If-Range: <ETag> または <最終更新日時>

If-Rangeヘッダーの具体例を以下に示します。

HTTPリクエスト例

以下のHTTPリクエストでは、クライアントは、If-Rangeヘッダーを用いています。If-RangeヘッダーにはEtag値を指定しています。

GET /example-resource HTTP/1.1
Host: example.com
Range: bytes=100-200
If-Range: "123456789abcdef"

HTTPレスポンス例

サーバー上のリソースのETagが"123456789abcdef"と一致した場合、範囲リクエスト成功なので、バイト範囲100-200を返します。

HTTP/1.1 206 Partial Content
Content-Range: bytes 100-200/1000
Content-Type: application/octet-stream

[リソースの指定された範囲のデータ]

サーバー上のリソースのETagが"123456789abcdef"と一致しない場合、リソースが変更されているため、サーバーはリソース全体を返します。

HTTP/1.1 200 OK
Content-Length: 1000
Content-Type: application/octet-stream

[リソース全体のデータ]

If-Unmodified-Since

If-Unmodified-Sinceヘッダーは、HTTPリクエストにおいて、指定された日時以降にリソースが変更されていない場合のみリクエストを実行するようサーバーに指示するHTTPヘッダーです。リソースがその日時以降に変更されている場合は、リクエストが拒否されます。

If-Unmodified-Sinceヘッダーの構文を以下に示します。

If-Unmodified-Since: <日時>

If-Unmodified-Sinceヘッダーの具体例を以下に示します。

HTTPリクエスト例

以下のHTTPリクエストでは、クライアントは、リソースが2025年1月24日 12:00:00 GMT以降変更されていない場合のみリクエストを処理するように指定しています。

PUT /example-resource HTTP/1.1
Host: example.com
If-Unmodified-Since: Wed, 24 Jan 2025 12:00:00 GMT
Content-Type: application/json

{
  "key": "new-value"
}

HTTPレスポンス例

リソースが変更されていない場合には、リクエストが成功します。

HTTP/1.1 200 OK

リソースが変更されていた場合には、サーバーはリクエストを拒否し、リソースは変更されません。他のプロセスがリソースを変更していた場合、リクエストを拒否することで意図しないデータの上書きを防げます。

HTTP/1.1 412 Precondition Failed

Max-Forwards

Max-Forwardsヘッダーは、HTTPリクエストにおいて、リクエストが経由できるプロキシやゲートウェイの最大数を制限するために使用されるHTTPヘッダーです。主にTRACEメソッドとともに使用され、無限ループを防ぐために役立ちます。

Max-Forwardsヘッダーの構文を以下に示します。

Max-Forwards: <数値>

Max-Forwardsヘッダーの具体例を以下に示します。

HTTPリクエスト例

以下のHTTPリクエストでは、クライアントはサーバーまでの経路をデバッグするためにTRACEメソッドを使用しており、リクエストは最大5回までプロキシやゲートウェイを経由できます。

TRACE / HTTP/1.1
Host: example.com
Max-Forwards: 5

Origin

Originヘッダーは、HTTPリクエストにおいて、HTTPリクエストの送信元（オリジン）を示すヘッダーで、CORS（Cross-Origin Resource Sharing）の判定に使用されます。主に、クロスオリジン（異なるドメイン間）でのリクエストのセキュリティ制御に関わります。

Originヘッダーの構文を以下に示します。

Origin: <スキーム>://<ホスト>[:<ポート>]

Originヘッダーの具体例を以下に示します。

HTTPリクエスト例

https://client.example.comのページからリクエストが発生した場合には、以下のようになります。

GET /api/data HTTP/1.1
Host: api.example.com
Origin: https://client.example.com

HTTPレスポンス例

サーバーがリクエストを許可した場合には、以下のようになります。以下の例だと、アクセスを許可するオリジンを、https://client.example.comのみに指定しています。

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://client.example.com

Proxy-Authorization

Proxy-Authorizationヘッダーは、HTTPリクエストにおいて、クライアントがプロキシサーバーを通じてリクエストを送信する際に、プロキシへの認証情報を提供するためのHTTPヘッダーです。プロキシが認証を要求する場合、クライアントはこのヘッダーを使用してユーザー名やパスワード、トークンを送信し、アクセスを許可されます。

サーバーがProxy-Authenticateヘッダーを送信し、クライアントがProxy-Authorizationヘッダーで認証情報を提供します。

Proxy-Authorizationヘッダーの構文を以下に示します。

Proxy-Authorization: <認証方式> <認証情報>

Proxy-Authorizationヘッダーの具体例を以下に示します。

Basic認証

ユーザー名とパスワードをBase64でエンコードして送信します。

Proxy-Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

dXNlcm5hbWU6cGFzc3dvcmQ=は、username:passwordをBase64でエンコードした文字列です。

Bearerトークン認証

アクセストークンを使用してリソースにアクセスします（OAuth 2.0などで使用）。

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

トークン（eyJhbGciOiJIUzI1NiIs...）は、アクセストークンです。

Range

Rangeヘッダーは、HTTPリクエストにおいて、HTTPリクエストでリソースの一部（特定の範囲のデータ）を要求するために使用されるHTTPヘッダーです。これにより、大きなファイルを分割して取得したり、ダウンロードの再開が可能になります。

Rangeヘッダーの構文を以下に示します。

Range: <単位>=<開始位置>-<終了位置>

Rangeヘッダーの具体例を以下に示します。

HTTPリクエスト例

以下のHTTPリクエストでは、クライアントは、Rangeヘッダーを用いて、リソースの一部（100-200バイト）を要求しています。

GET /example-resource HTTP/1.1
Host: example.com
Range: bytes=100-200

HTTPレスポンス例

サーバーがRangeリクエストをサポートしており、リソースのサイズが201バイト以上の場合、指定された範囲（100-200バイト）を返します。

HTTP/1.1 206 Partial Content
Content-Range: bytes 100-200/1000
Content-Length: 101
Content-Type: application/octet-stream

[100-200 バイト目のデータ]

サーバーが Range リクエストをサポートしていない場合、サーバーがRangeリクエストを無視し、全データを送信します。

HTTP/1.1 200 OK
Content-Length: 1000
Content-Type: application/octet-stream

[リソース全体のデータ]

Referer

Refererヘッダー（リファラー）は、HTTPリクエストにおいて、現在のリクエストが発生した元のページ（直前に閲覧していたページ）のURLを示すHTTPヘッダーです。ユーザーがあるページのリンクをクリックした際に、そのリンク元のURLをサーバーに伝えるために使用されます。

Refererヘッダーの構文を以下に示します。

Referer: <URL>

Refererヘッダーの具体例を以下に示します。

HTTPリクエスト例

ユーザーがhttps://example.comのページにあるリンクをクリックしてhttps://destination.com/pageに移動した場合には、以下のようなHTTPリクエストになります。その結果、destination.comのサーバーは、このリクエストの発生元がexample.comであることを知ることができます。

GET /page HTTP/1.1
Host: destination.com
Referer: https://example.com

Upgrade-Insecure-Requests

Upgrade-Insecure-Requestsヘッダーは、クライアント（通常はブラウザ）がHTTPからHTTPSへのアップグレードを希望することをサーバーに通知するためのヘッダーです。このヘッダーが送信された場合、サーバーは可能であれば、安全なHTTPSリソースを提供することが推奨されます。

Upgrade-Insecure-Requestsヘッダーの構文を以下に示します。

Upgrade-Insecure-Requests: 1

Upgrade-Insecure-Requestsヘッダーの具体例を以下に示します。

HTTPリクエスト例

以下のHTTPリクエストでは、クライアントはHTTPS版のリソースを要求できるなら提供してほしいことを示しています。

GET /example-page HTTP/1.1
Host: example.com
Upgrade-Insecure-Requests: 1

HTTPレスポンス例

サーバーがHTTPSリソースを提供することが可能な場合、リダイレクトを指示します。その結果、クライアントはhttps://example.com/example-pageに自動的に移動します。

HTTP/1.1 301 Moved Permanently
Location: https://example.com/example-page

サーバーがHTTPSを提供していない場合、通常のHTTPレスポンスを返します。

HTTP/1.1 200 OK
Content-Type: text/html

TE

TEヘッダーは、HTTPリクエストにおいて、クライアントがサーバーに対して「受け入れ可能なTransfer-Encodingの形式（転送エンコーディング）」を指定するためのヘッダーです。通常、HTTP/1.1の「チャンク転送エンコーディング（chunked）」に関するサポートを示すために使用されますが、通常のウェブブラウザではほとんど利用されません。

TEヘッダーの構文を以下に示します。

TE: <エンコーディング方式>[;q=<品質値>], ...

TEヘッダーの具体例を以下に示します。

HTTPリクエスト例

以下のHTTPリクエストでは、TE: chunkedでクライアントはchunked転送エンコーディングを受け入れ可能であることをサーバーに伝えています。

GET /example.txt HTTP/1.1
Host: example.com
TE: chunked

HTTPレスポンス例

サーバーはTransfer-Encoding: chunkedを含むレスポンスを返します。

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: text/plain

4
Test
7
 Message
0

サーバーがchunked転送を使用しない場合、通常のレスポンスを送信します。

HTTP/1.1 200 OK
Content-Length: 13
Content-Type: text/plain

Hello, World!

X-Forwarded-Host

X-Forwarded-Hostヘッダーは、HTTPリクエストにおいて、ロードバランサやプロキシサーバを経由してWebサーバに接続する際に、クライアントの送信元ホスト名をWebサーバに伝えるためのHTTPヘッダーです。通常、プロキシを経由するとHostヘッダーが変わる可能性があるため、元のホスト情報を保持するためにX-Forwarded-Hostが使用されます。

X-Forwarded-Hostヘッダーの構文を以下に示します。

X-Forwarded-Host: <オリジナルのホスト名>

X-Forwarded-Hostヘッダーの具体例を以下に示します。

HTTPリクエスト例

クライアントがexample.comにアクセスし、プロキシproxy.example.netを経由した場合のHTTPリクエストは以下のようになります。

GET /page HTTP/1.1
Host: proxy.example.net
X-Forwarded-Host: example.com

Host: proxy.example.netはプロキシのホスト名（実際のリクエストが送られる先）です。X-Forwarded-Host: example.comはクライアントが本来アクセスしようとしていたホスト名です。

HTTPレスポンス例

HTTPレスポンスは以下のようになります。

HTTP/1.1 200 OK
Content-Type: text/html
X-Processed-Host: example.com

<!DOCTYPE html>
<html>
<head><title>Example Page</title></head>
<body><h1>Welcome to Example.com!</h1></body>
</html>

X-Processed-Host: example.comはWebサーバーがX-Forwarded-Hostを認識し、オリジナルのホストを処理したことを示してます。

X-Forwarded-For

X-Forwarded-Forヘッダーは、HTTPリクエストにおいて、ロードバランサやプロキシサーバを経由してWebサーバに接続する際に、クライアントの送信元のIPアドレスをWebサーバに伝えるためのHTTPヘッダーです。アクセス制御やログ管理でクライアントの正しいIPを記録するために使用されます。

X-Forwarded-Forヘッダーの構文を以下に示します。

X-Forwarded-For: <クライアントIP>[, <プロキシ1IP>, <プロキシ2IP>, ...]

X-Forwarded-Forヘッダーの具体例を以下に示します。

HTTPリクエスト例

クライアント(203.0.113.10)がプロキシ(192.168.1.1)を経由してexample.comにHTTPリクエストを送信する場合、以下のようになります。

GET /page HTTP/1.1
Host: example.com
X-Forwarded-For: 203.0.113.10, 192.168.1.1

X-Forwarded-For: 203.0.113.10は元のクライアントのIPアドレスです。

クライアント(203.0.113.10)が、2つのプロキシ(192.168.1.1, 10.0.0.1)を経由してexample.comにHTTPリクエストを送信する場合、以下のようになります。

GET /page HTTP/1.1
Host: example.com
X-Forwarded-For: 203.0.113.10, 192.168.1.1, 10.0.0.1

HTTPレスポンス例

HTTPレスポンスは以下のようになります。

HTTP/1.1 200 OK
Content-Type: text/html
X-Client-IP: 203.0.113.10

<!DOCTYPE html>
<html>
<head><title>Client IP</title></head>
<body><h1>Your IP: 203.0.113.10</h1></body>
</html>

X-Client-IP: 203.0.113.10はサーバーがX-Forwarded-Forからクライアントの元IPを認識してレスポンスに含めています。

Response Header（レスポンスヘッダー）の一覧

Access-Control-Allow-Origin

Access-Control-Allow-Originヘッダーは、CORS（Cross-Origin Resource Sharing）において、他のオリジン（異なるドメイン）からのリクエストを許可するためのHTTPレスポンスヘッダーです。

Access-Control-Allow-Originヘッダーの構文を以下に示します。

Access-Control-Allow-Origin: <オリジン, *, またはnull>

Access-Control-Allow-Originヘッダーの具体例を以下に示します。

HTTPリクエスト例

クライアント(https://client.example.com)からhttps://api.example.comにGETリクエストを送信した場合、HTTPリクエストは以下のようになります。

GET /data HTTP/1.1
Host: api.example.com
Origin: https://client.example.com

Origin: https://client.example.comはクライアントのオリジン（リクエストの発信元）です。

HTTPレスポンス例

HTTPレスポンスは以下のようになります。

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://client.example.com
Content-Type: application/json

{"message": "CORS request successful"}

Access-Control-Allow-Origin: https://client.example.comはhttps://client.example.comからのリクエストのみ許可しています。

すべてのオリジンからのリクエストを許可する場合、HTTPレスポンスは以下のようになります。

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json

{"message": "CORS request from any origin is allowed"}

Access-Control-Allow-Credentials

Access-Control-Allow-Credentialsヘッダーは、CORS（Cross-Origin Resource Sharing）において、クライアントが認証情報（クッキーやHTTP認証ヘッダー）を含めたリクエストを送信できるかを制御するためのHTTPレスポンスヘッダーです。

Access-Control-Allow-Credentialsヘッダーの構文を以下に示します。

Access-Control-Allow-Credentials: true

Access-Control-Allow-Credentialsヘッダーの具体例を以下に示します。

HTTPリクエスト例

クライアント(https://client.example.com)からhttps://api.example.comに、クッキーを含めたリクエストを送信した場合、HTTPリクエストは以下のようになります。

GET /user-info HTTP/1.1
Host: api.example.com
Origin: https://client.example.com
Cookie: sessionId=abc123

Origin: https://client.example.comはクライアントのオリジン（CORSリクエスト）を示しており、Cookie: sessionId=abc123は認証情報（セッションID）を含めたリクエストです。

HTTPレスポンス例

HTTPレスポンスは以下のようになります。

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://client.example.com
Access-Control-Allow-Credentials: true
Content-Type: application/json

{"user": "JohnDoe"}

Access-Control-Allow-Origin: https://client.example.comは特定のオリジンのみ許可しています（*は使用できません）。Access-Control-Allow-Credentials: trueにより、クライアントがクッキーや認証情報を送信できるようにしています。

Access-Control-Allow-Methods

Access-Control-Allow-Methodsヘッダーは、CORS（Cross-Origin Resource Sharing）において、サーバーが許可するHTTPメソッド（GET, POST, DELETE など）を指定するHTTPレスポンスヘッダーです。このヘッダーは、プリフライトリクエスト（OPTIONS）に対するレスポンスとして送信されます。

Access-Control-Allow-Methodsヘッダーの構文を以下に示します。

Access-Control-Allow-Methods: <method1>, <method2>, ...

Access-Control-Allow-Methodsヘッダーの具体例を以下に示します。

HTTPリクエスト例

クライアントがDELETEメソッドを使用できるか確認するために、OPTIONSリクエストを送信した場合、HTTPリクエストは以下のようになります。

OPTIONS /api/resource HTTP/1.1
Host: example.com
Origin: https://client.example
Access-Control-Request-Method: DELETE

HTTPレスポンス例

サーバーがGET, POST, DELETEを許可している場合のHTTPレスポンスは以下のようになります。

HTTP/1.1 204 No Content
Access-Control-Allow-Methods: GET, POST, DELETE
Access-Control-Allow-Origin: https://client.example

Access-Control-Allow-Headers

Access-Control-Allow-Headersヘッダーは、CORS（Cross-Origin Resource Sharing）において、サーバーが許可するカスタムヘッダー（例: Content-Type, Authorizationなど）を指定するHTTPレスポンスヘッダーです。このヘッダーは、プリフライトリクエスト（OPTIONS）に対するレスポンスとして送信されます。

Access-Control-Allow-Headersヘッダーの構文を以下に示します。

Access-Control-Allow-Headers: <header1>, <header2>, ...

Access-Control-Allow-Headersヘッダーの具体例を以下に示します。

HTTPリクエスト例

クライアントがContent-TypeとAuthorizationを使用できるか確認するために、OPTIONSリクエストを送信した場合、HTTPリクエストは以下のようになります。

OPTIONS /api/resource HTTP/1.1
Host: example.com
Origin: https://client.example
Access-Control-Request-Headers: Content-Type, Authorization

HTTPレスポンス例

サーバーがContent-TypeとAuthorizationの使用を許可している場合のHTTPレスポンスは以下のようになります。

HTTP/1.1 204 No Content
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Origin: https://client.example

Access-Control-Max-Age

Access-Control-Max-AgeヘッダーはCORS（Cross-Origin Resource Sharing）において、プリフライトリクエスト（OPTIONS）の結果をキャッシュできる時間（秒）を指定するHTTPレスポンスヘッダーです。このヘッダーを設定すると、一定時間の間、クライアントは同じプリフライトリクエストを再送しなくて済みます。結果として、サーバーの負荷軽減やレスポンス速度の向上に役立ちます。

Access-Control-Max-Ageヘッダーの構文を以下に示します。

Access-Control-Max-Age: <seconds>

Access-Control-Max-Ageヘッダーの具体例を以下に示します。

HTTPリクエスト例

クライアントがPOSTメソッドを使いたい場合において、事前にサーバーに許可を求めるHTTPリクエストは以下のようになります。

OPTIONS /api/resource HTTP/1.1
Host: example.com
Origin: https://client.example
Access-Control-Request-Method: POST

HTTPレスポンス例

サーバーがPOSTを許可し、プリフライトリクエストの結果を3600秒（1時間）キャッシュする場合のHTTPレスポンスは以下のようになります。

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://client.example
Access-Control-Allow-Methods: POST
Access-Control-Max-Age: 3600

Access-Control-Expose-Headers

Access-Control-Expose-HeadersヘッダーはCORS（Cross-Origin Resource Sharing）において、ブラウザがアクセス可能なレスポンスヘッダーを指定するHTTPレスポンスヘッダーです。

通常、CORS環境では、ブラウザがアクセスできるレスポンスヘッダーはデフォルトで制限されており、Content-TypeやCache-Controlなど一部のヘッダーしかアクセスできません。しかし、このヘッダーを使用すると、サーバーは追加のヘッダーをクライアントに公開でき、ブラウザはX-Custom-Headerのようなカスタムヘッダーもアクセス可能になります。

Access-Control-Expose-Headersヘッダーの構文を以下に示します。

Access-Control-Expose-Headers: <header1>, <header2>, ...

Access-Control-Expose-Headersヘッダーの具体例を以下に示します。

HTTPリクエスト例

以下のHTTPリクエストを送信したとします。

GET /api/data HTTP/1.1
Host: example.com
Origin: https://client.example

HTTPレスポンス例

以下のHTTPレスポンスでは、サーバーがX-Custom-HeaderをHTTPレスポンスヘッダーとして返し、Access-Control-Expose-Headers: X-Custom-Headerでブラウザがその値にアクセスできるようにしています。

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://client.example
Access-Control-Expose-Headers: X-Custom-Header
X-Custom-Header: 12345

Accept-Ranges

Accept-Rangesヘッダーは、HTTPレスポンスにおいて、サーバーがRangeリクエスト（部分取得リクエスト）に対応しているかどうかを通知するHTTPヘッダーです。

Accept-Rangesヘッダーの構文を以下に示します。

Accept-Ranges: bytes or none

Accept-Rangesヘッダーの具体例を以下に示します。

HTTPリクエスト例

以下のHTTPリクエストでは、クライアントは、Rangeヘッダーを用いて、リソースの一部（100-200バイト）を要求しています。

GET /example-resource HTTP/1.1
Host: example.com
Range: bytes=100-200

HTTPレスポンス例

サーバーがRangeリクエスト（部分取得リクエスト）をサポートしている場合のHTTPレスポンスは以下のようになります。

HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Range: bytes 100-200/1000
Content-Length: 101
Content-Type: application/octet-stream

[100-200 バイト目のデータ]

Age

Ageヘッダーは、HTTPレスポンスにおいて、プロキシサーバーやCDNなどのキャッシュサーバーが、コンテンツをキャッシュしてからどれくらいの時間が経過したかをクライアントに通知するために使用されるHTTPヘッダーです。この情報を基に、クライアントはキャッシュが古くなっていないかを判断できます。

Ageヘッダーの構文を以下に示します。

Age: <seconds>

Ageヘッダーの具体例を以下に示します。

HTTPリクエスト例

以下のHTTPリクエストでは、クライアントがサーバーからindex.htmlを取得しています。

GET /index.html HTTP/1.1
Host: example.com

HTTPレスポンス例

HTTPレスポンスは以下のようになります。Age: 120でキャッシュされてから120秒（2分）経過していることが分かります。

HTTP/1.1 200 OK
Cache-Control: max-age=3600
Age: 120
Content-Type: text/html

ETag

ETag（エンティティタグ）は、HTTPレスポンスにおいて、リソースを識別するための一意な識別子です。HTTPレスポンスにETagヘッダーを含めることで、クライアントにEtagを渡します。主にキャッシュの管理や条件付きリクエストに使用され、リソースの変更を効率的に検出できます。

ETagの役割を以下に示します。

• キャッシュの最適化
  • クライアントは、サーバーから取得したリソースのETagを保存し、再取得時にIf-None-Matchを送信することで、リソースが変更されていない場合は再ダウンロードを回避できる。
• リソースの整合性チェック
  • If-MatchやIf-Rangeを使用して、データの変更がないことを確認しながらリクエストを行う。
• コンテンツのバージョン管理
  • ETagの値は、コンテンツのハッシュ値やバージョン番号などが使われ、リソースの変更を特定できる。

ETagヘッダーの構文を以下に示します。

ETag: "値"

ETagヘッダーの具体例を以下に示します。

1. 最初のHTTPリクエスト

以下のHTTPリクエストを送信したとします。

GET /index.html HTTP/1.1
Host: example.com

2. HTTPレスポンス

HTTPレスポンスは以下のようになります。ETag: "abc123"でクライアントにEtagを渡しています。

HTTP/1.1 200 OK
ETag: "abc123"
Cache-Control: max-age=3600
Content-Type: text/html

<!DOCTYPE html>
<html>
<head><title>Test Page</title></head>
<body><h1>Hello, World!</h1></body>
</html>

3. 次回のHTTPリクエスト

If-None-MatchにETagを指定し、サーバーに「このリソースは変わったか？」と確認しています。

GET /index.html HTTP/1.1
Host: example.com
If-None-Match: "abc123"

Location

Locationヘッダーは、HTTPレスポンスにおいて、リダイレクト先のURLを指定するために使用するHTTPヘッダーです。クライアントはこのURLへ自動的にリクエストを送信し、ユーザーを適切なページへ遷移させます。

Locationヘッダーの構文を以下に示します。

Location: <URL>

Locationヘッダーの具体例を以下に示します。

HTTPリクエスト例

以下のHTTPリクエストを送信したとします。以下の例では、クライアントがold-pageにアクセスしています。

GET /old-page HTTP/1.1
Host: example.com

HTTPレスポンス例

HTTPレスポンスは以下のようになります。以下の例では、サーバーがnew-pageへリダイレクトしています。

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page
Content-Length: 0

クライアントはhttps://example.com/new-pageへリクエストを送り直しています。301 Moved Permanentlyを指定すると、ブラウザはキャッシュし、次回からnew-pageに直接アクセスするようになります。

302 Foundを指定した場合、一時的なリダイレクトとなり、次回以降もold-pageにアクセス可能になります。

HTTP/1.1 302 Found
Location: https://example.com/new-page
Content-Length: 0

Proxy-Authenticate

Proxy-Authenticateヘッダーは、HTTPレスポンスにおいて、プロキシサーバーがクライアントに認証情報の入力を要求するためのHTTPヘッダーです。これはWWW-Authenticateヘッダーのプロキシ版であり、プロキシサーバーが認証を要求する際に使用します。

Proxy-Authenticateヘッダーの構文を以下に示します。

Proxy-Authenticate: <認証方式> realm="<認証領域>"

Proxy-Authenticateヘッダーの具体例を以下に示します。

HTTPリクエスト例

以下のHTTPリクエストを送信したとします。

GET /resource HTTP/1.1
Host: example.com

HTTPレスポンス例

認証が必要な場合、HTTPレスポンスは以下のようになります。

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Secure Proxy"
Content-Length: 0

407 Proxy Authentication Requiredはクライアントは認証情報を送る必要があることを示しています。Proxy-Authenticate: Basic realm="Secure Proxy"は認証方式はBasic、プロキシの認証領域は"Secure Proxy"であることを示しています。

その後、クライアントは以下のようなProxy-Authorizationヘッダーを含むHTTPリクエストを送ることで、プロキシへの認証情報を提供する必要があります。

GET http://example.com/ HTTP/1.1
Host: example.com
Proxy-Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Retry-After

Retry-Afterヘッダーは、HTTPレスポンスにおいて、サーバーが一時的にリクエストを処理できない場合に、クライアントが再試行するべきタイミングを通知するHTTPヘッダーです。主に503 Service Unavailableや429 Too Many Requestsのレスポンスと一緒に送信されます。

Retry-Afterヘッダーの構文を以下に示します。

Retry-After: <秒数>
または
Retry-After: <日時（HTTP日付フォーマット）>

Retry-Afterヘッダーの具体例を以下に示します。

HTTPリクエスト例

以下のHTTPリクエストを送信したとします。

GET /api HTTP/1.1
Host: example.com

HTTPレスポンス例

サーバーが一時的に負荷が高いため、120秒後に再試行するように通知した場合、HTTPレスポンスは以下のようになります。

HTTP/1.1 503 Service Unavailable
Retry-After: 120
Content-Type: text/plain

Service is temporarily unavailable. Please retry after 120 seconds.

メンテナンスが終わる時間を具体的な日時（GMT）で通知した場合、HTTPレスポンスは以下のようになります。

HTTP/1.1 503 Service Unavailable
Retry-After: Wed, 21 Oct 2025 07:28:00 GMT
Content-Type: text/plain

The service is down for maintenance. Please retry after the specified time.

Referrer-Policy

Referrer-Policyヘッダーは、HTTPレスポンスにおいて、ブラウザがRefererヘッダーをリクエストに含める際の情報量を制御するためのHTTPヘッダーです。プライバシー保護やセキュリティ強化のために使用されます。

Referrer-Policyヘッダーの構文を以下に示します。

Referrer-Policy: <ポリシー>

Referrer-Policyヘッダーの具体例を以下に示します。

HTTPリクエスト例

ユーザーがhttps://example.comのページにあるリンクをクリックしてhttps://destination.com/pageに移動した場合には、以下のようなHTTPリクエストになります。

GET /page HTTP/1.1
Host: destination.com
Referer: https://example.com

Refererヘッダーが送信されていますが、この送信内容はReferrer-Policyヘッダーによって変更されます。例えば、サーバーが以下のようなHTTPレスポンスを送信していた場合には、Refererヘッダーは送信されなくなります。

HTTP/1.1 200 OK
Referrer-Policy: no-referrer
Content-Type: text/html

Server

Serverヘッダーは、HTTPレスポンスにおいて、サーバーソフトウェアの情報（名称やバージョン）を示すためのHTTPヘッダーです。主にサーバーの種類（Apache, Nginx, IIS など）やバージョン情報を提供します。

Serverヘッダーの構文を以下に示します。

Server: <サーバーソフトウェア情報>

Serverヘッダーの具体例を以下に示します。

HTTPリクエスト例

クライアントがexample.comにアクセスしたとします。

GET / HTTP/1.1
Host: example.com

HTTPレスポンス例

サーバーがServerヘッダーを含むレスポンスを返します。サーバーがApache/2.4.41 (Ubuntu)で動作していることが分かります。

HTTP/1.1 200 OK
Server: Apache/2.4.41 (Ubuntu)
Content-Type: text/html

<!DOCTYPE html>
<html>
<head><title>Example</title></head>
<body><h1>Hello, World!</h1></body>
</html>

Set-Cookie

Set-Cookieヘッダーは、HTTPレスポンスにおいて、ウェブサーバーがクライアント（ブラウザ）に対してCookieを設定するためのHTTPヘッダーです。クッキーを使用することで、ユーザーのセッション情報や設定を保存し、ウェブサイトが利用者の状態を追跡・管理できます。

Set-Cookieヘッダーの構文を以下に示します。

Set-Cookie: <クッキー名>=<値>; <オプション>

Set-Cookieヘッダーの具体例を以下に示します。

HTTPリクエスト例

クライアントがexample.comにアクセスしたとします。

GET / HTTP/1.1
Host: example.com

HTTPレスポンス例

以下のHTTPレスポンスでは、サーバーがクッキーを設定しています。

HTTP/1.1 200 OK
Set-Cookie: sessionId=abc123; Path=/
Content-Type: text/html

<!DOCTYPE html>
<html>
<head><title>Example</title></head>
<body><h1>Welcome!</h1></body>
</html>

次回のHTTPリクエストではクライアントは保存したクッキーを送信します。その結果、サーバーはクッキー情報を受け取り、セッションを認識できます。

GET / HTTP/1.1
Host: example.com
Cookie: sessionId=abc123

Strict-Transport-Security(HSTS)

Strict-Transport-Securityヘッダーは、HTTPレスポンスにおいて、Webサイトへの接続を強制的にHTTPSへリダイレクトし、以降のそのドメインへのアクセスをHTTPSのみに制限するHTTPヘッダーです。仕様はRFC 6797で規定されており、中間者攻撃（MITM攻撃）を防ぐ目的で使用されます。

Strict-Transport-Securityヘッダーの構文を以下に示します。

Strict-Transport-Security: max-age=<秒数>
Strict-Transport-Security: max-age=<秒数>; includeSubDomains
Strict-Transport-Security: max-age=<秒数>; includeSubDomains; preload

Strict-Transport-Securityヘッダーの具体例を以下に示します。

HTTPリクエスト例

クライアントがexample.comにアクセスしたとします。

GET / HTTP/1.1
Host: example.com

HTTPレスポンス例

以下のHTTPレスポンスでは、サーバーがHSTSを有効化し、以降HTTPSのみを強制しています。

HTTP/1.1 301 Moved Permanently
Location: https://example.com/
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Vary

Varyヘッダーは、HTTPレスポンスにおいて、キャッシュのバリエーションを指定し、サーバーが異なるリクエストヘッダーの値に応じて異なるレスポンスを返す場合に使用されるHTTPヘッダーです。

Varyヘッダーの構文を以下に示します。

Vary: *
Vary: <ヘッダ名>, <ヘッダ名>, …

Varyヘッダーの具体例を以下に示します。

HTTPリクエスト例

クライアントがexample.comにアクセスし、日本語(ja)のコンテンツを要求したとします。

GET / HTTP/1.1
Host: example.com
Accept-Language: ja

HTTPレスポンス例

以下のHTTPレスポンスでは、サーバーがVary: Accept-Languageを設定し、言語ごとに異なるレスポンスをキャッシュ可能にしています。

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Vary: Accept-Language

<!DOCTYPE html>
<html>
<head><title>ようこそ</title></head>
<body><h1>こんにちは！</h1></body>
</html>

WWW-Authenticate

WWW-Authenticateヘッダーは、HTTPレスポンスにおいて、HTTPサーバーがクライアントに対して認証を要求する際に使用されるHTTPヘッダーです。このヘッダーを受け取ったクライアントは、認証情報をAuthorizationヘッダーに含めて再リクエストする必要があります。

WWW-Authenticateヘッダーの構文を以下に示します。

WWW-Authenticate: <認証方式> realm="<認証領域>"

WWW-Authenticateヘッダーの具体例を以下に示します。

HTTPリクエスト例

クライアントが認証が必要なページにアクセスしたとします。

GET /protected-resource HTTP/1.1
Host: example.com

HTTPレスポンス例

以下のHTTPレスポンスでは、サーバーが認証を要求しています。

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Secure Area"
Content-Length: 0

401 Unauthorizedは認証が必要であることを示しています。WWW-Authenticate: Basic realm="Secure Area"はBasic認証を要求し、"Secure Area"という領域の認証が必要であることを示しています。

HTTPリクエスト例

クライアントはAuthorizationヘッダーを追加して再リクエストします。

GET /protected-resource HTTP/1.1
Host: example.com
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

dXNlcm5hbWU6cGFzc3dvcmQ=はusername:passwordをBase64エンコードした値です。

Entity Header（エンティティヘッダー）の一覧

Allow

Allowヘッダーは、HTTPレスポンスにおいて、指定したURIで使用可能なHTTPメソッドをリスト化し、クライアントに通知するためのHTTPヘッダーです。主に405 Method Not Allowedのレスポンスとともに使用され、どのメソッドが許可されているかを明示します。

Allowヘッダーの構文を以下に示します。

Allow: <メソッド1>, <メソッド2>, …

Allowヘッダーの具体例を以下に示します。

HTTPリクエスト例

クライアントがDELETEメソッドでHTTPリクエストを送信したとします。

DELETE /resource HTTP/1.1
Host: example.com

HTTPレスポンス例

サーバーがDELETEを許可していない場合、405 Method Not Allowedを返し、使用可能なメソッドをAllowヘッダーで通知します。

HTTP/1.1 405 Method Not Allowed
Allow: GET, POST, HEAD
Content-Length: 0

405 Method Not Allowedはクライアントが送ったメソッド(DELETE)が許可されていないことを示しています。Allow: GET, POST, HEADで許可されているメソッドを通知しています。

Content-Encoding

Content-Encodingヘッダーは、HTTPレスポンスにおいて、ボディがどのエンコーディング方式（圧縮方式）でエンコードされているかを示すHTTPヘッダーです。クライアントはこのヘッダーを見て、データを適切にデコード（展開）します。

Content-Encodingヘッダーの構文を以下に示します。

Content-Encoding: <エンコーディング方式>

Content-Encodingヘッダーの具体例を以下に示します。

HTTPリクエスト例

クライアントがexample.comにリソースをリクエストしています。その際、クライアントはAccept-Encodingヘッダーで、gzip、deflate、brいずれかの圧縮方式を受け入れ可能であることをサーバーに通知しています。

GET /resource HTTP/1.1
Host: example.com
Accept-Encoding: gzip, deflate, br

HTTPレスポンス例

以下のHTTPレスポンスでは、サーバーはgzip圧縮されたレスポンスを返しています。

HTTP/1.1 200 OK
Content-Encoding: gzip
Content-Type: text/html
Content-Length: 1024

[圧縮されたHTMLデータ]

Content-Encoding: gzipはボディがgzipで圧縮されていることを示しています。クライアントはこれを解凍して元のHTMLデータに戻します。

Content-Language

Content-Languageヘッダーは、HTTPレスポンスにおいて、ボディ（コンテンツ）が使用している言語を指定するためのHTTPヘッダーです。主に、多言語対応のWebサイトで、サーバーがどの言語のコンテンツを返したかをクライアントに通知するために使われます。

Content-Languageヘッダーの構文を以下に示します。

Content-Language: <言語コード>

Content-Languageヘッダーの具体例を以下に示します。

HTTPリクエスト例

クライアントがexample.comにHTTPリクエストしたとします。

GET / HTTP/1.1
Host: example.com

HTTPレスポンス例

サーバーが日本語のコンテンツを返す場合には、以下のようなHTTPレスポンスになります。

HTTP/1.1 200 OK
Content-Language: ja
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html>
<html>
<head><title>こんにちは</title></head>
<body><h1>ようこそ！</h1></body>
</html>

クライアントはContent-Language: jaを見て、このページが日本語であると判断できます。

Content-Length

Content-Lengthヘッダーは、HTTPメッセージのボディのサイズ（バイト単位）を指定するHTTPヘッダーです。サーバーやクライアントは、このヘッダーを使ってボディのデータがどれくらいの長さなのかを把握し、適切に処理します。

Content-Lengthヘッダーの構文を以下に示します。

Content-Length: <バイト数>

Content-Lengthヘッダーの具体例を以下に示します。

HTTPリクエスト例

クライアントがPOSTリクエストでデータを送信する際にContent-Lengthヘッダーを用いることができます。

POST /submit HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 27

{"name": "Alice", "age": 25}

Content-Length: 27はボディの長さが27バイトであることを示しており、サーバーはこのヘッダーを見て、受信するデータサイズを確認することができます。

HTTPレスポンス例

サーバーが1,234バイトのHTMLを返す場合のHTTPレスポンスを以下に示します。

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234

<!DOCTYPE html>
<html>
<head><title>Example</title></head>
<body><h1>Welcome!</h1></body>
</html>

Content-Length: 1234はレスポンスのボディが1,234バイトであることを示しており、クライアントはこれを見て、データが完全に受信されたかを判断することができます。

Content-Location

Content-Locationヘッダーは、HTTPレスポンスにおいて、リソース（コンテンツ）の固有の位置（URI）を示すためのHTTPヘッダーです。これは、クライアントに対して「このレスポンスがどのURIに対応するのか」を明確にするために使用されます。

Content-Locationヘッダーの構文を以下に示します。

Content-Location: <URI>

Content-Locationヘッダーの具体例を以下に示します。

HTTPリクエスト例

以下のHTTPリクエストでは、クライアントは/latest-reportというエンドポイントにアクセスしています。

GET /latest-report HTTP/1.1
Host: example.com

HTTPレスポンス例

以下のHTTPレスポンスでは、サーバーは/latest-reportというエンドポイントが/reports/2025-01.pdfという具体的なリソースに対応していることを示しています。

HTTP/1.1 200 OK
Content-Location: /reports/2025-01.pdf
Content-Type: application/pdf

[PDFデータ]

Content-Range

Content-Rangeヘッダーは、HTTPレスポンスにおいて、レスポンスのボディがリソースの一部である場合に、その範囲（バイト範囲）を示すHTTPヘッダーです。主に部分配信（Rangeリクエスト）に使用され、動画ストリーミングや大きなファイルの分割ダウンロードなどで役立ちます。

Content-Rangeヘッダーの構文を以下に示します。

リソースのサイズが分かる場合
Content-Range: bytes <開始位置>-<終了位置>/<全体のサイズ>

リソースのサイズが不明な場合
Content-Range: bytes <開始位置>-<終了位置>/*

Content-Rangeヘッダーの具体例を以下に示します。

HTTPリクエスト例

以下のHTTPリクエストでは、クライアントがexample.com/video.mp4の一部（1000～1999バイト）を要求しています。

GET /video.mp4 HTTP/1.1
Host: example.com
Range: bytes=1000-1999

HTTPレスポンス例

以下のHTTPレスポンスでは、サーバーが要求された部分データ（1000～1999バイト）を返しています。

HTTP/1.1 206 Partial Content
Content-Range: bytes 1000-1999/500000
Content-Length: 1000
Content-Type: video/mp4

[要求された動画データ（1000バイト）]

206 Partial Contentはリクエストされた範囲のデータを返すこと示しています。Content-Range: bytes 1000-1999/500000は全体500,000バイトのうち、1000～1999バイトのデータを返していることを示しています。Content-Length: 1000はレスポンスのデータサイズを示しています。

Content-Type

Content-Typeヘッダーは、HTTPメッセージのボディ（データ）のメディアタイプ（MIMEタイプ）を指定するHTTPヘッダーです。サーバーとクライアントの両方で使用され、リクエストボディとレスポンスボディの種類を示します。

Content-Typeヘッダーの構文を以下に示します。

Content-Type: <メディアタイプ>; <オプション>

Content-Typeヘッダーの具体例を以下に示します。

HTTPリクエスト例

以下のHTTPリクエストでは、クライアントがJSONデータをサーバーに送信しています。

POST /submit HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 32

{"name": "Alice", "age": 25}

Content-Type: application/jsonによってサーバーにJSONデータを送ることを示ています。

HTTPレスポンス例

以下のHTTPレスポンスでは、サーバーがHTMLをクライアントに返しています。

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1024

<!DOCTYPE html>
<html>
<head><title>Example</title></head>
<body><h1>Welcome!</h1></body>
</html>

Content-Type: text/html; charset=UTF-8によって、レスポンスがHTMLであり、UTF-8エンコーディングであることが分かります。

Expires

Expiresヘッダーは、HTTPレスポンスにおいて、キャッシュの有効期限を指定するHTTPヘッダーです。クライアント（ブラウザやプロキシ）は、この日時を過ぎるまでキャッシュを利用し、新しいリクエストを送らずにキャッシュを使うことができます。

Expiresヘッダーの構文を以下に示します。

Expires: <日時（GMT形式）>

Expiresヘッダーの具体例を以下に示します。

HTTPリクエスト例

以下のHTTPリクエストでは、クライアントが画像をリクエストしています。

GET /logo.png HTTP/1.1
Host: example.com

HTTPレスポンス例

以下のHTTPレスポンスでは、サーバーがExpiresヘッダーを含めて返しています。

HTTP/1.1 200 OK
Content-Type: image/png
Expires: Wed, 21 Oct 2025 07:28:00 GMT

[画像データ]

Expires: Wed, 21 Oct 2025 07:28:00 GMTによって、クライアントこの日時までキャッシュを利用することができます。

Last-Modified

Last-Modifiedヘッダーは、HTTPレスポンスにおいて、リソース（コンテンツ）の最終更新日時を通知するHTTPヘッダーです。ブラウザやプロキシは、この情報を使ってキャッシュが最新かどうかを判断し、不要なリクエストを減らします。

Last-Modifiedヘッダーの構文を以下に示します。

Last-Modified: <日時（GMT形式）>

Last-Modifiedヘッダーの具体例を以下に示します。

HTTPリクエスト例

以下のHTTPリクエストでは、クライアントがindex.htmlをリクエストしています。

GET /index.html HTTP/1.1
Host: example.com

HTTPレスポンス例

以下のHTTPレスポンスでは、サーバーがLast-Modifiedを含めてレスポンスしています。

HTTP/1.1 200 OK
Content-Type: text/html
Last-Modified: Wed, 21 Oct 2025 07:28:00 GMT

<!DOCTYPE html>
<html>
<head><title>Example</title></head>
<body><h1>Welcome!</h1></body>
</html>

Last-Modified: Wed, 21 Oct 2025 07:28:00 GMTによって、このページは2025年10月21日 07:28:00 GMTに更新されたことが分かります。