HTTP 头部字段
HTTP - 头部字段
Section titled “HTTP - 头部字段”HTTP 头部字段（Header fields）是请求和响应消息中头部部分的组成部分。它们定义了 HTTP 事务的操作参数。头部字段名称不区分大小写，并且以冒号分隔的键值对形式表示。
头部字段可以按概念分组（尽管较新的 RFC，如 RFC 7230-7231 和 RFC 9110 对这些类别进行了细化）：
- **消息元数据头部字段（以前称为通用头部字段）：**适用于整个消息，例如
Date或Connection。 - **请求头部字段：**包含更多关于要获取的资源或客户端本身的信息，例如
User-Agent、Accept或Host。 - **响应头部字段：**包含关于响应的额外信息，例如其位置，或关于服务器本身的信息，例如
Server、Allow或Set-Cookie。 - **表示数据头部字段（以前称为实体头部字段）：**包含关于资源主体（body）的信息，例如其内容类型（
Content-Type）或编码（Content-Encoding）。
通用头部字段 / 消息元数据头部字段
Section titled “通用头部字段 / 消息元数据头部字段”Cache-Control
Section titled “Cache-Control”指定请求和响应中的缓存机制指令。它是一个逗号分隔的指令列表。
Syntax: `Cache-Control: directive1, directive2, ...`常见指令：
- 请求：
no-cache（与服务器重新验证），no-store（不存储），max-age=seconds，max-stale[=seconds]，min-fresh=seconds。 - 响应：
public（可被任何缓存缓存），private（仅供单个用户使用），no-cache（使用前重新验证），no-store，must-revalidate，proxy-revalidate，max-age=seconds，s-maxage=seconds（用于共享缓存），immutable，stale-while-revalidate=seconds，stale-if-error=seconds。
Example: `Cache-Control: no-cache, max-age=0, must-revalidate`Connection
Section titled “Connection”控制网络连接在当前事务完成后是否保持打开。也用于逐跳（hop-by-hop）头部字段。
Syntax: `Connection: "close" | "keep-alive" | header-name`Connection: close 表示在此请求/响应后连接将关闭。HTTP/1.1 默认使用 keep-alive。HTTP/2 和 HTTP/3 通过单连接多路复用（multiplexing）来管理连接，通常不使用此头部字段进行连接管理。
消息生成时的日期和时间，采用 RFC 1123 (IMF-fixdate) 格式 (GMT/UTC)。
Example: `Date: Tue, 22 Feb 2022 10:00:00 GMT`Pragma
Section titled “Pragma”一个 HTTP/1.0 头部字段，用于向后兼容，主要是 Pragma: no-cache。其行为规范性较差。对于缓存，推荐使用 Cache-Control。
Trailer
Section titled “Trailer”允许发送者在消息尾部（trailer）包含额外字段，这些字段附加在采用分块传输编码（chunked transfer-coding）的消息的最后一个块之后。Trailer 头部字段列出尾部中存在的头部字段名称。
Example: `Trailer: ETag, X-Checksum` (sent in main headers if `Transfer-Encoding: chunked` is used)Transfer-Encoding
Section titled “Transfer-Encoding”指定用于安全传输负载主体（payload body）到用户的编码形式。当事先不知道内容长度时，chunked 是 HTTP/1.1 中常用的值。这是一个逐跳（hop-by-hop）头部字段。HTTP/2 和 HTTP/3 不使用此机制进行数据分块。
Example: `Transfer-Encoding: chunked`Upgrade
Section titled “Upgrade”允许客户端指定如果服务器支持，则希望使用的其他通信协议（例如，从 HTTP/1.1 升级到 HTTP/2，或升级到 WebSockets）。如果成功，需要 101 Switching Protocols 响应。
Example: `Upgrade: h2c, websocket` (h2c for HTTP/2 over cleartext)由代理（正向和反向代理）添加，用于指示用户代理与源服务器之间或源服务器与客户端之间的中间协议和接收者。用于消息追踪和环路检测。
Example: `Via: 1.1 example-proxy.com (Squid/3.5.27), 1.0 internal-gw`Warning（已废弃）
Section titled “Warning（已废弃）”携带关于消息状态或转换的额外信息。此头部字段现已过时（RFC 7234）。
客户端请求头部字段
Section titled “客户端请求头部字段”Accept
Section titled “Accept”告知服务器客户端可以处理的媒体类型（MIME types），通常带有质量因子（q-values）。
Example: `Accept: application/json, text/plain;q=0.9, */*;q=0.8`Accept-Charset
Section titled “Accept-Charset”指示响应可以接受哪些字符集。由于 UTF-8 的普及，现在较少使用。
Example: `Accept-Charset: utf-8, iso-8859-1;q=0.5`Accept-Encoding
Section titled “Accept-Encoding”限制响应中可接受的内容编码（压缩方式）。
Example: `Accept-Encoding: gzip, deflate, br`Accept-Language
Section titled “Accept-Language”限制响应中首选的自然语言集合。
Example: `Accept-Language: en-US,en;q=0.9,fr;q=0.8`Authorization
Section titled “Authorization”包含用于客户端向服务器进行身份验证的凭据。
Examples: `Authorization: Basic dXNlcjpwYXNzd29yZA==` (Base64 encoded username:password)`Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...` (Bearer token, e.g., JWT)Cookie
Section titled “Cookie”包含服务器之前通过 Set-Cookie 发送的 HTTP Cookie。
Syntax: `Cookie: name1=value1; name2=value2`Expect
Section titled “Expect”指示服务器需要满足的期望，以便请求成功处理。唯一常见的期望是 100-continue，它询问服务器是否可以发送请求主体（body）。
Example: `Expect: 100-continue`From（罕用）
Section titled “From（罕用）”包含控制请求用户代理的人类用户的互联网电子邮件地址。因隐私顾虑而很少使用。
指定服务器的域名（用于虚拟主机），以及可选的 TCP 端口号。对于 HTTP/1.1 是强制性的。
Example: `Host: www.example.com` or `Host: api.example.com:8080`If-Match / If-None-Match / If-Modified-Since / If-Unmodified-Since / If-Range
Section titled “If-Match / If-None-Match / If-Modified-Since / If-Unmodified-Since / If-Range”这些是条件请求头部字段。它们根据资源元数据（如 ETag 或 Last-Modified 日期）使请求方法具有条件性。用于缓存验证、乐观并发控制或恢复下载。
Examples:`If-None-Match: "xyzzy"` (如果 ETag 不同则 GET)`If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT` (如果自此日期以来已修改则 GET)Max-Forwards
Section titled “Max-Forwards”与 TRACE 和 OPTIONS 一起使用，限制可以转发请求的代理或网关数量。
Proxy-Authorization
Section titled “Proxy-Authorization”允许客户端向需要身份验证的代理标识自己（或其用户）。
仅请求实体的一部分。字节从 0 开始编号。用于恢复中断的下载或获取大文件的部分。
Example: `Range: bytes=0-499` (前 500 字节)`Range: bytes=500-` (从第 500 字节到末尾)Referer（规范中拼写错误，应为 ‘Referrer’）
Section titled “Referer（规范中拼写错误，应为 ‘Referrer’）”用户代理访问当前请求页面之前所在的网页地址。Referrer-Policy 头部字段可以控制此行为。
指定用户代理愿意接受的传输编码。通常用于分块编码（chunked encoding）中的尾部（trailers）。
Example: `TE: trailers, deflate`User-Agent
Section titled “User-Agent”包含一个特征字符串，允许网络协议对等方识别请求软件用户代理的应用程序类型、操作系统、软件供应商或软件版本。
Example: `User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.102 Safari/537.36`服务器响应头部字段
Section titled “服务器响应头部字段”Accept-Ranges
Section titled “Accept-Ranges”指示服务器是否支持资源的范围请求（range requests），如果支持，则使用什么单位（例如 bytes）。
Example: `Accept-Ranges: bytes` or `Accept-Ranges: none`对象在代理缓存中停留的秒数。
资源的特定版本的标识符。使缓存更高效并节省带宽，因为如果内容未更改（If-None-Match），Web 服务器无需重新发送完整响应。
Example: `ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"` (强 ETag)`ETag: W/"0815"` (弱 ETag)Location
Section titled “Location”用于重定向（3xx 响应）以指定新的 URL，或用于 201 Created 响应以指定新创建资源的 URL。
Proxy-Authenticate
Section titled “Proxy-Authenticate”必须包含在 407 (Proxy Authentication Required) 响应中，定义代理所需的身份验证方法。
Retry-After
Section titled “Retry-After”可与 503 (Service Unavailable) 或 429 (Too Many Requests) 响应一起使用，指示服务预计不可用时长或重试前需要等待的时长。
Example: `Retry-After: 120` (秒) or `Retry-After: Fri, 31 Dec 2022 23:59:59 GMT`Server
Section titled “Server”包含关于源服务器使用的软件信息。出于安全原因（信息泄露）可以隐藏。
Example: `Server: nginx/1.21.6`Set-Cookie
Section titled “Set-Cookie”从服务器向用户代理发送 Cookie。用户代理保存 Cookie 并在后续请求中将其发送回同一服务器。
Syntax: `Set-Cookie: NAME=VALUE; [Expires=date;] [Max-Age=seconds;] [Domain=domain;] [Path=path;] [Secure;] [HttpOnly;] [SameSite=Strict|Lax|None]`Multiple cookies require multiple `Set-Cookie` headers.Example: `Set-Cookie: session_id=abc123xyz; Path=/; Secure; HttpOnly; SameSite=Lax`Strict-Transport-Security (HSTS)
Section titled “Strict-Transport-Security (HSTS)”指示用户代理（浏览器）仅使用 HTTPS 访问站点。有助于防止协议降级攻击和 Cookie 劫持。
Example: `Strict-Transport-Security: max-age=31536000; includeSubDomains`决定如何匹配未来的请求头部字段，以判断是否可以使用缓存响应而不是从源服务器请求新响应。它列出了影响此响应生成的请求头部字段。
Example: `Vary: Accept-Encoding, User-Agent`WWW-Authenticate
Section titled “WWW-Authenticate”必须包含在 401 (Unauthorized) 响应消息中。定义应用于访问资源的身份验证方法。
Example: `WWW-Authenticate: Basic realm="Restricted Area"``WWW-Authenticate: Bearer realm="example", error="invalid_token", error_description="The access token expired"`表示数据头部字段（以前称为实体头部字段）
Section titled “表示数据头部字段（以前称为实体头部字段）”列出资源支持的 HTTP 方法集合。通常与 405 (Method Not Allowed) 响应一起发送。
Example: `Allow: GET, HEAD, PUT, OPTIONS`Content-Encoding
Section titled “Content-Encoding”指定应用于实体主体（entity-body）的编码转换（例如，压缩）。
Example: `Content-Encoding: gzip` or `Content-Encoding: br`Content-Language
Section titled “Content-Language”描述封闭实体（entity）的目标受众的自然语言。
Example: `Content-Language: en-US, fr-CA`Content-Length
Section titled “Content-Length”指示实体主体（entity-body）的大小，以十进制字节（octets）为单位。
Example: `Content-Length: 3495`Content-Location（较少见）
Section titled “Content-Location（较少见）”指示返回数据的备用位置（有时在内容协商发生时使用）。
Content-MD5（已废弃）
Section titled “Content-MD5（已废弃）”实体主体（entity-body）的 Base64 编码二进制 MD5 摘要，用于检查消息完整性。已很大程度上废弃，转而使用 Digest 或依赖 TLS 来保证完整性。
Content-Range
Section titled “Content-Range”与部分实体主体（partial entity-body）（206 Partial Content 状态）一起发送，指定部分主体应在完整实体主体中的哪个位置应用。
Example: `Content-Range: bytes 21010-47021/47022` (总共 47022 字节中的 21010-47021 字节)Content-Type
Section titled “Content-Type”指示发送给接收者的实体主体（entity-body）的媒体类型（MIME type）。
Example: `application/json; charset=utf-8``Content-Type: image/png`Content-Security-Policy (CSP)
Section titled “Content-Security-Policy (CSP)”一个强大的安全头部字段，通过允许 Web 管理员控制用户代理允许加载的资源，有助于防止跨站脚本（XSS）、点击劫持（clickjacking）和其他代码注入攻击。
Example: `Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com`Expires（传统用法）
Section titled “Expires（传统用法）”给出响应被认为过时的日期/时间。对于 HTTP/1.1 及更高版本，推荐使用 Cache-Control: max-age。
Last-Modified
Section titled “Last-Modified”源服务器认为资源最后修改的日期和时间。用作缓存的验证器。
Example: `Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT`