引言
HTTP报文是在HTTP应用程序之间发送的数据块。这些数据块以一些文本形式的元信息开头，这些信息描述了报文的内容及含义，后面跟着可选的数据部分。HTTP使用术语流入和流出来描述事务处理方向，报文像流水一样向下游流动，所有报文发送者都在接受者的上游。
报文的组成部分
Http报文是简单的格式化数据块，有三部分组成：对报文进行描述的起始行；包含属性的首部快；包含数据主体。
所有Http报文都可以分为两类，请求报文和响应报文。请求报文都会向Web服务器请求一个动作，响应报文都会将请求的结果返回给客户端。
请求报文与响应报文的格式
请求报文格式： <method> <request-URL> <version> <headers> <entity-body>
响应报文格式：<version> <status-code> <reason-phrase> <headers> <entity-body>
方法（method）:方法是客户端希望服务器对资源执行的操作，是一个单独的词，比如GET、POST等
请求URL（Request-URI）:命名了所请求资源，或者URL路径组成的完整URL。如何直接与服务器进行对话，只要URL路径组件是资源的绝对路径，通常就不会有什么问题---服务器可以假定自己是URL的主机或者是端口。
版本（version）： 报文所使用的HTTP版本，格式是HTTP/<major>.<minor>, 其中主要版本号（major）和次要版本号（minor）都是整数。
状态码（status-code）:描述请求过程中发生的情况。每个状态码的第一位数字都是描述状态的一般类别（成功and出错）。
原因短语（reason-phrase）：数字状态码的可读办，包含行终止序列之前的所有文本。
首部（headers）：可以有零个或多个首部，每个首部都包含一个名字，后面跟着一个冒号（：），然后还是一个可选的空格，接着是一个值，最后是一个CRLF（回车符和换行符）。首部使用一个CRLF结束的，表示了首部列表的结束和实体主体部分的开始。
实体的主体部分（entity-body）：实体的主体部分包含一个有任意数据组成的数据块，并不是所有的报文都包含实体的主体部分，有时报文只是一个CRLF结束。
起始行
所有HTTP报文都是以一个起始行作为开始。
1.请求行： 请求报文请求服务器对资源进行一些操作，请求报文的起始行，也叫报文的请求行，包含了一个方法和一个请求URL，这个方法描述了服务器应该执行的操作，请求URL描述了要对那个资源执行这个方法。请求行中还包含HTTP的版本，用来告知服务器，客户端使用得是哪种HTTP。
2.响应行：响应报文承载了状态信息和操作产生的所有结果的数据，将其返回给客户端。响应报文的起始行，也成为响应行，包含了响应报文使用得HTTP版本、数字状态码，以及描述操作状态的文本形式操作原因短语。
3.方法：请求的起始行以方法作为开始，方法用来告知服务器要做些什么。
4.状态码： 状态码用来告诉服务器发生了什么。
5.原因短语：原因短语是响应起始行中的最后一个组件。它为状态码提供了文本形式的解释。原因短语与状态码成对出现。
6.版本号:版本号会以HTTP/x.y的形式出现在请求响应报文的起始行中。为HTTP应用程序提供一种将自己所遵循的协议版本告知对方的方式。
使用版本号的目的是为了使用HTTP的应用程序提供一种线索，以便相互了解对方的能力好报文格式。在与使用HTTP1.1的应用程序进行通讯的HTTP1.2应用程序应该知道，他不能使用任何新的1.2特性，因为使用老版本协议的应用程序很有可能无法实现这些特性。
首部
首部分为：
一.通用首部： 通用首部既可以出现在请求报文中，也可以出现在响应报文中。
二。请求首部： 提供更多有关请求的信息。
1.Accept首部： 为客户端提供了一种将其喜好和能力告知服务器的方式，包括他们想要什么，可以是用什么，以及最重要的，他们不想要什么。这样服务器就可以根据这些额外信息，对要发送的内容作出更明智的决定.
2.条件请求首部：有时客户端希望为请求加上某些限制。
3.安全请求首部：HTTP本身就支持一种简单的机制，可以对请求进行质询 / 响应认证。这种机制要求客户端在获取特定的资源之前，先对自身进行认证，这样就可以使事物稍微安全一些。
4.代理请求首部：
三。响应首部：提供更多有关响应的信息。
1.协商首部：如果资源有多种表示方法，服务器可以用他们来传递和协商资源有关的信息。
2.安全响应首部： HTTP的质询 / 响应认证机制的响应侧
四.实体首部：描述主体的长度和内容，或者资源自身
1.内容首部：内容首部提供了与实体内容有关的特定信息，说明了其类型、尺寸以及处理它所需的其他有用信息。
2.实体缓存首部： 通用的缓存首部说明了如果或什么时候进行缓存。实体的缓存首部提供了与被缓存实体有关的信息。
五、扩展首部。规范中没有定义的新首部。
方法
HTTP定义了一组被称为安全方法的方法，GET方法和HEAD方法为安全方法，使用它们的HTTP请求不会产生什么动作，但不一定什么动作也不执行。
一 GET方法： GET方法通常用于请求服务器发送某个资源
二 HEAD方法： HEAD方法与GET方法的行为很类似，但服务器在响应中只返回首部。不会返回实体的主体部分。这就允许允许客户端在未获取实际资源的情况下，对资源的首部进行检查。
1.在不获取资源的情况下了解资的情况
2.通过查看响应中的状态码，看看某个对象是否存在
3.通过查看首部，测试资源是否被修改过
服务器不许确保返回的首部与GET请求返回的首部完全相同。遵循HTTP/1.1规范，必须实现HEAD方法。
三 PUT方法：与GET从服务器读取文档相反，PUT方法会向服务器写入文档。PUT方法的语义就是让服务器用请求的主体部分来创建一个有所请求的URL命名的新文档，已存在的就用这个主体替代，Web服务器要求在执行PUT之前用密码登录。
四 POST：POST方法起初是用来向服务器输入数据的。通常用它来支持HTML表单。表单中填好的数据送给服务器，然后服务器将他发送到要去的地方。
五 TRACE：客户端发起一个请求，这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的HTTP请求。
TRACE方法允许客户端在最终将请求发送给服务器时，看看变成什么样子。TRACE请求会在目的服务器发起一个“环回”诊断。行程最后一站的服务器弹回一条TRACE响应，并在响应主体中携带它收到的原始请求报文。这样客户端就可以查看所有中间HTTP应用程序组成的请求/响应链上，原始报文是否，以及如何被毁坏或修改。
TRACE方法主要用于诊断；用于验证请求是否如愿穿过请求/响应链。查看代理和其他应用程序对用户请求所产生效果。
TRACE缺点，假定中间应用程序对各种不同类型请求（GET、HEAD、POST）的处理是相同的。很多HTTP应用程序会根据方法的不同做出不同的事情，TRACE并不提供区分这些方法的机制。中间应用程序自行决定TRACE请求的处理方式。
TRACE请求中不能带有实体的主体部分。TRACE响应的实体主体部分包含了响应服务器收到的请求的精确副本。
六 OPTIONS方法: OPTIONS方法请求Web服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法，或者对某些特殊资源支持哪些方法。为客户端提供一种手段，使其不用实际访问那些资源就能判定访问各种资源的最优方式。
七 DELETE： DELETE方法所做的事情就是请求服务器删除URL所指定的资源，但是客户端应用程序无法保证删除操作一定会被执行。因为HTTP规范允许服务器在不通知客户端的情况下撤销请求。
八 扩展方法：HTTP被设计成字段可扩展的，这样新的特性就不会使老的软件失效。并不是所有扩展方法都在正式规范中定义，比如大部分HTTP应用程序无法理解，能够在不破坏端到端行为的情况下将带有未知方法的报文传递给下游服务器的话，代理会尝试传递这些报文。
状态码
状态码为客户端提供了一种理解事务处理结果的便捷方式。
一。100~199 信息性状态码
HTTP/1.1向协议中引入了信息性状态码。 100 Continue状态码尤其让人糊涂。它的目的是对HTTP客户端应用程序有一个实体的主体部分要发送给服务器，但希望在发送之前查看一下服务器是否会接受这个实体进行优化。
1.客户端与100 Continue
如果客户端在向服务器发送一个实体，并且愿意在发送实体之前等待100 Continue响应，那么，客户端就要发送一个携带了值为100 Continue的Expect请求首部。如果客户端没有发送实体，就不应该发送100 Continue Expect首部，因为这样会使服务器误以为客户端要发送一个实体。
100 Continue是一种优化。客户端应用程序只有在避免向服务器发送一个服务无法处理或使用的大实体时，才应该使用100 Continue。发送100 Continue的Expect首部的客户端不应该永远在哪里等待服务器发送100 Continue响应。超过一段时间客户端应该将实体发送出去。
2.服务器与100 Continue
如果服务器收到一条带有值为100 Continue的Expect首部的请求，他会用100 Continue响应或一条错误码来进行响应。服务器永远也不应该向没有发送100 Continue期望的客户端发送100 Continue状态码。如果服务器在发送100 Continue响应之前收到部分或全部实体，说明客户端决定发送数据，就不需要发送这个状态码，单服务器读完请求后，还是要为请求发送一个最终状态码。
3.代理与100 Continue
如果代理从客户端收到一条带100 Continue期望的请求，如果代理知道下一个服务器是HTTP/1.1兼容的，或不知道与那个版本兼容，他都应该将Expect首部放在请求中向下转发。如果知道只能与HTTP/1.1之前版本兼容，应该以417 Expectation Failed错误进行相应 。
二. 200~299 成功状态码
三 300~399 重定向状态码
重定向状态码要么告知客户端使用替代位置来访问他们所感兴趣的资源，要么就提供一个替代的响应而不是资源的内容。如果资源已被移动，可发送一个重定向状态码和一个可选的Location首部来告知客户端资源已被移走，以及现在可以在哪里找到它。通过某些重定向状态码对资源的应用程序本地副本与源端服务器上的资源进行验证。
四 400~499 客户端错误状态码
有时客户端会发送一些服务器无法处理的东西，比如格式错误的请求报文或者不存在的URL。
五 500~599 服务器错误状态码
有时客户端发送一条有效请求，服务器自身却出现问题。
