第3章

报文流

是在HTTP应用程序之间发送的数据块。这些数据块以一些文本形式的元信息开头，这些信息描述了报文的内容以及含义，后面跟着可选的数据部分。这些报文在客户端、服务器和代理之间流动。

报文向下游流动

不管是请求报文还是响应报文，所有报文都会向下游游动。

报文的组成部分

一条来自服务器的响应由3部分组成：对报文进行描述的起始行、包含属性的首部块、可选的包含数据的主体部分

方法

安全方法

操作不会产生任何的动作，get和head方法被认为是安全的。操作不会产生任何的动作不会产生任何动作这是由开发者决定的

GET：通常用于请求服务器发送某个资源

HEAD：服务器在响应时只返回首部。不会返回实体的主体部分。这就允许客户端在未获取实际资源的情况下，对资源的首部进行检查。HEAD是HTTP1.0中定义的请求方法。多用于自动搜索机器人获取网页的标志信息，获取rss种子信息，或者传递安全认证信息等。

可以在不获取资源的情况下了解资源情况-检查资源有效性

通过查看响应中的状态码，看看某个对象是否存在-查看资源有效性

通过查看首部，测试资源是否被修改了-检查网页是否被篡改

PUT：会向服务器写入文档。让服务器用请求的主体部分来创建一个由所请求的主体部分来创建一个由所请求的URL命名的新文档，或者，如果那个URL已经存在的话，就用这个主体来替代它。用于向服务器上的资源中存储数据。

POST：通常会用它来支持HTML的表单。用于向服务器发送数据

TRACE：TRACE方法允许客户端在最终将请求发送给服务器时，看看它变成了什么样子。

TRACE请求会在目的服务器端发起一个“环回”诊断。行程最后一站的服务器会弹回一条TRACE响应，并在响应主体中携带它收到的原始请求报文。这样客户端就可以查看在所有中间HTTP应用程序组成的请求/响应链上，原始报文是否，以及如何被毁坏或修改过。

TRACE并不提供区分这些方法的机制，导致在中间过程中可能不同的中间应用程序作出不同的响应

请求中不能带有实体的主体部分

Options：请求web服务器告知其支持的各种功能

DELETE：请服务器删除请求URL所指定的资源。客户端应用程序无法保证删除操作一定会被执行。HTTP规范允许服务器在不通知客户端的情况下撤销请求。

状态码

100-199信息性状态码
- 100 continue客户端应用程序只有在避免向服务器发送一个服务器无法处理或使用的大实体时，才应该使用100 continue。
- 客户端和100 continue:发送了100 continue的expect首部的客户端不应该永远在那儿等待服务器发送100 continue响应，超时之后，客户端应该直接将实体发送出去。
- 服务器与100 continue：
  - 服务器一般是只会响应发送100 continue状态码的客户端进行响应，出错的服务器也可能会这么做。
  - 服务器在发送100 continue之前就收到了部分或者全部的实体，说明客户端已经决定继续发送数据了，这样服务器就不需要发送这个状态码了。但是服务器读完请求之后还是应该为请求发送一个最终状态码。
  - 服务器在读取实体的主体部分之前结束请求收到了带有100 continue的请求，就不应该仅仅是发送一条响应并关闭连接，因为这样会妨碍客户端接收响应。
- 代理与100 continue：
  - 代理收到一条请求时，知道下一跳服务器是HTTP/1.1兼容的，或者不知道下一跳服务器与哪个版本兼容，他都应该将expect首部放在请求中向下转发。如果知道下一跳服务器只能与HTTP/1.1之前的版本兼容，就应该以417Expectation Failed错误进行响应。
  - 如果代理决定代表与HTTP/1.0或之前版本兼容的客户端，再起请求中放入Expect首部和100 Continue值，那么，如果他从服务器收到了100 Continue响应，他就不应该将100 Continue响应转发给客户端，因为客户端可能不知道该拿它怎么办。

302、303、307状态码区别。

HTTP/1.0客户端发起一个POST请求，并在响应中收到302重定向状态码时，它会接收location首部的重定向url，并向那个URL发起一个GET请求。
HTTP/1.0服务器收到客户端发送的POST请求之后发送了302状态码，此时服务器希望客户端能够接收重定向URL，并向重定向URL发送GET请求。
HTTP/1.1中用303状态码来实现相同的行为。这样服务器就可以将302状态码保留起来为HTTP/1.0客户端使用了，因此服务器端要根据HTTP版本来决定发送适合的状态码。