HTTP 头去重:把一堆乱糟糟的请求头整理成干净一份

排查接口问题时,我常常要把一段 curl -v 的输出、浏览器响应面板里复制的内容、还有同事工单里贴的几行头,凑到一起看。麻烦的是这些来源各写各的:有人写 Content-Type,有人写 content-type,代理回显又多塞一行 Set-Cookie。肉眼一行行比对既慢又容易看漏。HTTP 头去重要解决的就是这件事:把同一个头合并成一条,留下证据,剩下一份能直接交接的清单。

为什么请求头会重复

重复头不是 bug,而是抓取过程的自然产物。一份原始抓包里,同一个字段出现两次的情况很常见:上游服务设了一次 Content-Type,网关又补了一次;Set-Cookie 被中间的反向代理原样回显;还有手抄时多复制了一行。再加上不同工具对字段名的大小写写法不统一,你拿到的就是一份看着冗长、实则信息重叠的列表。

排查时如果不先去重,你会反复盯着两行内容相同的头怀疑哪里配错了,其实它们就是一回事。

头名不区分大小写,这是去重的关键

HTTP 头名按规范是不区分大小写的。也就是说 Content-Type 和 content-type 指的是同一个头,服务端解析时也按同一个处理。所以去重不能做朴素的字符串完全匹配,否则这两行会被当成两个不同的头各留一条。

正确做法是先把头名归一(统一按小写比较),再判断是否重复。归一之后:

Content-Type: application/json
content-type: application/json

这两行折叠成一条,保留首次出现的写法和它的行号。值若也一致就计为一次重复;若头名相同但值不同(比如两行 Content-Type 一个是 text/html 一个是 application/json),那才是真正需要你介入排查的冲突,工具会把它们保留下来让你看到,而不是悄悄合掉。

一个真实的输入输出例子

假设你从两份导出里拼出这样一段:

Content-Type: application/json
X-Request-Id: a1b2c3
content-type: application/json
Cache-Control: no-cache
X-Request-Id: a1b2c3

按头名不区分大小写归一后去重,输出是:

Content-Type    application/json    行1    重复 2 次
X-Request-Id    a1b2c3              行2    重复 2 次
Cache-Control   no-cache            行4    重复 1 次

Content-Type 那两行(大小写不同)折叠成了一条,X-Request-Id 重复的也合掉了,五行收成三行。每条都带着首次出现的行号和重复次数,你想回原文核对随时能找回去。

排查重复头与规范化的顺序

我自己的习惯是先规范化再去重。从网页复制来的文本经常夹着隐藏空白和不可见字符,这些字符会让两条本该相同的头比对失败,去重就不彻底。先做一遍规范化把首尾空白、奇怪的换行清掉,再去重,结果才干净。

排查冲突时,建议保留无效项和有冲突的行一起带出来复核。比如缺冒号的 X-Foo bar,或者同名不同值的两行,这些不该被合并,留着它们你才看得到哪里没对上。

本地处理,数据不出浏览器

这类内容经常带着 token、Cookie、内部标识符,所以处理过程必须留在本地。解析、规范化、去重、复制、下载全在浏览器里跑,上传的 .http 抓包文件由 File API 在当前标签页读取,不会发到服务器。整理完直接导出 CSV、JSON 或 Markdown,带行号那种,既能交接也能当审计线索。

需要先把头从一坨文本里抽出来,可以配合 HTTP 头去重工具上游的提取环节;如果你只想做格式统一而不去重,HTTP 头规范化工具更合适。两个工具都是本地处理,数据不出浏览器。

整理重复头看着是小事,但在凌晨排查线上问题时,一份去过重、带行号的干净清单能省下很多无谓的来回。

Made by Toolora · Updated 2026-06-13