Fork me on GitHub

图解HTTP读书笔记六

发表于 | 分类于 | 本文总阅读量 次

图解HTTP协议读书笔记六-HTTP首部

HTTP协议的请求和响应报文中必定包含HTTP首部，只是我们平时在使用WEB的过程中感受不到它。

1. HTTP报文首部

报文结构

HTTP协议的请求和响应报文中必定包含HTTP首部。首部内容为客户端和服务器分别请求和响应提供所需要的信息。对于客户端用户来说，这些信息中的大部分内容都无须亲自查看。

报文首部由以下几个字段构成：

  • HTTP请求报文

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

  • HTTP响应报文

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

  • 在报文众多的字段当中，HTTP首部字段包含的信息最为丰富。

  • 首部字段同时存在于请求和响应报文内，并涵盖HTTP报文相关的内容信息。
  • 因HTTP版本或扩展规范的变化，首部字段可支持的字段内容略有不同。

2. HTTP首部字段

2.1 HTTP首部字段传递重要信息

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

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

2.2 HTTP首部字段结构

HTTP首部字段是由首部字段和字段值构成的，中间用冒号“：”分隔。
首都字段名：字段值
例如
Content-Type : text/html

  • 就以上述示例来看，首部字段名为Content-Type,字符串text/html是字段值。
  • 另外，字段值对应单个HTTP首部字段可以有多个值，如下：
    • Keep-Alive : timeout = 15 ,max = 100

注：若HTTP首部字段重复了会如何

当HTTP报文首部中出现了两个或两个以上具有相同首部字段名时会怎么样？
这种情况在规范内尚未明确，根据浏览器内部处理逻辑的不同，结果可能并不一致。
有些浏览器会优先处理第一次出现的首部字段，而有些则会优先处理最后出现的首部字段。

2.3 4种HTTP首部字段类型

HTTP首部字段根据实际用途被分为以下4种类型:

  • 通用首部字段
    • 请求报文和响应报文双方都会使用的首部。
  • 请求首部字段
    • 从客户端向服务器发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。
  • 响应首部字段
    • 从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。
  • 实体首部字段
    • 针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。

2.4 HTTP/1.1首部字段一览

HTTP/1.1规范定义了如下47种首部字段。

  • 通用首部字段
    通用首部字段
  • 请求首部字段
    请求首部字段
  • 响应首部字段
    响应首部字段
  • 实体首部字段
    实体首部字段

2.5 非HTTP/1.1 首部字段

在HTTP协议通信交互中使用到的首部字段，不限于这47中首部字段。
还有Cookie、Set-Cookie和Content-Disposition等在其他RFC中定义的首部字段，它们的使用频率也很高。
这些非正式的首部字段统一归纳在RFC4229HTTP Header Field Registrations中。

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

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

  • 端到端首部（End-to-end Header）
    • 分在此类别中的首部会转发给请求/响应对应的最终接受目标，且必须保存在由缓存生成的响应中，另外规定它必须被转发。
  • 逐跳首部（Hop-by-hop Header）
    • 分在此类别中的首部只对单次转发有效,会因通过缓存或代理而不再转发。HTTP/1.1和之后版本中，如果要使用hop-by-hop 首部，需要提供Connection首部字段。

下列举了HTTP/1.1中的逐跳首部字段。除这8个首部字段之外，其他所有字段都属于端到端首部。

  • Connection
  • Keep-Alive
  • Proxy-Authenticate
  • Proxy-Authorization
  • Trailer
  • TE
  • Transfer-Encoding
  • Upgrade

3. HTTP/1.1通用首部字段

通用首部字段是指，请求报文和响应报文双方都会使用的首部。

3.1 Cache-Control

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

  • 指令的参数是可选的，多个指令之间通过“，”分隔。
  • 首部字段Cache-Control的指令可用于请求及响应时。
  • Cache-Control指令一览：
    Cache-Control
    Cache-Control

3.2 Connection

Connection首部字段具备如下两个作用。
1.控制不再转发给代理的首部字段
2.管理持久连接

3.3 Date

首部字段Date表明创建HTTP报文的日期和时间

3.4 Pragma

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

示例：

1
Pragma:  no-cache

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

最佳规范：

1
Cache-Control: no-cachePragma:no-cache

3.5 Trailer

首部字段Trailer会事先说明在报文主体后记录了哪些首部字段。该首部字段可应用在HTTP/1.1版本分段传输编码时。

3.6 Transfer-Encoding

首部字段Transfer-Encoding规定了传输报文主体时采用的编码方式。
HTTP/1.1的传输编码方式仅对分块传输编码有效。

3.7 Upgrade

首部字段Upgrade用于检测HTTP协议及其他协议是否可使用更高的版本进行通信，其参数可以用来指定一个完全不同的通信协议。

3.8 Via

使用首部字段Via是为了追踪客户端与服务器之间的请求和响应报文的传输路径。

  • 报文经过代理或网关时，会先在首部字段Via中附加该服务器的信息，然后再进行转发。
  • 这个做法和traceroute及电子邮件的Received首部的工作机制很类似。

首部字段Via不仅用于追踪报文的转发，还可避免请求回环的发生。所以必须在经过代理时附加该首部字段内容。

3.9 Warning

HTTP/1.1 的 Warning首部是从HTTP/1.0的响应首部演变过来的。该首部通常会告知用户一些与缓存相关的问题的警告。

Warning首部的格式如下。最后的日期时间部分可省略。

1
Warning:[警告码][警告的主机：端口号] "[警告内容]"（[日期时间]）

Warning
Warning

4. 请求首部字段

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

4.1 Accept

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

Accept

  • 若想要给显示的媒体类型增加优先级，则使用q=来额外表示权重值，用分号（；）进行分隔。
  • 权重值q的范围是0~1（小数点后三位），且1位最大值。不指定权重q值时，默认权重为q=1.0。
  • 当服务器提供多种内容时，将会首先返回权重值最高的媒体类型。

4.2 Accept-Charset

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

0该首部字段应用于内容协商机制的服务器驱动协商。

4.3 Accept-Encoding

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

Accept-Encoding

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

4.4 Accept-Language

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

和Accept首部字段一样，按权重值q来表示相对优先级。

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

4.5 Authorization

首部字段Authorization使用来告知服务器，用户代理的认证信息（证书值）。
通常，想要通过服务器认证的用户代理会在接收到返回的401状态码响应后，把首部字段Authorization加入请求中。
公用缓存在接收到含有Authorization首部字段的请求时的操作处理会略有不同。

4.6 Expect

客户端使用首部字段Expect来告知服务器，期望出现的某种特定行为。因服务器无法理解客户端的期望作出回应而发生错误时，会返回状态码417。

  • 客户端可以利用该首部字段，写明所期望的扩展。虽然HTTP/1.1规范只定义了100。
  • 等待状态码100响应的客户端在发生请求时，需要指定Expect：100-continue。

4.7 From

首部字段From用来告知服务器使用用户代理的用户的电子邮件地址。

4.8 Host

首部字段Host会告知服务器，请求的资源所处的互联网主机名和端口号。Host首部字段在HTTP/1.1规范内是唯一一个必须被包含在请求内的首部字段。

首部字段Host和以单台服务器分配多个域名的虚拟主机的工作机制有很密切的关联，这是首部字段Host必须存在的意义。

  • 请求被发送至服务器时，请求中的主机名会用IP地址直接替换解决。
  • 但如果这时，相同的IP地址下部署运行着多个域名，那么服务器就会无法理解究竟是哪个域名对应的请求
  • 因此，就需要使用首部字段Host来明确指出请求的主机名，若服务器未设定主机名，那直接发送一个空值即可。

4.9 IF-XXX

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

4.10 Max-Forwards

通过TRACE方法或OPTIONS方法，发送包含首部字段Max-Forwards的请求时，该字段以十进制整数形式指定可经过的服务器最大数目。服务器在往下一个服务器转发请求之前，Max-Forwards的值减1后重新赋值。当服务器接收到Max-Forwards值为0的请求时，则不再进行转发，而是直接返回响应。

  • 使用HTTP协议通信，请求可能会经过代理等多台服务器。
  • 途中，如果代理服务器由于某些原因导致请求转发失败，客户端也就等不到服务器返回的响应了。
  • 对此，我们无从可知。

可以灵活使用首部字段Max-Forwards，针对以上问题产生的原因展开调查。
由于当Max-Forwards字段值为0时，服务器就会立即返回响应，由此我们至少可以对以那台服务器为终点的传输路径的通信状态有所把握。

4.11 Proxy-Authorzation

接收到从代理服务器发来的认证质询时，客户端会发送包含首部字段Proxy-Authorzation的请求，以告知服务器认证所需要的信息。

  • 这个行为是与客户端和服务器之间的HTTP访问认证相类似的。
  • 不同之处在于，认证行为发生在客户端与代理之间。
  • 客户端与服务器之间的认证，使用首部字段Authorzation可起到相同作用。

4.12 Range

对于只需要获取部分资源的范围请求，包含首部字段Range即可告知服务器资源的指定范围。

  • 接收到附带Range首部字段请求的服务器，会在处理请求之后返回状态码为206的响应。
  • 无法处理该范围请求时，则会返回状态码200OK的响应及全部资源。

4.13 Referer

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

  • 客户端一般都会发送Referer首部字段给服务器。
  • 但当直接在浏览器的地址栏输入URO，或出于安全性的考虑时，也可以不发送该首部字段。
  • 因为原始资源的URI中的查询字符串可能含有ID和密码等保密信息，要是写进Referer转发给其他服务器，则有可能导致保密信息的泄露。

注：Referer的正确的拼写应该是Referrer,不知为何这个错误一直沿用至今。

4.14 TE

首部字段TE会告知服务器客户端能够处理响应的传输编码方式及相对优先级。它和首部字段Accept-Encoding的功能很相像，但是用于传输编码。
首部字段TE除指定传输编码之外，还可以指定伴随trailer字段的分块传输编码的方式。应用后者时，只需把trailers赋值给该字段值。

4.15 User-Agent

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

  • 由网络爬虫发起请求时，有可能会在字段内添加爬虫作者的电子邮箱地址。
  • 此外，如果请求经过代理，那么中间也很可能被添加上代理服务器的名称。

5. 响应首部字段

响应首部字段是由服务器端向客户端返回响应报文中所使用的字段，用于补充响应的附加信息、服务器信息，以及对客户端的附加要求等信息。

5.1 Accept-Ranges

首部字段Accept-Ranges是用来告知客户端服务器是否能处理范围请求，以指定获取服务器端某个部分的资源。

可指定的字段值有两种

  • 可处理范围请求时指定其为bytes
  • 反之则指定其为none

5.2 Age

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

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

5.3 ETag

首部字段ETag能告知客户端实体标识。它是一种可将资源以字符串形式做唯一性标识的方式。服务器会为每份资源分配对应的ETag值。
另外，当资源更新时，ETag值也需要更新。生成ETag值时，并没有统一的算法规则，而仅仅是由服务器来分配。

资源被缓存时，就会被分配唯一性标识。例如，当使用中文版的浏览器访问http://www.google.com/时，就会返回中文版对应的资源，而使用英文版的浏览器访问时，则会返回英文版对应的资源。两者的URI是相同的，所以仅凭URI指定缓存的资源是相当困难的。若在下载过程中出现连接中断、再连接的情况，都会依照ETag值来指定资源。

强ETag值和弱ETag值

  • 强ETag值
    • 强ETag值，不论实体发生多么细微的变化都会改变其值。
  • 弱ETag值
    • 弱ETag值只用于提示资源是否相同。只有资源发生了根本改变，产生差异时才会改变ETag值。这时，会在字段值最开始处附加W/

5.4 Location

使用首部字段Location可以将相应接收方引导至某个与请求URI位置不同的资源。

  • 基本上，该字段会配合3XX：Redirection的响应，提供重定向的URI。
  • 几乎所有的浏览器在接收到包含首部字段Location的响应后，都会强制性地尝试对提示的重定向资源的访问。

5.5 Proxy-Authenticate

首部字段Proxy-Authenticate 会把代理服务器所要求的认证信息发送给客户端。

  • 它与客户端和服务器之间的HTTP访问认证的行为相似
  • 不同之处在于其认证行为是在客户端与代理之间进行的
  • 而客户端与服务器之间进行认证时，首部字段WWW-Authenticate 有着相同的作用。

5.6 Retry-After

首部字段Retry-After告知客户端应该在多久之后再次发送请求。

  • 主要配合状态码503响应，或3XX响应一起使用。
  • 字段值可以指定为具体的日期时间，也可以是创建响应后的秒数。

5.7 Server

首部字段Server告知客户端当前服务器上安装的HTTP服务器应用程序的信息。不单单会标出服务器上的软件应用名称，还有可能包括版本号和安装时启用的可选项。

5.8 Vary

首部字段Vary可对缓存进行控制。源服务器会向代理服务器传达关于本地缓存使用方法的命令。

  • 从代理服务器接收到源服务器返回包含Vary指定项的响应之后
  • 若再要进行缓存，仅对请求中含有相同Vary指定首部字段的请求返回缓存
  • 即使对相同资源发起请求，但由于Vary指定的首部字段不相同，因此必须要从源服务器重新获取资源。

5.9 WWW-Authenticate

首部字段WWW-Authenticate用于HTTP访问认证。它会告知客户端适用于访问请求URI所指定资源的认证方案（Basic或是Digest）和到参数提示的质询。状态码401响应中，肯定带有首部字段WWW-Authenticate。

6. 实体首部字段

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

6.1 Allow

首部字段Allow用于通知客户端能够支持Request-URI指定资源的所有HTTP方法

  • 当服务器接收到不支持的HTTP方法时，会以状态码405作为响应返回
  • 与此同时，还会把所有能支持的HTTP方法写入首部字段Allow后返回

6.2 Content-Encoding

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

主要采用以下4中内容编码的方式：

  • gzip
  • compress
  • deflate
  • identity

6.3 Content-Language

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

6.4 Content-Length

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

6.5 Content-Location

首部字段Content-Location给出与报文主体部分相对应的URI。
和首部字段Location不同，Content-Location表示的事报文主体返回资源对应的URI。

6.6 Content-MD5

首部字段Content-MD5是一串由MD5算法生成的值，其目的在于检查报文主体在传输过程中是否保持完整，以及确认传输到达。

  • 对报文主体执行MD5算法获取的128位二进制数，再通过Base64编码后将结果写入Content-MD5字段值。
  • 由于HTTP首部无法记录二进制值，所以要通过Base64编码处理。
  • 为确保报文的有效性，作为接受方的客户端会对报文主体再次执行一次相同的MD5算法。
  • 计算出的值与字段值作比较后，即可判断出报文主体的准确性。

采用这种方法，对内容上的偶发性改变是无从查证的，也无法检测出恶意篡改。
其中一个原因在于，内容如果能够被篡改，那么同时意味着Content-MD5也可从新计算后被篡改。
所以处在接收阶段的客户端是无法意识到报文主体以及首部字段Content-MD5是已经被篡改过的。

6.7 Content-Range

针对范围请求，返回响应时使用的首部字段Content-Range，能告知客户端作为响应返回的实体的哪个部分符合范围请求。字段值以字节为单位，表示当前发送部分及整个实体大小。

6.8 Content-Type

首部字段Content-Type说明了实体主体内对象的媒体类型。

  • 和首部字段Accepty一样，字段值用type/subtype 形式赋值。
  • 参数charset使用iso-8859-1或euc-jp等字符集进行赋值。

6.9 Expires

首部字段Expires会将资源失效的日期告知客户端。

  • 缓存服务器在接收到含有首部字段Expires的响应后，会以缓存来应答请求
  • 在Expires字段值指定的时间之前，响应的副本会一直被保存
  • 当超过指定的时间后，缓存服务器在请求发送过来时，会转向源服务器请求资源。

源服务器不希望缓存服务器对资源缓存时，最好在Expires字段内写入与首部字段Date相同的时间值。
但是，当首部字段Cache-Control有指定max-age指令时，比起首部字段Expires，会优先处理max-age指令

6.10 Last-Modified

首部字段 Last-Modified指明资源最终修改的时间。

  • 一般来说，这个值就是Request-URI指定资源被修改的时间。
  • 但类似使用CGI脚本进行动态数据处理时，该值有可能会变成数据最终修改时的时间。

7. 为Cookie服务的首部字段

管理服务器与客户端之间状态的Cookie
虽然没有被编入彼岸准话HTTP/1.1的RFC2616中，但在Web网站方面得到了广泛的应用。
Cookie的工作机制是用户识别及状态管理。
web网站为了管理用户的状态会通过Web浏览器，把一些数据临时写入用户的计算机内。接着当用户访问该Web网站时，可通过通信方式取回之前发放的Cookie。
调用Cookie时，由于可校验Cookie的有效期，以及发送方的域、路径、协议等信息，所以正规发布的Cookie内的数据不会因来自其他Web站点和攻击者的攻击而泄露。

至2013年5月，Cookie的规格标准文档有以下4种。

Cookie

当服务器准备开始管理客户端的状态时，会事先告知各种信息。

下面的表格列举了Set-Cookie的字段值。

Set-Cookie

  • expires属性

    • Cookie的expires属性指定浏览器可发送Cookie的有效期。

      当省略expires属性时，其有效期仅限于维持浏览器会话（Session）时间段内。这通常限于浏览器应用程序被关闭之前。
      另外，一旦Cookie从服务器发送至客户端，服务区端就不存在可以显式删除Cookie的方法。但可通过覆盖已过期的Cookie，实现对客户端Cookie的实质性删除操作。

  • path属性

    • Cookie的path属性可用于限制指定Cookie的发送范围的文件目录。不过另有办法可避开这项限制，看来对其作为安全机制的效果不能抱有期待。

  • domain属性

    • 通过Cookie的domain属性指定的域名可做到与结尾匹配一致。比如，当指定xxx.com后，除xxx.com以外，www.xxx.com或www2.xxx.com等都可以发送Cookie。因此，除了针对具体指定的多个域名发送Cookie之外，不指定domain属性显得更安全。

  • secure属性

  • HttpOnly属性

    • Cookie的HttpOnly属性是Cookie的扩展功能，它使JavaScript脚本无法获取Cookie。其主要目的为防止跨站脚本攻击（XSS）对Cookie的信息窃取。

      发送指定HttpOnly属性的Cookie的方法如下所示。
      Set-Cookie: name=value;HttpOnly
      通过上述设置，通常从Web页面内还可以对Cookie进行读取操作。但使用JavaScript的document.cookie就 无法读取附加HttpOnly属性后的Cookie的内容了。因此，也就无法再XSS中利用JavaScript劫持Cookie了
      该扩展并非为了防止XSS而开发的。

首部字段Cookie会告知服务器，当客户端想获取HTTP状态管理支持时，就会在请求中包含从服务器接收到的Cookie。接收到多个Cookie时，同样可以以多个Cookie形式发送。

8. 其他首部字段

HTTP首部字段是可以自行扩展的。所以在Web服务器和浏览器的应用上，会出现各种非标准的首部字段。

8.1 X-Frame-Options

首部字段X-Frame-Options属于HTTP响应首部，用于控制网站内容在其他Web网站的Frame标签内的显示问题。其主要目的是为了防止点击劫持攻击

首部字段X-Frame-Options有以下两个可指定的字段值。

  • DENY:拒绝
  • SAMEORIGIN：仅同源域名下的页面匹配时许可。

8.2 X-XSS-Protetion

首部字段X-XSS-Protetion属于HTTP响应首部，它是针对跨站脚本攻击（XSS）的一种对策，用于控制浏览器XSS防护机制的开关。

首部字段X-XSS-Protetion可指定的字段值如下。

  • 0：将XSS过滤蛇者成无效状态
  • 1：将XSS过滤设置成有效状态

8.3 DNT

首部字段DNT属于HTTP请求首部，其中DNT是Do Not Track的简称，意为拒绝个人信息被收集，是表示拒绝被精准广告追踪的一种方法。

首部字段DNT可指定的字段值如下。

  • 0：同意被追踪
  • 1：拒绝被追踪

由于首部字段DNT的功能具备有效性，所以Web服务器需要对DNT做对应的支持。

8.4 P3P

首部字段P3P属于HTTP相应首部，通过利用P3P（在线隐私偏好平台）技术，可以让Web网站上的个人隐私变成一种仅供程序可理解的形式，以达到保护用户隐私的目的。

  • 要进行P3P的设定，需按以下操作步骤进行。
  • 步骤1:创建P3P隐私
  • 步骤2：创建P3P隐私对照文件后，保存命名在/w3c/p3p.html