当前位置：首页 > backend >正文

学习黑客 http 响应头

backend 2025/5/19 7:04:57

现在我们来详细科普 HTTP 响应头（Response Headers）。

HTTP 响应头是服务器在 HTTP 响应中发送给客户端的附加信息，它们以键值对的形式描述了关于响应本身、服务器信息、资源特性或客户端应如何处理响应等内容。

理解响应头对于 Web 开发、API 交互、网络调试、性能优化和安全都至关重要。下面我将常见的 HTTP 响应头字段进行分类科普，并给出一些示例。

HTTP 响应结构：
一个典型的 HTTP 响应可能如下：

HTTP/1.1 200 OK
Date: Tue, 18 May 2025 03:15:00 GMT
Server: Apache/2.4.41 (Ubuntu)
Last-Modified: Mon, 17 May 2025 12:00:00 GMT
ETag: "xyzzy-12345"
Content-Type: text/html; charset=UTF-8
Content-Length: 1270
Content-Encoding: gzip
Cache-Control: max-age=3600, public
Set-Cookie: session_id=xyz789abc; Path=/; HttpOnly; Secure; SameSite=Lax
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com<!DOCTYPE html>
... (HTML content) ...

HTTP/1.1 200 OK 是状态行，之后直到空行之前的部分都是响应头，空行之后是响应体。

常见 HTTP 响应头字段分类详解：

1. 通用信息与上下文控制 (General & Context Control)

Date
- 作用：响应生成的日期和时间 (GMT)。
- 示例：Date: Tue, 18 May 2025 03:15:00 GMT
Server
- 作用：包含处理请求的源服务器的软件信息（例如，Apache, Nginx, IIS）。
- 注意：出于安全考虑，有时服务器会隐藏或修改此信息。
- 示例：Server: nginx/1.18.0
Connection
- 作用：决定当前事务完成后，网络连接是否关闭。
- HTTP/1.1 默认值：keep-alive (持久连接)。
- 其他值：close (响应完成后关闭连接)。
- 示例：Connection: keep-alive
Location
- 作用：用于重定向（状态码 3xx）或在创建新资源（状态码 201 Created）后指示新资源的 URL。
- 示例 (301/302)：Location: https://new.example.com/path
- 示例 (201)：Location: /api/items/123
Retry-After
- 作用：当服务器因过载或维护而无法处理请求时（通常配合 503 Service Unavailable 或 3xx 重定向），告知客户端在多长时间后可以重试。值可以是秒数或一个具体的日期时间。
- 示例：Retry-After: 120 (120秒后) 或 Retry-After: Wed, 21 Jul 2025 07:28:00 GMT

2. 响应体信息 (Response Body Information)

这些头部描述了响应体的内容。

Content-Type
- 作用：指示响应体的媒体类型（MIME 类型）以及字符集。
- 示例：
  - Content-Type: text/html; charset=utf-8
  - Content-Type: application/json
  - Content-Type: image/jpeg
  - Content-Type: application/octet-stream (通用二进制)
Content-Length
- 作用：响应体的长度（以字节为单位）。
- 注意：如果使用了 Transfer-Encoding: chunked，则此头部通常不存在。
- 示例：Content-Length: 1024
Content-Encoding
- 作用：指示响应体所使用的编码方式（通常是压缩算法）。客户端需要使用相应的解码方式来获取原始内容。
- 示例：Content-Encoding: gzip
Content-Language
- 作用：描述响应体内容的自然语言。
- 示例：Content-Language: en-US
Content-Disposition
- 作用：指示响应体如何被处理。通常用于文件下载，可以建议浏览器将内容保存为文件，并指定文件名。
- 值：
  - inline: 默认，内容在浏览器中显示。
  - attachment; filename="example.pdf": 提示用户下载文件，文件名为 example.pdf。
- 示例：Content-Disposition: attachment; filename="document.pdf"
Content-Range
- 作用：当响应是部分内容时（状态码 206 Partial Content），指示这部分内容在整个资源中的位置和总大小。
- 示例：Content-Range: bytes 0-499/1234 (表示0-499字节，总共1234字节)
Transfer-Encoding
- 作用：指定了为保证消息安全传输所使用的编码形式。最常见的是 chunked，表示响应体被分成多个块传输，允许服务器在不知道总大小的情况下开始发送数据。
- 示例：Transfer-Encoding: chunked

3. 缓存控制 (Caching)

这些头部告诉客户端和中间缓存如何缓存响应。

Cache-Control
- 作用：提供详细的缓存指令。
- 常见响应指令：
  - public: 响应可以被任何缓存（包括共享缓存如 CDN）缓存。
  - private: 响应只能被单个用户的浏览器缓存，不能被共享缓存缓存。
  - no-cache: 强制缓存在使用缓存副本之前必须与源服务器确认其有效性（通过 ETag 或 Last-Modified）。
  - no-store: 禁止缓存存储任何版本的请求或响应。通常用于敏感数据。
  - max-age=<seconds>: 响应在指定秒数内是新鲜的。
  - s-maxage=<seconds>: 类似于 max-age，但仅适用于共享缓存（如 CDN）。
  - must-revalidate: 一旦资源过期，缓存必须与源服务器验证，不能使用过期的副本。
  - proxy-revalidate: 类似于 must-revalidate，但仅适用于共享缓存。
  - immutable: 表示响应体在新鲜期内不会改变，客户端可以安全地不重新验证。
- 示例：Cache-Control: max-age=3600, public, must-revalidate
Expires (历史遗留，主要用于 HTTP/1.0)
- 作用：指定响应过期的具体日期和时间。如果 Cache-Control 中有 max-age 指令，Expires 会被忽略。
- 示例：Expires: Thu, 01 Dec 2025 16:00:00 GMT
ETag (Entity Tag)
- 作用：资源的特定版本的标识符，通常是一个哈希值。当资源改变时，ETag 也会改变。用于条件请求（If-Match, If-None-Match）和缓存验证。
- 示例：ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4" 或 ETag: W/"0815" (W/ 表示弱 ETag)
Last-Modified
- 作用：资源最后修改的日期和时间。用于条件请求（If-Modified-Since, If-Unmodified-Since）和缓存验证。
- 示例：Last-Modified: Tue, 15 Nov 2025 12:45:26 GMT
Vary
- 作用：指示缓存（包括浏览器和代理）在决定是否使用缓存副本时，除了 URL 之外，还应该考虑哪些请求头字段。例如，如果响应内容根据 Accept-Encoding 或 Accept-Language 而变化，则应包含这些头部。
- 示例：Vary: Accept-Encoding, User-Agent
Age
- 作用：表示对象在代理缓存中存活的时长（秒）。
- 示例：Age: 23

4. Cookie 与状态管理

Set-Cookie
- 作用：服务器向客户端发送 Cookie。客户端会在后续请求中通过 Cookie 请求头将这些 Cookie 发回服务器。
- 属性：
  - Expires=<date>: Cookie 的过期日期。
  - Max-Age=<seconds>: Cookie 的生命周期（秒）。
  - Domain=<domain>: Cookie 适用的域名。
  - Path=<path>: Cookie 适用的路径。
  - Secure: 仅通过 HTTPS 发送 Cookie。
  - HttpOnly: 禁止 JavaScript 访问 Cookie，有助于防止 XSS 攻击。
  - SameSite=Strict|Lax|None: 控制 Cookie 是否随跨站请求发送，有助于防止 CSRF 攻击。
- 示例：Set-Cookie: user_id=123; Path=/; Expires=Wed, 21 Oct 2025 07:28:00 GMT; HttpOnly; Secure; SameSite=Lax
- 注意：一个响应中可以有多个 Set-Cookie 头部。

5. 安全相关的响应头 (Modern Security Headers)

这些头部帮助增强 Web 应用的安全性，防御常见的 Web 攻击。

Strict-Transport-Security (HSTS)
- 作用：告知浏览器在指定时间内，只能通过 HTTPS 访问该域名（及其子域名，如果包含 includeSubDomains）。有助于防止协议降级攻击和 Cookie 劫持。
- 示例：Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Content-Security-Policy (CSP)
- 作用：一种强大的安全机制，允许网站管理员控制页面可以加载哪些资源（脚本、样式、图片、字体、媒体等）的来源。有助于防御 XSS 攻击和数据注入攻击。
- 示例：Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.google.com; img-src *; style-src 'self' 'unsafe-inline'
X-Frame-Options
- 作用：指示浏览器是否应该允许页面在 <frame>, <iframe>, <embed> 或 <object> 中展现。有助于防止点击劫持攻击。
- 值：
  - DENY: 页面不能在任何 frame 中显示。
  - SAMEORIGIN: 页面只能在同源的 frame 中显示。
  - ALLOW-FROM uri: 页面只能在指定来源的 frame 中显示 (已废弃，应使用 CSP 的 frame-ancestors 指令)。
- 示例：X-Frame-Options: SAMEORIGIN
X-Content-Type-Options
- 作用：阻止浏览器对响应内容进行 MIME 类型嗅探。通常设置为 nosniff。
- 原因：如果服务器发送的 Content-Type 不正确或未指定，浏览器可能会尝试猜测内容类型，这可能导致安全问题（例如，将文本文件解释为脚本）。
- 示例：X-Content-Type-Options: nosniff
Referrer-Policy
- 作用：控制在导航到其他页面时，HTTP Referer 请求头中应包含哪些信息。
- 常见值：no-referrer, no-referrer-when-downgrade, origin, origin-when-cross-origin, same-origin, strict-origin, strict-origin-when-cross-origin, unsafe-url
- 示例：Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy (原 Feature-Policy)
- 作用：允许网站控制哪些浏览器特性（如摄像头、麦克风、地理位置、全屏等）可以在其页面和嵌入的 iframe 中使用。
- 示例：Permissions-Policy: geolocation=(self "https://example.com"), microphone=() (允许同源和 example.com 使用地理位置，禁止使用麦克风)
Cross-Origin-Opener-Policy (COOP)
- 作用：允许你确保顶层文档不会与跨源文档共享浏览上下文组。有助于防御某些跨站泄漏攻击。
- 示例：Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy (COEP)
- 作用：防止文档加载任何未明确授予文档加载权限的跨源资源。
- 示例：Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy (CORP)
- 作用：控制哪些跨源请求可以包含当前资源。
- 示例：Cross-Origin-Resource-Policy: same-origin

6. CORS (Cross-Origin Resource Sharing) 相关的响应头

这些头部用于控制跨域 HTTP 请求。

Access-Control-Allow-Origin
- 作用：指示哪些源可以访问该资源。可以是单个源或 * (允许任何源，但不适用于带凭据的请求)。
- 示例：Access-Control-Allow-Origin: https://developer.mozilla.org 或 Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials
- 作用：当值为 true 时，指示响应可以暴露给带凭据（如 Cookies, HTTP 认证）的跨域请求的客户端代码。
- 示例：Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods
- 作用：在预检请求（OPTIONS 请求）的响应中，指示实际请求所允许的 HTTP 方法。
- 示例：Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers
- 作用：在预检请求的响应中，指示实际请求所允许的 HTTP 请求头。
- 示例：Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With
Access-Control-Expose-Headers
- 作用：指示哪些响应头可以暴露给客户端 JavaScript 代码。默认情况下，只有一些简单响应头可以访问。
- 示例：Access-Control-Expose-Headers: Content-Length, X-My-Custom-Header
Access-Control-Max-Age
- 作用：指示预检请求的结果可以被缓存多长时间（秒）。
- 示例：Access-Control-Max-Age: 86400 (24小时)

7. 其他重要响应头

Allow
- 作用：列出资源所支持的 HTTP 方法集合。通常在响应 405 Method Not Allowed 时发送。
- 示例：Allow: GET, HEAD, POST
WWW-Authenticate
- 作用：当请求需要认证但未提供或认证失败时（状态码 401 Unauthorized），此头部定义了应使用的认证方法。
- 示例：WWW-Authenticate: Basic realm="Restricted Area"
Proxy-Authenticate
- 作用：类似于 WWW-Authenticate，但用于代理服务器认证（状态码 407 Proxy Authentication Required）。
- 示例：Proxy-Authenticate: Basic realm="Proxy"
Link
- 作用：提供与当前资源相关的链接，例如预加载资源、分页链接等。
- 示例：Link: <https://example.com/styles.css>; rel=preload; as=style
- 示例 (分页)：Link: <https://api.example.com/items?page=2>; rel="next", <https://api.example.com/items?page=10>; rel="last"
Accept-Ranges
- 作用：指示服务器是否接受范围请求（Range requests）。
- 值：bytes (接受字节范围请求) 或 none (不接受)。
- 示例：Accept-Ranges: bytes