前端/后端开发者必知的HTTP请求头 – wiki基地

---

深入解析HTTP请求头：前端与后端工程师的必备指南

在Web开发的世界里，HTTP（超文本传输协议）是支撑整个网络通信的基石。对于前端和后端开发者而言，我们每天都在与HTTP打交道，无论是通过浏览器发起请求，还是在服务器端处理这些请求。然而，在HTTP的报文结构中，除了我们熟知的URL、请求方法（GET, POST等）和请求体（Body）之外，还有一个至关重要但常常被忽视的部分——HTTP请求头（Request Headers）。

HTTP请求头是客户端（通常是浏览器）向服务器发送请求时，附加的一系列键值对信息。它们像是一份详细的“请求说明书”，告诉服务器关于本次请求的各种元数据：客户端想要什么、能接受什么、身份是谁、从哪里来等等。深刻理解HTTP请求头，不仅能帮助我们高效地排查问题（如跨域、缓存、认证失败），更能让我们设计出更健壮、更高效、更安全的Web应用。

本文将从前端和后端的双重视角，对常用且重要的HTTP请求头进行一次系统性的梳理和深入的剖析，旨在成为每一位Web开发者工具箱中的常备参考。

一、 HTTP请求头的分类与作用

我们可以根据功能将常见的HTTP请求头大致分为以下几类：

1. 内容协商（Content Negotiation）: 定义客户端期望接收的数据格式、语言和编码。
2. 认证与授权（Authentication & Authorization）: 承载用户的身份凭证。
3. 缓存控制（Caching Control）: 指示服务器和中间代理如何处理缓存。
4. 来源与路由（Origin & Routing）: 提供请求的来源、目标主机及代理信息。
5. 实体信息（Entity Information）: 描述请求体的具体信息，如类型和长度。
6. 其他重要首部: 包含安全、连接管理等多种功能的头部。

接下来，我们将逐一详解这些分类下的核心请求头。

二、 内容协商（Content Negotiation）

内容协商机制允许客户端声明它能理解哪些内容格式，从而让服务器能够返回最合适的资源版本。这对于国际化、多设备适配和性能优化至关重要。

1. Accept

• 作用: 告诉服务器，客户端能够处理的内容类型（MIME类型）。
• 常见值: application/json, text/html, image/jpeg, */* (接受任意类型)。可以使用 q 因子（0到1之间）表示优先级，如 Accept: text/html, application/xhtml+xml, application/xml;q=0.9, image/webp;q=0.8。
• 前端视角:
  • 在使用 fetch 或 axios 等库发起AJAX请求时，通常需要明确设置 Accept: 'application/json'，以确保后端返回JSON格式的数据。
  • 浏览器在请求HTML文档时，会默认发送一个复杂的 Accept 头，包含它所支持的多种类型。
• 后端视角:
  • 这是实现“同一URL，不同表示”RESTful API的关键。服务器需要解析 Accept 头，根据其值来决定是返回HTML页面（用于浏览器直接访问）还是JSON数据（用于API调用）。
  • 如果服务器无法提供任何客户端接受的格式，应返回 406 Not Acceptable 状态码。

2. Accept-Language

• 作用: 告诉服务器，客户端偏好的自然语言。
• 常见值: en-US, zh-CN, en;q=0.8。同样可以使用 q 因子表示优先级。
• 前端视角:
  • 该头部通常由浏览器根据操作系统的语言设置自动添加。前端开发者一般无需手动设置。
• 后端视角:
  • 实现网站国际化（i18n）的核心。后端框架（如Express, Spring）通常有中间件或库来解析此头部，并加载相应的语言资源文件，返回本地化的内容。

3. Accept-Encoding

• 作用: 告诉服务器，客户端支持的内容编码格式（通常是压缩算法）。
• 常见值: gzip, deflate, br (Brotli), identity (不压缩)。
• 前端视角:
  • 浏览器会自动包含此头部，并声明它支持的解压算法。前端开发者几乎不需要关心它的存在，因为解压过程是浏览器自动完成的。
• 后端视角:
  • 性能优化的关键！服务器应该检查此头部，如果客户端支持（如gzip），则应该对响应体进行压缩，并设置响应头 Content-Encoding: gzip。这可以极大地减小传输数据的大小，加快页面加载速度。Nginx、Apache等Web服务器通常可以配置自动处理压缩。

三、 认证与授权（Authentication & Authorization）

这是Web安全的核心，几乎所有需要用户登录的应用都会用到。

1. Authorization

• 作用: 携带用于HTTP认证的凭证。
• 常见值:
  • Basic <credentials>: Basic认证，其中 <credentials> 是username:password经过Base64编码后的字符串。简单但不安全，除非在HTTPS下使用。
  • Bearer <token>: 现代Web应用中最常见的方式。Bearer 表示持有者，<token> 通常是一个JWT (JSON Web Token) 或其他不透明的令牌。
• 前端视角:
  • 当用户登录成功后，前端需要从服务器的响应（通常是响应体或Set-Cookie头）中获取Token。
  • 将Token存储在安全的地方（如HttpOnly Cookie、localStorage或内存中）。
  • 对于需要认证的后续请求，使用请求拦截器（如Axios Interceptors）在Authorization头中附加上 Bearer ${token}。
• 后端视角:
  • API的保护屏障。后端需要编写一个认证中间件，在每个受保护的路由上运行。
  • 该中间件负责解析Authorization头，提取Token，然后验证Token的有效性（如签名、过期时间）。
  • 验证通过后，将用户信息（如用户ID）附加到请求对象上（如req.user），供后续的业务逻辑使用。如果验证失败，应返回 401 Unauthorized。

2. Cookie

• 作用: 携带服务器先前通过 Set-Cookie 响应头下发到客户端的HTTP Cookie。
• 常见值: 一个或多个由分号分隔的 name=value 对，例如 session_id=abcde12345; theme=dark。
• 前端视角:
  • Cookie的管理主要由浏览器自动完成。如果服务器在响应中设置了 Set-Cookie，浏览器会自动存储，并在后续对同域的请求中自动带上Cookie头。
  • 前端JS可以通过 document.cookie 读写非HttpOnly的Cookie，但这存在XSS风险。
  • 对于跨域请求，需要 withCredentials: true (在fetch或XHR中) 才能发送Cookie。
• 后端视角:
  • 这是传统的会话（Session）管理机制。后端通过解析Cookie头中的session_id，在服务器端的存储（如Redis、内存）中查找对应的会话数据，从而识别用户。
  • 后端通过设置 Set-Cookie 响应头来创建或更新Cookie。强烈建议对敏感Cookie（如session_id）设置 HttpOnly 属性，防止JS窃取；设置 Secure 属性，确保只在HTTPS下传输；设置 SameSite 属性（Lax或Strict）来防御CSRF攻击。

四、 缓存控制（Caching Control）

合理利用缓存是提升Web性能最有效的手段之一。请求头中的缓存控制字段让客户端可以更精细地与服务器协商缓存策略。

1. Cache-Control

• 作用: 在请求中，Cache-Control用于指定客户端对缓存的要求。
• 常见值:
  • no-cache: 不是“不缓存”！而是“强制确认缓存”。表示客户端本地可以存储副本，但每次使用前都必须去服务器验证其有效性（通过If-None-Match或If-Modified-since）。
  • no-store: 真正意义上的“禁止缓存”。要求服务器和任何中间代理都不要存储此请求/响应的任何部分。
  • max-age=<seconds>: 表示客户端愿意接受一个存在时间（age）不超过指定秒数的缓存。
• 前端视角:
  • 用户按 Ctrl+F5 强制刷新时，浏览器通常会发送 Cache-Control: no-cache。
  • 开发者可以在 fetch API中设置 cache 选项来影响缓存行为，例如 fetch(url, { cache: 'no-store' })。
• 后端视角:
  • 服务器也使用 Cache-Control 响应头来指示浏览器如何缓存。请求头中的Cache-Control是客户端的“意愿”，后端可以遵循也可以忽略。
  • 理解no-cache的含义对后端至关重要，这意味着需要准备好处理条件请求。

2. If-None-Match

• 作用: 这是一个条件请求头。当客户端拥有一个资源的副本时，它会存储该副本的ETag（由服务器在上次响应的ETag头中提供）。再次请求该资源时，客户端会通过If-None-Match将这个ETag值发给服务器。
• 前端视角:
  • 此过程由浏览器自动处理，开发者通常无需干预。
• 后端视角:
  • 服务器收到带If-None-Match的请求后，会将客户端传来的ETag与当前服务器上资源的ETag进行比较。
  • 如果不匹配，说明资源已更新，服务器返回新的资源和 200 OK 状态码。
  • 如果匹配，说明资源未改变，服务器返回一个空的响应体和 304 Not Modified 状态码，告诉浏览器直接使用本地缓存。这极大地节省了带宽。

3. If-Modified-Since

• 作用: 类似于If-None-Match，但它使用的是时间戳。客户端存储了上次服务器在Last-Modified响应头中返回的时间。
• 前端视角:
  • 同样由浏览器自动处理。
• 后端视角:
  • 服务器比较If-Modified-Since的时间戳和资源的最后修改时间。如果资源在此时间之后未被修改，则返回 304 Not Modified。
  • ETag通常被认为是更优的验证方式，因为它能精确到文件内容的任何变化，而Last-Modified只能精确到秒，且在某些分布式系统中难以保证时间同步。

五、 来源与路由（Origin & Routing）

这类头部帮助服务器识别请求的来源和最终目标，对于安全（CORS）、路由和日志分析非常重要。

1. Host

• 作用: 指定请求的目标服务器的域名（和端口号）。在HTTP/1.1中，这是唯一一个强制必须包含的请求头。
• 常见值: www.example.com, api.myservice.io:8080
• 前端视角:
  • 由浏览器根据URL自动填充，开发者无需关心。
• 后端视角:
  • 至关重要。一台物理服务器可能托管了多个网站（虚拟主机）。后端Web服务器（如Nginx, Apache）使用Host头来决定将请求路由到哪个具体的网站配置或应用进程。

2. Referer

• 作用: 告知服务器，当前请求是从哪个页面链接过来的。
• 常见值: 一个完整的URL，如 https://www.google.com/。
• 前端视角:
  • 浏览器自动添加。例如，在页面A点击一个链接跳转到页面B，那么对页面B的请求头中就会包含Referer: A的URL。
  • 可以通过在HTML中设置 <meta name="referrer" content="origin"> 或使用 Referrer-Policy 响应头来控制Referer的发送策略，以保护用户隐私。
• 后端视角:
  • 常用于数据分析和日志记录，了解流量来源。
  • 安全警告：绝不能将Referer用于安全控制（如防盗链或CSRF防御），因为它很容易被伪造，并且在某些情况下（如用户直接输入地址、从HTTPS跳到HTTP）浏览器不会发送它。

3. Origin

• 作用: 包含发起请求的源站信息（协议、域名、端口），但不包含路径。主要用于跨域资源共享（CORS）。
• 常见值: https://developer.mozilla.org
• 前端视角:
  • 当发起跨域的AJAX请求时，浏览器会自动添加Origin头。这是CORS机制的核心。
• 后端视角:
  • 在处理CORS时，后端必须检查Origin头。如果该Origin在允许的白名单内，服务器就需要在响应头中包含Access-Control-Allow-Origin: <origin>或*，浏览器看到这个响应头后才会将数据交给前端JS。否则，浏览器会拦截响应，前端会看到CORS错误。

4. User-Agent

• 作用: 一个包含客户端（通常是浏览器）类型、操作系统、版本等信息的字符串。
• 前端视角:
  • 由浏览器自动添加。
• 后端视角:
  • 用于统计分析，了解用户使用的设备和浏览器分布。
  • 可以用来针对特定浏览器做兼容性处理或功能降级。
  • 安全警告：同样不能用于安全目的，因为它可以被任意伪造。不要因为User-Agent是“Googlebot”就信任它是谷歌爬虫。

六、 实体信息（Entity Information）

当请求中包含主体（Body）时，例如POST或PUT请求，这些头部用来描述主体的细节。

1. Content-Type

• 作用: 告知服务器请求体的媒体类型（MIME类型）。
• 常见值:
  • application/json: 发送JSON数据。
  • application/x-www-form-urlencoded: HTML表单默认的提交方式。
  • multipart/form-data: 用于上传文件或包含二进制数据的表单。
• 前端视角:
  • 发起POST请求时必须正确设置。如果用fetch发送JSON，需要手动设置：headers: { 'Content-Type': 'application/json' }。如果使用FormData对象，浏览器会自动设置正确的multipart/form-data类型和boundary。
• 后端视角:
  • 服务器根据Content-Type来决定使用哪个解析器（Body Parser）来处理请求体。如果Content-Type是application/json，就用JSON解析器；如果是application/x-www-form-urlencoded，就用表单解析器。
  • 如果收到的Content-Type不被支持，应返回 415 Unsupported Media Type。

2. Content-Length

• 作用: 指示请求体的大小（以字节为单位）。
• 前端视角:
  • 在使用XMLHttpRequest或fetch时，这个头部通常由浏览器或库自动计算并添加。
• 后端视角:
  • 服务器可以用它来预知需要读取多少数据，有助于防止不完整的请求或缓冲区溢出。对于某些需要预先分配内存的服务器应用，这个头非常有用。

七、 其他重要首部

1. X-Forwarded-For

• 作用: 当请求经过HTTP代理或负载均衡服务器时，此头部用来识别发起请求的客户端的原始IP地址。
• 常见值: 一个IP地址列表，client, proxy1, proxy2。最左边的是最原始的客户端IP。
• 后端视角:
  • 如果你的应用部署在反向代理（如Nginx）之后，直接从请求中获取的IP地址将是代理服务器的IP。为了获取真实的用户IP，你需要读取X-Forwarded-For头。
  • 安全警告: 此头部也可能被伪造。在信任它之前，需要确保你的网络架构配置正确，只信任你自己的代理服务器添加的IP信息。

2. X-Requested-With

• 作用: 一个非标准的头部，但被许多JavaScript库（如jQuery, Prototype）广泛使用。当发起AJAX请求时，它们会添加X-Requested-With: XMLHttpRequest。
• 后端视角:
  • 可以用来判断一个请求是普通的页面同步请求还是AJAX异步请求。这在某些场景下很有用，比如，如果是AJAX请求，发生错误时可以返回JSON格式的错误信息；如果是普通请求，则渲染一个错误页面。

总结

HTTP请求头是连接前端与后端的无形桥梁，它们承载着丰富的上下文信息，驱动着现代Web应用的复杂交互。

• 对于前端开发者而言，理解请求头意味着能更精确地控制向服务器的“索求”，能更好地与后端API协作，并能快速定位由请求配置不当引发的CORS、认证和缓存问题。
• 对于后端开发者而言，请求头是理解客户端“意图”的窗口。正确解析和响应这些头部，是实现高效API、健壮安全策略、卓越性能优化和良好用户体验的基石。

掌握HTTP请求头，就像是学会了Web世界的“官方方言”。它让你不再是一个只会说“你好”（发GET请求）和“谢谢”（收200 OK）的初学者，而是一个能够进行深度、精确、高效沟通的专家。花时间去熟悉它们，并在日常开发中留心观察和运用，这将是你技术成长道路上一次极具价值的投资。