一文读懂Http Headers为何物(超详细)

HodgeJoyce 发布于1年前

一、HTTP 请求内容

由于最新的http2,并没有被各大浏览器广泛使用,所以本文是基于http/1.1所编写的。
同时经过检测我们也发现,chrome等浏览器也正是使用http/1.1版本的。

图片描述
关于http/1.1协议的详情,可查看官方文档

我们打开chrome的network,点击任何一条request请求,即可发现,每个http headers都包含以下部分:Genaral,Response Headers,

General(不属于headers,只用于收集请求url和响应的status等信息)
clipboard.png

Request Headers(请求headers)
clipboard.png

Response Headers(响应headers)
clipboard.png

Request Payload(请求参数)

clipboard.png

二、HTTP Headers分类

在http heanders中,为了方便,分为以下几类:Genaral headers(和上面说的General不同,这个只是为了方便统计),Request Headers,Response Headers,Entity Headers(也是为了方便统计)。

clipboard.png

1、Genaral headers: 同时适用于请求和响应消息,但与最终消息主体中传输的数据无关的消息头。
2、Request Headers: 包含更多有关要获取的资源或客户端本身信息的消息头。
3、Response Headers:包含有关响应的补充信息,如其位置或服务器本身(名称和版本等)的消息头
4、Entity Headers:包含有关实体主体的更多信息,比如主体长(Content-Length)度或其MIME类型(用于响应header中)。

1、Genaral headers

Cache-Control——控制缓存的行为; 详情
Connection——决定当前的事务完成后,是否会关闭网络连接; 详情
Date——创建报文的日期时间; 详情
Keep-Alive——用来设置超时时长和最大请求数; 详情
Via——代理服务器的相关信息; 详情
Warning——错误通知; 详情
Trailer——允许发送方在分块发送的消息后面添加额外的元信息; 详情
Transfer-Encoding——指定报文主体的传输编码方式; 详情
Upgrade——升级为其他协议;

2、Request headers

Accept——客户端可以处理的内容类型; 详情
Accept-Charset——客户端可以处理的字符集类型; 详情
Accept-Encoding——客户端能够理解的内容编码方式; 详情
Accept-Language——客户端可以理解的自然语言; 详情
Authorization——Web 认证信息; 详情
Cookie——通过Set-Cookie设置的值; 详情
DNT——表明用户对于网站追踪的偏好; 详情
From——用户的电子邮箱地址; 详情
Host——请求资源所在服务器; 详情
If-Match——比较实体标记(ETag); 详情
If-Modified-Since——比较资源的更新时间; 详情
If-None-Match——比较实体标记(与 If-Match 相反); 详情
If-Range——资源未更新时发送实体 Byte 的范围请求; 详情
If-Unmodified-Since——比较资源的更新时间(与 If-Modified-Since 相反); 详情
Origin——表明了请求来自于哪个站点; 详情
Proxy-Authorization——代理服务器要求客户端的认证信息; 详情
Range——实体的字节范围请求; 详情
Referer——对请求中 URI 的原始获取方; 详情
TE——指定用户代理希望使用的传输编码类型; 详情
Upgrade-Insecure-Requests——表示客户端优先选择加密及带有身份验证的响应; 详情
User-Agent——浏览器信息; 详情

3、Response Headers

Accept-Ranges——是否接受字节范围请求; 详情
Age——消息对象在缓存代理中存贮的时长,以秒为单位; 详情
Clear-Site-Data——表示清除当前请求网站有关的浏览器数据(cookie,存储,缓存); 详情
Content-Security-Policy——允许站点管理者在指定的页面控制用户代理的资源; 详情
Content-Security-Policy-Report-Only—— 详情
ETag——资源的匹配信息; 链接描述
Location——令客户端重定向至指定 URI; 详情
Proxy-Authenticate——代理服务器对客户端的认证信息; 详情
Public-Key-Pins——包含该Web 服务器用来进行加密的 public key (公钥)信息; 详情
Public-Key-Pins-Report-Only——设置在公钥固定不匹配时,发送错误信息到report-uri; 详情
Referrer-Policy——用来监管哪些访问来源信息——会在 Referer 中发送; 详情
Server——HTTP 服务器的安装信息; 详情
Set-Cookie——服务器端向客户端发送 cookie; 详情
Strict-Transport-Security——它告诉浏览器只能通过HTTPS访问当前资源; 详情
Timing-Allow-Origin——用于指定特定站点,以允许其访问Resource Timing API提供的相关信息; 详情
Tk——显示了对相应请求的跟踪情况; 详情
Vary——服务器缓存的管理信息; 详情
WWW-Authenticate——定义了使用何种验证方式去获取对资源的连接; 详情
X-XSS-Protection——当检测到跨站脚本攻击 (XSS)时,浏览器将停止加载页面; 详情

4、Entity Headers

Allow——客户端可以处理的内容类型,这种内容类型用MIME类型来表示; 详情
Content-Encoding——用于对特定媒体类型的数据进行压缩; 详情
Content-Language——访问者希望采用的语言或语言组合; 详情
Content-Length——发送给接收方的消息主体的大小; 详情
Content-Location——替代对应资源的 URI; 详情
Content-Range——实体主体的位置范围; 详情
Content-Type——告诉客户端实际返回的内容的内容类型; 详情
Expires——包含日期/时间, 即在此时候之后,响应过期; 详情
Last-Modified——资源的最后修改日期时间; 详情

三、HTTP 具体应用

1、Cookie

HTTP 协议是无状态的,主要是为了让 HTTP 协议尽可能简单,使得它能够处理大量事务。HTTP/1.1 引入 Cookie 来保存状态信息。

Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据,它会在浏览器之后向同一服务器再次发起请求时自动被携带上,用于告知服务端两个请求是否来自同一浏览器。由于之后每次请求都会需要携带 Cookie 数据,因此会带来额外的性能开销(尤其是在移动环境下)。

Cookie 曾一度用于客户端数据的存储,因为当时并没有其它合适的存储办法而作为唯一的存储手段,但现在随着现代浏览器开始支持各种各样的存储方式,Cookie 渐渐被淘汰。新的浏览器 API 已经允许开发者直接将数据存储到本地,如使用 Web storage API(本地存储和会话存储)或 IndexedDB。

a、创建过程

服务器发送的响应报文包含Set-Cookie首部字段,客户端得到响应报文后把 Cookie 内容保存到浏览器中。

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: PHPSESSID=kq8v6iujarsgflkeq7shmai9c7

客户端之后对同一个服务器发送请求时,会从浏览器中取出 Cookie 信息并通过 Cookie 请求首部字段发送给服务器。

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: PHPSESSID=kq8v6iujarsgflkeq7shmai9c7

b、分类

会话期 Cookie:浏览器关闭之后它会被自动删除,也就是说它仅在会话期内有效。
持久性 Cookie:指定一个特定的过期时间(Expires)或有效期(max-age)之后就成为了持久性的 Cookie。
安全 Cookie:指定HttpOnly,这样cookie不能使用 JavaScript 经由 Document.cookie 属性,来防范跨站脚本攻击(XSS)。
HTTPS Cookie: 指定Secure,只有在请求使用SSL和HTTPS协议的时候才会被发送到服务器。
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;HttpOnly
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;Secure

2、缓存

降低客户端获取资源的延迟:缓存通常位于内存中,读取缓存的速度更快。并且缓存在地理位置上也有可能比源服务器来得近,例如浏览器缓存。

实现方法:
1、让代理服务器进行缓存;
2、让客户端浏览器进行缓存

a、使用 Cache-Control来控制缓存

禁止进行缓存。
no-store 规定不能对请求或响应的任何一部分进行缓存

Cache-Control: 

强制确认缓存。
no-cache 指令规定缓存服务器需要先向源服务器验证缓存资源的有效性,只有当缓存资源有效才将能使用该缓存对客户端的请求进行响应。

Cache-Control: no-cache

缓存过期机制。

max-age 指令出现在请求报文中,并且缓存资源的缓存时间小于该指令指定的时间,那么就能接受该缓存。
max-age 指令出现在响应报文中,表示缓存资源在缓存服务器中保存的时间。或者使用Expires
//请求中
Cache-Control: max-age=31536000
//响应中,优先处理max-age
Cache-Control: max-age=31536000
Expires: Wed, 04 Jul 2012 08:26:05 GMT

缓存验证
可以将缓存资源的值放入request header的 If-None-Match 首部,服务器收到该请求后,判断缓存资源的 值和资源的最新 值是否一致,如果一致则表示缓存资源有效,返回 304 Not Modified。并在response header中戴上 ETag 值

//请求
If-None-Match: W/"646-RJRVaOjMluW+SOAL0EThThA2lnM"
//响应
ETag: W/"646-RJRVaOjMluW+SOAL0EThThA2lnM"

后续待更...

查看原文: 一文读懂Http Headers为何物(超详细)

  • purpleswan
  • bigpanda
  • silverbutterfly
  • lazygoose