49、HTTP标准头部详解

HTTP标准头部详解

在HTTP通信中，头部信息起着至关重要的作用，它可以携带各种与请求和响应相关的信息。下面将详细介绍一些常见的HTTP标准头部。

1. 请求头部

• Accept
  • 类型 ：请求头部
  • 重要性 ：中等
  • 作用 ：客户端通过发送 Accept 头部告知服务器，它希望服务器在响应中使用的数据格式。例如，一个客户端可能希望获取JSON格式的表示，而另一个客户端可能希望获取同一数据的RDF格式表示。对于Web浏览器来说，将此信息隐藏在HTTP头部是个不错的主意，但对于Web服务客户端而言，不应仅依赖此方式。建议使用不同的URI来暴露不同的表示形式，不过这并不意味着要采用像Rails那样在URI后追加 .html 来表示HTML格式的粗略规则，但信息应该以某种方式包含在URI中。如果在此基础上还支持 Accept 头部，那就更好了。
• Accept-Charset
  • 类型 ：请求头部
  • 重要性 ：低
  • 作用 ：客户端发送 Accept-Charset 头部，告知服务器它希望服务器在响应中使用的字符集。例如，一个客户端可能希望包含日语文本的资源以UTF - 8编码表示，而另一个客户端可能希望使用Shift - JIS编码。为了减少麻烦，建议选择Unicode编码（如UTF - 8或UTF - 16）并坚持使用，因为现代客户端通常都能处理这些编码。
• Accept-Encoding
  • 类型 ：请求头部
  • 重要性 ：中到高
  • 作用 ：客户端发送 Accept-Encoding 头部，告知服务器可以使用像 compress 或 gzip 这样的知名算法压缩响应实体主体，从而节省带宽。需要注意的是，此头部与字符集编码无关，字符集编码由 Accept-Charset 头部处理。从技术上讲， Accept-Encoding 可用于对实体主体应用其他类型的转换，但实际上主要用于数据压缩。
• Accept-Language
  • 类型 ：请求头部
  • 重要性 ：低
  • 作用 ：客户端发送 Accept-Language 头部，告知服务器它希望服务器在响应中使用的人类语言。与媒体类型类似，建议Web服务使用不同的URI来暴露给定资源的不同语言表示形式，在此基础上支持 Accept-Language 头部则是额外的优势。
• Authorization
  • 类型 ：请求头部
  • 重要性 ：非常高
  • 作用 ：此请求头部包含授权凭证，如用户名和密码，客户端根据某种约定的方案对其进行编码。服务器对凭证进行解码，并决定是否执行请求。理论上，这是唯一需要的授权头部（除了在不同层面工作的 Proxy-Authorization ），因为它具有可扩展性。最常见的方案是HTTP Basic和HTTP Digest，但只要客户端和服务器都理解，方案可以是任意的。实际上，HTTP本身已经得到扩展，出现了像 X - WSSE 这样基于 Authorization 的非官方请求头部。

2. 响应头部

• Accept-Ranges
  • 类型 ：响应头部
  • 重要性 ：低到中等
  • 作用 ：服务器发送此头部，表明它支持对请求的URI进行部分HTTP GET操作。客户端可以先对URI发送HEAD请求，解析此响应头部的值，然后再向同一URI发送GET请求，并提供适当的 Range 头部。
• Age
  • 类型 ：响应头部
  • 重要性 ：低
  • 作用 ：如果响应实体主体不是直接从服务器获取的新鲜内容， Age 头部表示它离开服务器的时间。此头部通常由HTTP缓存设置，以便客户端知道它可能获取的是旧版本的表示。
• Allow
  • 类型 ：响应头部
  • 重要性 ：潜在高，目前低
  • 作用 ：该头部在响应 OPTIONS 请求时发送，告知客户端特定URI所暴露的统一接口的子集。如果人们开始使用 OPTIONS 方法，此头部将变得更加重要。
• Content-Encoding
  • 类型 ：响应头部
  • 重要性 ：中到高
  • 作用 ：此响应头部是请求头部 Accept-Encoding 的对应部分。请求头部要求服务器使用特定算法压缩实体主体，而此头部则告知客户端服务器实际使用的算法（如果有）。
• Content-Language
  • 类型 ：响应头部
  • 重要性 ：中等
  • 作用 ：此响应头部是 Accept-Language 请求头部的对应部分，或者与资源URI中设置的相应变量对应。它指定了人类为理解实体主体内容所需理解的自然语言。这里可能会列出多种语言，例如，如果实体主体是带有日文字幕的普通话电影， Content-Language 的值可能是“zh - guoyu,jp”。如果电影中仅出现一个英语短语，“en”可能不会出现在 Content-Language 头部中。
• Content-Length
  • 类型 ：响应头部
  • 重要性 ：高
  • 作用 ：此响应头部以字节为单位给出实体主体的大小。这很重要，原因有二：一是客户端可以根据此信息为小或大的实体主体做好准备；二是客户端可以通过发送HEAD请求来了解实体主体的大小，而无需实际请求它。 Content-Length 的值可能会影响客户端决定是获取整个实体主体、使用 Range 获取部分内容还是不获取。
• Content-Location
  • 类型 ：响应头部
  • 重要性 ：低
  • 作用 ：此头部告知客户端它所请求资源的规范URI。与 Location 头部的值不同，这纯粹是信息性的，不期望客户端开始使用新的URI。这对于为同一资源的不同表示形式分配不同URI的服务特别有用。如果客户端想要链接到资源的通用版本，而不依赖于任何特定表示形式，它可以使用 Content-Location 中给出的URI。
• Content-MD5
  • 类型 ：响应头部
  • 重要性 ：低到中等
  • 作用 ：这是实体主体的加密校验和。客户端可以使用它来检查实体主体在传输过程中是否损坏。但攻击者（如中间人）可以更改实体主体并相应更改 Content-MD5 头部，因此它仅用于错误检测，而非安全目的。
• Content-Range
  • 类型 ：响应头部
  • 重要性 ：低到中等
  • 作用 ：当客户端使用 Range 请求头部进行部分GET请求时，此响应头部说明客户端正在获取的表示部分。
• Content-Type
  • 类型 ：响应头部
  • 重要性 ：非常高
  • 作用 ：这无疑是最著名的响应头部。它告知客户端实体主体的类型。在人类Web中，Web浏览器使用此头部来决定是否可以内联显示实体主体，以及如果不能显示则需要运行哪个外部程序。在可编程Web中，Web服务客户端通常使用此头部来决定对实体主体应用哪个解析器。
• Date
  • 类型 ：请求和响应头部
  • 重要性 ：请求时高，响应时必需
  • 作用 ：作为请求头部，它表示客户端发送请求时的时间；作为响应头部，它表示服务器完成请求时的时间。作为响应头部， Date 头部被缓存使用。
• ETag
  • 类型 ：响应头部
  • 重要性 ：非常高
  • 作用 ： ETag 的值是一个不透明的字符串，用于指定表示的特定版本。每当表示发生变化时， ETag 也应相应改变。只要可能，此头部应在响应GET请求时发送。客户端可以在未来的条件GET请求中使用 ETag 的值作为 If-None-Match 的值。如果表示没有变化， ETag 也不会变化，服务器可以通过不再次发送表示来节省时间和带宽。条件GET请求的主要驱动因素是更简单的 Last-Modified 响应头部及其请求对应部分 If-Modified-Since 。 ETag 的主要目的是提供第二道防线。如果表示在一秒内变化两次， Last-Modified-Since 只会有一个值，而 ETag 会有两个不同的值。

3. 其他头部

• Connection
  • 类型 ：响应头部
  • 重要性 ：低
  • 作用 ：大多数HTTP响应是服务器向客户端的通信。像代理这样的中间件可以查看响应，但其中没有专门针对它们的内容。然而，服务器可以插入专门针对代理的额外头部，一个代理也可以插入针对链中下一个代理的头部。当发生这种情况时，特殊头部会在 Connection 头部中列出。这些头部适用于一台机器与另一台机器之间的TCP连接，而不是服务器与客户端之间的HTTP连接。在传递响应之前，代理应该移除特殊头部和 Connection 头部本身。当然，如果需要，它可以添加自己的特殊通信和新的 Connection 头部。例如，服务器可能在通过代理的响应中发送以下三个HTTP头部：

Content-Type: text/plain
X-Proxy-Directive: Deliver this as fast as you can!
Connection: X-Proxy-Directive

代理会移除 X-Proxy-Directive 和 Connection ，并将剩余的一个头部发送给客户端：

Content-Type: text/html

如果编写的是不使用代理的客户端， Connection 头部最可能看到的值是“close”，这表示服务器在完成此请求后将关闭TCP连接。

下面通过一个表格总结部分重要头部的信息：
| 头部名称 | 类型 | 重要性 | 作用 |
| ---- | ---- | ---- | ---- |
| Accept | 请求头部 | 中等 | 告知服务器期望的数据格式 |
| Accept-Encoding | 请求头部 | 中到高 | 告知服务器可使用的压缩算法 |
| Authorization | 请求头部 | 非常高 | 包含授权凭证 |
| Content-Type | 响应头部 | 非常高 | 告知客户端实体主体的类型 |
| ETag | 响应头部 | 非常高 | 指定表示的特定版本 |

通过对这些HTTP标准头部的了解，我们可以更好地理解HTTP通信过程中请求和响应的细节，从而在开发Web应用和Web服务时做出更合理的决策。

HTTP标准头部详解（续）

4. 条件请求头部

• If-Match
  • 类型 ：请求头部
  • 重要性 ：中等
  • 作用 ：该头部与 If-Unmodified-Since 类似，用于使除GET之外的HTTP操作成为条件操作。不同的是， If-Unmodified-Since 以时间作为值，而 If-Match 以 ETag 作为值。简单来说， If-Match 与 If-None-Match 和 ETag 的关系，就如同 If-Unmodified-Since 与 If-Modified-Since 和 Last-Modified 的关系。
• If-Modified-Since
  • 类型 ：请求头部
  • 重要性 ：非常高
  • 作用 ：此请求头部是条件HTTP GET的核心。其值是之前从对该URI的请求中获得的 Last-Modified 响应头部的值。如果自上次请求以来资源发生了变化，其新的 Last-Modified 日期会比之前的更新，这意味着 If-Modified-Since 条件满足，服务器将发送新的实体主体。如果资源未发生变化， Last-Modified 日期保持不变， If-Modified-Since 条件不满足，服务器将发送响应代码304（“Not Modified”）且不发送实体主体。也就是说，条件HTTP GET在该条件不满足时成功。由于 Last-Modified 的精度仅为一秒，仅依赖 If-Modified-Since 时，条件HTTP GET偶尔可能会给出错误结果，这也是使用 ETag 和 If-None-Match 的主要原因。
• If-None-Match
  • 类型 ：请求头部
  • 重要性 ：非常高
  • 作用 ：该头部也用于条件HTTP GET。其值是之前从对该URI的请求中获得的 ETag 响应头部的值。如果自上次请求以来 ETag 发生了变化， If-None-Match 条件满足，服务器将发送新的实体主体。如果 ETag 保持不变，条件不满足，服务器将发送响应代码304（“Not Modified”）且不发送实体主体。
• If-Range
  • 类型 ：请求头部
  • 重要性 ：低
  • 作用 ：此头部用于进行条件部分GET请求。头部的值来自之前范围请求的 ETag 或 Last-Modified 响应头部。只有当实体主体的该部分发生变化时，服务器才会发送新的范围。否则，即使实体主体的其他部分发生了变化，服务器也会发送304（“Not Modified”）。条件部分GET不太常用，因为客户端很少会先从较大的表示中获取几个字节，然后再尝试仅获取相同的字节。
• If-Unmodified-Since
  • 类型 ：请求头部
  • 重要性 ：中等
  • 作用 ：通常，客户端使用响应头部 Last-Modified 的值作为请求头部 If-Modified-Since 的值来执行条件GET请求。此头部同样采用 Last-Modified 的值，但通常用于使除GET之外的HTTP操作成为条件操作。例如，当多人都想修改某个特定资源时，你获取一个表示，进行修改后通过PUT请求发送回去。但在此期间其他人可能已经修改了该资源，你可能会收到响应代码409（“Conflict”），或者使资源进入你不期望的状态。如果你使PUT请求以 If-Not-Modified 为条件，那么如果其他人更改了资源，你的请求将始终收到响应代码417（“Precondition Failed”）。你可以重新获取表示并决定如何处理其他人修改后的新版本。此头部也可与GET一起使用，例如在 Range 头部的示例中。

5. 其他重要头部

• Last-Modified
  • 类型 ：响应头部
  • 重要性 ：非常高
  • 作用 ：此头部使条件HTTP GET成为可能。它告知客户端表示最后一次更改的时间。客户端可以跟踪此日期，并在未来请求的 If-Modified-Since 头部中使用它。在Web应用中， Last-Modified 通常是当前时间，这使得条件HTTP GET变得无用。Web服务应尽量做得更好，因为Web服务客户端经常反复向服务器请求相同的URI。
• Location
  • 类型 ：响应头部
  • 重要性 ：非常高
  • 作用 ：这是一个多功能头部，具有许多相关功能。它与3xx（“Redirection”）响应代码密切相关，许多围绕HTTP重定向的困惑都与如何解释此头部有关。此头部通常告知客户端应该使用哪个URI来访问资源，可能是因为客户端的请求创建了资源（响应代码201（“Created”）），或者导致资源的URI发生了变化（301（“Moved Permanently”））。也可能是因为客户端使用的URI不太准确，但服务器仍能识别。在这种情况下，响应代码可能是301、307（“Temporary Redirect”）或302（“Found”）。有时， Location 的值只是一个默认URI，是对模糊请求的多种可能解决方案之一，例如300（“Multiple Choices”）。有时， Location 的值指向的不是客户端试图访问的资源，而是提供补充信息的其他资源，例如303（“See Other”）。此头部只能在特定HTTP响应代码的上下文中理解。
• Max-Forwards
  • 类型 ：请求头部
  • 重要性 ：非常低
  • 作用 ：此头部主要与TRACE方法一起使用，TRACE方法用于跟踪处理客户端HTTP请求的代理。在TRACE请求中， Max-Forwards 用于限制请求可以通过的代理数量。
• Pragma
  • 类型 ：请求或响应
  • 重要性 ：非常低
  • 作用 ： Pragma 头部是客户端、服务器和中间件（如代理）之间特殊指令的位置。唯一的官方pragma是“no-cache”，在HTTP 1.1中已过时，它与为 Cache-Control 头部发送值“no-cache”相同。你可以定义自己的HTTP pragmas，但最好定义自己的HTTP头部。例如，在解释 Connection 头部时提到的 X-Proxy-Directive 头部。

6. 流程图展示请求与响应流程

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px

    A([客户端发起请求]):::startend --> B{请求头部类型}:::decision
    B -->|Accept| C(告知服务器期望的数据格式):::process
    B -->|Accept-Encoding| D(告知服务器可使用的压缩算法):::process
    B -->|Authorization| E(包含授权凭证):::process
    B -->|其他| F(其他请求头部作用):::process
    G([服务器返回响应]):::startend --> H{响应头部类型}:::decision
    H -->|Content-Type| I(告知客户端实体主体的类型):::process
    H -->|ETag| J(指定表示的特定版本):::process
    H -->|其他| K(其他响应头部作用):::process

7. 总结表格

头部类型	常见头部	重要性	主要作用
请求头部	Accept、Accept-Encoding、Authorization、If-Modified-Since等	从低到非常高	携带客户端的请求信息，如期望的数据格式、压缩算法、授权凭证、条件请求等
响应头部	Content-Type、ETag、Last-Modified、Location等	从低到非常高	携带服务器的响应信息，如实体主体类型、表示版本、最后修改时间、重定向信息等
其他头部	Connection、Pragma、Max-Forwards等	非常低到低	处理中间件通信、特殊指令、限制代理数量等

HTTP标准头部在HTTP通信中扮演着关键角色，它们为客户端和服务器之间的信息交换提供了丰富的控制和反馈机制。通过深入理解这些头部的作用和使用场景，开发者可以更好地优化Web应用和Web服务的性能、安全性和用户体验。无论是处理数据格式、授权认证、缓存控制还是条件请求，每个头部都有其独特的价值，合理运用它们能够使HTTP通信更加高效和可靠。