HTTP报文我们已经很熟悉了。如果说HTTP是因特网的信使，那我们可以把HTTP报文当做它用来搬东西的包裹了。下面是关于HTTP报文这块的详细总结和记录。主要内容有：报文时如何流动的？HTTP报文的组成是什么？我们知道报文可以分为请求报文和响应报文，那么这两个又有什么区别呢？请求报文支持的各种功能和方法有？响应报文状态常见的码总结。图片全部来源《http权威指南》，感谢。
报文流
HTTP报文是再HTTP应用程序之间发送的数据块。这些数据块以一些文本形式的原信息开头。这些信息描述了报文的内容及含义。这些报文时再客户端，服务器，代理之间不断的流动的。我们一般用“流入”，“流出”，“上游”，“下游”来描述报文流动的方向。
报文流入服务器端并流回客户端
这个很好理解。
报文向下游流动
注意，这里不管是请求还是响应报文，所有报文都是会向下游流动。所有报文的发送者都在上游，接受者都在下游。报文就像河水一样。河水不能往上游流，是不是？一样的道理。
报文的组成部分-重要
每一条报文都是包含一个来自客户端的请求，或者是一条来自服务器的响应。它们由三个部分组成，对报文进行描述的起始行，包含属性的首部块，以及可选的包含数据的主体部分。即：start line+header+body。
起始行和首部都是由行分割的ASCII文本。每一行都是以一个由两个字符组成的序列作为结束。一个回车13，一个换行10。我们把这个终止序列可以写作CRLF。
这里要注意下，虽然标准是说要CRLF表示终止行，但是稳健的应用程序也应该接受单个换行符作为行的终止。因为有一些老的不完成的应用程序并不能总是即发送回车，又发送换行。
实体，也就是body部分。是一个可以选择的数据块。但是与起始行和首部不同，body部分可以是文本，可以是二进制，当然也可以为空。注意下上面图里的content-length是说的主体部分的长度。
报文的语法
请求报文的语法
<method><request-url><version>
<headers>
<entity-body>
响应报文的语法
<version><status><reason-phrase>
<headers>
<entity-body>
具体解释上面语法
- 方法（method）：客户端希望服务器对资源执行的动作，是一个单独的词，比如
GET,POST,HEAD。 - 请求URL（request-url）:命名了所请求的资源，如果是直接跟服务器对话，则只要是绝对路径，但如果通过了代理就是要写全。
- 版本（version）:
HTTP/<major>.<minor>主要是版本号和次要版本号。都是整数，1.22和1.3,版本号不会被当做小树来处理，都是单独的数据。所以2.22比2.3要高。因为22>3。 - 状态码（status-code）:这三个数字描述了请求过程中所发生的情况。
- 原因短语：数字状态码的可读版本，包含行终止序列之前所有的文本。原因短语只供我们阅读，比如
HTTP/1.0 200 NOT OK和HTTP/1.0 200 OK都是表示成功指示。原因短语和状态码成对出现。 - 首部（headers）：可以有多个header,
名字： 值 CRLF - 实体（entity-body):可以选择的数据块。实体，也就是
body部分。就是HTTP要传输的内容。是一个可以选择的数据块。可以是文本，二进制，空。可以承载很多类型，图片，视频，HTML文档，软件应用陈旭，信用卡事物，电子邮件等。
方法method
注意这些方法的请求报文中有主体，有些则是没有主体的请求，并且也并不是所有的服务器都实现了上面的7中方法。而且就算服务器实现了所有的这些方法，这些方法的使用也会受到限制。比如put和delete方法，服务器不可能让任何人都可以删除或者存储资源。这些现实都会在服务器进行配置。因此会随着站点的不同而不同。
下面详细介绍常见的几个方法。
GET
请求服务器上的某个资源。
POST
POST方法起初是要向服务器输入数据的。实际上，通常用来支持表单。
TRACE
当客户端发起一个请求的时候，这个请求可能要穿过防火墙，代理，网关，或者其他一些应用程序。每个中间节点都可能会修改该原始HTTP请求。Trace方法允许客户端在最终将请求发送给服务器时，看看它变成了什么样。Trace请求会在目的服务器发起一个换回诊断。航程最后一站的服务器会弹送一个Trace响应。并且把响应主体中携带它收到的原始请求报文。这样就可以在客户端查看在所有中间HTTP应用程序组成的请求上。原始报文是否或者如何被毁坏或修改过。
注意，trace请求中不能带有实体部分的主体内容，trace响应的实体主体部分包含了响应服务器收到的请求的精确副本。
HEAD
HEAD方法与GET方法很类似，但服务器在响应中只返回首部，不会返回实体，这就允许客户端在未获取实体资源的情况下，对资源的首部进行检查，使用HEAD的作用具体如下：
1. 在不获得资源的情况下了解资源的情况（比如判断类型）。
2. 通过查看响应中的状态码，看看某个对象是否存在。
3. 通过查看首部，测试资源是否被修改。
DELETE
请服务器删除请求URL所指定的资源，但是客户端应用程序无法保证删除的操作一定会被执行。因为HTTP规范允许服务器在不通知客户端的情况下撤销请求。
PUT
与GET从服务器中读取文档相反，PUT方法会向服务器写入文档。有些发布系统允许用户创建WEB页面并用PUT直接安装到服务器上去。
它的语义就是让服务器用请求主体部分来创建一个由所请求的URL命名的新文档。或者，如果这个URL已经存在，就用这个主体代替它。一般Web服务器都要要求在执行PUT之前，用密码登陆。原因你懂的。
OPTIONS
OPTIONS方法请求Web服务器告之其支持的各种功能。可以询问服务器通常支持的哪些方法。或者堆某些特殊资源支持哪些方法。
这的作用就是为客户端应用程序提供了一种手段。使其不用实际访问哪些资源就能判定访问的资源的最优方式。
状态码
方法是用来告诉服务器要做什么事情的，状态码是用来告诉客户端发生了什么事情的。可以通过三维数字代码对不同的状态码进行分类。
我们可以看到目前定义了的状态码不是很多。但是分类很明确。
主要了解下：
100（continue）,101(Switching Protocols),
200(ok),201(created),202(accepted),
300(Multipul Choices),301(moved permanently),302(Found),303(See other),304(Not Modified),
400(Bad Request),401(Unauthorized),402(Payment Required),403（Forbidden）,404(Not Found),
500(Internal Server Error),501(Not Implemented),502(Bad Gateway),503(Service Unavailable),504(Gateway Timeout)
301：永久重定向，302临时重定向。
307：HTTP1.1指出，对于HTTP1.1客户端，用307状态码来取代302状态码来进行临时重定向，这样就可以把302状态码保留起来，为HTTP1.0客户端使用。这样一来，服务器要选择适当的重定向状态码放入重定向响应中发送。
402：该状态码暂时未使用，但是被保留了，以做未来使用
502：作为代理或者网关使用的服务器从请求响应链的下一条链路上收到了一条伪响应。（比如：无法连接到其他网关上）
503：用来说明服务器目前无法 为请求提供服务。但将来可以。
首部
首部和方法配合工作，可以共同决定客户端和服务器能做什么事情。这有分为了通用首部，请求首部，响应首部，实体首部，扩展首部这些分类。
- 通用首部：客户端和服务器端都可以使用的首部。比如Date首部。
Date: Tue,3 Oct... - 请求首部：请求首部是请求报文特有的。比如
Accept:*/*。它们为服务器提供了一些额外的信息。比如客户端希3. 望接收什么类型的数据。 - 响应首部：响应报文特有的，以便为客户端提供信息，比如客户端正在跟哪种服务器发生通信。
Server: Tiki... - 实体首部：是用于实体部分的首部，比如可以说明主体部分的数据类型。
Content-type: text/html;charset... - 扩展首部：非标准首部，由应用程序开发者创建，但还是没有添加到规范中去。
总结
主要是对整个报文部分做了一个稍微完整点的了解和记录。其实还有比如状态码部分都是很粗略的介绍，还有关于首部，里面的各个分类分别有哪些信息都只是大概的记录下。我觉得这些可以遇到的时候再去查，现在大概的看下有哪些和大致的作用就可以了。
