HTTP报文

报文的组成部分

• 每条报文都包含三个部分：对报文进行描述的起始行，包含属性的首部块，以及可选的、包含数据的主体部分。
• 起始行和首部是由行分隔的ASCII 文本。每行都以一个由两个字符组成的行终止序列作为结束，其中包括一个回车符（ASCII吗13）和一个换行符（ASCII吗10）.需要注意的是：HTTP规范中说明应该用回车换行来表示，但稳健的应用程序也应该接收单个换行符作为行的终止。有些老的，或不完整的HTTP 应用程序并不总是既发送回车符，又发送换行符。
• 实体的主体或报文的主体是一个可选的数据块。与起始行和首部不同的是，主体中可以包含文本或二进制数据，也可以为空。

报文的语法

• 所有的HTTP 报文都可以分为两类：请求报文和响应报文。
• 请求报文的格式
  
• 响应报文的格式
  

起始行

• 请求行：请求报文请求服务器对资源进行一些操作。请求报文的起始行。包含了一个方法和一个请求URL。这个方法描述了服务器应该执行的操作，请求URL 描述了要对那个资源执行这个方法。请求行中还包含HTTP 的版本，用来告知服务器，客户端使用的是那种HTTP。

  • 所有字段都由空格符分隔。

• 响应行：响应报文承载了状态信息和操作产生的所有结果数据，将其返回给客户端。

• 方法：请求的起始行以方法作为开始，方法告知服务器要做些什么。
  

• 状态码：用来服务器告诉客户端，发生了什么事情。状态码位于响应的起始行中。

  • 可以通过三位数字代码对不同状态码进行分类。200到299 之间的状态吗表示成功。300到399之间的代码表示资源已经被移走了。400到499之间的代码表示客户端的请求出错了。500到599之间的额代码表示服务器出错了。
    
    

• 原因短语：响应起始行的最后一个组件。他为状态吗提供了文本形式的解释。原因短语是状态吗的可读版本，用以说明在请求期间发生了什么情况。

• 版本号：请求和响应报文的起始行中。使用版本号的目的是为了使用HTTP 的应用程序提供一种线索，以便互相了解对方的能力和报文格式。

首部

• 首部分类：
  1. 通用首部：既可以出现在请求报文中，也可以出现在响应报文中
  2. 请求首部：提供更多有关请求的信息
  3. 响应首部：提供更多有关响应的信息
  4. 实体首部：描述主体的长度和内容，或者资源自身
  5. 扩展首部：规范中没有定于的新首部
• 注意：将长的首部分成多行可以提高可读性，多出来的每行前面至少要有一个空格或者制表符。
  

实体的主体部分

• 实体的主体是HTTP 报文的负荷。就是HTTP 要传输的内容。
• HTTP 报文可以承载很多类型的数字数据：图片、视频、HTML文档、软件应用程序、信用卡事务、电子邮件等。

方法

• GET：通常用于请求服务器发哦是那个某个资源。

• HEAD：与GET方法的行为很类似，但服务器在响应中只返回首部。不会返回实体的主体部分。这就允许客户端在未获取实际资源的情况下，对资源的首部进行检查。

  • 使用HEAD，可以：
  • 在不获取资源的情况下了解资源的情况（比如，判断其类型）
  • 通过查看响应中的状态码，看看某个对象是否存在
  • 通过查看首部，测试资源是否被修改

• PUT：会向服务器写入文档。有些发布系统允许用户创建Web页面，并用PUT 直接将其安装到Web服务器上去。

  • PUT 方法的语义就是让服务器用请求的主体部分来创建一个由所请求的URL 命名的新文档，或者，如果这个URL已经存在的话，就用这个主体来替代它。
  • 因为PUT 允许用户对内容进行修改，所以很多Web 服务器都要求在执行PUT 之前，用密码登陆。

• POST：起初是用来向服务器输入数据的。实际上，通常会用来支持HTML 的表单。表单中填好的数据通常会被送给服务器，然后由服务器将其发送到他要去的地方。
  

• TRACE：客户端发起一个请求时，这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的HTTP请求。TRACE 方法允许客户端在最终将请求发哦是那个给服务器时，看看它变成了什么样子。

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

• TRACE：主要用于诊断，也就是说，用于验证请求是否如愿穿过了请求/响应链。它也是一个很好的工具，可以用来查看代理和其他应用程序对用户请求所产生的效果。

  • TRACE 请求中不能带有实体的主体部分，TRACE响应的实体主体部分包含了响应服务器收到的请求的精确副本。

• OPTIONS：方法请求Web 服务器告知其支持的各种功能。可以询问服务器通常支持那些方法，或者对某些特殊资源支持那些方法。

  • 这为客户端应用程序提供了一种手段，使其不用实际访问那些资源就能判定访问各种资源的最优方式。
    

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

状态码

100-199------信息性状态码

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

1. 客户端与100 continue
   如果客户端在向服务器发送一个实体，并且愿意在发送实体之前等待100 continue 响应。那么，客户端就要发哦是那个一个携带了值为100 continue 的expect 请求首部。如果客户端没有发哦是那个实体，就不应该发送100 continue，以免让服务器误会。发送了值为100 continue 的Expect 首部的客户端不应该永远在哪儿等待服务器发送100 continue 响应。超过一定时间之后，客户端应该直接将实体发送出去。
2. 服务器与100 continue
   服务器永远也不应该向没有发送100 continue 期望的客户端发送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。
• 很多客户端错误都是由浏览器来处理的，甚至不会打扰到你。只有少量错误，比如404，还是会穿过浏览器来到用户面前。
  
  

500-599 服务器错误状态码

• 服务端的缺陷，或者服务器上的子元素，比如某个网关，出了错。
• 代理尝试着代表客户端与服务器进行交流时，经常会出现问题。
  

首部

通用首部

• 通用缓存首部：HTTP/1.0 引入了第一个允许HTTP应用程序缓存对象本地副本的首部，这样就不需要总是直接从源端服务器获取了。
  

请求首部

• 请求首部只在请求报文中有意义的首部。用于说明谁或什么在发送请求、请求源自何处，或者客户端的喜好及能力。服务器可以根据请求首部给出的客户端信息，试着为客户端提供更好的响应。
  

• Accept 首部：提供了一种将其喜好和能力告知服务器的方式，包括它们想要什么，可以使用什么，以及最重要的，他们不想要什么。这样，服务器就可以根据这些额外信息，对要发送的内容做出更明智的决定。Accept 首部会使连接的两端都受益。客户端会得到他们想要的内容，服务器则不会浪费其时间和带宽来发送客户端无法使用的东西。
  - 条件请求首部
  有时客户端希望为请求加上某些限制。比如，如果客户端已经有了一份文档副本，就希望只在服务器上的文档与客户端拥有的副本有所区别时，才请求服务器传输文档。通过条件请求首部，客户端就可以为请求加上这种限制，要求服务器在对请求进行响应之前，确保某个条件为真。
  

• 安全请求首部
  HTTP 本身就支持一种简单的机制，可以对请求进行质询/响应认证。这种机制要求客户端在获取特定的资源之前，先对自身进行认证，这样做就可以使事务稍微安全一些。
  

• 代理请求首部
  

响应首部

• 响应报文有自己的响应首部集，响应首部为客户端提供了一额外信息，比如谁在发送响应、响应者的功能，甚至与响应相关的一些特殊指令。这些首部有助于客户端处理响应，并在将来发起更好的请求。
  
• 还有协商首部和安全响应首部

实体首部

• 实体首部提供了有关实体及其内容的大量信息，从有关对象类型的信息，到能够对资源使用的各种有效的请求方法。总之。实体首部可以告知报文的接收者它在对什么进行处理。
• 实体的信息性首部
  
• 内容首部：提供了与实体内容有关的特定信息，说明了其类型、尺寸以及处理它所需的其他有用信息。
  
• 实体缓存首部：说明了如何或者什么时候进行缓存。实体的缓存首部提供了与被缓存实体有关的信息