HTTP首部字段大全

HTTP首部字段大全

MDN Web Docs：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers

首部字段分类

类型	描述
通用首部字段	请求报文和响应报文两方都会使用的首部
请求首部字段	请求报文使用的首部
响应首部字段	响应报文使用的首部
实体首部字段	针对请求报文和响应报文的实体部分使用的首部

通用首部字段（HTTP/1.1）

Cache-Control

通过指定通用首部字段Cache-Control的指令，就能操作缓存的工作机制。

在介绍之前，先啰嗦两个容易忽视的地方：

1. 符合缓存策略时，服务器不会发送新的资源，但不是说客户端和服务器就没有会话了，客户端还是会发请求到服务器的。

2. Cache-Control除了在响应中使用，在请求中也可以使用。

指令参数是可选的，多个参数之间使用“,”进行分隔。

请求指令一览表

指令	参数	说明
no-cache	无	告知（代理）服务器不直接使用缓存，要求向源服务器发起请求
no-store	无	所有内容都不会保存到缓存
max-age=delta-seconds	必须	告知服务器客户端希望接收一个存在时间（Age）不大于delta-seconds秒的资源。
max-stale[=delta-seconds]	可省略	告知（代理）服务器客户端愿意接收一个超过缓存时间的资源。若有定义delta-seconds则为delta-seconds秒，若没有则为任意超出的时间。
min-fresh=delta-seconds	必须	告知（代理）服务器客户端希望接收一个在小于delta-seconds秒内被更新的资源。
no-transform	无	告知（代理）服务器客户端希望获取实体数据没有被转换（比如压缩）过的资源。
only-if-cached	无	告知（代理）服务器客户端希望获取缓存的内容（若有），而不用向源服务器发去请求。
cache-extention	-	自定义扩展值，若服务器不识别该值将被忽略掉。

响应指定一览表

指令	参数	说明
public	无	表明在任何情况下都得缓存资源（即使是需要http认证的资源）
private[=“filed-name”]	可省略	表明返回报文中全部或部分（若指定了field-name则为field-name的字段数据）仅开放给某些用户（服务器指定的share-user，如代理服务器）做缓存使用，其他用户则不能缓存这些数据。
no-cache	可省略	不直接使用缓存，要求向服务器发起（新鲜度校验）请求。
no-store	无	所有内容都不会被保存到缓存
no-transform	无	告知客户端缓存文件时不得对实体数据做任何改变。
only-if-cached	无	告知（代理）服务器客户端希望获取缓存的内容（若有），而不用向源服务器发去请求。
must-revalidate	无	当前资源一定是向源服务器发去验证请求的，若请求失败会返回504（而非代理服务器上的缓存）
proxy-revalidate	无	与must-revalidate类似，但仅能应用于共享缓存（如代理）
max-age=delta-seconds	必须	告知客户端该资源在delta-seconds秒内是新鲜的，无需向服务器发请求
s-maxage=delta-seconds	必须	与max-age类似，但仅应用于共享缓存（如代理）
cache-extention	-	自定义扩展值，若服务器不识别该值将被忽略掉。

no-store优先级最高
在Cache-Control 中，这些值可以自由组合，多个值如果冲突时，也是有优先级的，而no-store优先级最高。

public和private的选择

如果你用了CDN，你需要关注下这个值。CDN厂商一般会要求cache-control的值为public，提升缓存命中率。如果你的缓存命中率很低，而访问量很大的话，可以看下是不是设置了private，no-cache这类的值。如果定义了max-age，可以不用再定义public，它们的意义是一样的。

哪里设置Cache-Control

以LNMP的环境为例，一次响应经历的过程是：php-cgi解析代码并执行，将结果返回给nginx，如果nginx前面有反向代理，则会经过一次反向代理服务器，所以cache-control可能会在nginx，php-cgi，php代码，反向代理服务器这些地方地方设置。在php.ini中，有个参数是session.cache_limiter，需要注意下。在nginx中有个很常见的配置：

location ~* ^.+\.(ico|gif|jpg|jpeg|png)$ { 
            expires      30d;
	}

这个指令等同于cache-control: max-age=2592000，同时你会在响应头部看到一个etag字段，这是由于nginx默认开启，如果要关闭可以增加个配置etag off。这个etag就是我们接下要看的缓存校验字段。

缓存校验

在缓存中，我们需要一个机制来验证缓存是否有效。比如服务器的资源更新了，客户端需要及时刷新缓存；又或者客户端的资源过了有效期，但服务器上的资源还是旧的，此时并不需要重新发送。缓存校验就是用来解决这些问题的，在http 1.1 中，我们主要关注下Last-Modified 和 etag 这两个字段。

Last-Modified

服务端在返回资源时，会将该资源的最后更改时间通过Last-Modified字段返回给客户端。客户端下次请求时通过If-Modified-Since或者If-Unmodified-Since带上Last-Modified，服务端检查该时间是否与服务器的最后修改时间一致：如果一致，则返回304状态码，不返回资源；如果不一致则返回200和修改后的资源，并带上新的时间。

If-Modified-Since和If-Unmodified-Since的区别是：
If-Modified-Since：告诉服务器如果时间一致，返回状态码304
If-Unmodified-Since：告诉服务器如果时间不一致，返回状态码412

etag

单纯的以修改时间来判断还是有缺陷，比如文件的最后修改时间变了，但内容没变。对于这样的情况，我们可以使用etag来处理。
etag的方式是这样：服务器通过某个算法对资源进行计算，取得一串值(类似于文件的md5值)，之后将该值通过etag返回给客户端，客户端下次请求时通过If-None-Match或If-Match带上该值，服务器对该值进行对比校验：如果一致则不要返回资源。
If-None-Match和If-Match的区别是：
If-None-Match：告诉服务器如果一致，返回状态码304，不一致则返回资源
If-Match：告诉服务器如果不一致，返回状态码412

Connection

在HTTP/1.0 时代，每次HTTP请求和响应都发生一次TCP三次握手和四次挥手。以HTTP/1.0 时代的网络通信量来看，都是些容量很小的文本传输，所以这种方式性能没有较大问题。

可是随着互联网普及，Web网页的图片逐渐多起来。比如，使用浏览器浏览一个包含多张图片的HTML页面时，在发送HTTP请求访问HTML页面资源的同时，也会请求该HTML页面里包含的其他资源，比如图片等静态文件。因此，每次的请求都会造成无谓的TCP连接建立和断开，增加网络通信量的开销。

为了解决上述问题，HTTP/1.1和一部分的HTTP/1.0想出了持久连接的办法，即只要任意一端没有明确提出断开连接，则保持TCP连接状态。

HTTP持久连接实现手段是HTTP首部添加Connection字段

• Connection: keep-alive , 开启HTTP持久连接，HTTP 1.1默认值
• Connection: close , 关闭HTTP持久连接，HTTP 1.0默认值

Date

Pragma

HTTP/1.0 caches协议没有实现Cache-Control（在http1.1实现）， 实现了 Pragma: no-cache的功能。

请求头中如果包含pragma头的时候，服务器端会将该请求转发给源服务器。

Trailer

The Trailer header allows the sender to include additional fields at the end of chunked messages in order to supply metadata that might be dynamically generated while the message body is sent, such as a message integrity check, digital signature, or post-processing status.

一个http/1.1消息会包含一个Trailer头域，如果它利用了块（chunked）传输编码并且编码里的尾部（trailer）不为空的话。

Trailer头域值指明了在以块（chunked）传输编码消息里的尾部（trailer）里用到的头域。

Transfer-Encoding

通常，HTTP协议中使用Content-Length这个头来告知数据的长度。然而，在数据下行（服务器到客户端）的过程中，Content-Length的方式要预先在服务器中缓存所有数据，然后所有数据再一股脑儿地发给客户端。如果要一边产生数据，一边发给客户端，WEB 服务器就需要使用"Transfer-Encoding: chunked"这样的方式来代替Content-Length。

Transfer-Encoding，是一个 HTTP 头部字段，字面意思是「****传输编码****」。实际上，HTTP 协议中还有另外一个头部与编码有关：Content-Encoding(****内容编码****)。Content-Encoding 通常用于对实体内容进行压缩编码，目的是优化传输，例如用 gzip 压缩文本文件，能大幅减小体积。内容编码通常是选择性的，例如 jpg / png 这类文件一般不开启，因为图片格式已经是高度压缩过的，再压一遍没什么效果不说还浪费 CPU。

而 Transfer-Encoding 则是用来改变报文格式，它不但不会减少实体内容传输大小，甚至还会使传输变大，那它的作用是什么呢?本文接下来主要就是讲这个。我们先记住一点，Content-Encoding 和 Transfer-Encoding 二者是相辅相成的，对于一个 HTTP 报文，很可能同时进行了内容编码和传输编码。

由于 Content-Length 字段必须真实反映实体长度，****但实际应用中，有些时候实体长度并没那么好获得****，例如实体来自于网络文件，或者由动态语言生成。这时候要想准确获取长度，只能开一个足够大的 buffer，等内容全部生成好再计算。但这样做一方面需要更大的内存开销，另一方面也会让客户端等更久。
我们在做 WEB 性能优化时，有一个重要的指标叫 ****TTFB****(Time To First Byte)，它代表的是从客户端发出请求到收到响应的第一个字节所花费的时间。大部分浏览器自带的 Network 面板都可以看到这个指标，越短的 TTFB 意味着用户可以越早看到页面内容，体验越好。可想而知，服务端为了计算响应实体长度而缓存所有内容，跟更短的 TTFB 理念背道而驰。但在 HTTP 报文中，实体一定要在头部之后，顺序不能颠倒，为此我们需要一个新的机制：不依赖头部的长度信息，也能知道实体的边界。

*Transfer-Encoding: chunked*
本文主角终于再次出现了，Transfer-Encoding 正是用来解决上面这个问题的。历史上 Transfer-Encoding 可以有多种取值，为此还引入了一个名为 TE 的头部用来协商采用何种传输编码。但是最新的 HTTP 规范里，只定义了一种编码传输：分块编(chunked)。

分块编码相当简单，在头部加入 Transfer-Encoding: chunked 之后，就代表这个报文采用了分块编码。这时，报文中的实体需要改为用一系列分块来传输。每个分块包含****十六进制的长度值和数据****，****长度值独占一行****，长度不包括它结尾的 CRLF(\r\n)，也不包括分块数据结尾的 CRLF。最后一个分块长度值必须为 0，对应的分块数据没有内容，表示实体结束。

Upgrade

The HTTP 1.1 (only) Upgrade header can be used to upgrade an already established client/server connection to a different protocol (over the same transport protocol). For example, it can be used by a client to upgrade a connection from HTTP 1.1 to HTTP 2.0, or an HTTP or HTTPS connection into a WebSocket.

The Upgrade header field may be used by clients to invite a server to switch to one (or more) of the listed protocols, in descending preference order.

For example, the client might send a GET request as shown, listing the preferred protocols to switch to (in this case “example/1” and “foo/2”):

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

Note: Connection: upgrade must be set whenever Upgrade is sent.

The server can choose to ignore the request, for any reason, in which case it should just respond as though the Upgrade header had not been sent (for example, with a 200 OK).

If the server decides to upgrade the connection, it must:

1. Send back a 101 Switching Protocols response status with an Upgrade header that specifies the protocol(s) being switched to. For example:

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

2. Send a response to the original request using the new protocol (the server may only switch to a protocol with which it can complete the original request).

A server may also send the header as part of a 426 Upgrade Required response, to indicate that the server won’t perform the request using the current protocol, but might do so if the protocol is changed. The client can then request a protocol change using the process above.

Via

**Via** 是一个通用首部，是由代理服务器添加的，适用于正向和反向代理，在请求和响应首部中均可出现。这个消息首部可以用来追踪消息转发情况，防止循环请求，以及识别在请求或响应传递链中消息发送者对于协议的支持能力。

示例：

Via: 1.1 vegur
Via: HTTP/1.1 GWA
Via: 1.0 fred, 1.1 p.example.net

Warning

Warning 是一个通用报文首部，包含报文当前状态可能存在的问题。在响应中可以出现多个 Warning 首部。

一般来说， Warning 首部可以应用于任何类型的报文。然而一部分警告码（warn-code）是为缓存代理服务器定制的，并且只可以应用在响应报文中。

语法：

Warning: <warn-code> <warn-agent> <warn-text> [<warn-date>]

指令：

<warn-code>

三位数字警告码。第一位数字表示 Warning 信息在验证之后是否需要从已存储的响应中删除。

• 1xx 警告码描述了关于当前响应的新鲜度或者验证状态的警告信息，并且将会在验证之后被缓存服务器删除。
• 2xx 警告码描述了验证之后不会被修复的某些展现内容方面的警告信息，并且在验证之后不会被缓存服务器删除。

<warn-agent>

添加到 Warning 首部的服务器或者软件的名称或者伪名称（当代理不可知的时候可以用 “-” 代替）。

<warn-text>

用来描述错误信息的警告文本。

<warn-date>

可选。假如多个 Warning 被发送，那么需包含一个与 Date 首部相对应的日期字段。

警告码：

码值	文字描述	详细说明
110	Response is Stale	由缓存服务器提供的响应已过期（设置的失效时间已过）。
111	Revalidation Failed	由于无法访问服务器，响应验证失败。
112	Disconnected Operation	缓存服务器断开连接。
113	Heuristic Expiration	如果缓存服务器采用启发式方法，将缓存的有效时间设定为24小时，而在该响应的年龄超过24小时时发送。
199	Miscellaneous Warning	任意的、未明确指定的警告信息。
214	Transformation Applied	由代理服务器添加，如果它对返回的展现内容进行了任何转换，比如改变了内容编码、媒体类型等。
299	Miscellaneous Warning	与199类似，只不过指代的是持久化警告。

请求首部字段（HTTP/1.1）

Accept

Accept 请求头用来告知（服务器）客户端可以处理的内容类型，这种内容类型用MIME类型来表示。借助内容协商机制, 服务器可以从诸多备选项中选择一项进行应用，并使用 Content-Type 应答头通知客户端它的选择。浏览器会基于请求的上下文来为这个请求头设置合适的值，比如获取一个CSS层叠样式表时值与获取图片、视频或脚本文件时的值是不同的。

Accept-Charset

Accept-Charset 请求头用来告知（服务器）客户端可以处理的字符集类型。 借助内容协商机制，服务器可以从诸多备选项中选择一项进行应用， 并使用Content-Type 应答头通知客户端它的选择。浏览器通常不会设置此项值，因为每种内容类型的默认值通常都是正确的，但是发送它会更有利于识别。

如果服务器不能提供任何可以匹配的字符集的版本，那么理论上来说应该返回一个 406 （Not Acceptable，不被接受）的错误码。但是为了更好的用户体验，这种方法很少采用，取而代之的是将其忽略。

Accept-Encoding

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

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

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

Authorization

HTTP协议中的 Authorization 请求消息头含有服务器用于验证用户代理身份的凭证，通常会在服务器返回401 Unauthorized 状态码以及WWW-Authenticate 消息头之后在后续请求中发送此消息头。

语法

Authorization: <type> <credentials>

指令

<type>

验证类型。 常见的是 “基本验证（Basic）” 。其他类型包括：

• 在IANA机构注册的验证方案
• AWS服务器的验证方案 (AWS4-HMAC-SHA256)

<credentials>

如果使用“基本验证”方案，凭证通过如下步骤生成：

• 用冒号将用户名和密码进行拼接（如：aladdin:opensesame）。
• 将第一步生成的结果用 base64 方式编码(YWxhZGRpbjpvcGVuc2VzYW1l)。

其他参考：

Authorizaton头部的作用

主要用作http协议的认证。

HTTP协议的主要认证方式

• No Auth
• Basic Auth
• Digest Auth
• OAuth 1.0
• OAuth 2.0
• Hawk Authorization
• AWS Signature

HTTP协议主要的认证过程

因为http协议是无状态的，所以如果使用Authrization的方式进行认证的话，那么每次都要将认证的信息放到Authrization头部。

其他参考：

客户端发送 http 请求
服务器发现配置了 http auth，于是检查 request 里面有没有 “Authorization” 的 http header
如果有，则判断 Authorization 里面的内容是否在用户列表里面，Authorization header 的典型数据为 “Authorization: Basic jdhaHY0=”，其中 Basic 表示基础认证， jdhaHY0= 是 base64 编码的 “user:passwd” 字符串。
如果没有，或者用户密码不对，则返回 http code 401 页面给客户端。
标准的 http 浏览器在收到 401 页面之后，应该弹出一个对话框让用户输入帐号密码；并在用户点确认的时候再次发出请求，这次请求里面将带上 Authorization header