HTTP首部字段彻底解析

时间 2020-04-22

原文原文链接

http协议是前端开发人员最常接触到的网络协议。在开发过程当中，尤为是调试过程当中避免不了须要去分析http请求的详细信息。在这其中头部字段提供的信息最多，好比经过响应状态码咱们能够直观的看到响应的大体状态。那么你是否清楚http首部字段都有哪些，具体含义是什么，可选值又有哪些呢？看完下面的内容，我相信对于这几个问题你就会迎刃而解。html

http协议用于交互的信息被称为HTTP报文。请求端（客户端）的HTTP报文叫作请求报文，响应端（服务器端）的HTTP报文叫作响应报文。HTTP报文大体能够分为报文首部和报文主题两部分。咱们来看下请求报文和响应报文的结构。前端

从上图咱们能够看出，请求报文和响应报文的首部内容由如下数据组成。web

请求行面试

包含用于请求的方法，请求 URI 和 HTTP 版本。算法

状态行浏览器

包含代表响应结果的状态码，缘由短语和 HTTP 版本。缓存

首部字段服务器

包含表示请求和响应的各类条件和属性的各种首部。cookie

下面咱们重点来看下首部字段的一些信息，而且对最经常使用到的首部字段的含义及可选值都有哪些，分别表明什么意思进行讲解。 http首部字段类型根据实际用途被分为如下4种类型：网络

通用首部字段（General Header Fields）

请求报文和响应报文两方都会使用的首部。

请求首部报文（Request Headers Fields）

从客户端向服务端发送请求报文时使用的首部。补充了请求的附加内容，客户端信息，响应内容相关优先级等信息。

响应首部字段（Response Header Fields）

从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。

实体首部字段（Entity Header Fields）

针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体相关的信息。

其中http/1.1规范定义了47种首部字段，下面咱们按照以上的四个大类对这47种字段进行一个简要解释：

通用首部字段

首部字段名	说明
Cache-Control	控制缓存的行为
Connection	链接的管理
Date	建立报文的日期时间
Pragma	报文指令
Trailer	报文末端的首部一览
Transfer-Encoding	指定报文主体的传输编码方式
Upgrade	升级为其余协议
Via	代理服务器的相关信息
Warning	错误通知

请求首部字段

首部字段名	说明
Accept	用户代理可处理的媒体类型
Accept-Charset	优先的字符集
Accept-Encoding	优先的内容编码
Accept-Language	优先的语言（天然语言）
Authorization	Web认证信息
Expect	期待服务器的特定行为
From	用户的电子邮箱地址
Host	请求资源所在服务器
If-Match	比较实体标记（ETag）
If-Modified-Since	比较资源的更新时间
If-None-Match	比较实体标记（与 If-Match 相反）
If-Range	资源未更新时发送实体 Byte 的范围请求
If-Unmodified-Since	比较资源的更新时间（与If-Modified-Since相反）
Max-Forwards	最大传输逐跳数
Proxy-Authorization	代理服务器要求客户端的认证信息
Range	实体的字节范围请求
Referer	对请求中URI的原始获取方
TE	传输编码的优先级
User-Agent	HTTP客户端程序的信息

响应首部字段

首部字段名	说明
Accept-Ranges	是否接受字节范围请求
Age	推算资源建立通过时间
ETag	资源的匹配信息
Location	令客户端重定向至指定URI
Proxy-Authenticate	代理服务器对客户端的认证信息
Retry-After	对再次发起请求的时机要求
Server	HTTP服务器的安装信息
Vary	代理服务器缓存的管理信息
WWW-Authenticate	服务器对客户端的认证信息

实体首部字段

首部字段名	说明
Allow	资源可支持的HTTP方法
Content-Encoding	实体主体适用的编码方式
Content-Language	实体主体的天然语言
Content-Length	实体主体的大小（单位：字节）
Content-Location	替代对应资源的URI
Content-MD5	实体主体的报文摘要
Content-Range	实体主体的位置范围
Content-Type	实体主体的媒体类型
Expires	实体主体过时的日期时间
Last-Modified	资源的最后修改日期时间

经常使用首部字段分析：

1. Cache-Control 指令一览

可用的指令按请求和响应分类以下所示：

缓存请求指令：

指令	参数	说明
no-cache	无	强制向原服务器再次验证
no-store	无	不缓存请求或响应的任何内容
max-age = [ 秒]	必须	响应的最大Age值
max-stale( = [ 秒])	可省略	接收已过时的响应
min-fresh = [ 秒]	必需	指望在指定的时间内的响应仍有效
no-transform	无	代理不可更改媒体类型
only-if-cached	无	代理不可更改媒体类型
cache-extension	-	新指令标记（token）

缓存响应指令：

指令	参数	说明
public	无	可向任意方提供响应的缓存
private	可省略	仅向特定用户返回响应
no-cache	可省略	缓存前必需先确认其有效性
no-store	无	不缓存请求或响应的任何内容
no-transform	无	代理不可更改媒体类型
must-revalidate	无	可缓存但必须再向源服务器进行确认
proxy-revalidate	无	要求中间缓存服务器对缓存的响应有效性再进行确认
max-age=[秒]	必需	响应的最大Age值
s-maxage=[秒]	必需	公共缓存服务器响应的最大Age值
cache-extension	-	新指令标记（token）

从字面意思上很容易把 no-cache 误解成为不缓存，但事实上 no-cache 表明不缓存过时的资源，缓存会向源服务器进行有效期确认后处理资源，也许称为 do-notserve- from-cache-without-revalidation 更合适。no-store 才是真正地不进行缓存，请读者注意区别理解

2. Connection

Connection首部字段具有以下两个做用

控制再也不转发给代理的首部字段
管理持久链接

HTTP/1.1 版本的默认链接都是持久链接。为此，客户端会在持久链接上连续发送请求。当服务器端想明确断开链接时，则指定 Connection 首部字段的值为 Close。

Date

首部字段Date代表建立HTTP报文的日期和时间。

3. Pragma

Pragma是HTTP/1.1以前版本的历史遗留字段，仅做为与HTTP/1.0的向后兼容而定义。

规范定义的形式惟一，以下所示：

Pragma: no-cache
该首部字段属于通用首部字段，但只用在客户端发送的请求中。客户端会要求全部的中间服务器不返回缓存的资源。

全部的中间服务器若是都能以 HTTP/1.1 为基准，那直接采用 Cache- Control: no-cache 指定缓存的处理方式是最为理想的。但要总体掌握所有中间服务器使用的 HTTP 协议版本倒是不现实的。所以，发送的请求会同时含有下面两个首部字段。

Cache-Control: no-cache
Pragma: no-cache

4. Upgrade

首部字段 Upgrade 用于检测 HTTP 协议及其余协议是否可以使用更高的版本进行通讯，其参数值能够用来指定一个彻底不一样的通讯协议。

使用首部字段 Upgrade 时，还须要额外指定Connection:Upgrade。

5. Accept

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3

Accept 首部字段可通知服务器，用户代理可以处理的媒体类型及媒体类型的相对优先级。可以使用 type/subtype 这种形式，一次指定多种媒体类型。

6. Accept-Charset

Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

Accept-Charset 首部字段可用来通知服务器用户代理支持的字符集及字符集的相对优先顺序。另外，可一次性指定多种字符集。与首部字段 Accept 相同的是可用权重 q 值来表示相对优先级

7. Accept-Encoding

Accept-Encoding: gzip, deflate

Accept-Encoding 首部字段用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序。可一次性指定多种内容编码。

下面试举出几个内容编码的例子。

gzip

由文件压缩程序 gzip（GNU zip）生成的编码格式（RFC1952），采用 Lempel-Ziv 算法（LZ77）及 32 位循环冗余校验（Cyclic Redundancy Check，通称 CRC）。

compress

由 UNIX 文件压缩程序 compress 生成的编码格式，采用 Lempel- Ziv-Welch 算法（LZW）。

deflate

组合使用 zlib 格式（RFC1950）及由 deflate 压缩算法（RFC1951）生成的编码格式。

identity

不执行压缩或不会变化的默认编码格式

采用权重 q 值来表示相对优先级，这点与首部字段 Accept 相同。另外，也可以使用星号（*）做为通配符，指定任意的编码格式。

8. Accept-Language

Accept-Language: zh-cn,zh;q=0.7,en-us,en;q=0.3

首部字段 Accept-Language 用来告知服务器用户代理可以处理的天然语言集（指中文或英文等），以及天然语言集的相对优先级。可一次指定多种天然语言集。

和 Accept 首部字段同样，按权重值 q 来表示相对优先级。在上述图例中，客户端在服务器有中文版资源的状况下，会请求其返回中文版对应的响应，没有中文版时，则请求返回英文版响应。

9. If-Match

形如 If-xxx 这种样式的请求首部字段，均可称为条件请求。服务器接收到附带条件的请求后，只有判断指定条件为真时，才会执行请求。

首部字段 If-Match，属附带条件之一，它会告知服务器匹配资源所用的实体标记（ETag）值。这时的服务器没法使用弱 ETag 值。（请参照本章有关首部字段 ETag 的说明）

服务器会比对 If-Match 的字段值和资源的 ETag 值，仅当二者一致时，才会执行请求。反之，则返回状态码 412 Precondition Failed 的响应。

还可使用星号（*）指定 If-Match 的字段值。针对这种状况，服务器将会忽略 ETag 的值，只要资源存在就处理请求。

10. Referer

Referer: http://172.30.1.34:4200/

首部字段 Referer 会告知服务器请求的原始资源的 URI。

11. User-Agent

User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.87 Safari/537.36

首部字段 User-Agent 会将建立请求的浏览器和用户代理名称等信息传达给服务器。

12. Age

首部字段 Age 能告知客户端，源服务器在多久前建立了响应。字段值的单位为秒。

若建立该响应的服务器是缓存服务器，Age 值是指缓存后的响应再次发起认证到认证完成的时间值。代理建立响应时必须加上首部字段 Age。

13. ETag

首部字段 ETag 能告知客户端实体标识。它是一种可将资源以字符串形式作惟一性标识的方式。服务器会为每份资源分配对应的 ETag 值。

14. Location

使用首部字段 Location 能够将响应接收方引导至某个与请求 URI 位置不一样的资源。

基本上，该字段会配合 3xx ：Redirection 的响应，提供重定向的 URI。

几乎全部的浏览器在接收到包含首部字段 Location 的响应后，都会强制性地尝试对已提示的重定向资源的访问。

15. Content-Encoding

首部字段 Content-Encoding 会告知客户端服务器对实体的主体部分选用的内容编码方式。内容编码是指在不丢失实体信息的前提下所进行的压缩。

16. Content-Language

Content-Language: zh-CN

首部字段 Content-Language 会告知客户端，实体主体使用的天然语言（指中文或英文等语言）。

17. Content-Length

Content-Length: 15000

首部字段 Content-Length 代表了实体主体部分的大小（单位是字节）。对实体主体进行内容编码传输时，不能再使用 Content-Length 首部字段

18. Content-Type

Content-Type: text/html; charset=UTF-8

首部字段 Content-Type 说明了实体主体内对象的媒体类型。和首部字段 Accept 同样，字段值用 type/subtype 形式赋值。

19. Last-Modified

Last-Modified: Wed, 21 Aug 2019 06:18:22 GMT

首部字段 Last-Modified 指明资源最终修改的时间。通常来讲，这个值就是 Request-URI 指定资源被修改的时间。但相似使用 CGI 脚本进行动态数据处理时，该值有可能会变成数据最终修改时的时间。

20. Set-Cookie

Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31

服务器设置客户端cookie信息，以便管理客户端状态。

HttpOnly 属性

Cookie 的 HttpOnly 属性是 Cookie 的扩展功能，它使 JavaScript 脚本没法得到 Cookie。其主要目的为防止跨站脚本攻击（Cross-site scripting，XSS）对 Cookie 的信息窃取。

发送指定 HttpOnly 属性的 Cookie 的方法以下所示。

Set-Cookie: name=value; HttpOnly

经过上述设置，一般从 Web 页面内还能够对 Cookie 进行读取操做。但使用 JavaScript 的 document.cookie 就没法读取附加 HttpOnly 属性后的 Cookie 的内容了。所以，也就没法在 XSS 中利用 JavaScript 劫持 Cookie 了。

以上所列出的首部字段都是基于HTTP/1.1，到这里本文要介绍的相关知识也就结束了。对于文章开头提出的三个问题不知道你如今有没有清楚呢。最后但愿小伙伴能够在下方留言评论（对于文章的文字排版，写做技巧，相关内容均可以相互交流学习）

原文出处：https://www.cnblogs.com/xzsty/p/11452610.html