HTTP ヘッダー

HTTP ヘッダーにより、 HTTP リクエストやレスポンスでクライアントやサーバーが追加情報を渡すことができます。 HTTP ヘッダーは、大文字小文字を区別しないヘッダー名とそれに続くコロン (:)、値で構成されます。値の前にあるホワイトスペースは無視されます。

私的な独自のヘッダーは、以前は X- 接頭辞を使用していましたが、この慣習は 2012 年 6 月の RFC 6648 で非推奨になりました。これは、標準外のフィールドが標準になったときに発生する不便さのためです。それ以外のヘッダーは IANA レジストリーに収録されており、その基になったものは RFC 4229 です。また IANA は新たに提案された HTTP ヘッダーのレジストリーも管理しています。

ヘッダーは、そのコンテキストに応じて分類できます。

リクエストヘッダーは、読み込むリソースについての情報や、そのリソースをリクエストしているクライアントに関する詳細な情報を持ちます。
レスポンスヘッダーは、レスポンスに関する追加情報、例えば場所や提供しているサーバーに関する情報を保持します。
表現ヘッダーは、リソースの本体に関する情報、例えば MIME タイプや適用されるエンコード／圧縮方式などについての情報を持ちます。
ペイロードヘッダー (en-US)は、転送されるデータの表現から独立した情報、例えばコンテンツの長さや転送に使われるエンコード方式などを持ちます。

またヘッダーは、プロキシーサーバーがどのように扱うかに応じてグループ化されます。

エンドツーエンドヘッダー: これらのヘッダーは、メッセージの最終的な宛先、すなわちリクエストならばサーバー、レスポンスならばクライアントに伝送しなければなりません。中間のプロキシーはヘッダーを変更せずに再伝送しなければならず、またキャッシュには保存しなければなりません。
ホップバイホップヘッダー: これらのヘッダーは単一のトランスポート層の接続にのみ意味を持ち、プロキシーが再転送したり、キャッシュを行ったりしてはいけません。なお、 Connection ヘッダーを用いて設定する場合があるのはホップバイホップヘッダーのみです。

認証

WWW-Authenticate: リソースへアクセスに使用すべき認証方法を定義します。
Authorization: サーバーでユーザーエージェントを認証するための資格情報を持ちます。
Proxy-Authenticate: プロキシーサーバーの背後にあるリソースへアクセスできるようにするために使用すべき認証方法を定義します。
Proxy-Authorization: プロキシーサーバーでユーザーエージェントを認証するための資格情報を持ちます。

キャッシュ

Age: オブジェクトがプロキシーのキャッシュに存在する時間を秒数で表します。
Cache-Control: リクエストおよびレスポンスで、キャッシュ機能に関するディレクティブです。
Clear-Site-Data: リクエストしているウェブサイトに関連付けられた閲覧用のデータ (クッキー、ストレージ、キャッシュなど) を消去します。
Expires: レスポンスが古くなると考えられる日時を表します。
Pragma: リクエストからレスポンスへの流れの中でさまざまな影響がある、実装依存のヘッダーです。 Cache-Control ヘッダーが未実装である HTTP/1.0 キャッシュとの後方互換性のために使用します。
Warning 非推奨: 起こりうる問題に関する一般警告情報です。

クライアントヒント

HTTP のクライアントヒントとは、端末の種類やネットワークの状態など、クライアントに関する有用な情報を提供する一連のリクエストヘッダーのことで、サーバーはこれらの条件に合わせて提供するコンテンツを最適化することができます。

サーバーは、 Accept-CH を使用して、クライアントが関心を持っているクライアントヒントヘッダーを積極的に要求します。クライアントは、要求されたヘッダーを後続のリクエストに含めることがあります。

Accept-CH Experimental: サーバーはクライアントヒントに対応していることを、 Accept-CH ヘッダーフィールドまたは HTML の <meta> 要素の http-equiv 属性で同等の指定をすることで広報することができます。
Accept-CH-Lifetime Experimental 非推奨: サーバーは、指定された期間サーバーが対応する一連のクライアントヒントを記憶するようクライアントに依頼し、そのサーバーのオリジンに対するその後のリクエストでクライアントヒントを配信できるようにすることができます。
Critical-CH (en-US) Experimental: サーバーは Accept-CH と共に Critical-CH を使用し、受け入れられるクライアントヒントも重要なクライアントヒントであることを指定しています。

クライアントヒントの様々なカテゴリーを以下に示します。

ユーザーエージェントクライアントヒント

ユーザーエージェントクライアントヒントは、ユーザーエージェント、それが動作しているプラットフォーム/アーキテクチャ、ユーザーエージェントやプラットフォーム上に設定されたユーザー環境設定に関する情報を提供するリクエストヘッダーです。

Sec-CH-Prefers-Reduced-Motion (en-US) Experimental: ユーザーエージェントで動きの縮小を優先する設定。
Sec-CH-UA (en-US) Experimental: ユーザーエージェントのブランド名とバージョン。
Sec-CH-UA-Arch (en-US) Experimental: ユーザーエージェントの基盤となるプラットフォームアーキテクチャ。
Sec-CH-UA-Bitness (en-US) Experimental: ユーザーエージェントの基本的な CPU アーキテクチャのビット数（例: "64" ビット）。
Sec-CH-UA-Full-Version (en-US) 非推奨: ユーザーエージェントの意味づけされた完全なバージョン文字列。
Sec-CH-UA-Full-Version-List (en-US) Experimental: ユーザーエージェントのブランドリストにある各ブランドのフルバージョン。
Sec-CH-UA-Mobile (en-US) Experimental: ユーザーエージェントがモバイル端末で動作している、あるいは、より一般的には、「モバイル」の使い勝手を好んでいる。
Sec-CH-UA-Model (en-US) Experimental: ユーザーエージェントの端末モデル。
Sec-CH-UA-Platform (en-US) Experimental: ユーザーエージェントの基盤となっているオペレーティングシステム/プラットフォーム。
Sec-CH-UA-Platform-Version (en-US) Experimental: ユーザーエージェントの基盤となっているオペレーションシステムのバージョン。

端末クライアントヒント

Content-DPR (en-US) 非推奨 Experimental: 画像リソースを選択するために DPR クライアントヒントが使用されたリクエストで、画像デバイスとピクセルの比率を確認するために使用される レスポンスヘッダー です。
Device-Memory 非推奨 Experimental: 技術的には端末メモリー API の一部で、このヘッダーはクライアントが持つおよその RAM の量を表します。
DPR 非推奨 Experimental: クライアントの端末ピクセル比 (DPR)、すなわち CSS ピクセルあたりの物理ピクセル数を示します。
Viewport-Width (en-US) 非推奨 Experimental: 数値で、レイアウトビューポートの幅を CSS ピクセル数で示します。指定されたピクセル数は、それ以上の最小の整数に丸められます（つまり切り上げ）。
Width (en-US) 非推奨 Experimental: 数値で、要求するリソースの幅（つまり画像の内在的な寸法）を物理ピクセル数で示します。

ネットワーククライアントヒント

ネットワーククライアントヒントにより、サーバーはネットワークの帯域やレイテンシーに基づいて、どの情報を送るかを選択することができます。

Downlink (en-US): サーバーに対するクライアントのコネクションのおよその帯域を、 Mbps で表します。これは Network Information API の一部です。
ECT (en-US): 有効接続種別 (「ネットワークプロファイル」) は、そのコネクションのレイテンシーや帯域に最も近いものです。これは Network Information API の一部です。
RTT (en-US): アプリケーション層のラウンドトリップ時間 (RTT) をミリ秒で表し、これにはサーバーの処理時間も含みます。これは Network Information API の一部です。
Save-Data (en-US) Experimental: 論理型で、ユーザーエージェントのデータ利用の削減についての設定を示します。

条件付き

Last-Modified: リソースが最後に変更された日時であり、同じリソースの複数のバージョンを比較するために使用されます。 ETag より正確さは低いのですが、環境によっては計算が容易です。If-Modified-Since や If-Unmodified-Since を使用する条件付きリクエストでは、リクエストの動作を変更するためにこの値を使用します。
ETag: 一意な文字列であり、リソースのバージョンを識別します。 If-Match や If-None-Match を使用する条件付きリクエストでは、リクエストの動作を変更するためにこの値を使用します。
If-Match: リクエストを条件付きにして、保存されたリソースが指定した ETag のいずれかに一致する場合に限りメソッドを適用します。
If-None-Match: リクエストを条件付きにして、保存されたリソースが指定した ETag のいずれかに一致しない場合に限りメソッドを適用します。これはキャッシュを更新する (安全なリクエスト向け)、あるいはすでにリソースが存在する場合に新しいリソースのアップロードを止めるために使用します。
If-Modified-Since: リクエストを条件付きにして、そのリソースが指定した日時より後に変更されている場合に限り転送するようリクエストします。キャッシュが期限切れである場合に限りデータを転送するために使用します。
If-Unmodified-Since: リクエストを条件付きにして、そのリソースが指定した日時より後に変更されていない場合に限り転送するようリクエストします。これは、特定の範囲の新しい断片と古い断片の一貫性を保証する、あるいは既存の文書を変更するときに楽観的な並行性制御システムを実装するために使用します。
Vary: 新しいものを元のサーバーにリクエストするのではなく、キャッシュされたレスポンスが使用できるよう決定するために、リクエストヘッダーを一致させる方法を定めます。

接続管理

Connection: 現在の転送が完了した後も、ネットワークコネクションを維持するかを制御します。
Keep-Alive: 持続的なコネクションをどれだけの期間維持するかを制御します。

コンテンツネゴシエーション

コンテンツネゴシエーションヘッダーです。

Accept: 送り返すことができるデータの種類をサーバーに通知します。
Accept-Encoding: 送り返すリソースで使用できるエンコードアルゴリズム (一般的には圧縮アルゴリズム) をサーバーに通知します。
Accept-Language: 送り返すリソースで期待する自然言語をサーバーに通知します。これはヒントであり、必ずしもユーザーの完全な制御下にあるものではありません。サーバーはユーザーの選択 (ドロップダウンリストで選ぶ言語など) を明示的に上書きしないように、常に注意を払うべきです。

制御

Expect: リクエストを適切に扱うためにサーバーが実行しなければならないと期待されていることを示します。
Max-Forwards (en-US): TRACE を使用する場合、リクエストが送信者に反映されるまでにできる最大のホップ数を示します。

クッキー

Cookie: 過去に Set-Cookie ヘッダーでサーバーから送信されて保存している HTTP クッキーを持ちます。
Set-Cookie: サーバーからユーザーエージェントにクッキーを送信します。

CORS

CORS についての詳細は、こちらを参照してください。

Access-Control-Allow-Origin: レスポンスが共有可能かを示します。
Access-Control-Allow-Credentials: credentials フラグが真であるときに、リクエストへのレスポンスを開示してよいかを示します。
Access-Control-Allow-Headers: プリフライトリクエストへのレスポンスで使用し、実際のリクエストを行うときに使用できる HTTP ヘッダーを指定します。
Access-Control-Allow-Methods: プリフライトリクエストへのレスポンスで、リソースへアクセスするときに使用できるメソッドを指定します。
Access-Control-Expose-Headers: ヘッダー名を羅列して、レスポンスの一部として開示できるヘッダーを示します。
Access-Control-Max-Age: プリフライトリクエストの結果をキャッシュしてよい期間を示します。
Access-Control-Request-Headers: 実際のリクエストを行う際に使用する HTTP ヘッダーをサーバーがわかるようにするため、プリフライトリクエストを発信する際に使用します。
Access-Control-Request-Method: 実際のリクエストを行う際に使用する HTTP メソッドをサーバーがわかるようにするため、プリフライトリクエストを発信する際に使用します。
Origin: どこから読み込みが発生したかを示します。
Timing-Allow-Origin: Resource Timing API の機能を通じて受け取った属性の値を見ることができるオリジンを指定します。そうでなければオリジン間の制約によってゼロとして報告されます。

ダウンロード

Content-Disposition: 転送したリソースをインラインで表示すべきか (ヘッダーが存在しない場合の既定の動作)、またはダウンロードとして扱い、「名前を付けて保存」ウィンドウを表示すべきかを示します。

メッセージ本文の情報

Content-Length: リソースの大きさを、バイト単位の10進数で示します。
Content-Type: リソースのメディア種別を示します。
Content-Encoding: 圧縮アルゴリズムを指定するために使用します。
Content-Language: 読者向けに言語を示すヘッダーであり、ユーザーが自身の好む言語に応じて区別することができます。
Content-Location: 返すデータの代替データの場所を示します。

プロキシー

Forwarded: リクエストのパスにプロキシーが関与したときに変更または遺失した、プロキシーサーバーのクライアント側の情報を持ちます。
X-Forwarded-For Non-standard: HTTP プロキシーやロードバランサーを経由してウェブサーバーに接続するクライアントの、接続元 IP アドレスを識別します。
X-Forwarded-Host Non-standard: プロキシーやロードバランサーに接続するクライアントがリクエストした、オリジナルのホストを示します。
X-Forwarded-Proto Non-standard: クライアントがプロキシーやロードバランサーに接続するために使用したプロトコル (HTTP または HTTPS) を識別します。
Via: フォワードプロキシーとリバースプロキシーの両方が追加するヘッダーであり、リクエストヘッダーとレスポンスヘッダーのどちらでも見られます。

リダイレクト

Location: ページのリダイレクト先の URL を示します。
Refresh: ブラウザーにページを再読み込みするか、別のページにリダイレクトするように指示します。 http-equiv="refresh" を持つ meta 要素と同じ値をとります。

リクエストコンテキスト

From: リクエストを行うユーザーエージェントを操作している人間の、インターネット電子メールアドレスを持ちます。
Host: サーバーのドメイン名 (バーチャルホスト向け) およびサーバーが待ち受けている TCP ポート番号 (省略可能) を指定します。
Referer: 現在リクエストしているページへリンクしていた、前のウェブページのアドレスです。
Referrer-Policy: Referer ヘッダーで送信するどのリファラー情報をリクエストに含めるかを制御します。
User-Agent: リクエストを行うユーザーエージェントソフトウェアのアプリケーションタイプ、オペレーティングシステム、ベンダー、バージョンを、ネットワークプロトコルのピアが識別できるようにする文字列を持ちます。 Firefox ユーザーエージェント文字列リファレンスもご覧ください。

レスポンスコンテキスト

Allow: リソースがサポートする HTTP リクエストメソッドを示します。
Server: リクエストを扱うサーバーが使用するソフトウェアの情報を持ちます。

範囲付きリクエスト

Accept-Ranges: サーバーが範囲付きリクエストに対応するかどうか、対応していれば対応する場合は、範囲を表すことができる単位を示します。
Range: サーバーが返すべきである文書の範囲を示します。
If-Range: 指定した ETag または日時がリモートのリソースにマッチする場合に限定した、条件付き range request を生成します。異なるバージョンのリソースから 2 つの範囲をダウンロードすることを防ぎます。
Content-Range: 部分的なメッセージが、メッセージ本文全体のどこに位置するかを示します。

セキュリティ

Cross-Origin-Embedder-Policy (COEP): サーバーが指定された文書の埋め込み方針を宣言するために使います。
Cross-Origin-Opener-Policy (COOP): 他のドメインがウィンドウを開いたり制御したりすることを防ぎます。
Cross-Origin-Resource-Policy (CORP): このヘッダーが適用されたリソースのレスポンスが他のドメインから読み取られるのを防ぎます。
Content-Security-Policy (CSP): ユーザーエージェントがページで読み込むことを許可するリソースを制御します。
Content-Security-Policy-Report-Only: ウェブの開発者がポリシーの効果を適用せずに監視することで、実験を行うことができます。これらの違反レポートは、 HTTP POST リクエストによって指定した URI へ送信される JSON 文書で構成されます。
Expect-CT: サイトが証明書の透明性要件の報告や実施を選択できるようにします。これにより、そのサイトで不正な証明書の使用に気づかないことを防ぎます。サイトが Expect-CT ヘッダーを有効にした場合、そのサイトの証明書が公開CTログに表示されることを Chrome が確認するようにリクエストしています。
Origin-Isolation Experimental: ウェブアプリケーションをオリジンから独立させるための仕組みを提供します。
Permissions-Policy: 自身のフレームまたはその中に埋め込まれた <iframe> で、ブラウザーの機能を使用することを許可または拒否する仕組みを提供します。
Strict-Transport-Security (HSTS): HTTP の代わりに HTTPS による通信を強制します。
Upgrade-Insecure-Requests: 暗号化や認証されたレスポンスについて、クライアントの設定を表す信号をサーバーに送信して、upgrade-insecure-requests ディレクティブを正しく扱うことができます。
X-Content-Type-Options: ブラウザーで MIME スニッフィングを無効化して、Content-Type で指定したタイプを強制的に使用させます。
X-Download-Options: HTTP の X-Download-Options ヘッダーは、ブラウザー (Internet Explorer) がアプリケーションからのダウンロードでファイルを「開く」の選択肢を表示しないようにし、アプリケーションのコンテキストで実行するアクセス権を得ることがないようにして、ファイルとすることでフィッシング詐欺を防止します。
X-Frame-Options (XFO): ブラウザーがページを <frame>, <iframe>, <embed>, <object> の内部に表示することを許可するかを示します。
X-Permitted-Cross-Domain-Policies: クロスドメインポリシーファイル (crossdomain.xml) を許可するかどうかを指定します。このファイルは、 Adobe の Flash Player、Adobe Acrobat、Microsoft Silverlight、Apache Flex などのクライアントに、同一オリジンポリシーによって制限されているドメイン間のデータを処理する許可を与えるポリシーを定義することができます。詳細については、 Cross-domain Policy File Specification を参照してください。
X-Powered-By: ホスティング環境やその他のフレームワークによって設定される可能性があり、アプリケーションや訪問者に有益ではない情報を含みます。潜在的な脆弱性が発現することを防ぐために、このヘッダーは設定しないでください。
X-XSS-Protection: クロスサイトスクリプティングのフィルタリングを有効化します。

メタデータ読み取りリクエストヘッダー

メタデータ読み取りリクエストヘッダーは、リクエストが発生したときのコンテキストに関する情報を提供します。これによりサーバーは、リクエストがどこから来たのか、リソースがどのように使用されるのかに基づいて、リクエストを許可すべきかどうかを判断することができます。

Sec-Fetch-Site (en-US): リクエスト開始元のオリジンと宛先のオリジンとの関係を示すリクエストヘッダーです。これは構造化ヘッダーで、値はトークンであり、取りうる値は cross-site, same-origin, same-site, none です。
Sec-Fetch-Mode (en-US): サーバーへのリクエストモードを示すリクエストヘッダーです。これは構造化ヘッダーで、値はトークンであり、取りうる値は cors, navigate, nested-navigate, no-cors, same-origin, websocket です。
Sec-Fetch-User: ナビゲーションリクエストがユーザー操作によって起動されたかどうかを示すリクエストヘッダーです。これは構造化ヘッダーであり、論理値で、取りうる値は ?0 ならば偽、 ?1 ならば真です。
Sec-Fetch-Dest (en-US): リクエストの宛先を示すリクエストヘッダーです。これは構造化ヘッダーで、値はトークンであり、取りうる値は audio, audioworklet, document, embed, empty, font, image, manifest, object, paintworklet, report, script, serviceworker, sharedworker, style, track, video, worker, xslt です。
Service-Worker-Navigation-Preload (en-US): サービスワーカーの起動中に、リソースに対して fetch() で先制的なリクエストをする際に送られるリクエストヘッダーです。この値は NavigationPreloadManager.setHeaderValue() (en-US) で設定され、通常の fetch() 処理とは異なる形でリソースを返すべきことをサーバーに通知するために使用することができます。

サーバー送信イベント

Last-Event-ID: TBD
NEL Experimental: 開発者がネットワークエラー報告ポリシーを宣言できるようにする仕組みを定義します。
Ping-From: TBD
Ping-To: TBD
Report-To: 警告やエラーを送信るためのブラウザーに対するサーバーのエンドポイントを指定するために使用します。

転送エンコーディング

Transfer-Encoding: エンティティをユーザーへ問題なく転送できるエンコード形式を指定します。
TE (en-US): ユーザーエージェントが進んで受け入れる転送エンコーディングを指定します。
Trailer (en-US): 送信者が chunk メッセージの終端に追加フィールドを含めることができます。

WebSocket

Sec-WebSocket-Key: TBD
Sec-WebSocket-Extensions: TBD
Sec-WebSocket-Accept (en-US): TBD
Sec-WebSocket-Protocol: TBD
Sec-WebSocket-Version: TBD

その他

Accept-Push-Policy Experimental: クライアントはリクエストに対して求めるプッシュポリシーを、リクエスト内で Accept-Push-Policy ヘッダーフィールドを送信することで表現することができます。
Accept-Signature Experimental: クライアントは Accept-Signature ヘッダーフィールドを送信して、利用可能な署名を利用する意図を示したり、対応している署名の種類を示したりすることができます。
Alt-Svc: このサービスにたどり着く他の方法のリストに使用します。
Date: メッセージが生成された日時です。
Early-Data Experimental: このリクエストが TLS early data で送信されたことを示します。
Large-Allocation (en-US) 非推奨: 読み込み中のページは大量の割り当てが必要であることをブラウザーに伝えます。
Link: Link エンティティヘッダーフィールドは、 HTTP ヘッダー内の 1 つ以上のリンクを記述する方法を提供します。意味的には HTML の <link> 要素と等価です。
Push-Policy Experimental: Push-Policyはリクエストを処理するときのプッシュ通知に関するサーバーの動作を定義します。
Retry-After: 後続のリクエストを行う前に、ユーザーエージェントがどれだけの期間待つべきかを示します。
Signature Experimental: Signature ヘッダーフィールドは、交換のための署名のリストを伝え、それぞれはその署名の権威を決定して、そして更新する方法についての情報を伴います。
Signed-Headers Experimental: Signed-Headers ヘッダーフィールドは、シグネチャに含めるためのレスポンスヘッダーフィールドの順序付きリストを識別します。
Server-Timing: 指定されたリクエストとレスポンスのサイクルについて、１つ以上のメトリクスまたは説明を通信します。
Service-Worker-Allowed: パス制約を解除するために、サービスワーカースクリプトのレスポンスで使用します。
SourceMap: 生成されたコードとソースマップを関連付けます。
Upgrade: Upgrade ヘッダーフィールドに関連する RFC 文書は RFC 9110, section 7.8 です。標準仕様では、現在のクライアント、サーバー、トランスポート層プロトコル接続で別のプロトコルへ更新または変更するための規則を定めています。例えば、このヘッダー標準ではサーバーが Upgrade ヘッダーフィールドを認めて実装すると決める前提で、クライアントが HTTP 1.1 から WebSocket へ変更することを可能にします。どちらの相手も、 Upgrade ヘッダーフィールドで指定された要件を受け入れる必要はありません。これはクライアントのヘッダーでもサーバーのヘッダーでも使用できます。Upgrade ヘッダーフィールドを指定した場合は、更新オプションを指ヘッダーonnection ヘッダーフィールドも送信者が送信しなければなりません。Connection ヘッダーフィールドについて、詳しくは前述の RFC のセクション 7.6.1 をご覧ください。
X-DNS-Prefetch-Control: ユーザーがたどるであろうリンクや、ドキュメントが参照する画像、 CSS、 JavaScript などのリソースのドメイン名解決をブラウザーが事前に行う機能である、 DNS プリフェッチを制御します。
X-Firefox-Spdy 非推奨 Non-standard: TBD
X-Pingback Non-standard: TBD
X-Requested-With: TBD
X-Robots-Tag Non-standard: X-Robots-Tag ヘッダーは、一般の検索エンジンの結果でウェブページをどのように索引付けをするかを示します。このヘッダーは <meta name="robots" content="…"> と等価です。
X-UA-Compatible Non-standard: 使用する文書モードを示すために Internet Explorer で使用されています。

協力

新しい記事を書いたり、既存のものを改善したりすることにご協力ください。