HTTPヘッダは、HTTPリクエスト・レスポンスの本体（ボディ）とは別に、通信のメタ情報を伝えるためのキー・バリュー形式の項目群です。ホスト名・コンテンツ種類・キャッシュ可否・認証情報・圧縮方式・言語設定・Cookieなど、通信の振る舞いに影響するほぼ全ての設定がヘッダで運ばれます。HTTP/1.1（RFC 9110、2022年）では「一般ヘッダ」「リクエストヘッダ」「レスポンスヘッダ」「エンティティヘッダ」の4分類で整理され、IANAが管理する公式登録だけでも200種類以上、独自拡張を含めると無数のヘッダがWeb上で飛び交っています。Webサービスの挙動を理解・チューニング・デバッグするうえで、ヘッダ理解は避けて通れない基本知識です。
この記事の目次
- 4分類によるヘッダの整理
- RFC 822から現代仕様までの歴史
- 頻出ヘッダと主な役割
- ヘッダ vs ボディ vs URLでのデータ運び方
- まとめ
4分類によるヘッダの整理
HTTPヘッダはRFC 2616（1999年）で4分類が整理され、RFC 9110にも引き継がれています。「一般ヘッダ（General Headers）」はリクエスト・レスポンス両方に現れるもので、Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Viaなどがあります。通信の枠組みに関する情報が中心で、ボディの内容には依存しません。
「リクエストヘッダ（Request Headers）」はクライアントからサーバへの情報伝達用で、Host、User-Agent、Accept、Accept-Language、Authorization、Cookie、Refererなどが代表例です。「レスポンスヘッダ（Response Headers）」はサーバからクライアントへの状態通知用で、Server、Set-Cookie、WWW-Authenticate、Location、Retry-Afterなどが含まれます。「エンティティヘッダ（Entity Headers）」はボディに関する情報を表し、Content-Type、Content-Length、Content-Encoding、Content-Language、Last-Modified、ETagなどがあります。ボディに付随するメタ情報という性質から、リクエスト・レスポンスどちらにも出現可能です。近年はEntity Headersという用語は薄れ、Representation Headersという呼び方も増えていますが、4分類の枠組み自体は引き続き有効です。
RFC 822から現代仕様までの歴史
HTTPヘッダの「キー: 値」形式は、1982年8月のRFC 822（電子メールの仕様）に由来します。電子メールのSubject・From・Toなどのヘッダ表記をHTTPが流用した経緯があり、Webと電子メールはこの表現を共有しています。1996年5月のHTTP/1.0仕様（RFC 1945）で基本的なヘッダ群が定義され、Content-Type・Content-Length・Last-Modified・Locationなど現代に通じる中核ヘッダが揃いました。
1999年6月のRFC 2616でHTTP/1.1としてヘッダの分類と意味論が拡張され、Cache-Control・ETag・Hostなど現代Webの根幹をなすヘッダが加わりました。2014年にはRFC 7230〜7235として機能別に文書が分割され、2022年のRFC 9110で再統合される形で現代仕様になっています。HTTP/2（2015年RFC 7540、2022年RFC 9113）以降はヘッダ圧縮（HPACK/QPACK）が導入され、繰り返し送信されるヘッダの帯域消費を大幅に削減する技術的進化も進みました。プロトコルの世代が変わってもヘッダの「キー: 値」モデル自体は維持されています。
頻出ヘッダと主な役割
現代Webで毎リクエスト送られる代表的ヘッダのHostはHTTP/1.1で必須化されたもので、同一IPに複数ドメインを乗せるバーチャルホスト方式の前提となります。AuthorizationはBasic認証・Bearer Token・AWS Signature V4など、認証情報を運ぶ標準ヘッダで、APIアクセスの中心的役割を担います。Accept-EncodingでクライアントがサポートできるContent-Encoding（gzip、br、zstdなど）を伝え、サーバはこれを見て圧縮方式を選びます。
User-Agentはブラウザやアプリの自己紹介で、レンダリング分岐・解析・bot識別などに使われます。近年はプライバシー保護のためUser-Agent Reduction（Client Hintsへの移行）が進行中で、Sec-CH-UA-*系のヘッダが新たに定義されています。ロードバランサーやCDN経由のリクエストでは元IPアドレスがX-Forwarded-Forヘッダで伝搬され、サーバ側で実際のクライアントIPを把握できます。他にもRefererによる遷移元、Originによるオリジン情報、Acceptによる希望コンテンツ種別、Range/Content-Rangeによる部分取得など、多種多様なヘッダが目的別に使い分けられています。
ヘッダ vs ボディ vs URLでのデータ運び方
HTTPでデータを運ぶ場所は大きく分けて「URL（クエリ文字列）」「ヘッダ」「ボディ」の3つあり、それぞれ得手不得手があります。ヘッダはメタ情報の自然な居場所で、Webサーバ・プロキシ・CDN・ブラウザの各レイヤーが認識でき、ルーティングやキャッシュ判定、ログ集計に直接活用できます。HTTP/2以降はヘッダ自体が圧縮対象になるため、頻繁に送られる繰り返しヘッダの効率も改善しています。
ボディは大量のペイロードを運ぶ場所で、JSONやファイルアップロードなど数百KB〜数百MBクラスのデータに適しています。URLクエリ文字列は短く・人間が読みやすく・ブックマーク可能なメリットがありますが、サイズ制限（実用的に8KB前後）があり、機密情報をURLに置くとログに残るリスクもあります。ヘッダも個別の値長や合計サイズに実用上の上限があり（多くのサーバで8KB〜32KB程度がデフォルト）、巨大なクッキーや認証トークンを詰め込みすぎると431 Request Header Fields Too Largeエラーになることもあります。セキュリティ要件・サイズ・可視性を考慮して、3つの場所を適切に使い分けるのがWeb設計の基本です。
まとめ
HTTPヘッダはRFC 822起源・HTTP/1.0で整備・現在はRFC 9110（2022年）で統合された、Web通信のメタ情報を運ぶキー・バリュー形式の項目群です。一般・リクエスト・レスポンス・エンティティの4分類で整理され、Host・Cache-Control・Content-Type・Authorization・Set-Cookieなど数百種類のヘッダが目的別に使い分けられています。HTTP/2以降は圧縮も導入され、ボディやURLと住み分けながら、現代Web通信の挙動を決める核心要素として機能し続けています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント