HTTP协议基础

报文组成方式

• 起始行(start line)；
• 包含属性的首部(header)块；
• 可选的、包含数据的主体(body)部分。
  
• 
  

报文的语法

• 请求报文(request message)
  <method> <request-URL> <version>
  <headers>
  <entity-body>
• 响应报文(response message)
  <version> <status> <reason-phrase>
  <headers>
  <entity-body>
  
  

  方法

• GET
  GET是最常用的方法，通常用于请求服务器发送某个资源。
  
  
• HEAD
  HEAD方法和GET方法的行为类似，但服务器在响应中只返回首部。不会返回实体的主体部分。这就允许客户端在未获取实际资源情况下，对资源的首部进行检查。这可以验证服务器是否有效
  
  
• PUT
  与GET从服务器读取文档相反，PUT方法会向服务器写入文档。
  
  
• POST
  通常会用它来支持HTML的表单，表单中填好的数据通常会被送给服务器，然后由服务器将其发送到其他的地方。
  
  
• TRACE
  客户端要发起一个请求时，这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的HTTP请求。TRACE允许客户端在最终将请求发送给服务器时，看看它变成什么样子。
  TRACE请求会在目的服务器发起一个"环回"诊断。行程最后一站的服务器会弹回一条TRACE响应，并在响应主体中携带它收到的原始请求报文。这样客户端就可以查看在所有中间HTTP应用程序组成的请求/响应链上，原始报文是否，以及如何被毁坏或修改。
  
• 
  
• TRACE方法主要用于诊断；但它确实也有缺点，它假定中间应用程序对各种不同类型请求(不同的方法--GET、HEAD、POST等)的处理是相同的。比如，代理可能将POST请求直接发送给服务器，而将GET请求发送给另一个HTTP应用程序(比如Web缓存)。TRACE不提供区分这些方法的机制。通常，中间应用程序会自行决定对TRACE请求的处理方式。
  TRACE请求中不能带有实体的主体部分。TRACE响应的实体主体部分包含了响应服务器收到的请求的精确副本。
• OPTIONS
  OPTIONS方法请求Web服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法，或者对某些特殊资源支持哪些方法。(有些服务器可能只支持对一些特殊类型的对象使用特定的操作)。
  这位客户端应用程序提供了一种手段，使其不用实际访问那些资源就能判断访问各种资源的最优方式。
  
  
• DELETE
  DELETE方法所做的事情就是请求服务器删除请求URL所指定的资源。但是客户端应用无法保证删除操作一定会被执行。因为HTTP规范允许服务器在不通知客户端的情况下撤销请求。

• 状态码

HTTP状态码分为五大类。

• 100~199——信息性状态码
• HTTP/1.1向协议中引入了信息性状态码。
• 
  

• 200~299——成功状态码
• 客户端发起请求时，这些请求通常都是成功的。服务器有一组表示成功的状态码，分别对应于不同类型的请求。
• 
  
• • 300~399——重定向状态码
  • 重定向状态码要么告诉客户端使用替代位置来访问他们所感兴趣的资源，要么就提供一个替代的响应而不是资源的内容。如果资源已被移动，可发送一个重定向状态码和一个可选的Location首部来告诉客户端资源已被移除，以及现在可以在那里找到它，这样浏览器就可以在不打扰使用者情况下，透明地转入新的位置。
  • 
    
  • 
    
  • 
    
  • • 400~499——客户端错误状态码
    • 有时客户端会发送一些服务器无法处理的东西，比如格式错误的请求报文，或者最常见的是，请求一个不存在的URL。
    • 
      
    • 
      
    • • 500~599——客户端错误状态码
      • 有时客户端发送一条有效请求，服务器自身却出错了。这可能是客户端碰上了服务器的缺陷，或者服务器上的子元素，比如某个网管资源，出了错。
      • 
        
        
        

首部

首部和方法配合工作，共同决定了客户端和服务器能做什么事情。

在请求和响应报文中都可以用首部来提供信息，有些首部是某种报文专用的，有些首部则更通用一些。可以将首部分为五个主要的类型。

• 通用首部

这些是客户端和服务器都可以使用的通用首部。可以在客户端、服务器和其他应用程序之间提供一些非常有用的通用功能。比如Date首部就是一个通用首部，每一端都可以用它来说明构建报文的时间和日期。

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

• 请求首部

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

1. Accept首部

Accept首部为客户端提供了一种将其喜好和能力告知服务器的方式，这样服务器就可以根据这些额外信息，对要发送的内容做出更明智的决定。Accept首部会使连接的两端都受益。

2.条件请求首部

有时客户端希望为请求加上某些限制。比如，如果客户端已经有了一份文档副本，就希望只在服务器上的文档与客户端拥有的副本有所区别时，才请求服务器传输文档。通过条件请求首部，客户端就可以为请求加上这种限制，要求服务器在对请求进行响应之前，确保某个条件为真。

3.安全请求首部

HTTP本身就支持一种简单的机制，可以对请求进行质询/响应认证。这种机制要求客户端在获取特定的资源之前，先对自身进行认证，这样就可以使事物稍微安全一些，同时还会对在HTTP之上实现的其他安全机制进行讨论。

4.代理请求首部

• 响应首部

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

1.协商首部

如果资源有多种表示方法--比如，如果服务器上有某些文档的法语和德语译稿，HTTP/1.1可以为服务器和客户端提供对资源进行协商的能力。

2.安全响应首部

我们已经看到安全请求首部了，本质上这里说的就是HTTP的质询/响应认证机制的响应侧。

• 实体首部

有很多首部可以用来描述HTTP报文的负荷。由于请求和响应报文中都可能包含实体部分，所以在这两种类型的报文中都可能出现这些首部。

实体首部提供了有关实体及内容的大量信息，从有关对象类型的信息，到能够对资源使用的各种有效的请求方法。总之，实体首部可以告知报文的接受者它在对什么进行处理。

1.内容首部

内容首部提供了与实体有关的特定信息，说明了其类型、尺寸以及处理它所需的其他有用信息。比如，Web浏览器可以通过查看返回的内容类型，得知如何显示对象。

2.实体缓存首部

通用的缓存首部说明了如何或什么时候进行缓存。实体的缓存首部提供了与被缓存实体有关的信息--比如，验证已缓存的资源副本是否仍然有效所需的信息，以及更好地估计已缓存资源何时失效所需的线索。