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、参数）依然照常运行。