HTTP 头格式化

功能

• 请求头与响应头都认，`curl -I` 的输出直接可用
• 同名多行各自保留，不合并（`Set-Cookie` 常常有十几行）
• 续行接到上一行并折叠成一个空格
• `Content-Length` 换算成可读体积，`Content-Type` 的 charset 拆出来
• 状态行的状态码单独抽出，方便对照状态码表
• 检查响应里缺失的三个安全头，并说明各自漏掉的后果
• 全部在本机解析，粘进来的头不会离开这台设备

使用方法

1. 把 HTTP 头原文粘贴到左侧（`curl -I https://…` 的输出即可）
2. 按需关掉安全头检查
3. 结果立刻出现，每一行都能单独复制
4. 想细看某个 cookie 的话，把 `Set-Cookie` 那几行拿去「Cookie 格式化」

常见问题

为什么有两行一样的头名？是解析错了吗？

不是，那是正确的。HTTP 允许同一个头出现多次，而 `Set-Cookie` 是最常见的例子 —— 一个响应里十几行 `Set-Cookie` 是家常便饭，每一行描述一个独立的 cookie。 ⚠️ 这里刻意不把它们合并成一行。技术上「多个值用逗号连接」是 HTTP 允许的写法，但 `Set-Cookie` 恰恰是个例外：它的值里本来就可能有逗号（`Expires=Wed, 21 Oct 2015 07:28:00 GMT`），连起来之后谁也没法再拆开。结果是「解析看着成功了，cookie 却少了一个」。

「续行」是什么？

一种老写法：一个长头的值折成多行，后续行以空格或 tab 开头表示它是上一行的延续。 ``` X-Custom: part one part two ``` 上面这两行是一个头，值是 `part one part two`。RFC 7230 已经废弃了这个写法（因为它容易和正文混淆、也很难正确解析），但抓包工具与一些老网关的输出里仍能见到，所以这里照常处理并在旁边标出来。

检查出来的「缺少的安全头」必须补上吗？

看情况，但三个都值得认真对待。`X-Content-Type-Options: nosniff` 几乎没有代价，任何站点都该有 —— 少了它，浏览器可能把用户上传的文件当成脚本执行。`Strict-Transport-Security` 只对 HTTPS 站点有意义，注意它一旦下发就很难撤回（浏览器会记住 `max-age`），先给一个短的值试。`Content-Security-Policy` 价值最高但也最容易配错，一上来就用严格策略极可能直接白屏，建议先用 `Content-Security-Policy-Report-Only` 跑一段时间收集违规报告再切换。 另外：这三个头只对响应有意义，所以粘请求头时不会检查。