HTTP ヘッダーパーサー

HTTP リクエストまたはレスポンス全体を貼り付けてください。curl -v が出力するブロックや、ブラウザーのネットワークパネルに表示されるものです。すると、すべてのヘッダー行がデコードされます。名前、値、それが何をするかを説明する平易な文、そしてそれを定義する文書。Set-Cookie は属性ごとに分解され（Secure、HttpOnly、SameSite、Max-Age、Expires…）、Content-Type と Accept のパラメータが展開され、ブロックは古典的な構造上の問題について監査されます。廃止された折り返し行、不正な文字、重複ヘッダー、逆方向に送られたヘッダー。すべてはブラウザー内で動作し、何もアップロードされません。
入力
自動は最初の行を見ます。リクエスト行（GET /path HTTP/1.1）ならリクエスト、ステータス行（HTTP/1.1 200 OK）ならレスポンス、それ以外は裸のヘッダーブロックとして読まれます。他の選択肢は方向を強制し、それによって適用される警告が変わります。
解析レポート
まだ解析していません。上にリクエストまたはレスポンスのブロックを貼り付けてヘッダーを解析を押すか、サンプルを押すと実例を見られます。
解析する価値のあるブロックの入手方法。ターミナルでは、curl -v https://example.com/ 2>&1 がリクエストとレスポンスを > と < のプレフィックス付きで出力します。それらを取り除いて貼り付けてください。curl -sI https://example.com/ はレスポンスヘッダーブロックだけを返します。ブラウザーでは、開発者ツールを開いてネットワークタブで再読み込みし、ドキュメントのリクエストを選んで コピー → レスポンスヘッダーをコピー を使います。リクエスト側は cURL としてコピー でフラグを読んでください。開始行のない Name: value 行の裸のブロックも解析できます。その場合、方向チェックは緩和されます。
セルフテスト
固定ブロックに対してパーサーを再実行します。方向検出、両方のサンプルプール、すべての Set-Cookie 属性規則（Secure なしの SameSite=None、数値でない Max-Age、壊れた Expires、未知の属性、= のない Cookie）、obs-fold の結合、不正なフィールド名、重複ヘッダー、方向の不一致、そして各負経路。何もどこにも送信されません。
HTTP ヘッダーとは？
一文で言うと：HTTP メッセージは、開始行、ヘッダーと呼ばれる Name: value 行のブロック、空行、そして任意の本文で構成され、ヘッダーが本文以外のすべてを運びます。誰が送ったか、何を受け付けられるか、どうキャッシュされるか、どう認証されるか、送り手が何を求めているか。
4 つのファミリー
ファミリー流れる方向例答える質問
リクエストヘッダークライアント → サーバーHost, Accept, Cookie, Referer, Authorizationクライアントが何を求め、誰を名乗っているか
レスポンスヘッダーサーバー → クライアントLocation, Server, Set-Cookie, Retry-Afterサーバーが何をしたか、見返りに何を求めるか
表現ヘッダー両方向、本文についてContent-Type, Content-Length, Content-Encoding, ETag本文がどの形式で、そのどのコピーか
制御ヘッダー両方向、接続についてCache-Control, Connection, Via, Transfer-Encodingメッセージと接続が経路上でどう扱われるか

ある種のヘッダーは頑固に一方向です。If-None-Match はリクエストでしか意味を持たず、Set-Cookie はレスポンスでしか意味を持ちません。誤った方向での解析はコピペデバッグの古典的ミスの 1 つであり、だからこのページはそれを警告します。

ヘッダー行の文法

RFC 9110 はフィールド行を field-name ":" OWS field-value OWS と定義します。トークン文字のみで作られた名前（英字、数字、!#$%&'*+-.^_`|~）、手前にスペースを置かないコロン、そして可視文字・スペース・タブからなる値です。ヘッダーの名前は大文字小文字を区別しません（content-type は Content-Type と等価）。値はほぼ常に区別されます。スペースやタブで始まる行は、かつて前のヘッダーの継続でした。2014 年に廃止された obs-fold です。展開するプロキシはヘッダーの意味を変え得るため、このパーサーは結合しつつ、その存在を警告します。

よくある間違い
  • X-Forwarded-For を信頼すること。経路上のすべてのプロキシが追記し、クライアントは最初のホップを偽装できます。それはプロキシの連鎖の主張であって、実際の接続者ではありません。ヒントとして扱い、可能なら自分が管理するプロキシに上書きさせるのが良い使い方です。
  • レスポンスヘッダーだけを読むこと。興味深いミスの半分（重複した Accept、欠けた Host、間違ったホストに向けられた認証ヘッダー）は、ブラウザーがデフォルトで隠すリクエスト側にあります。cURL としてコピーで自分のものを見てください。
  • Set-Cookie 行のマージ。重複するほとんどのヘッダーはカンマで 1 行に結合できますが、Set-Cookie はしてはいけません。値自身の中にカンマが現れるためです。ブラウザーは各行を別々の Cookie として扱います。
  • Content-Length が書いた本文のサイズだと思うこと。それは Content-Encoding 適用後のサイズで、しかもメッセージが chunked でない場合に限ります。Transfer-Encoding: chunked のレスポンスに意味のある単一の長さはありません。
  • X- プレフィックスでヘッダーを判断すること。その慣習は RFC 6648 で廃止されました。X-Forwarded-For や X-Content-Type-Options は永続的な事実上の標準であり、一方で X でないヘッダーにも実験的なものはたくさんあります。プレフィックスではなく、定義文書で判断してください。
よくある質問

ここにヘッダーを貼り付けて安全ですか？解析は完全にブラウザー内で行われ、何もアップロードされません。とはいえ、コピーしたヘッダーブロックは指紋です。Cookie、認証ヘッダー、正確な User-Agent が揃えばあなたを特定できます。同僚に見せても構わないブロックを解析してください。

ブラウザーが :status のようなヘッダーを表示するのに、このページはなぜエラーと言うのですか？あれは HTTP/2 と HTTP/3 の疑似ヘッダーです。バイナリフレーミング層が開始行と Host を疑似フィールドに置き換えます。このページは古典的な HTTP/1.1 の通信テキストを解析します。疑似ヘッダーは、プロトコルが翻訳した後の同じ情報です。

X-XSS-Protection はどうなりましたか？廃止されました。それが動かしていた監査機能自体がセキュリティバグを引き起こし、ブラウザーは削除しました。その役割は Content-Security-Policy に属します。CSP 生成で構築し、セキュリティヘッダーチェックで全体を監査してください。

Set-Cookie の属性はどうチェックされますか？RFC 6265 に照らして。名前と値は最初の = で分割され、属性は最初のセミコロンの後、Expires は Cookie 形式の日付でなければならず、Max-Age は数字、SameSite は Strict/Lax/None のいずれか。そして Secure なしの None は現行ブラウザーに拒否されるため、明示的に指摘されます。

ヘッダー行のリストだけを解析できますか？はい。ヘッダーブロックのみを選んで、開始行なしで貼り付けてください。方向チェックは緩和され、それ以外（構造、Set-Cookie、パラメータ）はすべて引き続き実行されます。