Loading article…
HTTP ヘッダー フィールドは、 HTTP 要求と応答ごとにクライアント プログラムとサーバーの両方で送受信される文字列のリストです。これらのヘッダーは通常、エンド ユーザーには表示されず、サーバーとクライアント アプリケーションによってのみ処理またはログに記録されます。接続を通じて送受信される情報のエンコード方法 ( Content-Encodingなど)、クライアントのセッション検証と識別 (ブラウザー クッキー、IP アドレス、ユーザー エージェントなど) またはその匿名性 (VPN またはプロキシ マスキング、ユーザー エージェント スプーフィング)、サーバーによるデータの処理方法 ( Do-Not-Trackなど)、ダウンロードされるドキュメントの経過時間 (共有キャッシュに存在していた時間) などを定義します。
一般的な形式
HTTP バージョン 1.x では、ヘッダー フィールドは、メッセージの最初の行であるリクエスト行 (リクエスト HTTP メッセージの場合) またはレスポンス行 (レスポンス HTTP メッセージの場合) の後に送信されます。ヘッダー フィールドは、クリア テキスト文字列形式のコロンで区切られたキーと値のペアで、キャリッジ リターン(CR) とライン フィード(LF) の文字シーケンスで終了します。ヘッダー セクションの終了は空のフィールド行で示され、2 つの連続した CR-LF ペアが送信されます。以前は、長い行を複数の行に折り返すことができました。継続行は、次の行の最初の文字としてスペース (SP) または水平タブ (HT) が存在することで示されました。この折り返しは、RFC 7230 で非推奨になりました。[1]
HTTP/2 [2]とHTTP/3では、代わりにバイナリプロトコルが使用され、ヘッダーはHPACK [3]HEADERS (HTTP/2) または QPACK (HTTP/3) を使用して 1 つ以上のフレームにエンコードされ、効率的なヘッダー圧縮が提供されます。HTTP/1 のリクエストまたはレスポンス行も、コロン ( ) で始まるいくつかの疑似ヘッダーフィールドに置き換えられました。
CONTINUATION:
フィールド名
コアフィールドセットは、インターネット技術タスクフォース(IETF) によってRFC 9110 および 9111で標準化されています 。フィールド名、ヘッダーフィールド、暫定登録のリポジトリは、IANAによって管理されています。追加のフィールド名と許容値は、各アプリケーションによって定義される場合があります。
ヘッダーフィールド名は大文字と小文字を区別しません。[4]これは、大文字と小文字を区別するHTTPメソッド名（GET、POSTなど）とは対照的です。[5]
HTTP/2 では、特定のヘッダー フィールドにいくつかの制限が設けられています (以下を参照)。
非標準のヘッダーフィールドは、従来、フィールド名の前に を付けてマークされていましたX-が、非標準のフィールドが標準になったときに不便が生じるため、この慣例は 2012 年 6 月に廃止されました。[6]の使用に関する以前の制限Downgraded-は 2013 年 3 月に解除されました。[7]
フィールド値
いくつかのフィールドにはコメントを含めることができます（User-Agent、Server、Viaフィールドなど）。ソフトウェアによって無視される可能性があります。[8]
多くのフィールド値には、等号で区切られた品質（q）キーと値のペアが含まれており、コンテンツネゴシエーションで使用する重みを指定します。[9]たとえば、ブラウザは、次のように のq値をの値よりも高く設定することで、ドイツ語または英語の情報を受け付け、ドイツ語を優先することを示すことができます。
deen
Accept-Language: de; q=1.0, en; q=0.5
サイズ制限
この標準では、各ヘッダーフィールドの名前や値のサイズ、フィールドの数に制限はありません。ただし、ほとんどのサーバー、クライアント、プロキシソフトウェアでは、実用上およびセキュリティ上の理由から、何らかの制限が課されています。たとえば、Apache 2.3 サーバーでは、デフォルトで各フィールドのサイズが 8,190 バイトに制限されており、1 つのリクエストに含まれるヘッダーフィールドは最大 100 個です。[10]
リクエストフィールド
標準リクエストフィールド
一般的な非標準リクエストフィールド
回答フィールド
標準応答フィールド
一般的な非標準応答フィールド
選択したフィールドの効果
キャッシュの回避
Web サーバーが で応答した場合、Cache-Control: no-cacheWeb ブラウザーまたはその他のキャッシュ システム(中間プロキシ) は、最初に発信元サーバーに確認せずに、後続の要求を満たすために応答を使用してはなりません (このプロセスは検証と呼ばれます)。このヘッダー フィールドは HTTP バージョン 1.1 の一部であり、一部のキャッシュおよびブラウザーでは無視されます。HTTPExpiresバージョン 1.0 のヘッダー フィールド値を応答時間よりも前の時間に設定することで、これをシミュレートできます。no-cache は、ブラウザーまたはプロキシにコンテンツをキャッシュするかどうかを指示するものではないことに注意してください。ブラウザーおよびプロキシに、キャッシュ コンテンツを使用する前にサーバーで検証するように指示するだけです (これは、上記の If-Modified-Since、If-Unmodified-Since、If-Match、If-None-Match 属性を使用して行われます)。したがって、no-cache 値を送信すると、ブラウザーまたはプロキシに、キャッシュ コンテンツの「鮮度基準」のみに基づいてキャッシュ コンテンツを使用しないように指示します。古いコンテンツが検証なしでユーザーに表示されないようにするもう 1 つの一般的な方法は ですCache-Control: max-age=0。これは、コンテンツが古く、使用前に検証する必要があることをユーザー エージェントに指示します。
ヘッダー フィールドはCache-Control: no-store、ブラウザ アプリケーションに、ディスクに書き込まないように (つまり、キャッシュしないように) 最善を尽くすように指示することを目的としています。
リソースをキャッシュしないという要求は、それがディスクに書き込まれないことを保証するものではありません。特に、HTTP/1.1 の定義では、履歴ストアとキャッシュが区別されています。ユーザーが前のページに戻ると、ブラウザにはディスク上の履歴ストアに保存されているページが表示されることがあります。これは仕様に従った正しい動作です。多くのユーザー エージェントは、プロトコルが HTTP か HTTPS かによって、履歴ストアまたはキャッシュからページを読み込む際の動作が異なります。
HTTP Cache-Control: no-cache/1.1 ヘッダーフィールドも、クライアントからのリクエストで使用することを目的としています。これは、ブラウザがサーバーと中間キャッシュにリソースの最新バージョンが必要であることを伝える手段です。HTTP Pragma: no-cache/1.0 仕様で定義されているヘッダーフィールドも同じ目的を持っています。ただし、これはリクエストヘッダーに対してのみ定義されています。レスポンスヘッダーでの意味は指定されていません。[77]レスポンスでのの動作Pragma: no-cacheは実装固有です。一部のユーザーエージェントはレスポンスでこのフィールドに注意を払いますが、[78] HTTP/1.1 RFC では、この動作に依存しないように特に警告しています。
参照
参考文献
- ^ 「フィールド解析」。ハイパーテキスト転送プロトコル (HTTP/1.1): メッセージ構文とルーティング。2014 年 6 月。3.2.4 節。doi : 10.17487 / RFC7230。RFC 7230 。
- ^ HTTP/2. 2022年6月. doi : 10.17487/RFC9113 . RFC 9113.
- ^ Peon, R.; Ruellan, H. (2015 年 5 月). 「HPACK: HTTP/2 のヘッダー圧縮」. IETF . doi :10.17487/RFC7541 . 2021 年12 月 13 日閲覧。
{{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です - ^ 「フィールド名」。HTTPセマンティクス。2022年6月。sec. 5.1。doi : 10.17487/ RFC9110。RFC 9110 。
- ^ 「メソッド: 概要」。HTTP セマンティクス。2022 年 6 月。9.1 節。doi : 10.17487 / RFC9110。RFC 9110 。
- ^ Internet Engineering Task Force (2012 年 6 月 1 日). 「RFC 6648」. doi :10.17487/RFC6648 . 2012 年11 月 12 日閲覧。
{{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です - ^ 「メッセージ ヘッダー」。Iana.org。2014 年 6 月 11 日。2014年6 月 12 日閲覧。
- ^ 「コメント」。HTTPセマンティクス。2022年6月。sec. 5.6.5。doi : 10.17487/ RFC9110。RFC 9110 。
- ^ 「 品質値」。HTTPセマンティクス。2022年6月。sec. 12.4.2。doi : 10.17487/ RFC9110。RFC 9110 。
- ^ 「core - Apache HTTP Server」。Httpd.apache.org。2012年5月9日時点のオリジナルよりアーカイブ。2012年3月13日閲覧。
- ^ abc RFC 3229. doi : 10.17487/RFC3229 .
- ^ abc 「Cross-Origin Resource Sharing」。2017年7月24日閲覧。
- ^ ab "接続ヘッダー". HTTPセマンティクス. 2022年6月. sec. 7.6.1. doi : 10.17487/RFC9110 . RFC 9110.
- ^ abcdefgh 「接続固有のヘッダーフィールド」。HTTP / 2。2022年6月。sec. 8.2.2。doi : 10.17487/ RFC9113。RFC 9113 。
- ^ ab 「RFC 2616 からの変更点」。ハイパーテキスト転送プロトコル (HTTP/1.1): セマンティクスとコンテンツ。2014 年 6 月。sec. B。doi : 10.17487 / RFC7231。RFC 7231 。
- ^ Petersson, A.; Nilsson, M. (2014 年 6 月). 「Forwarded HTTP Extension: Introduction」. IETF . doi :10.17487/RFC7239 . 2016 年1 月 7 日閲覧。
{{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です - ^ 「Host and :authority」。HTTPセマンティクス。2022年6月。7.2節。doi : 10.17487 / RFC9110。RFC 9110 。
- ^ 「リクエスト疑似ヘッダーフィールド」。HTTP/2。2022年6月。8.3.1節。doi : 10.17487 / RFC9113。RFC 9113 。
- ^ 「メッセージ ヘッダー」www.iana.org . 2018 年11 月 26 日閲覧。
- ^ 「 HTTP2 -Settings ヘッダーフィールド」。ハイパーテキスト転送プロトコル バージョン 2 (HTTP/2)。sec. 3.2.1。doi : 10.17487/ RFC7540。RFC 7540 。
- ^ ab 「警告ヘッダー」。HTTPキャッシュ。2022年6月。sec.5.5。doi ：10.17487 / RFC9111。RFC 9111 。
- ^ 「安全でないアップグレード要求 - W3C 候補勧告」W3C 2015 年 10 月 8 日。 2016 年1 月 14 日閲覧。
- ^ 「「X-Requested-With」ヘッダー – Stoutner」。2022年10月31日。
- ^ 「「Do Not Track」HTTP ヘッダーを試してみる」。2011年1 月 31 日閲覧。
- ^ 「Web トラッキング保護: 最低基準と革新の機会」 。2011年3 月 24 日閲覧。
- ^ IETF Do Not Track: ユニバーサルなサードパーティ Web トラッキング オプトアウト 2011 年 3 月 7 日
- ^ W3C トラッキング プリファレンス エクスプレッション (DNT)、2012 年 1 月 26 日
- ^ Amos Jeffries (2010 年 7 月 2 日)。「SquidFaq/ConfiguringSquid - Squid Web Proxy Wiki」 。2009年9 月 10 日閲覧。
- ^ Apache Software Foundation. 「mod_proxy - Apache HTTP Server バージョン 2.2」 。2014年11 月 12 日閲覧。
- ^ Dave Steinberg (2007 年 4 月 10 日)。「GeekISP のロードバランサーで動作するように SSL サイトを調整するにはどうすればいいですか?」。2010 年9 月 30 日閲覧。
- ^ 「Helping to Secure Communication: Client to Front-End Server」 2006 年 7 月 27 日。 2012 年4 月 23 日閲覧。
- ^ 「OpenSocial Core API Server仕様2.5.1」。2014年10月8日閲覧。
- ^ 「ATT デバイス ID」。2012 年 2 月 16 日時点のオリジナルよりアーカイブ。2012 年1 月 14 日閲覧。
- ^ 「WAP プロファイル」。2012年1月14日閲覧。
- ^ de Boyne Pollard, Jonathan (2007). 「Proxy-Connection: ヘッダーは、一部の Web ブラウザーの HTTP 使用方法における誤りです」。2016 年 10 月 23 日時点のオリジナルよりアーカイブ。2018 年1 月 16 日閲覧。
- ^ 「Verizon が永久 Cookie を挿入してモバイル顧客を追跡、プライバシー制御を回避」。電子フロンティア財団。2014年1 月 19 日閲覧。
- ^ 「既知の AT&T、Verizon、Sprint、Bell Canada、Vodacom の固有識別子ビーコンの確認」 。2014年1 月 19 日閲覧。
- ^ クレイグ・ティンバーグ。「Verizon、AT&Tが『スーパークッキー』でユーザーを追跡」ワシントンポスト。 2014年1月19日閲覧。
- ^ 「SAP クロスサイトリクエストフォージェリ保護」。SAP SE。2015年1 月 20 日閲覧。
- ^ 「Django のクロスサイトリクエストフォージェリ保護」。Django (ウェブフレームワーク)。2015年1月20日時点のオリジナルよりアーカイブ。2015年1月20日閲覧。
- ^ 「Angular クロスサイトリクエストフォージェリ (XSRF) 保護」。AngularJS。2015年1月 20 日閲覧。
- ^ 「HTTP リクエスト ID」。devcenter.heroku.com。2022年3 月 22 日閲覧。
- ^ 「相関IDの価値」Rapid7 ブログ2016年12月23日2018年4月13日閲覧。
- ^ Hilton, Peter (2017 年 7 月 12 日)。「マイクロサービス アーキテクチャの相関 ID - Peter Hilton」。hilton.org.uk。2018年4月 13 日閲覧。
- ^ 「W3C Trace Context」. w3c.org . 2024年6月19日閲覧。
- ^ 「Save Data API Living Document ドラフト コミュニティ グループ レポート 2.1.1. Save-Data リクエスト ヘッダー フィールド」。Web Platform Incubator コミュニティ グループ。2020 年 6 月 30 日。2021年3 月 5 日閲覧。
- ^ MDN寄稿者 (2023年3月3日). 「Sec-GPC」. MDN Web Docs . 2023年3月12日閲覧。
- ^ Dusseault, L.; Snell, J. (2010). 「RFC 5789」. doi :10.17487/RFC5789. S2CID 42062521 . 2014年12月24日閲覧。
{{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です - ^ Nottingham, M.; McManus, P.; Reschke, J. (2016 年 4 月). 「HTTP Alternative Services」. IETF. doi : 10.17487/RFC7838 . 2016 年4 月 19 日閲覧。
{{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です - ^ Nottingham, M.; McManus, P.; Reschke, J. (2016 年 4 月). 「HTTP 代替サービス、セクション 3」. IETF. doi : 10.17487/RFC7838 . 2017 年6 月 8 日閲覧。
{{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です - ^ レシュケ、J. (2011)。 「RFC 6266」。土井: 10.17487/RFC6266 。2015 年3 月 13 日に取得。
{{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です - ^ 「 Content-Language」。HTTPセマンティクス。2022年6月。sec.8.5。doi : 10.17487/ RFC9110。RFC 9110 。
- ^ Link rel="canonical" HTTP ヘッダーで応答して URL の正規バージョンを示します。取得日: 2012-02-09
- ^ W3C P3P 作業が中断
- ^ 「HTTP の公開鍵ピンニング拡張機能」。IETF。2015年4 月 17 日閲覧。
- ^ 「 Retry-After」。HTTPセマンティクス。2022年6月。sec. 10.2.3。doi : 10.17487/ RFC9110。RFC 9110 。
- ^ Ross, D.; Gondrom, T. (2013). 「HTTP ヘッダーフィールド X-Frame-Options」. IETF. doi : 10.17487/RFC7034 . 2014年6月12日閲覧。
{{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です - ^ 「コンテンツ セキュリティ ポリシー レベル 2」。2014年8 月 2 日閲覧。
- ^ 「コンテンツセキュリティポリシー」。W3C。2012年。 2017年4月28日閲覧。
- ^ 「Expect-CT」。Mozilla Developer Network 。 2021年7月23日閲覧。
- ^ “NEL”. Mozilla Developer Network . 2021年. 2021年5月18日閲覧。
- ^ 「Permissions Policy」. W3C. 2020 . 2021年5月1日閲覧。
- ^ 「Am I FLoCed?」 EFF. 2021 . 2021年5月1日閲覧。
- ^ 「AnnevkによるHTTP Refreshヘッダーの定義 · Pull Request #2892 · whatwg/html」。GitHub。2017年8月9日。 2021年4月17日閲覧。
- ^ 「CSP: report-to」。Mozilla Developer Network。2021年。 2021年5月18日閲覧。
- ^ RFC 9110: HTTPセマンティクス
- ^ 「Timing-Allow-Origin」。Mozilla Developer Network 。 2018年1月25日閲覧。
- ^ 「Ogg メディア用のサーバーの構成」。2014 年 5 月 26 日。2015年1 月 3 日閲覧。
- ^ 「期間追跡をクリーンアップし、スレッド間アクセスにミラーリングを使用する」。Bugzilla @Mozilla 。 2024年2月9日閲覧。
- ^ Eric Lawrence (2008 年 9 月 3 日)。「IE8 セキュリティ パート VI: ベータ 2 アップデート」。2010 年9 月 28 日閲覧。
- ^ 「ホスティング - Google Chrome 拡張機能 - Google Code」 。2012年6 月 14 日閲覧。
- ^ van Kesteren, Anne (2016年8月26日). 「Fetch standard」. WHATWG . 2016年8月26日時点のオリジナルよりアーカイブ。 2016年8月26日閲覧。
- ^ 「X-Redirect-By HTTP 応答ヘッダー」。2021 年5 月 29 日閲覧。
- ^ 「ドキュメント互換性の定義: ドキュメント互換性モードの指定」。2011 年 4 月 1 日。2012 年1 月 24 日閲覧。
- ^ 「HTML Living Standard 4.2.5.3 プラグマディレクティブ、X-UA-compatible 状態」。WHATWG。2021年 3 月 12 日。2021年3 月 14 日閲覧。X
-UA-compatible 状態の http-equiv 属性を持つ meta 要素の場合、content 属性には、文字列 と大文字と小文字を区別せずに一致する ASCII 文字列の値を指定する必要があります
。
"IE=edge" - ^ Eric Lawrence (2008 年 7 月 2 日)。「IE8 セキュリティ パート IV: XSS フィルター」。2010 年9 月 30 日閲覧。
- ^ 「 Pragme」。HTTP キャッシュ。2022 年 6 月。sec. 5.4。doi : 10.17487/ RFC9111。RFC 9111 。
- ^ 「Internet Explorer でキャッシュを防止する方法」。Microsoft 2011年 9 月 22 日。2015 年4 月 15 日閲覧。
この編集時点で、この記事はStack Exchange の Stefan Kögl が執筆した「X-REQUEST-ID http ヘッダーとは何ですか?」のコンテンツを使用しています。これはCreative Commons Attribution-ShareAlike 3.0 Unported Licenseの下で再利用を許可するライセンスですが、GFDLの下では許可されません。関連するすべての条件に従う必要があります。
- ^ ab 「X-REQUEST-ID http ヘッダーとは何ですか?」 . 2022 年3 月 20 日閲覧。
この編集時点で、この記事はStack Exchange の Adrian Grigore が執筆した「ASP.NET フレームワークが応答に 'X-Powered-By:ASP.NET' HTTP ヘッダーを追加するのはなぜですか?」のコンテンツを使用しています。これはCreative Commons Attribution-ShareAlike 3.0 Unported Licenseの下で再利用を許可するライセンスですが、 GFDLの下では許可されません。関連するすべての条件に従う必要があります。
- ^ 「ASP.NET フレームワークが応答に 'X-Powered-By:ASP.NET' HTTP ヘッダーを追加するのはなぜですか? - Stack Overflow」 。2022年3 月 20 日閲覧。
外部リンク
- ヘッダー: 永続的なメッセージ ヘッダー フィールド名
- RFC 6265: IETF HTTP 状態管理メカニズム
- RFC 9110: HTTP セマンティクス
- RFC 9111: HTTP キャッシュ
- RFC 9112: HTTP/1.1
- RFC 9113: HTTP/2
- RFC 9114: HTTP/3
- RFC 7239: 転送された HTTP 拡張
- RFC 7240: HTTP の優先ヘッダー
- ウェブサーバーの観点から見た HTTP/1.1 ヘッダー
- Internet Explorer とカスタム HTTP ヘッダー - EricLaw の IEInternals - サイト ホーム - MSDN ブログ