8.1 Set-Cookie
Set-Cookie: status=enable; expires=Mon, 10 Jul 2017 15:50:06 GMT; path=/;
下面的表格列举了 Set-Cookie 的字段值。
8.1.1 expires 属性
- Cookie 的 expires 属性指定浏览器可发送 Cookie 的有效期。
- 当省略 expires 属性时，其有效期仅限于维持浏览器会话（Session）时间段内。这通常限于浏览器应用程序被关闭之前。
- 另外，一旦 Cookie 从服务器端发送至客户端，服务器端就不存在可以显式删除 Cookie 的方法。但可通过覆盖已过期的 Cookie，实现对客户端 Cookie 的实质性删除操作。
8.1.2 path 属性
Cookie 的 path 属性可用于限制指定 Cookie 的发送范围的文件目录。
8.1.3 domain 属性
- 通过 Cookie 的 domain 属性指定的域名可做到与结尾匹配一致。比如，当指定 example.com 后，除example.com 以外，www.example.com 或 www2.example.com 等都可以发送 Cookie。
- 因此，除了针对具体指定的多个域名发送 Cookie 之 外，不指定 domain 属性显得更安全。
8.1.4 secure 属性
Cookie 的 secure 属性用于限制 Web 页面仅在 HTTPS 安全连接时，才可以发送 Cookie。
8.1.5 HttpOnly 属性
- Cookie 的 HttpOnly 属性是 Cookie 的扩展功能，它使 JavaScript 脚本无法获得 Cookie。其主要目的为防止跨站脚本攻击（Cross-site scripting，XSS）对 Cookie 的信息窃取。
- 通过上述设置，通常从 Web 页面内还可以对 Cookie 进行读取操作。但使用 JavaScript 的 document.cookie 就无法读取附加 HttpOnly 属性后的 Cookie 的内容了。因此，也就无法在 XSS 中利用 JavaScript 劫持 Cookie 了。
8.2 Cookie
Cookie: status=enable
首部字段 Cookie 会告知服务器，当客户端想获得 HTTP 状态管理支持时，就会在请求中包含从服务器接收到的 Cookie。接收到多个 Cookie 时，同样可以以多个 Cookie 形式发送。
9. 其他首部字段
HTTP 首部字段是可以自行扩展的。所以在 Web 服务器和浏览器的应用上，会出现各种非标准的首部字段。
以下是最为常用的首部字段。
9.1 X-Frame-Options
X-Frame-Options: DENY
首部字段 X-Frame-Options 属于 HTTP 响应首部，用于控制网站内容在其他 Web 网站的 Frame 标签内的显示问题。其主要目的是为了防止点击劫持（clickjacking）攻击。首部字段 X-Frame-Options 有以下两个可指定的字段值：
- DENY：拒绝
- SAMEORIGIN：仅同源域名下的页面（Top-level-browsing-context）匹配时许可。（比如，当指定 http://sample.com/sample.html 页面为 SAMEORIGIN 时，那么 sample.com 上所有页面的 frame 都被允许可加载该页面，而 example.com 等其他域名的页面就不行了）
9.2 X-XSS-Protection
X-XSS-Protection: 1
首部字段 X-XSS-Protection 属于 HTTP 响应首部，它是针对跨站脚本攻击（XSS）的一种对策，用于控制浏览器 XSS 防护机制的开关。首部字段 X-XSS-Protection 可指定的字段值如下:
- 0 ：将 XSS 过滤设置成无效状态
- 1 ：将 XSS 过滤设置成有效状态
9.3 DNT
DNT: 1
首部字段 DNT 属于 HTTP 请求首部，其中 DNT 是 Do Not Track 的简称，意为拒绝个人信息被收集，是表示拒绝被精准广告追踪的一种方法。首部字段 DNT 可指定的字段值如下：
- 0 ：同意被追踪
- 1 ：拒绝被追踪
由于首部字段 DNT 的功能具备有效性，所以 Web 服务器需要对 DNT做对应的支持。
9.4 P3P
P3P: CP="CAO DSP LAW CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa OUR BUS IND
首部字段 P3P 属于 HTTP 响应首部，通过利用 P3P（The Platform for Privacy Preferences，在线隐私偏好平台）技术，可以让 Web 网站上的个人隐私变成一种仅供程序可理解的形式，以达到保护用户隐私的目的。
要进行 P3P 的设定，需按以下操作步骤进行：
- 步骤 1：创建 P3P 隐私
- 步骤 2：创建 P3P 隐私对照文件后，保存命名在 /w3c/p3p.xml
- 步骤 3：从 P3P 隐私中新建 Compact policies 后，输出到 HTTP 响应中
1. 状态码概述
- HTTP 状态码负责表示客户端 HTTP 请求的返回结果、标记服务器端的处理是否正常、通知出现的错误等工作。
- HTTP 状态码如 200 OK ，以 3 位数字和原因短语组成。数字中的第一位指定了响应类别，后两位无分类。
- 不少返回的响应状态码都是错误的，但是用户可能察觉不到这点。比如 Web 应用程序内部发生错误，状态码依然返回 200 OK。
2. 状态码类别
我们可以自行改变 RFC2616 中定义的状态码或者服务器端自行创建状态码，只要遵守状态码的类别定义就可以了。
3. 常用状态码解析
HTTP 状态码种类繁多，数量达几十种。其中最常用的有以下 14 种，一起来看看。
3.1 200 OK
表示从客户端发来的请求在服务器端被正常处理了。
3.2 204 No Content
- 代表服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分。另外，也不允许返回任何实体的主体。
- 一般在只需要从客户端向服务器端发送消息，而服务器端不需要向客户端发送新消息内容的情况下使用。
3.3 206 Partial Content
表示客户端进行了范围请求，而服务器成功执行了这部分的 GET 请求。响应报文中包含由 Content-Range 首部字段指定范围的实体内容。
3.4 301 Moved Permanently
永久性重定向。表示请求的资源已被分配了新的 URI。以后应使用资源现在所指的 URI。也就是说，如果已经把资源对应的 URI 保存为书签了，这时应该按 Location 首部字段提示的 URI 重新保存。
3.5 302 Found
- 临时性重定向。表示请求的资源已被分配了新的 URI，希望用户（本次）能使用新的 URI 访问。
- 和 301 Moved Permanently 状态码相似，但 302 Found 状态码代表资源不是被永久移动，只是临时性质的。换句话说，已移动的资源对应的 URI 将来还有可能发生改变。
3.6 303 See Other
- 表示由于请求的资源存在着另一个 URI，应使用 GET 方法定向获取请求的资源。
- 303 See Other 和 302 Found 状态码有着相同的功能，但 303 See Other 状态码明确表示客户端应采用 GET 方法获取资源，这点与 302 Found 状态码有区别。
3.7 304 Not Modified
- 表示客户端发送附带条件的请求时，服务器端允许请求访问的资源，但未满足条件的情况。
- 304 Not Modified 状态码返回时，不包含任何响应的主体部分。
- 304 Not Modified 虽然被划分到 3xx 类别中，但和重定向没有关系。
3.8 307 Temporary Redirect
临时重定向。该状态码与 302 Found 有着相同的含义。
3.9 400 Bad Request
- 表示请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。
- 另外，浏览器会像 200 OK 一样对待该状态码。
3.10 401 Unauthorized
- 表示发送的请求需要有通过 HTTP 认证（BASIC 认证、DIGEST 认证）的认证信息。
- 另外，若之前已进行过 1 次请求，则表示用户认证失败。
- 返回含有 401 Unauthorized 的响应必须包含一个适用于被请求资源的 WWW-Authenticate 首部用以质询（challenge）用户信息。
3.11 403 Forbidden
表明对请求资源的访问被服务器拒绝了。服务器端没有必要给出详细的拒绝理由，当然也可以在响应报文的实体主体部分对原因进行描述。
3.12 404 Not Found
表明服务器上无法找到请求的资源。除此之外，也可以在服务器端拒绝请求且不想说明理由的时候使用。
3.13 500 Internal Server Error
表明服务器端在执行请求时发生了错误。也可能是 Web 应用存在的 bug 或某些临时的故障。
3.14 503 Service Unavailable
表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。如果事先得知解除以上状况需要的时间，最好写入 Retry-After 首部字段再返回给客户端。
八、HTTP 报文实体1. HTTP 报文实体概述
HTTP 报文结构
大家请仔细看看上面示例中，各个组成部分对应的内容。
接着，我们来看看报文和实体的概念。如果把 HTTP 报文想象成因特网货运系统中的箱子，那么 HTTP 实体就是报文中实际的货物。
- 报文：是网络中交换和传输的数据单元，即站点一次性要发送的数据块。报文包含了将要发送的完整的数据信息，其长短很不一致，长度不限且可变。
- 实体：作为请求或响应的有效载荷数据（补充项）被传输，其内容由实体首部和实体主体组成。（实体首部相关内容在上面第六点中已有阐述。）
我们可以看到，上面示例右图中深红色框的内容就是报文的实体部分，而蓝色框的两部分内容分别就是实体首部和实体主体。而左图中粉红框内容就是报文主体。
通常，报文主体等于实体主体。只有当传输中进行编码操作时，实体主体的内容发生变化，才导致它和报文主体产生差异。
2. 内容编码
- HTTP 应用程序有时在发送之前需要对内容进行编码。例如，在把很大的 HTML 文档发送给通过慢速连接上来的客户端之前，服务器可能会对其进行压缩，这样有助于减少传输实体的时间。服务器还可以把内容搅乱或加密，以此来防止未授权的第三方看到文档的内容。
- 这种类型的编码是在发送方应用到内容之上的。当内容经过内容编码后，编好码的数据就放在实体主体中，像往常一样发送给接收方。
内容编码类型：
