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

学习黑客HTTP 请求头

news 来源：原创 2025/5/19 8:45:10

HTTP 请求头（Request Headers）是 HTTP 请求中非常重要的一部分，它们以键值对的形式向服务器传递关于请求的附加信息、客户端的能力或上下文。

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

HTTP 请求头结构：
一个典型的 HTTP 请求（例如 GET 请求）可能如下：

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: session_id=abc123xyz; user_preference=dark_mode
If-Modified-Since: Mon, 17 May 2025 10:00:00 GMT
Authorization: Bearer <token>

GET /index.html HTTP/1.1 是请求行，之后直到空行之前的部分都是请求头。

常见 HTTP 请求头字段分类详解：

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

Host (必需)
- 作用：指定请求的目标服务器的域名和端口号（如果不是默认端口80或443）。这是 HTTP/1.1 协议中唯一一个强制要求的请求头。
- 原因：允许多个域名（虚拟主机）共享同一个 IP 地址。
- 示例：Host: www.example.com 或 Host: api.example.com:8080
User-Agent
- 作用：包含发起请求的客户端（通常是浏览器、爬虫或应用程序）的标识信息。
- 原因：服务器可以根据不同的客户端提供不同的内容或体验（例如，移动版网页）。
- 示例：User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
Referer (注意：单词本身是 “Referrer” 的拼写错误，但已成为标准)
- 作用：表示当前请求是从哪个 URL 跳转过来的。
- 原因：用于统计分析、日志记录、缓存优化或防盗链。
- 示例：Referer: https://www.google.com/search?q=http+headers
Origin
- 作用：指示引发该请求的源（协议、域名和端口）。主要用于 CORS（跨源资源共享）请求中。
- 原因：帮助服务器判断是否允许跨域请求。
- 示例：Origin: https://developer.mozilla.org
Connection
- 作用：决定当前事务完成后，网络连接是否关闭。
- HTTP/1.1 默认值：keep-alive (持久连接，允许在同一连接上发送多个请求)。
- 其他值：close (请求完成后关闭连接)。
- 示例：Connection: keep-alive
Date
- 作用：请求发送的日期和时间 (GMT)。
- 原因：主要用于消息跟踪、缓存控制等。
- 示例：Date: Tue, 18 May 2025 03:10:07 GMT

2. 内容协商 (Content Negotiation - 客户端期望的响应格式)

这些头部告诉服务器客户端期望接收什么样格式的响应。

Accept
- 作用：客户端可以处理的内容类型（MIME 类型）。可以使用 q 值（权重因子，0到1）来表示优先级。
- 示例：Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Charset
- 作用：客户端可以处理的字符集。
- 示例：Accept-Charset: utf-8, iso-8859-1;q=0.5
Accept-Encoding
- 作用：客户端可以处理的内容编码方式（通常是压缩算法）。
- 示例：Accept-Encoding: gzip, deflate, br
Accept-Language
- 作用：客户端偏好的自然语言。
- 示例：Accept-Language: en-US,en;q=0.9,zh-CN;q=0.8

3. 条件请求 (Conditional Requests)

这些头部允许客户端基于某些条件发起请求，通常用于缓存验证或避免不必要的数据传输。

If-Modified-Since
- 作用：如果资源自指定日期时间以来未被修改，则服务器返回 304 Not Modified 状态码，不返回资源内容。
- 示例：If-Modified-Since: Mon, 17 May 2025 12:00:00 GMT
If-Unmodified-Since
- 作用：如果资源自指定日期时间以来已被修改，则服务器返回 412 Precondition Failed。
- 示例：If-Unmodified-Since: Mon, 17 May 2025 12:00:00 GMT
If-Match
- 作用：仅当资源的 ETag（实体标签，资源的特定版本标识符）与此头部中给出的一个或多个 ETag 匹配时，请求才会成功。常用于防止并发更新时“丢失更新”问题（乐观锁）。
- 示例：If-Match: "xyzzy"
If-None-Match
- 作用：仅当资源的 ETag 与此头部中给出的任何 ETag 都不匹配时，请求才会成功。常用于缓存验证（类似 If-Modified-Since，但基于 ETag）。如果匹配，服务器返回 304 Not Modified。
- 示例：If-None-Match: "xyzzy", "r2d2xxxx"
If-Range
- 作用：如果资源未改变（基于 ETag 或日期），则返回 Range 头部指定的资源部分；否则，返回整个新资源。用于断点续传。
- 示例：If-Range: "xyzzy" 或 If-Range: Mon, 17 May 2025 12:00:00 GMT

4. 认证与授权 (Authentication & Authorization)

Authorization
- 作用：包含用于向服务器验证用户代理身份的凭证。
- 常见类型：
  - Basic <base64_encoded_credentials>: 基本认证。
  - Bearer <token>: OAuth 2.0 或 JWT 等令牌认证。
- 示例：Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== 或 Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Proxy-Authorization
- 作用：包含用于向代理服务器验证用户代理身份的凭证。
- 示例：Proxy-Authorization: Basic ...

5. Cookie 与状态管理

Cookie
- 作用：包含先前由服务器通过 Set-Cookie 响应头发送并存储在客户端的 HTTP Cookie。
- 原因：用于维护会话状态、用户偏好设置等。
- 示例：Cookie: session_id=abc123xyz; theme=dark

6. 缓存控制 (Caching)

Cache-Control (也用于响应头)
- 作用：在请求中，它可以指示客户端或中间缓存如何处理请求。
- 常见请求指令：
  - no-cache: 强制缓存向源服务器验证资源，即使本地有缓存副本。
  - no-store: 禁止缓存存储任何版本的请求或响应。
  - max-age=<seconds>: 客户端愿意接受一个其年龄不超过指定秒数的响应。
  - max-stale[=<seconds>]: 客户端愿意接受一个已过期的响应。
  - min-fresh=<seconds>: 客户端希望得到一个在指定秒数内仍然保持新鲜的响应。
  - only-if-cached: 仅当缓存中有副本时才返回，否则返回 504。
- 示例：Cache-Control: no-cache, max-age=0
Pragma (历史遗留，主要用于 HTTP/1.0)
- 作用：通常设置为 Pragma: no-cache，效果类似 Cache-Control: no-cache。
- 示例：Pragma: no-cache

7. 请求体信息 (Request Body Information - 主要用于 POST, PUT, PATCH 等方法)

Content-Type
- 作用：指示请求体的媒体类型（MIME 类型）。
- 示例：
  - Content-Type: application/json
  - Content-Type: application/x-www-form-urlencoded
  - Content-Type: multipart/form-data; boundary=something
  - Content-Type: text/xml
Content-Length
- 作用：请求体的长度（以字节为单位）。
- 示例：Content-Length: 1024
Content-Encoding
- 作用：指示请求体所使用的编码方式（通常是压缩）。这与 Accept-Encoding 不同，后者是客户端声明它能理解的响应编码。
- 示例：Content-Encoding: gzip (表示请求体本身是 gzip 压缩过的)

8. 其他重要请求头

Range
- 作用：请求资源的一部分。服务器成功处理则返回 206 Partial Content。
- 示例：Range: bytes=0-499 (请求前500字节)
Expect
- 作用：指示客户端期望服务器的特定行为。最常见的是 Expect: 100-continue，客户端在发送实际请求体之前，先询问服务器是否接受该请求。如果服务器接受，返回 100 Continue，客户端再发送请求体。
- 示例：Expect: 100-continue
TE
- 作用：指定客户端愿意接受的传输编码（与内容编码不同），通常用于 HTTP 分块传输。
- 示例：TE: trailers, deflate
Upgrade
- 作用：请求服务器升级到另一个协议，例如从 HTTP/1.1 升级到 WebSocket。
- 示例：Upgrade: websocket (通常与 Connection: Upgrade 一起使用)
Upgrade-Insecure-Requests
- 作用：客户端向服务器表明它支持升级到 HTTPS 的机制，并希望服务器将所有 HTTP URL 重定向到 HTTPS。
- 示例：Upgrade-Insecure-Requests: 1
DNT (Do Not Track)
- 作用：表示用户不希望被追踪的偏好。1 表示不追踪，0 表示同意追踪。
- 示例：DNT: 1

9. 安全相关的请求头 (Modern Security Headers - 通常由浏览器自动添加)

这些头部通常与 Fetch API 相关，为服务器提供更多关于请求上下文的信息，以帮助服务器做出更安全的决策，防御 CSRF、XSSI 等攻击。

Sec-Fetch-Site
- 作用：指示请求的来源与目标资源的关系。
- 值：cross-site, same-origin, same-site, none
- 示例：Sec-Fetch-Site: same-origin
Sec-Fetch-Mode
- 作用：指示请求的模式。
- 值：cors, navigate, no-cors, same-origin, websocket
- 示例：Sec-Fetch-Mode: cors
Sec-Fetch-Dest
- 作用：指示请求的目标类型。
- 值：audio, audioworklet, document, embed, empty, font, frame, iframe, image, manifest, object, paintworklet, report, script, serviceworker, sharedworker, style, track, video, worker, xslt
- 示例：Sec-Fetch-Dest: script
Sec-Fetch-User
- 作用：指示导航请求是否由用户激活（例如点击链接）。?1 表示是，?0 表示否。
- 示例：Sec-Fetch-User: ?1
Sec-CH-UA (Client Hints - User Agent)
- 作用：User-Agent Client Hints 是一组头部，旨在以更结构化、更注重隐私的方式取代传统的 User-Agent 字符串。
- 示例：Sec-CH-UA: " Not A;Brand";v="99", "Chromium";v="90", "Google Chrome";v="90"
- 还有 Sec-CH-UA-Mobile, Sec-CH-UA-Platform 等。