HTTP 頭部解析器

貼上一整段 HTTP 請求或響應 —— curl -v 列印的那塊，或瀏覽器 Network 面板顯示的內容 —— 每個頭部行都會被逐條解讀：名稱、值、一句說明它作用的大白話，以及定義它的文件。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 屬性規則（SameSite=None 但缺 Secure、非數字的 Max-Age、壞掉的 Expires、未知屬性、沒有等號的 Cookie）、折行合併、非法欄位名、重複頭部、方向不匹配以及各類異常路徑。任何資料都不會被髮送。
什麼是 HTTP 頭部？
一句話：一條 HTTP 訊息由起始行、一組名為頭部的 名稱: 值 行、一個空行和可選的正文構成 —— 頭部承載了除正文本身之外關於這條訊息的一切：誰發的、能接受什麼、如何快取、如何認證，以及傳送方想要什麼回報。
四大類
類別出現在示例回答的問題
請求頭客戶端 → 伺服器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 只可能出現在響應裡。按錯誤的方向去解析是除錯時最經典的複製貼上錯誤之一，所以本頁會把它標出來。

頭部行的語法

RFC 9110 把欄位行定義為 field-name ":" OWS field-value OWS —— 名稱只能由 token 字元構成（字母、數字和 !#$%&'*+-.^_`|~），冒號前面不能有空格，值由可見字元、空格和製表符組成。頭部名稱不區分大小寫（content-type 等於 Content-Type）；值幾乎總是區分大小寫。以空格或製表符開頭的行曾經用來延續上一個頭部 —— 即 obs-fold，2014 年起已廢棄：把它展開的代理可能改變該頭部的含義，所以本頁解析器會合並它，但會警告你它存在。

常見誤區
  • 信任 X-Forwarded-For。路徑上每個代理都會追加它，而客戶端可以偽造第一跳。它告訴你的是一串代理聲稱的內容，不是實際連線者；請把它當作線索，並優先讓你自己控制的代理覆蓋它。
  • 只看響應頭。一半有趣的錯（重複的 Accept、缺失的 Host、指向錯誤主機的授權頭）都藏在請求裡，而瀏覽器預設不顯示請求。用複製為 cURL 才能看到你自己的請求。
  • 合併 Set-Cookie 行。大多數重複頭部可以用逗號合併 —— Set-Cookie 絕不能，因為逗號會出現在值本身裡。瀏覽器把每一行當作獨立的 Cookie。
  • 以為 Content-Length 就是你寫入的正文大小。它是應用 Content-Encoding 之後的大小，且僅在訊息未分塊時存在；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 怎麼了？它已廢棄：它驅動的審計器本身就製造了安全漏洞，瀏覽器已將其移除。它的職責屬於內容安全策略 —— 可在CSP 生成器上構建策略，並在安全頭部檢查器中審計整套設定。

Set-Cookie 的屬性是怎麼校驗的？依據 RFC 6265：名稱與值在第一個等號處拆分，屬性在第一個分號之後拆分，Expires 必須是 Cookie 格式的日期，Max-Age 必須是數字，SameSite 必須是 Strict/Lax/None 之一 —— 並且 None 缺 Secure 會被當前瀏覽器拒絕，所以本頁會把它標出來。

能只解析一列頭部行嗎？可以 —— 選擇僅頭部塊並在沒有起始行的情況下貼上。方向檢查會放寬；其餘（結構、Set-Cookie、引數）依然照常執行。