1、报文流

HTTP报文是在HTTP应用程序之间发送的数据块。这些数据块以一些文本形式的元信息开头，这些信息描述了报文的内容及含义，后面跟着可选的数据部分。可以把报文流比喻成水流，对于水来说是永远往低处流的，报文流也是如此。不论是从客户端流向服务器还是从服务器流向客户端，接收报文的那个端永远都是下游。

2、HTTP报文的组成成分。

包括起始行，首部和主体。起始行和首部是由行分割的ASCII文本。每行以一个由两个字符组成的行终止序列作为结束（CRLF）

2.1、起始行

对于请求行来说包含请求方法，请求URL以及HTTP的版本。对于响应行来说包含HTTP版本，数字状态码和原因短语。

2.1.1、方法

报纸服务器要做什么。常用的HTTP方法有7种：

  GET：从服务器获取一份文档。

  HEAD：只从服务器获取文档的首部。

  POST：向服务器发送需要发处理的数据

  PUT：将请求的主体部分存储在服务器上

  TRACE：对可能经过代理服务器传送到服务器上去的报文进行追踪

  OPTIONS：决定可以在服务器上执行哪些方法

  DELETE：从服务器上删除一份文档。

注：除了POST和PUT包含主体外其余都不包含。而且并非所有的服务器都支持这7种方法。除了这些外，有些服务器可能还有一些自己的请求方法。

GET和HEAD方法被认为是安全方法，这意味着使用这两个方法的HTTP请求都不会产生什么动作。按照我的理解，这意思就是说服务器不会因为这两个方法而执行一个动作。例如用POST请求，服务器就会为用户执行一个动作，像登录的时候发送用户名和密码用的就是POST请求，这时服务器会在数据库中进行匹配，然后将结果返回给用户。

通常用POST来支持HTML表单。表单中填好的数据会被发送给服务器，然后由服务器将其发送到它要去的地方，比如发送到一个服务器网关程序中，然后由这个程序对其进行处理。

客户端发起一个请求时，这个请求可能会穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的HTTP请求。TRACE方法允许客户端在最终将请求发送给服务器时，看看它变成了什么样子。这让我想起了我国伟大的防火墙——GFW。尤其是在访问国外网站时，报文在通过GFW时可能就被进行了修改，因此最终服务器返回一个404错误的响应报文。。。

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

2.1.2、状态码

告诉客户端发生了什么。共分为5大类。

100～199——信息性状态码。它的目的是对这样的情况进行优化：HTTP客户端应用程序有一个实体的主体部分要发送给服务器，但希望在发送之前查看一下服务器是否会接收这个实体。

200～299——成功状态码

详细代码的含义请看P64

300～399——重定向状态码

返回一个可选的Location首部来告诉客户端资源被移走了，并提供一个地址。一般浏览器都在不打扰用户的前提下，直接转向那个地址。详细请看P65-67

400～499——客户端错误状态码

客户端如果发送一些服务器无法处理的东西，比如格式错误的请求报文，或是不存在的URL。这让我觉得我国的GFW是不是在请求报文传输的时候改动了URL，从而导致服务器端无法处理。

500～599——服务器错误状态码

详细看P69-70

2.2、首部

是一些名/值对列表。可以分为通用首部，请求首部，响应首部，实体首部，扩展首部。

各首部的详细信息可看书P71-76

本文出自 “莲的思念” 博客，请务必保留此出处http://liandesinian.blog.51cto.com/7737219/1557537

第3章 HTTP报文