HTTP 头部分析器

HTTP 头部承载请求和响应的元数据。此工具解析完整的 HTTP 消息，包括请求/状态行、头部和正文内容。它分析安全头部（HSTS、CSP）、认证（Basic、Bearer）、Cookie、CORS 配置和缓存指令。正文内容根据 Content-Type（JSON、HTML、XML）自动格式化并语法高亮。

规范

常见用例

调试从浏览器 DevTools 网络标签复制的 API 请求
分析 curl -i 或 curl -v 输出的头部和正文
审计安全头部以满足合规要求（OWASP 建议）
排查 CORS 预检和跨域问题
检查认证头部和 Cookie 配置
验证 CDN 和浏览器缓存行为

功能

解析完整的 HTTP 请求（GET /path HTTP/1.1）
解析带状态码和原因短语的 HTTP 响应
格式化并语法高亮正文内容（JSON、HTML、XML、CSS）
解码 Authorization 头部（Basic 认证凭证、Bearer 令牌）
分析安全头部（HSTS、CSP、X-Frame-Options、X-Content-Type-Options）
解析 Set-Cookie 属性（Secure、HttpOnly、SameSite、过期时间）
从头部提取和列出 Cookie
显示 CORS 头部（Access-Control-Allow-Origin 等）
解释 Cache-Control 指令（max-age、no-cache、private）

示例

带 JSON 正文的 API 响应

试试看 →

一个包含头部和 JSON 正文的完整 HTTP 响应，类似于从 curl -i 输出中复制的内容。

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Cache-Control: max-age=3600, public
X-Frame-Options: DENY
Strict-Transport-Security: max-age=31536000; includeSubDomains

{
  "status": "success",
  "data": {
    "id": 12345,
    "name": "Example User"
  }
}

带认证的 HTTP 请求

试试看 →

一个带有 Bearer 令牌认证和 Cookie 的请求。

GET /api/users HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Accept: application/json
Cookie: session=abc123; theme=dark

提示

使用 "curl -i URL" 在输出中包含响应头部。
在浏览器 DevTools 中，右键单击请求并选择"复制为 cURL"以获取完整请求。
HSTS（Strict-Transport-Security）告诉浏览器仅对该域使用 HTTPS。
CSP（Content-Security-Policy）控制页面可以加载哪些资源。
SameSite Cookie 属性有助于防止 CSRF 攻击。

理解 HTTP 头部分析器

HTTP 头部是作为每个 HTTP 请求和响应的一部分在客户端和服务器之间发送的键值对。它们承载关于消息的元数据：内容类型、缓存指令、认证凭证和安全策略。头部出现在请求行或状态行之后、可选正文之前，与正文之间用空行分隔。

请求头部提供关于客户端和期望响应的上下文。Host 标识目标服务器。Accept 和 Content-Type 协商媒体格式。Authorization 携带凭证（Basic、Bearer、API 密钥）。Cookie 发送存储的会话数据。User-Agent 标识客户端软件。

响应头部控制客户端如何处理内容。Cache-Control 和 ETag 管理缓存行为。Set-Cookie 建立客户端状态。Content-Security-Policy 限制资源加载以减轻 XSS 攻击。Strict-Transport-Security 强制使用 HTTPS。CORS 头部（Access-Control-Allow-Origin 及相关头部）控制跨域资源共享，这是 Web API 中最常见的配置错误之一。

理解头部对于调试 Web 应用程序至关重要。当 API 返回意外结果时，头部通常揭示原因：缺少 Content-Type、过期的认证令牌、提供过时数据的缓存指令或阻止请求的 CORS 策略。

Cache-Control 指令是最容易被误解的头部之一。no-cache 指令并不意味着"不缓存"——它意味着缓存在使用存储的响应前必须与源服务器重新验证。响应仍然可以被缓存。no-store 指令才是真正阻止缓存的，应该用于敏感数据。对于需要条件请求的频繁变更内容，no-cache 配合 ETag 或 Last-Modified 是合适的策略。

CORS 错误发生在浏览器对不同源的请求缺少 Access-Control-Allow-Origin 响应头部时。服务器必须在此头部中包含请求源或使用 * 用于公共 API。当涉及凭证（Cookie 或 Authorization 头部）时，不允许使用通配符——头部必须指定确切的源。预检 OPTIONS 请求还需要 Access-Control-Allow-Methods 和 Access-Control-Allow-Headers。Bearer 令牌认证使用 Authorization: Bearer <token> 格式，其中令牌通常是来自 OAuth 2.0 流程的 JWT 或不透明访问令牌。与 Cookie 不同，Bearer 令牌不会自动发送——客户端必须在每个请求中显式附加头部。

每个网站都应设置一组最低限度的安全头部。Strict-Transport-Security（HSTS）确保始终使用 HTTPS。Content-Security-Policy 通过限制资源加载来减轻 XSS 攻击。X-Content-Type-Options: nosniff 防止 MIME 类型嗅探。X-Frame-Options 防止点击劫持，Referrer-Policy 控制 Referer 头部中发送的信息。API 还应配置适当的 CORS 头部来控制哪些源可以发送请求。

← 返回所有工具