MDN’s new design is in Beta! A sneak peek: https://blog.mozilla.org/opendesign/mdns-new-design-beta/

HTTP ヘッダー

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

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

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

  • 一般ヘッダー: リクエストとレスポンスの両方に適用されますが、最終的にボディで転送されるデータとの関係はないヘッダーです。
  • リクエストヘッダー: 読み込むリソースやクライアント自身に関する詳細な情報を持つヘッダーです。
  • レスポンスヘッダー: レスポンスに関する追加情報 (場所など) やサーバー自身に関する追加情報 (名前やバージョンなど) を持つヘッダーです。
  • エンティティヘッダー: コンテンツの量や MIME タイプなど、エンティティのボディに関する詳細情報を持つヘッダーです。

またヘッダーは、プロキシサーバーがどのように処理するかに応じて分類されます。

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

以下の一覧は、用途で分類したHTTP ヘッダーの要約です。アルファベット順の一覧は、左側のナビゲーションにあります。

認証

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

キャッシュ

Age
オブジェクトがプロキシのキャッシュに存在する時間を秒数で表します。
Cache-Control
リクエストおよびレスポンスで、キャッシュ機能に関するディレクティブを指定します。
Expires
レスポンスが陳腐化すると考えられる日時を表します。
Pragma
リクエストからレスポンスへの流れの中でさまざまな影響がある、実装依存のヘッダーです。Cache-Control ヘッダーが未実装である HTTP/1.0 キャッシュとの後方互換性のために使用します。
Warning
起こりうる問題に関する情報を持つ、一般警告フィールドです。

Client hints

Accept-CH
...
Content-DPR
...
DPR
...
Downlink
...
Save-Data
...
Viewport-Width
...
Width
...

条件

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

接続制御

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

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

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

制御

Expect
リクエストを適切に扱うためにサーバーが実行しなければならないと期待されていることを示します。
Max-Forwards
...

Cookie

Cookie
過去に Set-Cookie ヘッダーでサーバーから送信されて保存している HTTP Cookie を持ちます。
Set-Cookie
サーバーからユーザーエージェントに Cookie を送信します。
Cookie2
過去に Set-Cookie2 ヘッダーでサーバーから送信された HTTP Cookie を持ちますが、仕様書で廃止されました。代わりに Cookie を使用してください。
Set-Cookie2
サーバーからユーザーエージェントに Cookie を送信するために使用しますが、仕様書で廃止されました。代わりに Set-Cookie を使用してください。

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
どこから読み込みが発生したかを示します。

Do Not Track

DNT
ユーザーのトラッキング設定を示すために使用します。
Tk
対応するリクエストに適用するトラッキング状態を示します。

ダウンロード

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

メッセージボディの情報

Content-Length
受信者に送信するエンティティボディのサイズを、10 進数表記のオクテット数で表します。
Content-Type
リソースのメディアタイプを示します。
Content-Encoding
圧縮アルゴリズムを指定するために使用します。
Content-Language
読者向けに言語を示すヘッダーであり、ユーザーが自身の好む言語に応じて区別することができます。
Content-Location
返すデータの代替データの場所を示します。

プロキシ

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

リダイレクト

Location
ページのリダイレクト先の URL を示します。

リクエストコンテキスト

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

レスポンスコンテキスト

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

Range requests

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

セキュリティ

Content-Security-Policy (CSP)
ユーザーエージェントがページで読み込むことを許可するリソースを制御します。
Content-Security-Policy-Report-Only
ポリシーの効果を監視する (しかし適用しない) ことで、ウェブ開発者がポリシーの実験を行うことができます。これらの違反レポートは、HTTP POST 要求によって指定した URI へ送信される JSON ドキュメントで構成されます。
Public-Key-Pins (HPKP)
偽造した証明書による MITM 攻撃の危険性を軽減するため、特定の暗号公開鍵とウェブサーバーを関連付けます。
Public-Key-Pins-Report-Only
ピンニングに違反する場合でも、ヘッダーで指定した report-uri にレポートを送信して、クライアントからサーバーへの接続は許可します。
Strict-Transport-Security (HSTS)
HTTP の代わりに HTTPS による通信を強制します。
Upgrade-Insecure-Requests
暗号化や認証されたレスポンスについて、クライアントの設定を表す信号をサーバーに送信して、upgrade-insecure-requests ディレクティブを正しく扱うことができます。
X-Content-Type-Options
ブラウザーで MIME スニッフィングを無効化して、Content-Type で指定したタイプを強制的に使用させます。
X-Frame-Options (XFO)
ブラウザーがページを <frame><iframe><object> の内部に表示することを許可するかを示します。
X-XSS-Protection
クロスサイトスクリプティングのフィルタリングを有効化します。

Server-sent events

Ping-From
...
Ping-To
...
Last-Event-ID
...

転送エンコーディング

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

WebSockets

Sec-WebSocket-Key
...
Sec-WebSocket-Extensions
...
Sec-WebSocket-Accept
...
Sec-WebSocket-Protocol
...
Sec-WebSocket-Version
...

その他

Date
メッセージを生成した日時です。
Large-Allocation
読み込み中のページは大量の割り当てが必要であることをブラウザーに伝えます。
Link
...
Retry-After
後続のリクエストを行う前に、ユーザーエージェントがどれだけの期間待つべきかを示します。
SourceMap
生成されたコードと ソースマップ を関連付けます。
Upgrade
これは Proposed Internet Standard です。Official Internet Standards や Proposed Internet Standards の包括的な一覧および詳細情報については、日々更新される Internet Standards リファレンス をごらんください。Upgrade ヘッダーフィールド標準に関連する RFC 文書は、RFC 7230 のセクション 6.7 です。標準仕様では、現在のクライアント、サーバー、トランスポート層プロトコル接続で別のプロトコルへ更新または変更するための規則を定めています。例えば、このヘッダー標準ではサーバーが Upgrade ヘッダーフィールドを認めて実装すると決める前提で、クライアントが HTTP 1.1 から HTTP 2.0 へ変更することを可能にします。どちらの相手も、Upgrade ヘッダーフィールドで指定された要件を受け入れる必要はありません。これはクライアントのヘッダーでもサーバーのヘッダーでも使用できます。Upgrade ヘッダーフィールドを指定した場合は、更新オプションを指定した Connection ヘッダーフィールドも送信者が送信しなければなりません。Connection ヘッダーフィールドについて、詳しくは 前述の RFC のセクション 6.1 をご覧ください。
Vary
提供元のサーバーからレスポンスを得るように要求せずにキャッシュ済みのレスポンスを使用できるかを判断するために、以降のリクエストヘッダーをどのように照合するかを定義します。
X-DNS-Prefetch-Control
ユーザーがたどるであろうリンクや、ドキュメントが参照する画像、CSS、JavaScript などのリソースのドメイン名解決をブラウザーが事前に行う機能である、DNS プリフェッチを制御します。
X-Requested-With
...
X-UA-Compatible
...

関連情報

ドキュメントのタグと貢献者

 このページの貢献者: yyss, hamasaki
 最終更新者: yyss,