图解HTTP读书笔记-（HTTP首部）

6.1 HTTP报文首部

HTTP 协议的请求和响应报文中必定包含 HTTP 首部。首部内容为客户端和服务器分别处理请求和响应提供所需要的信息。

HTTP请求报文：

在请求中，HTTP报文由方法、URI、HTTP版本、HTTP首部字段等部分组成。 

 

HTTP响应报文：

HTTP响应报文：在响应中，HTTP报文由HTTP版本、状态码（数字和原因短语）、HTTP首部字段3部分组成。

 

在报文众多的字段当中，HTTP 首部字段包含的信息最为丰富。首部字段同时存在于请求和响应报文内，并涵盖 HTTP 报文相关的内容信息。

6.2 HTTP首部字段

HTTP首部字段传递重要信息

在客户端与服务器之间以 HTTP 协议进行通信的过程中，无论是请求还是响应都会使用首部字段，它能起到传递额外重要信息的作用。

使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容。

 

HTTP 首部字段是由首部字段名和字段值构成的，中间用冒号“:” 分隔。

4 种 HTTP 首部字段类型：

1）通用首部字段（General Header Fields） 
请求报文和响应报文两方都会使用的首部。

2）请求首部字段（Request Header Fields） 
从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息 。 
3）响应首部字段（Response Header Fields） 
从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。

4）实体首部字段（Entity Header Fields） 
针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。

End-to-end首部和Hop-by-hop首部

HTTP 首部字段将定义成缓存代理和非缓存代理的行为，分成 2 种类型。

1）端到端首部（End-to-end Header） 
分在此类别中的首部会转发给请求 / 响应对应的最终接收目标，且必须保存在由缓存生成的响应中，另外规定它必须被转发。

2）逐跳首部（Hop-by -hop Header） 
分在此类别中的首部只对单次转发有效，会因通过缓存或代理而不再转发。HTTP/1.1 和之后版本中，如果要使用 hop-by-hop 首部，需提供 Connection 首部字段。 
下面列举了 HTTP/1.1 中的逐跳首部字段。除这 8 个首部字段之外，其他所有字段都属于端到端首部。

Connection

Keep-A live

Proxy -A uthenticate

Proxy -A uthorization

Trailer

TE

Transfer-Encoding

Upgrade

6.3 HTTP1.1 通用首部字段

通用首部字段是指，请求报文和响应报文双方都会使用的首部。包含字段及作用如下：

Cache-Control：

通过指定首部Cache-Control的指令，就可以操作缓存的工作机制。如no-cache，public等。首部字段 Cache-Control 能够控制缓存的行为。

Connection：

主要有两个作用，控制不再转发给代理的首部字段、管理持久连接。

http1.1版本默认的是长链接，当服务端想明确断开链接的时候，则指定connection的字段值为close。

Date：

表明创建HTTP报文和日期。

pragma ：

报文指令。与http1.1之前的版本兼容。

Trailer：

首部字段Trailer会事先说明在报文主体后记录了哪些首部字段，可以应用在HTTP1.1版本分块传输编码时使用。

Transfer-Encoding：

规定了传输报文主体时采用的编码方式。

HTTP1.1的传输编码方式仅对分块传输编码有效。

Upgrade：

用于检测HTTP协议及其他协议是否可以使用更高版本进行通信。

Via ：

追踪客户端与服务器之间的请求响应和响应报文的传输途径。还可以避免请求回环的发生。

Warning：

告知用户一些与缓存相关问题的警告。

6.4 请求首部字段

请求首部字段是从客户端往服务器端发送请求报文中所使用的字段，用于补充请求的附加信息、客户端信息、对响应内容相关优先级等内容。

ACCept

通知服务器，用户代理能够处理的媒体类型及媒体类型的相对优先级。

可以使用type/subtype这种形式一次指定多种媒体类型。

优先级用q表示，范围在0-1之间，不指定默认为q=1.0。

Accept-charset:

通知服务器，用户代理支持的字符集及字符集优先级。

Accept-coding：

通知服务器，用户代理支持的内容编码及内容编码的优先级顺序。

常见的编码格式有：Gzip（GNU zip）,compress(unix 标准压缩),deflate（zlib）,identity(不进行编码)

Accept-language:

通知服务器，用户代理支持的自然语言集及自然语言集的相对优先级。

Authorization:

用户代理的认证信息，通常是服务端返回的状态码401有关。

Except：

客户端使用Except来告知服务器期待某些特殊的的行为，服务器无法理解客户端的期望二发生错误时，返回错误状态码417.

From:

告知服务器使用用户代理的用户电子邮件地址。

Host：

请求资源所处的互联网主机名跟端口号。HTTP1.1协议规范唯一要求是请求内必需包含的字段。若服务器没有涉及主机名，则可为空值。

IF-match：

属于条件请求，只有当服务器判断指定条件为真时，才会执行请求。

在请求方法为 GET 和 HEAD 的情况下，服务器仅在请求的资源满足此首部列出的 ETag 之一时才会返回资源。而对于 PUT 或其他非安全方法来说，只有在满足条件的情况下才可以将资源上传。

The comparison with the stored ETag 之间的比较使用的是强比较算法，即只有在每一个比特都相同的情况下，才可以认为两个文件是相同的。在 ETag 前面添加    W/ 前缀表示可以采用相对宽松的算法。

以下是两个常见的应用场景：

For GET  和 HEAD 方法，搭配  Range首部使用，可以用来保证新请求的范围与之前请求的范围是对同一份资源的请求。如果  ETag 无法匹配，那么需要返回 416 (Range Not Satisfiable，范围请求无法满足) 响应。

对于其他方法来说，尤其是 PUT, If-Match 首部可以用来避免更新丢失问题。它可以用来检测用户想要上传的不会覆盖获取原始资源之后做出的更新。如果请求的条件不满足，那么需要返回  412 (Precondition Failed，先决条件失败) 响应。

If-Modified-Since:

If-Modified-Since 是一个条件式请求首部，服务器只在所请求的资源在给定的日期时间之后对内容进行过修改的情况下才会将资源返回，状态码为 200  。如果请求的资源从那时起未经修改，那么返回一个不带有消息主体的  304  响应，而在 Last-Modified 首部中会带有上次修改时间。 不同于  If-Unmodified-Since, If-Modified-Since 只可以用在 GET 或 HEAD 请求中。

用途：确认代理或客户端本地资源的有效性。

If-None-Match :

If-None-Match 是一个条件式请求首部。作用于if-match相反，对于 GETGET 和 HEAD 请求方法来说，当且仅当服务器上没有任何资源的 ETag 属性值与这个首部中列出的相匹配的时候，服务器端会才返回所最新的资源，响应码为  200  。对于其他方法来说，当且仅当最终确认没有已存在的资源的  ETag 属性值与这个首部中所列出的相匹配的时候，才会对请求进行相应的处理。

作用于If-Modified-Since 类似，If-None-Match 优先级更高。

If-range:

HTTP 请求头字段用来使得 Range 头字段在一定条件下起作用：当字段值中的条件得到满足时，Range 头字段才会起作用，同时服务器回复206 部分内容状态码，以及Range 头字段请求的相应部分；如果字段值中的条件没有得到满足，服务器将会返回 200 OK 状态码，并返回完整的请求资源。

作者还举了使用if-range的场景。

If-Unmodified-Since 

作用于If-Modified-Since相反，也是条件式请求：只有当资源在指定的时间之后没有进行过修改的情况下，服务器才会返回请求的资源，或是接受 POST 或其他 non-safe 方法的请求。如果所请求的资源在指定的时间之后发生了修改，那么会返回 412 (Precondition Failed) 错误。

常见场景：

与 non-safe 方法如 POST 搭配使用，可以用来优化并发控制，例如在某些wiki应用中的做法：假如在原始副本获取之后，服务器上所存储的文档已经被修改，那么对其作出的编辑会被拒绝提交。

Max-forwards:

最大代理数，每经过一个代理，就会-1.当数值为0时返回响应。

Proxy-Authorization

Proxy-Authorization 是一个请求首部，其中包含了用户代理提供给代理服务器的用于身份验证的凭证。这个首部通常是在代理服务器返回了 407 Proxy Authentication Required 响应状态码及 Proxy-Authenticate 首部后发送的。

这个是客户端与代理服务器直接的认证，与HTTP的客户端与服务器认证类似，Authentication起相同作用。

Range 

对于一个只获取部分资源的范围请求，The Range 是一个请求首部，告知服务器返回文件的指定范围。在一个  Range 首部中，可以一次性请求多个部分，服务器会以 multipart 文件的形式将其返回。

如果服务器返回的是范围响应，需要使用 206 Partial Content 状态码。假如所请求的范围不合法，那么服务器会返回  416 Range Not Satisfiable 状态码，表示客户端错误。服务器允许忽略  Range  首部，从而返回整个文件，状态码用 200 

Referer 

首部包含了当前页面的来源页面的地址。

首部拥有暴露用户的浏览历史的潜在性，涉及到用户的隐私问题。

在以下两种情况下，Referer 不会被发送：

来源页面采用的协议为表示本地文件的 "file" 或者 "data" URI；

当前请求采用的是非安全协议，而来源页面采用的是安全协议（HTTPS）。

Referer是个错误拼写。

TE：

TE 请求型头部能够告知服务器客户端能够处理响应的传输编码方式及相对优先级。

类似于Accept-encoding,但是用于传输编码。

还可以指定伴随tailer字段的分块传输编码方式。

（不太理解）

User-Agent：

首部包含了一个特征字符串，用来让网络协议的对端来识别发起请求的用户代理软件的应用类型、操作系统、软件开发商以及版本号。

6.5 响应字段首部：

Accept-Ranges：

服务器使用 HTTP 响应头 Accept-Range 标识告知客户端自身支持范围请求。可指定的字段值有两种：可处理范围请求时指定其为bytes,反之指定为none.

Age :

告知客户端源服务器多久前创建了响应，若创建该响应的服务器是缓存服务器，则age表示消息对象在缓存代理中存贮的时长，以秒为单位。.

ETAG：

它是一种可以将资源以字符串的形式做唯一标识的方式，服务器会为没分资源分配对应的Etag值。当资源更新时，etag值会更新。

作用：这可以让缓存更高效，并节省带宽，因为如果内容没有改变，Web服务器不需要发送完整的响应。而如果内容发生了变化，使用ETag有助于防止资源的同时更新相互覆盖（“空中碰撞”）。

Etag值有强弱之分：强etag值实体任何属性变化都会改变。弱tag值只有资源发生了根本改变，才会改变etag值。字段开始以“W/”标识.

Location

Location 首部指定的是需要将页面重新定向至的地址。一般在响应码为3xx的响应中才会有意义。

发送新请求，获取Location指向的新页面所采用的方法与初始请求使用的方法以及重定向的类型相关。

 Proxy-Authenticate

 Proxy-Authenticate 是一个响应首部，指定了获取 proxy server （代理服务器）上的资源访问权限而采用的身份验证方式。代理服务器对请求进行验证，以便它进一步传递请求。

Proxy-Authenticate 首部需要与 407 Proxy Authentication Required 响应一起发送。

注意它是客户端与代理服务器之间的认证行为。

Retry-After

 Retry-After 告知客户端需要等待多长时间之后才能继续发送请求。这个首部主要应用于 以下两种场景：

》当与 503 (Service Unavailable，当前服务不存在) 响应一起发送的时候，表示服务下线的预期时长。

》当与重定向响应一起发送的时候，比如 301 (Moved Permanently，永久迁移)，表示用户代理在发送重定向请求之前需要等待的最短时间。

字段值可以是具体时间，也可以是创建响应后的秒数。

Server：

Server会告知客户端当前服务器上安装HTTP服务器应用程序的信息。

应该避免使用过长或者过于详细的描述作为 Server 的值，因为这有可能泄露服务器的内部实现细节，有利于攻击者找到或者探测已知的安全漏洞。

Vary：

可对缓存进行控制，它决定了对于未来的一个请求头，应该用一个缓存的回复(response)还是向源服务器请求一个新的回复。它被服务器用来表明在 content negotiation algorithm（内容协商算法）中选择一个资源代表的时候应该使用哪些头部信息（headers）.

WWW-Authenticate ：

用户HTTP访问认证，它会告知客户端适用于访问请求URI所指定资源的认证方案（basic或digest）和待参数提示的质询。WWW-Authenticate header通常会和一个 401 Unauthorized 的响应一同被发送.

6.6 实体首部字段

实体首部字段是包含在请求报文和响应报文实体部分所使用的首部，用于补充内容的更新时间等和实体有关的信息。

Allow ：

首部字段用于通知客户端能够支持request-URI指定资源所支持的 HTTP 方法的集合。当服务器接收到不支持的方法时，会返回返回状态码 405 Method Not Allowed。

Content-Encoding：

表示告知客户端服务器对消息主体进行了何种方式的内容编码转换。这个消息首部用来告知客户端应该怎样解码才能获取在 Content-Type 中标示的媒体类型内容。

Content-Language：

 

 

告知客户端，实体主体使用的自然语言（中英文等）

Content-Length ：

用来指明发送给接收方的消息主体的大小，即用十进制数字表示的八位元组的数目。

对实体主体进行内容编码传输时，不能再使用content-length首部字段。

Content-Location： 

指定的是要返回的数据的地址选项。最主要的用途是用来指定要访问的资源经过内容协商后的结果的URL。

Location 与 Content-Location是不同的，前者（Location ）指定的是一个重定向请求的目的地址（或者新创建的文件的URL），而后者（ Content-Location） 指向的是可供访问的资源的直接地址，不需要进行进一步的内容协商。Location 对应的是响应，而Content-Location对应的是要返回的实体。

Content-MD5：

HTTP中Content-MD5即一串由MD5算法生成的值，其目的在于检查报文主体在传输过程中是否保持完整，以确认消息传输到达。对报文主体执行MD5算法获得128位二进制数后，HTTP首部无法记录二进制值，所以还要通过Base64编码处理。

这里有相关知识点：MD5，Base64，ASCII，UTF8等编码先关。

当然作者还介绍了Content-MD5无法检测恶意篡改，因为内容可改，对应的md5也会重新计算。

 Content-Range：

  显示的是一个数据片段在整个文件中的位置。字段值一字节为单位。

Content-type：

实体头部用于指示资源的MIME的媒体类型 。

Expires ：

将资源的失效日期告诉客户端， 在这个日期/时间之后，HTTP响应被认为是过时的；

源服务器不希望缓存服务器资源时，最好在Expires字段设置有首部字段Date相同的值。 如果还有一个 设置了 "max-age" 或者 "s-max-age" 指令的Cache-Control响应头，那么  Expires 头就会被忽略。

Last-Modified ：

其中包含源头服务器认定的资源做出修改的日期及时间。 它通常被用作一个验证器来判断接收到的或者存储的资源是否彼此一致。由于精确度比  ETag 要低，所以这是一个备用机制。包含有  If-Modified-Since 或 If-Unmodified-Since 首部的条件请求会使用这个字段。

6.7 为cookie服务的首部字段

Cookie的工作机制就是用户识别及状态管理。

Set-Cookie：

 Expires=<date> 

cookie 的最长有效时间，形式为符合 HTTP-date 规范的时间戳。如果没有设置这个属性，那么表示这是一个会话期 cookie 。一个会话结束于客户端被关闭时，这意味着会话期 cookie 在彼时会被移除。然而，很多Web浏览器支持会话恢复功能，这个功能可以使浏览器保留所有的tab标签，然后在重新打开浏览器的时候将其还原。与此同时，cookie 也会恢复，就跟从来没有关闭浏览器一样。

Path=<path-value> 

指定一个 URL 路径，这个路径必须出现在要请求的资源的路径中才可以发送 Cookie 首部。字符  %x2F ("/") 可以解释为文件目录分隔符，此目录的下级目录也满足匹配的条件。

Domain=<domain-value> 

指定 cookie 可以送达的主机名。假如没有指定，那么默认值为当前文档访问地址中的主机部分（但是不包含子域名）。与之前的规范不同的是，域名之前的点号会被忽略。假如指定了域名，那么相当于各个子域名也包含在内了

Secure ：

一个带有安全属性的 cookie ，只有在请求使用SSL和HTTPS协议的时候才会被发送到服务器。

HttpOnly ：

设置了 HttpOnly 属性的 cookie 不能使用 JavaScript 经由  Document.cookie 属性、XMLHttpRequest 和  Request APIs 进行访问，以防范跨站脚本攻击（XSS）。

Cookie：

Cookie 是一个请求首部，其中含有先前由服务器通过 Set-Cookie  首部投放并存储到客户端的 HTTP cookies。