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

以前は「エンティティヘッダー（Entity Header）」というカテゴリがあり、これはエンティティ（リクエストやレスポンスのメッセージボディに関する情報）を示すヘッダーでした。しかし、現在のHTTP/1.1の仕様では「エンティティ」や「エンティティヘッダー」という用語は使われなくなり、一部のヘッダーは「表現ヘッダー（Representation Header）」という新しいカテゴリに分類されています。

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

HTTPヘッダー説明
Cache-ControlHTTP/1.1でブラウザやプロキシがコンテンツをどのようにキャッシュするかを制御するヘッダー
ConnectionTCPコネクションを切断するか維持するかを指定するヘッダー
DateHTTPメッセージが作成または送信された日時を示すヘッダー
PragmaHTTP/1.0でキャッシュ制御を行うためのヘッダー
Trailerチャンク転送エンコーディング使用時に追加のヘッダーを指定するためのヘッダー
Transfer-EncodingHTTPメッセージボディのエンコード方式（圧縮や分割など）を指定するためのヘッダー
UpgradeHTTP接続をWebSocketやHTTP/2、HTTP/3などにアップグレードするためのヘッダー
ViaHTTPメッセージが経由したプロキシやゲートウェイの情報を記録するためのヘッダー
WarningHTTPレスポンスに追加情報や警告を提供し、キャッシュの問題などを示すためのヘッダー

Cache-Control

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

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

Cache-Controlヘッダーの構文

Cache-Control: <ディレクティブ>
  • <ディレクティブ>
    • キャッシュのルールを指定するオプション（例: no-cache, no-store, public, max-age=3600 など）を指定します。
    • no-cache
      • キャッシュを保存できるが、キャッシュを再利用する際には、再利用前にそのキャッシュが有効であることをオリジンサーバーで確認する。
    • no-store
      • コンテンツを一切キャッシュに保存しない。機密情報に適しています。
    • public
      • どのキャッシュ（ブラウザ、CDN、プロキシ）でも保存可能。
    • max-age=<秒数>
      • キャッシュの有効期間を指定（例: max-age=3600 は1時間）。
  • 複数のオプションをカンマ ,で区切って指定可能
    • 例; Cache-Control: public, max-age=86400

Connection

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

Connectionヘッダーの値

Connectionヘッダーに指定可能な値には、keep-aliveとcloseがあります。

  • keep-alive
    • 現在の通信を送信した後もTCPコネクションを維持し、後続の通信でも再利用します。
  • close
    • 応答送信後にTCPコネクションを切断します。

以下にConnectionヘッダ－の具体例を示しています。

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ヘッダーの値

Pragmaヘッダーに指定可能な値には、no-cacheがあります。

  • no-cache
    • Cache-Control: no-cacheと同じです。

以下に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ヘッダーの値

Transfer-Encodingヘッダーに指定可能な値には、chunkedやgzipやidentityなどがあります。

  • chunked
    • データを「チャンク（塊）」に分割して送信する。
  • gzip
    • データをgzip形式に圧縮して送信する。
    • 圧縮方式の指定については、現在はContent-Encodingヘッダーで指定するのが一般的です。
  • identity
    • エンコードを行わず、元のデータをそのまま送信します。これがデフォルトです。

以下にTransfer-Encodingヘッダ－の使用例を示しています。

Transfer-Encoding: chunked

Transfer-Encodingヘッダーが指定されていない場合、HTTPメッセージボディは「そのまま送信される」のがデフォルトです。この場合、ボディのサイズをContent-Lengthヘッダーで明示する必要があります。

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ヘッダーの構文

Via: <received-protocol> <received-by> [<comment>]
  • received-protocol
    • 経由したプロキシやゲートウェイが使用したプロトコル。
    • 通常、HTTPバージョンが指定されます（例えば、 経由ノードがHTTP/1.1を使用していた場合には、1.1となります）。
  • received-by
    • 経由したノードのホスト名またはIPアドレス。
  • 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ヘッダーの構文を以下に示します。

Viaヘッダーの構文

Warning: <コード番号> <エージェント> "<警告テキスト>" [<日付>]
  • コード番号
    • 警告の種類を示す3桁のコード。
    • 110：レスポンスが「古い」（過去のデータを提供）。
    • 113：キャッシュが期限切れ（過去に保存されたデータ）。
  • エージェント
    • 警告を生成したサーバーやプロキシの情報（例: ホスト名）。
  • 警告テキスト
    • 警告メッセージ。
  • 日付（任意）
    • 警告が生成された日時。

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

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

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

HTTPヘッダー説明
Access-Control-Request-MethodsCORSのプリフライトリクエストで、使用予定のHTTPメソッドをサーバーへ通知するヘッダー
Access-Control-Request-HeadersCORSのプリフライトリクエストで、送信予定のカスタムヘッダーをサーバーへ通知するヘッダー
Acceptクライアントが受け入れ可能なMIMEタイプをサーバーに通知するヘッダー
Accept-Charsetクライアントが受け入れ可能な文字エンコーディングをサーバーに通知するヘッダー
Accept-Encodingクライアントが受け入れ可能なコンテンツエンコーディング形式を通知するヘッダー
Accept-Languageクライアントが受け入れ可能な言語（自然言語）をサーバーに通知するヘッダー
Authorizationサーバーに対して認証情報を提供するヘッダー
Cookieクライアントに保存されたCookie情報をサーバーに送信するヘッダー
Expectリクエストボディ送信前にサーバーの受け入れ可否を確認するヘッダー
Fromクライアントのメールアドレスを示すヘッダー
Hostリクエスト先のサーバーのホスト名とポート番号を指定するヘッダー
If-Modified-Since指定日時以降にリソースが変更されていれば取得するようサーバーに指示するヘッダー
If-Matchリソースが特定のETag値と一致する場合のみリソースへの処理（削除など）を許可するヘッダー
If-None-Matchリソースが特定のETag値と異なる場合のみリソースへの処理（取得など）を許可するヘッダー
If-Rangeリソースが変更されていなければ範囲リクエストを許可し、変更があれば全体を取得するヘッダー
If-Unmodified-Since指定日時以降にリソースが変更されていない場合のみリクエストを実行するヘッダー
Max-Forwardsリクエストが経由できるプロキシやゲートウェイの最大数を制限するヘッダー
Originリクエストの送信元を示し、CORSの判定に使用されるヘッダー
Proxy-Authorizationプロキシサーバーを通じたリクエストの際に認証情報を提供するためのヘッダー
Rangeリソースの一部（特定範囲）を取得するためのヘッダー
Refererリクエストが発生した元のページのURLを示すヘッダー
Upgrade-Insecure-RequestsHTTPからHTTPSへのアップグレードを希望することをサーバーに通知するヘッダー
TEクライアントが受け入れ可能な転送エンコーディングの形式を指定するヘッダー
User-Agentクライアントの情報（ブラウザ、OS等）をサーバーに通知するヘッダー
X-Forwarded-Hostプロキシ経由時にクライアントの送信元ホスト名をWebサーバーに伝えるヘッダー
X-Forwarded-Forプロキシ経由時にクライアントの送信元IPアドレスをWebサーバーに伝えるヘッダー

Access-Control-Request-Methods

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

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

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-Methodはリクエストヘッダーであり、クライアントがサーバーに通知するためのものです。サーバーが許可するメソッドはAccess-Control-Allow-Methodsレスポンスヘッダーで応答します。

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）からのリクエストを許可。

Access-Control-Request-Headersはリクエストヘッダーであり、クライアントがサーバーに通知するためのものです。サーバーが許可するヘッダーはAccess-Control-Allow-Headersレスポンスヘッダーで応答します。

Accept

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

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

Acceptヘッダーの構文

Accept: <メディアタイプ>[;q=<品質値>], ...
  • <メディアタイプ>
    • 受け入れ可能なメディアタイプ（例: application/json, text/html）。
  • q=<品質値>（任意）
    • 優先度を示す値（1.0が最も高い、デフォルトは1.0）。

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ヘッダーが指定されていない場合、通常はデフォルトの形式（例: text/html）でレスポンスを返します。

Accept-Charset

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

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

Accept-Charsetヘッダーの構文

Accept-Charset: <文字セット>[;q=<品質値>], ...
  • <文字セット>
    • クライアントが受け入れる文字エンコーディング（例: UTF-8, ISO-8859-1）。
  • q=<品質値>（任意）
    • 優先度を示す値（1.0が最も高い、デフォルトは1.0）。

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（次点）、その他すべての文字セット（最低優先度）の順番で受け入れる。

現代のWeb環境では、ほとんどのクライアントとサーバーがデフォルトでUTF-8を使用するため、このヘッダーが指定されることは少なくなっています。

Accept-Encoding

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

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

Accept-Encodingヘッダーの構文

Accept-Encoding: <エンコーディング形式>[;q=<品質値>], ...
  • <エンコーディング形式>
    • クライアントが受け入れるエンコーディングの形式（例: gzip, br）。
  • q=<品質値>（任意）
    • 優先度を示す値（1.0が最も高い、デフォルトは1.0）。

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-Encodingヘッダーが指定されない場合、サーバーは通常、データを圧縮せずに送信します。また、サーバーが指定された形式をサポートしていない場合、圧縮されないレスポンスを返します。

Accept-Language

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

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

Accept-Languageヘッダーの構文

Accept-Language: <言語コード>[;q=<品質値>], ...
  • <言語コード>
    • 言語コード（例: en, ja, fr）。必要に応じて地域コード（例: en-US, en-GB）を含めることも可能です。
  • q=<品質値>（任意）
    • 優先度を示す値（1.0が最も高い、デフォルトは1.0）。

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, Bearer）。
  • <認証情報>
    • 認証スキームに基づく認証データ（例: エンコードされた文字列やトークン）

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ヘッダーの構文

Cookie: <キー1>=<値1>; <キー2>=<値2>; ...
  • <キー>
    • Cookie名。
  • <値>
    • Cookieに保存された値。

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

単一のCookieを送信

Cookie: sessionId=abc123

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

複数のCookieを送信

Cookie: sessionId=abc123; userPref=darkMode

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

Expect

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

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

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

補足

  • 多くのクライアント（例: ブラウザ）はExpectヘッダーを明示的に指定しませんが、一部のライブラリやツールでは大きなデータを送信する際に自動的に付加されます。
  • サーバーがExpect: 100-Continueをサポートしていない場合、417 Expectation Failedを返します。

From

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

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

Fromヘッダーの構文

From: <メールアドレス>

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

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

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

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

補足

  • メールアドレスは個人情報に該当するため、Fromヘッダーを使用する際は注意が必要です。自動化されたシステムやボットでのみ利用するのが一般的です。

Host

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

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

Hostヘッダーの構文

Host: <ホスト名>[:<ポート番号>]
  • <ホスト名>
    • リクエストの宛先となるサーバーのホスト名（例: example.com）。
  • <ポート番号>（任意）
    • 必要に応じて指定するポート番号（例: :443）。

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

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

Host: example.com

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

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

Host: example.com:8080

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

補足

  • HTTP/1.1では、すべてのリクエストにおいてHostヘッダーが必須です。これがない場合、サーバーはリクエストを拒否するか、エラーを返す可能性があります。
  • サーバーが複数のドメインをホストしている場合、Hostヘッダーを基に適切なリソースを識別します。
  • HTTP/2ではHostヘッダーは非推奨であり、代わりに:authorityヘッダーが使用されます。

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: <日時>
  • <日時>
    • クライアントが持つキャッシュの最終取得日時（Dateヘッダーと同じ形式）。

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ヘッダーの構文

If-Match: <ETag値>[, <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-Matchヘッダーの使用手順

  • リソースの取得
    • クライアントは、GETリクエストを送信してリソースを取得します。
    • サーバーはレスポンスにETagを含めます。
  • 条件付きリクエストの送信
    • クライアントは、受け取ったETagをIf-Matchヘッダーに設定し、条件付きのPUTまたはDELETEリクエストを送信します。
  • サーバーの処理
    • サーバーはリソースのETagとIf-Matchの値を比較します。
    • 一致する場合: リクエストを処理します。
    • 一致しない場合: リクエストを拒否し、412 Precondition Failedを返します。

If-None-Match

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

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

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

If-None-Matchヘッダーの構文

If-None-Match: <ETag値>[, <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-Matchヘッダーの使用手順

  • リソースの取得
    • クライアントは、GETリクエストを送信してリソースを取得します。
    • サーバーはレスポンスにETagを含めます。
  • 条件付きリクエストの送信
    • クライアントは、受け取ったETagをIf-None-Matchヘッダーに設定し、サーバーにリクエストを送信します。
  • サーバーの処理
    • サーバーはリソースのETagとIf-None-Matchの値を比較します。
    • 一致する場合: 304 Not Modifiedやエラーを返します。
    • 一致しない場合: リソースを返します。

If-Range

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

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

If-Rangeヘッダーの構文

If-Range: <ETag> または <最終更新日時>
  • ETag
    • リソースのバージョンを識別する識別子（例: "123456789abcdef"）。
  • 最終更新日時
    • リソースの最終更新日時を示す値（例: Wed, 26 Jan 2025 09:00:00 GMT）。

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-Matchヘッダーの使用手順

  • リソースの取得
    • クライアントは、GETリクエストを送信してリソースを取得します。
    • サーバーはレスポンスにETagまたはLast-Modifiedを含めます。
  • 条件付きリクエストの送信
    • クライアントはIf-RangeヘッダーとRangeヘッダーを設定してリクエストを送信します。
  • サーバーの処理
    • サーバーはリソースが変更されていない場合は範囲リクエストを処理し、変更されている場合はリソース全体を返します。

If-RangeヘッダーはIf-None-MatchやIf-Modified-Sinceと異なり、部分的なレスポンスをサポートするのが目的です。

If-Unmodified-Since

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

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

If-Unmodified-Sinceヘッダーの構文

If-Unmodified-Since: <日時>
  • <日時>
    • リソースの変更を判定する基準となる日時（Dateヘッダーと同じ形式）。

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

If-Matchヘッダーの使用手順

  • リソースの取得
    • クライアントはリソースを取得し、そのLast-Modified日時を保存します。
  • 条件付きリクエストの送信
    • クライアントは、リソースが変更されていないか確認するためにIf-Unmodified-Sinceヘッダーを送信します。
  • サーバーの処理
    • サーバーはリソースの更新日時とIf-Unmodified-Sinceの値を比較します。
    • 変更されていない場合 → リクエストを処理。
    • 変更されている場合 → 412 Precondition Failedを返し、リクエストを拒否。

Max-Forwards

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

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

Max-Forwardsヘッダーの構文

Max-Forwards: <数値>
  • <数値>
    • リクエストが通過できる最大プロキシ/ゲートウェイの数。0になるとサーバーがリクエストを処理し、それ以上転送されません。

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

HTTPリクエスト例

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

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

Max-Forwardsヘッダーの使用手順

  • クライアントがMax-Forwardsを設定
    • クライアントがMax-Forwardsヘッダーを設定し、リクエストを送信します。
  • プロキシまたはゲートウェイが値を減少させる
    • リクエストを転送するたびにMax-Forwardsの値を1減らします。
  • 値が0になったらサーバーが処理
    • 転送を停止し、リクエストを処理してレスポンスを返します。

Max-ForwardヘッダーはTRACEとともに使用されることがほとんどで、一般的なGETやPOSTリクエストには通常不要です。

Origin

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

オリジンとは

オリジンは、URL内の「スキーム（プロトコル） + FQDN（ホスト+ドメイン） + ポート番号」の組み合わせです（ポート番号は省略可能）。例えばこのページからHTTPリクエストした場合、オリジンは「https://it-infomation.com」となります。

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

Originヘッダーの構文

Origin: <スキーム>://<ホスト>[:<ポート>]
  • <スキーム>
    • httpまたはhttps
  • <ホスト>
    • FQDN（完全修飾ドメイン名）またはIPアドレス
  • <ポート>（省略可）
    • 標準ポート（HTTP: 80, HTTPS: 443）は省略可能

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

Originヘッダーの注意点

  • サーバー側のCORS設定が必要
    • Access-Control-Allow-Originを適切に設定しないと、ブラウザはレスポンスをブロックする。
  • 異なるオリジン間のリクエストは制限される
    • https://client.example.comからhttps://api.example.comへのリクエストは、CORSの許可がないと失敗します。

Proxy-Authorization

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

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

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

Proxy-Authorizationヘッダーの構文

Proxy-Authorization: <認証方式> <認証情報>
  • <認証方式>
    • 認証方式（例: Basic, Bearer）。
  • <認証情報>
    • 認証スキームに基づく認証データ（例: エンコードされた文字列やトークン）

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: <単位>=<開始位置>-<終了位置>
  • <単位>: bytes（バイト単位）が一般的に使用される。
  • <開始位置>: 取得したいデータの開始バイト位置（0から始まる）。
  • <終了位置>: （省略可）: 取得したいデータの終了バイト位置。

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ヘッダーの構文

Referer: <URL>
  • <URL>
    • ユーザーがリクエストを発行した元のページの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

「Referer」の綴りは正しくは「Referrer」ですが、HTTP仕様を決定する際に「Referer」と誤記され、そのまま正式な仕様として定着しました

Upgrade-Insecure-Requests

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

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

Upgrade-Insecure-Requestsヘッダーの構文

Upgrade-Insecure-Requests: 1

1の値は「HTTPSへのアップグレードを希望する」という意味です。それ以外の値は使用されません。

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ヘッダーの構文

TE: <エンコーディング方式>[;q=<品質値>], ...
  • <エンコーディング形式>
    • クライアントが受け入れ可能な Transfer-Encoding 方式（例: chunked）
  • q=<品質値>（任意）:
    • 優先度を示す値（1.0が最も高い、デフォルトは1.0）。

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!

補足

  • TEヘッダーは主にchunked転送のために使用します。
  • その他のエンコーディング（gzipやdeflateなど）はTEではなくAccept-Encodingヘッダーで指定します。

X-Forwarded-Host

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

X-Forwarded-For: <クライアントIP>[, <プロキシ1IP>, <プロキシ2IP>, ...]
  • <クライアントIP>
    • 最初のIPが元のクライアントのIP。
  • <プロキシIP>
    • 複数のプロキシを通過した場合、経由したプロキシのIPが順番に追加されます。

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（レスポンスヘッダー）の一覧

HTTPヘッダー説明
Access-Control-Allow-OriginCORSにおいて、他のオリジンからのリクエストを許可するヘッダー
Access-Control-Allow-CredentialsCORSにおいて、認証情報（クッキー等）の送信を制御するヘッダー
Access-Control-Allow-MethodsCORSにおいて、サーバーが許可するHTTPメソッドを指定するヘッダー
Access-Control-Allow-HeadersCORSにおいて、サーバーが許可するカスタムヘッダーを指定するヘッダー
Access-Control-Max-AgeCORSのプリフライトリクエストの結果をキャッシュできる時間を指定するヘッダー
Access-Control-Expose-HeadersCORSにおいて、ブラウザがアクセス可能な追加のレスポンスヘッダーを指定するヘッダー
Accept-RangesサーバーがRangeリクエスト（部分取得リクエスト）に対応しているかを通知するヘッダー
Ageキャッシュサーバーがコンテンツをキャッシュしてからの経過時間を示すヘッダー
ETagリソースの識別用の一意な識別子を示すヘッダー
Locationリダイレクト時の遷移先URLを指定するヘッダー
Proxy-Authenticateプロキシがクライアントに認証情報の入力を要求する際に使用するヘッダー
Retry-Afterサーバーが一時的に処理できない場合の再試行推奨時間を通知するヘッダー
Referrer-PolicyブラウザがRefererヘッダーをリクエストに含める際の情報量を制御するヘッダー
Serverサーバーソフトウェアの情報（名称やバージョン）を示すヘッダー
Set-CookieサーバーがクライアントにCookieを設定する際に使用するヘッダー

Access-Control-Allow-Origin

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

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

Access-Control-Allow-Originヘッダーの構文

Access-Control-Allow-Origin: <オリジン, *, またはnull>
  • オリジン
    • 指定したオリジンのみリクエストを許可する
  • *
    • 全てのオリジンからのリクエストを許可（ただし、認証情報を伴うリクエストには使用不可）
  • null
    • file://やdata://などのサンドボックス化された文書に対して、リクエストを許可する。

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ヘッダーの構文

Access-Control-Allow-Credentials: true

trueのみが有効な値です（falseや他の値は無効）。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-Credentials: trueを使用する場合、Access-Control-Allow-Originにワイルドカード（*）は設定できません。必ず特定のオリジンを指定する必要があります（例: Access-Control-Allow-Origin: https://client.example.com）。

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ヘッダーの構文

Access-Control-Allow-Methods: <method1>, <method2>, ...
  • <method1>, <method2>
    • 許可するHTTPメソッドをカンマ区切りで指定。

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ヘッダーの構文

Access-Control-Allow-Headers: <header1>, <header2>, ...
  • <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ヘッダーの構文

Access-Control-Max-Age: <seconds>
  • <seconds>
    • プリフライトリクエストのキャッシュ有効期間（秒単位）を指定します。
    • 例えば、3600（1時間）を指定すると、1時間の間、同じプリフライトリクエストを再送しなくてもよくなります。

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ヘッダーの構文

Access-Control-Expose-Headers: <header1>, <header2>, ...
  • <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ヘッダーの構文

Accept-Ranges: bytes or none
  • byte
    • サーバーがRangeリクエストをサポートしています。
  • none
    • サーバーがRangeリクエストをサポートしていません。

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 バイト目のデータ]

補足

Accept-Rangesは、サーバーがRangeリクエスト（部分取得リクエスト）をサポートしているかどうかをクライアントに通知するためのレスポンスヘッダーです。ただし、Accept-Rangesを送らなくても、サーバーが206 Partial Contentを返せば、クライアントはRangeリクエストが機能することを理解できます。仕様上は必須ではないですが、サーバーがRangeリクエストに対応していることを明示するために、Accept-Ranges: bytesを送るのが一般的です。

Age

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

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

Ageヘッダーの構文

Age: <seconds>
  • <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: "値"
  • "値"
    • サーバーが生成する一意な識別子（例: ハッシュ値やバージョン情報）。

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ヘッダーの構文

Location: <URL>
  • <URL>
    • クライアントがリダイレクトすべきURL
    • 通常は絶対URLを指定（例: https://example.com/new-page）
    • 相対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ヘッダーの構文

Proxy-Authenticate: <認証方式> realm="<認証領域>"
  • <認証方式>
    • Basic, Digest, Bearer などの認証方式を指定します。
  • realm="<認証領域>"
    • 認証が必要な範囲を示す（例: "Secure Proxy"）

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: <秒数>
または
Retry-After: <日時（HTTP日付フォーマット）>
  • <秒数>
    • 再試行までの秒数（例: Retry-After: 120 → 120秒後に再試行）
  • <日時>
    • 具体的な時刻（RFC 7231 フォーマット）（例: Retry-After: Wed, 21 Oct 2025 07:28:00 GMT）

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: <ポリシー>
  • <ポリシー>
    • リファラー情報の送信ルールを指定します。以下に一例を示します。
    • no-referrer
      • Refererを一切送信しない
    • strict-origin-when-cross-origin
      • 同一オリジンならフルURL、異なるオリジンならドメインのみ。HTTPS→HTTPのダウングレード時はRefererを送信しない。
  • <日時>
    • 具体的な時刻（RFC 7231 フォーマット）（例: Retry-After: Wed, 21 Oct 2025 07:28:00 GMT）

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: <サーバーソフトウェア情報>
  • <サーバーソフトウェア情報>
    • サーバーの名称やバージョンを記述します。
    • 例
      • Server: Apache/2.4.41 (Ubuntu)
      • Server: nginx/1.18.0

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>

補足

Serverヘッダーが有効だと、攻撃者にサーバー情報が知られる可能性があります。古いバージョンのサーバーを使っていると、既知の脆弱性を狙われるリスクがあります。そのため、不要なら削除または簡略化（例: Server: Apacheのみ）するのが推奨されています。

Set-Cookie

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

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

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ヘッダーの構文

Strict-Transport-Security: max-age=<秒数>
Strict-Transport-Security: max-age=<秒数>; includeSubDomains
Strict-Transport-Security: max-age=<秒数>; includeSubDomains; preload
  • max-age=<秒数>
    • HTTPS接続を強要する時間（秒）（必須）
  • includeSubDomains
    • サブドメインにも適用する（任意）
  • preload
    • HSTS 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: <ヘッダ名>, <ヘッダ名>, …
  • Vary: *
    • すべてのヘッダーに応じてレスポンスが変わる（キャッシュ不可）
  • Vary: Accept-Language
    • 言語設定によってレスポンスを分ける
  • Vary: User-Agent, Accept-Encoding
    • 複数のヘッダーに応じてキャッシュを分ける

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>

補足

例えば、ユーザAは、Accept-Languageヘッダーの値を「ja」（日本語）に設定し、ユーザBは「en」（英語）に設定したとします。この場合、ユーザAは日本語のページを、ユーザBは英語のページを要求することになります。同じURLであっても、言語設定によって異なる内容のページが提供されます。このような状況では、キャッシュが適切に動作するようにするためにVaryヘッダーが必要です。サーバーがレスポンスにVary: Accept-Languageを含めることで、キャッシュはAccept-Languageの値に応じて異なるページを保存し、適切な言語のページを提供できるようになります。

WWW-Authenticate

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

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

WWW-Authenticateヘッダーの構文

WWW-Authenticate: <認証方式> realm="<認証領域>"
  • <認証方式>
    • Basic, Digest, Bearer などの認証方式を指定
  • 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（エンティティヘッダー）の一覧

HTTPヘッダー説明
Allow指定URIで使用可能なHTTPメソッドをリスト化し、クライアントに通知するレスポンスヘッダー
Content-Encodingレスポンスボディがどのエンコーディング方式（圧縮方式）でエンコードされているかを示すヘッダー
Content-Languageレスポンスボディが使用する言語を指定し、多言語対応サイトで使用されるヘッダー
Content-Lengthレスポンスボディのサイズ（バイト単位）を示し、適切な処理を可能にするヘッダー
Content-Locationレスポンスが対応するリソースのURIを示し、コンテンツの位置を明確にするヘッダー
Content-Rangeレスポンスボディがリソースの一部である場合に、その範囲（バイト範囲）を示すヘッダー
Content-Typeレスポンスボディのメディアタイプ（MIMEタイプ）を指定するヘッダー
Expiresキャッシュの有効期限を指定し、クライアントがキャッシュを利用するか判断するヘッダー
Last-Modifiedリソースの最終更新日時を通知し、キャッシュの最新性を判断するためのヘッダー

Allow

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

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

Allowヘッダーの構文

Allow: <メソッド1>, <メソッド2>, …
  • <メソッド>
    • 許可されるHTTPメソッドをカンマ区切りで記述します。

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: <エンコーディング方式>
  • <エンコーディング方式>
    • gzip → Gzip圧縮。最も一般的な圧縮方式です。
    • compress → Unix
    • compress コマンドの圧縮（ほぼ使用されない）
    • deflate → Zlib圧縮
    • br → Brotli 圧縮（HTTP/2以降で推奨）
    • identity → 何もエンコードされていない（デフォルト）
  • 複数のエンコーディングが適用される場合、カンマ , で区切ります。
    • 例：Content-Encoding: gzip, identity

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: <言語コード>
  • <言語コード>
    • ISO 639-1 言語コード（例: ja, en, fr, de）
  • 複数の言語を指定可能
    • 英語とフランス語の両方で書かれているコンテンツの場合
      • Content-Language: en, frのようにカンマ区切りで記述します。

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-Languageの用途

  • Webサイトが多言語対応している場合、正しい言語情報を提供できる。
  • 検索エンジンが適切な言語を認識し、検索結果の言語を最適化できる。
  • 音声読み上げなどで、正しい言語として認識される。

Content-Length

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

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

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ヘッダーの構文

Content-Location: <URI>
  • <URI>
    • レスポンスが対応するリソースの場所（絶対URIまたは相対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ヘッダーの構文

リソースのサイズが分かる場合
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: <メディアタイプ>; <オプション>
  • <メディアタイプ>
    • text/html, application/json, image/pngなど
  • <オプション>（任意）
    • charset=UTF-8 などの追加情報

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エンコーディングであることが分かります。

よく使われるContent-Typeの例

  • text/html：HTMLドキュメント
  • text/plain：プレーンテキスト
  • application/json：JSONデータ
  • application/xml：XMLデータ
  • image/png：PNG画像
  • image/jpeg：JPEG画像
  • multipart/form-data：ファイルアップロード用（フォームデータ）
  • application/octet-stream：バイナリデータ（汎用）

Expires

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

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

Expiresヘッダーの構文

Expires: <日時（GMT形式）>
  • <日時>
    • RFC 1123 フォーマット（例: Wed, 21 Oct 2025 07:28:00 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ヘッダーの構文

Last-Modified: <日時（GMT形式）>
  • <日時>
    • RFC 1123 フォーマット（例: Wed, 21 Oct 2025 07:28:00 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に更新されたことが分かります。