图解HTTP----HTTP首部--实体首部字段及其他首部字段

一、实体首部字段

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

二、Allow（通知客户端能够支持Request-URI指定资源的所有HTTP方法）

Allow: GET, HEAD

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

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

三、Content-Encoding（实体的主体内容编码方式）

Content-Encoding: gzip

（1）首部字段Content-Encoding会告知客户端服务器对实体的主体部分选用的内容编码方式。

（2）内容编码是指在不丢失实体信息的前提下所进行的压缩。

（3）主要采用以下4中内容编码的方式

• gzip
• compress
• deflate
• identity

四、Content-Language（实体主体使用的自然语言）

Content-Language: zh-CN

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

五、Content-Length（实体主体部分的大小）

Content-Length: 15000

（1）首部字段Content-Length表明了实体主体部分的大小（单位是字节）。

（2）对实体主体进行内容编码传输时，不能再使用Content-Length首部字段。

六、Content-Location（报文主体部分相对应的URI）

Content-Location: http://www.hackr.jp/index-ja.html

（1）首部字段Content-Location给出与报文主体部分相对应的URI。

（2）和首部字段Location不同，Content-Location表示的是报文主体返回资源对应的URI。

比如，对于使用首部字段 Accept-Language 的服务器驱动型请求，当 返回的页面内容与实际请求的对象不同时，首部字段 Content-Location内会写明 URI。（访问 http://www.hackr.jp/ 返回的对象却是http://www.hackr.jp/index-ja.html 等类似情况）/

七、Content-MD5（检查报文主体在传输过程中是否保持完整）

Content-MD5: OGFkZDUwNGVhNGY3N2MxMDIwZmQ4NTBmY2IyTY==

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

（2）对报文主体执行MD5算法获得的128位二进制数，再通过Base64编码后将结果写入Content-MD5字段值。由于HTTP首部无法记录二进制值，所以要通过Base64编码处理。

（3）为确保报文的有效性，作为接收方的客户端会对报文主体再执行一次相同的MD5算法。计算出的值与字段值作比较后，即可判断出报文主体的准确性。

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

八、Content-Range（告知客户端作为响应的实体的哪个部分符合范围请求）

Content-Range: bytes 5001-10000/10000

（1）针对范围请求，返回响应时使用的首部字段Content-Range，能告知客户端作为响应的实体的哪个部分符合范围请求。

（2）字段值以字节为单位，表示当前发送部分及整个实体大小。

九、Content-Type（实体主体内对象的媒体类型）

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

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

（2）和首部字段Accept一样，字段值用type/subtype形式赋值。

（3）参数charset使用iso-8859-1 或 euc-jp 等字符集进行赋值。

十、Expires（将资源失效的日期告知客户端）

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

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

（3）源服务器不希望缓存服务器对资源缓存时，最好在 Expires 字段内写入与首部字段 Date 相同的时间值。

（4）当首部字段 Cache-Control 有指定 max-age 指令时，比起首部字段 Expires，会优先处理 max-age 指令。

十一、Last-Modified（指明资源最终修改的时间）

Last-Modified: Wed, 23 May 2012 09:59:55 GMT

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

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

十二、为Cookie服务的首部字段

（1）管理服务器与客户端之间状态的 Cookie，虽然没有被编入标准化HTTP/1.1 的 RFC2616 中，但在 Web 网站方面得到了广泛的应用。

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

（3）Web 网站为了管理用户的 状态会通过 Web 浏览器，把一些数据临时写入用户的计算机内。接 着当用户访问该Web网站时，可通过通信方式取回之前发放的Cookie。

（4）调用 Cookie 时，由于可校验 Cookie 的有效期，以及发送方的域、路径、协议等信息，所以正规发布的 Cookie 内的数据不会因来自其他Web 站点和攻击者的攻击而泄露。

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

由网景公司颁布的规格标准

网景通信公司设计并开发了 Cookie，并制定相关的规格标准。1994 年前后，Cookie 正式应用在网景浏览器中。目前最为普及的 Cookie方式也是以此为基准的。

RFC2109

某企业尝试以独立技术对 Cookie 规格进行标准化统筹。原本的意图 是想和网景公司制定的标准交互应用，可惜发生了微妙的差异。现在该标准已淡出了人们的视线。

RFC2965

为终结 Internet Explorer 浏览器与 Netscape Navigator 的标准差异而导 致的浏览器战争，RFC2965 内定义了新的 HTTP 首部 Set-Cookie2 和Cookie2。可事实上，它们几乎没怎么投入使用。

RFC6265

将网景公司制定的标准作为业界事实标准（De facto standard），重新定义 Cookie 标准后的产物。

目前使用最广泛的 Cookie 标准却不是 RFC 中定义的任何一个。而是在网景公司制定的标准上进行扩展后的产物。

（6）为 Cookie 服务的首部字段

• Set-Cookie

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

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

1）expires属性

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

2、当省略 expires 属性时，其有效期仅限于维持浏览器会话（Session）时间段内。这通常限于浏览器应用程序被关闭之前。

3、一旦 Cookie 从服务器端发送至客户端，服务器端就不存在可 以显式删除 Cookie 的方法。但可通过覆盖已过期的 Cookie，实现对客户端 Cookie 的实质性删除操作。

2）path属性

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

3）domain 属性

1、通过 Cookie 的 domain 属性指定的域名可做到与结尾匹配一致。比如，当指定 example.com 后，除 example.com 以外，www.example.com或 www2.example.com 等都可以发送 Cookie。

2、除了针对具体指定的多个域名发送 Cookie 之 外，不指定domain 属性显得更安全。

4）secure属性

1、Cookie 的 secure 属性用于限制 Web 页面仅在 HTTPS 安全连接时，才可以发送 Cookie。

2、发送 Cookie 时，指定 secure 属性的方法如下所示

Set-Cookie: name=value; secure

以上例子仅当在 https://www.example.com/（HTTPS）安全连接的情况下才会进行 Cookie 的回收。也就是说，即使域名相同，

http://www.example.com/（HTTP）也不会发生 Cookie 回收行为。

3、当省略 secure 属性时，不论 HTTP 还是 HTTPS，都会对 Cookie 进行回收。

5）HttpOnly 属性

Set-Cookie: name=value; HttpOnly

1、Cookie 的 HttpOnly 属性是 Cookie 的扩展功能，它使 JavaScript 脚本无法获得 Cookie。

2、其主要目的为防止跨站脚本攻击（Cross-site scripting，XSS）对 Cookie 的信息窃取。

3、通过上述设置，通常从 Web 页面内还可以对 Cookie 进行读取操作。 但使用 JavaScript 的 document.cookie 就无法读取附加 HttpOnly 属性后的 Cookie 的内容了。因此，也就无法在 XSS 中利用 JavaScript 劫持Cookie 了。

• Cookie

Cookie: status=enable

1)首部字段 Cookie 会告知服务器，当客户端想获得 HTTP 状态管理支持时，就会在请求中包含从服务器接收到的 Cookie。

2)接收到多个Cookie 时，同样可以以多个 Cookie 形式发送。

十三、其他首部字段

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

• X-Frame-Options

X-Frame-Options: DENY

（1）首部字段X-Frame-Options属于HTTP响应首部，用于控制网站内容在其他Web网站的Frame标签内的显示问题。

（2）其主要目的是为了防止点击劫持攻击。

（3）有以下两个可指定的字段值

• DENY ：拒绝
• SAMEORIGIN ：仅同源域名下的页面（Top-level-browsing-context）匹配时许可。（比如，当指定 http://hackr.jp/sample.html 页面为 SAMEORIGIN 时，那么 hackr.jp 上所有页面的 frame 都被 允许可加载该页面，而 example.com 等其他域名的页面就不行了）

（4）支持该首部字段的浏览器有：Internet Explorer 8、Firefox 3.6.9+、 Chrome 4.1.249.1042+、Safari 4+ 和 Opera 10.50+ 等。现在主流的浏览器都已经支持。

（5）能在所有的 Web 服务器端预先设定好 X-Frame-Options 字段值是最理想的状态。

• X-XSS-Protection

X-XSS-Protection: 1

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

（2）首部字段 X-XSS-Protection 可指定的字段值如下。

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

• DNT

DNT: 1

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

（2）首部字段 DNT 可指定的字段值如下

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

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

• P3P

P3P: CP="CAO DSP LAW CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa OUR BUS I

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

（2）要进行 P3P 的设定，需按以下操作步骤进行。

步骤 1：创建 P3P 隐私

步骤 2：创建 P3P 隐私对照文件后，保存命名在 /w3c/p3p.xml

步骤 3：从 P3P 隐私中新建 Compact policies 后，输出到 HTTP 响应中