HTTP：header头总结

小鱼儿 2022-09-03 04:28 209阅读 0赞

# Header #

**端到端标头**：

*  这些标头必须传输到消息的最终接收者：请求的服务器，或响应的客户端。
 *  中间代理必须未经修改地重新传输这些标头，并且缓存必须存储它们。

**逐跳报头**

*  这些标头仅对单个传输级连接有意义，并且不得由代理重新传输或缓存。
 *  请注意，只能使用`Connection`首部设置逐跳首部。

# Upgrade #

*  用于将已建立的客户端/服务器连接升级到不同的协议。
 *  例如，客户端可以使用它来将连接从 HTTP 1.1 升级到 HTTP 2.0，或者将 HTTP 或 HTTPS 连接升级为 WebSocket。

> `Upgrade`仅可以在HTTP/1.1中使用。HTTP/2 明确禁止使用此机制/标头

客户端可以使用Upgrade header字段邀请服务器以降序优先顺序切换到列出的一个（或多个）协议。

例如，客户端可能会发送如下请求，列出要切换到的首选协议（在本例中为“example/1”和“foo/2”）：

GET /index.html HTTP/1.1
    Host: www.example.com
    Connection: upgrade
    Upgrade: example/1, foo/2

> 注意，如果发送了`Upgrade`那么就一定要设置`Connection: upgrade`

服务器可以出于任何原因选择忽略该请求，在这种情况下，它应该像尚未发送升级头一样进行响应，比如200 OK

如果服务器决定升级连接，它必须：

*  响应`101 Switching Protocols`， 以及`Upgrade`指定要切换到的协议的标头，比如：

HTTP/1.1 101 Switching Protocols
    Upgrade: foo/2
    Connection: Upgrade

*  使用新协议发送对原始请求的响应

## 语法 ##

Connection: upgrade
    Upgrade: protocol_name[/protocol_version]

*  Connection带有类型的标头upgrade 必须始终与Upgrade标头一起发送
 *  协议之间以逗号分隔
 *  协议按优先级降序排列
 *  协议版本是可选的（以“/”分隔）。例如：

Connection: upgrade
      Upgrade: a_protocol/1, example ,another_protocol/2.2

## 例子 ##

Connection: upgrade
    Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

Connection: Upgrade
    Upgrade: websocket

# Proxy-Connection #

从字面上的意思看，这个字段表示和代理的连接。下面我们来具体看一下

首先我们看一下设置了浏览器代理之后HTTP的请求有哪些变化

GET / HTTP/1.1
    Host: www.example.com
    Connection: keep-alive

GET http://www.example.com/ HTTP/1.1
    Host: www.example.com
    Proxy-Connection: keep-alive

我们看到有两个变化

1.  请求的资源URI变成了完整路径
2.  Connection 头变为了 Proxy-Connection头

> 为什么需要完整路径

早期的HTTP设计中，浏览器直接和单个服务器对话，不存在虚拟主机。 所以单个服务器总知道自己的主机名和端口，这样浏览器发送请求只需要发送相对地址就可以了。如下:

GET / HTTP /1.0

有了代理就麻烦了，代理不知道GET / HTTP /1.0 这个请求发给哪个主机，所以HTTP 1.0 又要求浏览器给代理发送的时候必须发送完整的路径名称：

GET http: //www .example.com/ HTTP /1 .0

HTTP 1.1 规定了必须包含Host主机名这个字段。所以 HTTP 1.1 可以是：

GET / HTTP/1.1
    
    Host: www.example.com

但是由于不清楚代理是1.0 还是1.1的 也许代理不认识Host这个头。 所以http 1.1 发给代理的最后格式就变为

GET http://www.example.com/ HTTP/1.1
    Host: www.example.com

# Connection #

Connection 头（header） 决定当前的事务完成后，是否会关闭网络连接。如果该值是“keep-alive”，网络连接就是持久的，不会关闭，使得对同一个服务器的请求可以继续在该连接上完成。

除去标准的逐段传输（hop-by-hop）头（Keep-Alive, Transfer-Encoding, TE, Connection, Trailer, Upgrade (en-US), Proxy-Authorization and Proxy-Authenticate），任何逐段传输头都需要在 Connection 头中列出，这样才能让第一个代理知道必须处理它们且不转发这些头

## 语法 ##

Connection: keep-alive
    Connection: close

## 指令 ##

**close**：表明客户端或服务器想要关闭该网络连接，这是HTTP/1.0请求的默认值  
**keep-alive**：表明客户端想要保持该网络连接打开，HTTP/1.1的请求默认使用一个持久连接

# Keep-Alive #

`Keep-Alive`是一个通用消息头，允许消息发送者暗示连接的状态，还可以用来设置超时时长和最大请求数。

>  *  需要将 Connection 首部的值设置为 “keep-alive” 这个首部才有意义。同时需要注意的是，在HTTP/2 协议中， Connection 和 Keep-Alive 是被忽略的；在其中采用其他机制来进行连接管理。
>  *  是逐跳标头，**仅对单个传输级别连接有意义，并且不能由代理重新传输或缓存**

### 语法 ###

Keep-Alive: parameters

### 指令 ###

**parameters**：一系列用逗号隔开的参数，每一个参数由一个标识符和一个值构成，并使用等号 (’=’) 隔开。下述标识符是可用的：

*  `timeout`：指定了一个空闲连接需要保持打开状态的最小时长（以秒为单位）。需要注意的是，如果没有在传输层设置 keep-alive TCP message 的话，大于 TCP 层面的超时设置会被忽略。
 *  `MAX`：在连接关闭之前，在此连接可以发送的请求的最大值。在非管道连接中，除了 0 以外，这个值是被忽略的，因为需要在紧跟着的响应中发送新一次的请求。HTTP 管道连接则可以用它来限制管道的使用。

### 示例 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]

# Content-Length #

`Content-Length`是一个实体消息首部，用来指明发送给接收方的消息主体的大小。

## 语法 ##

Content-Length: <length>

# Accept-Encoding #

HTTP 请求头 Accept-Encoding 会将客户端能够理解的内容编码方式——通常是某种压缩算法——进行通知（给服务端）。通过内容协商的方式，服务端会选择一个客户端提议的方式，使用并在响应头 `Content-Encoding`中通知客户端该选择。

即使客户端和服务器都支持相同的压缩算法，在identity指令可以被接受的情况下，服务器也可以选择对响应主体不进行压缩。导致这种情况出现的两种常见情形是：

*  要发送的数据已经经过压缩，再次进行压缩不会导致被传输的数据量更小。一些图像格式的文件会存在这种情况
 *  服务器超载，无法承受压缩需求导致的计算开销。通常，如果服务器使用超过80%的计算能力，微软建议不要压缩。

只要 identity —— 表示不需要进行任何编码——没有被明确禁止使用（通过 identity;q=0 指令或是 \*;q=0 而没有为 identity 明确指定权重值），则服务器禁止返回表示客户端错误的 406 Not Acceptable 响应。

## 语法 ##

Accept-Encoding: gzip
    Accept-Encoding: compress
    Accept-Encoding: deflate
    Accept-Encoding: br
    Accept-Encoding: identity
    Accept-Encoding: *
    
    // Multiple algorithms, weighted with the quality value syntax:
    Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5

## 指令 ##

**gzip**:

*  表示采用 Lempel-Ziv coding (LZ77) 压缩算法，以及32位CRC校验的编码方式。
 *  这个编码方式最初由 UNIX 平台上的 gzip 程序采用。
 *  出于兼容性的考虑， HTTP/1.1 标准提议支持这种编码方式的服务器应该识别作为别名的 x-gzip 指令。

**compress**：

*  采用 Lempel-Ziv-Welch (LZW) 压缩算法。这个名称来自UNIX系统的 compress 程序，该程序实现了前述算法。
 *  与其同名程序已经在大部分UNIX发行版中消失一样，这种内容编码方式已经被大部分浏览器弃用，部分因为专利问题（这项专利在2003年到期）。

**deflate**：

*  采用 zlib 结构 (在 RFC 1950 中规定)，和 deflate 压缩算法(在 RFC 1951 中规定)。

**identity**：

*  用于指代自身（例如：未经过压缩和修改）。
 *  除非特别指明，这个标记始终可以被接受。

**br**：

*  表示采用 Brotli 算法的编码方式。

**`*`**：

*  匹配其他任意未在该请求头字段中列出的编码方式。
 *  假如该请求头字段不存在的话，这个值是默认值。
 *  它并不代表任意算法都支持，而仅仅表示算法之间无优先次序

**;q= (qvalues weighting)**：

*  值代表优先顺序，用**相对质量值** 表示，又称为权重
 *  相对质量值：由后缀’;q='后紧跟一个介于0和1之间的值来标记

## 示例 ##

Accept-Encoding: gzip
    
    Accept-Encoding: gzip, compress, br
    
    Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1

# Content-Encoding #

`Content-Encoding`是一个实体消息首部，用于对特定媒体类型的数据进行压缩。当这个首部出现的时候，它的值表示消息主体进行了何种方式的内容编码转换。这个消息首部用来告知客户端应该怎样解码才能获取在 `Content-Type`中标示的媒体类型内容。

一般建议对数据尽可能地进行压缩，因此才有了这个消息首部的出现。不过对于特定类型的文件来说，比如jpeg图片文件，已经是进行过压缩的了。有时候再次进行额外的压缩无助于负载体积的减小，反而有可能会使其增大。

## 语法 ##

Content-Encoding: gzip
    Content-Encoding: compress
    Content-Encoding: deflate
    Content-Encoding: identity
    Content-Encoding: br

## 示例 ##

客户端可以事先声明一系列的可以支持压缩模式，与请求一齐发送。 `Accept-Encoding`这个首部就是用来进行这种内容编码形式协商的：

Accept-Encoding: gzip, deflate

服务器在 Content-Encoding 响应首部提供了实际采用的压缩模式：

Content-Encoding: gzip

需要注意的是，服务器端并不强制要求一定使用何种压缩模式。采用哪种压缩方式高度依赖于服务器端的设置，及其所采用的模块。

# Transfer-Encoding #

`Transfer-Encoding` 消息首部指明了将 实体安全传递给用户所采用的编码形式。

`Transfer-Encoding` 是一个**逐跳传输消息首部**，即仅应用于两个节点之间的消息传递，而不是所请求的资源本身。一个多节点连接中的每一段都可以应用不同的Transfer-Encoding 值。如果你想要将压缩后的数据应用于整个连接，那么请使用**端到端传输消息首部**`Content-Encoding` 。

## 语法 ##

Transfer-Encoding: chunked
    Transfer-Encoding: compress
    Transfer-Encoding: deflate
    Transfer-Encoding: gzip
    Transfer-Encoding: identity
    
    // Several values can be listed, separated by a comma
    Transfer-Encoding: gzip, chunked

## 指令 ##

`chunked`：

*  数据以一系列分块的形式进行发送。
 *  `Content-Length` 首部在这种情况下不被发送。
 *  在每一个分块的开头需要添加当前分块的长度，以十六进制的形式表示，后面紧跟着`\r\n`，之后是分块本身，后面也是`\r\n` 。
 *  终止块是一个常规的分块，不同之处在于其长度为0.终止块后面是一个挂载（trailer），由一系列（或者为空）的实体消息首部构成。

## 示例 ##

### 分块编码 ###

分块编码主要应用于如下场景，即要传输大量的数据，但是在请求没有被处理完之前响应的长度是无法获得的。例如，当需要用从数据库中查询获得的数据生成一个大的HTML表格的时候，或者需要传输大量的图片的时候。一个分块响应形式如下：

HTTP/1.1 200 OK
    Content-Type: text/plain
    Transfer-Encoding: chunked
    
    7\r\n
    Mozilla\r\n
    9\r\n
    Developer\r\n
    7\r\n
    Network\r\n
    0\r\n
    \r\n

# Trailer #

Trailer响应头允许发送方在分块消息的末尾包含额外的字段，以提供可能在发送消息体时动态生成的元数据，如消息完整性检查、数字签名或后处理状态。

> Note: The TE request header needs to be set to “trailers” to allow trailer fields.  
> ![在这里插入图片描述][5b4a7832260c429dbebc105a4b7682bd.png]

## 语法 ##

Trailer: header-names

## 指令 ##

*  header-names：将出现在HTTP头中分块消息的尾部部分。这些头字段是运行的：
    
     *  消息帧头(例如，`Transfer-Encoding`和`Content-Length`)，
     *  路由报头(例如，`Host`)，
     *  请求修饰符(如Cache-Control,Max-Forwards，或TE)
     *  认证头(例如，Authorization或Set-Cookie)，
     *  或 Content-Encoding, Content-Type, Content-Range和它自己(Trailer)

## 示例 ##

### 使用Trailer的分块传输编码 ###

在这个例子中，Expires报头被使用在分块消息的末尾，作为一个尾随报头。

HTTP/1.1 200 OK
    Content-Type: text/plain
    Transfer-Encoding: chunked
    Trailer: Expires
    
    7\r\n
    Mozilla\r\n
    9\r\n
    Developer\r\n
    7\r\n
    Network\r\n
    0\r\n
    Expires: Wed, 21 Oct 2015 07:28:00 GMT\r\n
    \r\n

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]: /images/20220829/37e91f60ae8f4e289de397b21545aaa8.png
[5b4a7832260c429dbebc105a4b7682bd.png]: /images/20220829/c5f179fedcc943b1af02bf5c1fb4cde9.png