《HTTP权威指南》-第3章 HTTP报文

 

---

3.1 报文流

3.1.1 报文流入源端服务器

 

3.1.2 报文向下流动

 

3.2 报文的组成部分

 

3.2.1 报文的语法

 

这是请求报文的格式：

1.<method> <request-URL> <version>
2.<headers>
3.
4.<entity-body>

1.方法 请求URL 版本
2.首部
3.
4.实体主体部分

这是响应报文的格式（注意，只有起始行的语能有所不同）：

1.<version> <status> <reason-phrase>
2.<headers>
3.
4.<entity-body>

1.版本 状态码 原因短语
2.首部
3.
4.实体的主体部分

各部分描述

• 方法
  客户端希望服务器对资源执行的动作。如GET、HEAD或POST。
• 请求URL
  指明了所请求资源或者URL路径组件的完整URL。
• 版本
  报文所使用的HTTP 版本，其格式看起来是这样的：HTTP/<major>.<minor>
• 状态码
  这三位数字描述了请求过程中所发生的情况。
• 原因短语
  数字状态码的可读版本，包含行终止序列之前的所有文本。
• 首部
  可以有零个或多个首都，每个首部都包含一个名字，后面跟着一个冒号（：），然
  后是一个可选的空格，接着是一个值，最后是一个CRLF. 首部是由一个空行
  (CRLF）结束的，表示了首部列表的结束和实体主体部分的开始。
• 实体的主体部分
  实体的主体部分包含一个由任意数据组成的数据块。

例子


 

3.2.2 起始行

1. 请求行
   资源、HTTP版本
2. 响应行
   状态码、原因短语
3. 方法
   
   
    

并不是所有服务器都实现了表3-1 列出的所有7 种方挫。而且，由于HπP 设计得
易于扩展，所以除了这些方桂之外，其他服务器可能还会实现一些自己的请求方桂． 这些附加的方桂是对HTTP 规范的扩展，因此被称为扩展方法。

1. 状态码
   状态码分类：
   
   
    
   常见状态码
   
   
    
2. 原因短语
   
   • 原因短语是响应起始行中的最后一个组件．它为状态码提供了文本形式的解籍。比如，在行HTTP/1.0 200 OK 中， OK 就是原因短语。
   • 原因短语和状态码是成对出现的。原因短语是状态码的可读版本，应用程序开发者将其传送给用户．用以说明在请求期间发生了什么情况。
3. 版本号
   版本号会以HTTP/x. y 的形式出现在请求和响应报文的起始行中。为HTTP 应用程序提供了一种将自己所遵循的协议版本告知对方的方式。

3.2.3 首部

前一小节的重点是请求和响应报文的第一行（方法、状态码、原因短语和版本号）。跟在起始行后面的就是零个、一个或多个HTTP 首部字段。
HTTP 首部字段向请求和响应报文中添加了一些附加信息。本质上来说，它们只是一
些名／值对的列表。

1. 首部分类
   
   • 通用首部：可以出现在请求报文中，也可以出现在响应报文中。
   • 请求首部：提供更多有关请求的信息。
   • 响应首部：提供更多有关响应的信息．
   • 实体首部：描述主体的长度和内容，或者资源自身。
   • 扩展首部：规范中没有定义的新首部。

 

1. 首部延续行
   将长的首部行分为多行可以提高可读性，多出来的每行前面至少要有一个空格或制表符（ tab ）。

3.2.4 实体的主体部分

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

3.2.5 版本0.9的报文

 

3.3 方法

　3.3.1 安全方法

HTTP 定义了一组被称为安全方棒的方法。GET 方法和HEAD 方法都被认为是安全的，这就意味着使用GET 或HEAD 方捷的HTTP 请求都不会产生什么动作。

3.3.2 GET

用于请求服务器发送某个资源。


 

3.3.3 HEAD

HEAD 方法与GET 方法的行为很类似， 但服务器在响应中只返回首部。不会返回实体的主体部分。


 

3.3.4 PUT

与GET 从服务器读取文档相反， PUT 方能会向服务器写入文挡。


 

3.3.5 POST

POST 方法起初是用来向服务器输入数据的。实际上，通常会用它来支持HTML的表单。


 

3.3.6 TRACE

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

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


 

3.3.7 OPTIONS

OPTIONS 方法请求Web 服务器告知其支持的各种功能。


 

3.3.8 DELETE

DELETE 方法所做的事情就是请服务楼删除请求URL 所指定的资源。
HTTP 规范允许服务器在不通知客户端的情况下撤销请求。


 

3.3.9 扩展方法

HTTP 被设计成字段可扩展的，这样新的特性就不会使老的软件失效了。扩展方法指的就是没有在HTTP/1.1 规范中定义的方法。


 

3.4 状态码

3.4.1 100 ~ 109 —-信息性状态码

 

1. 客户端与100 Continue
   如果客户端在向服务器发送一个实体，并且愿意在发送实体之前等待100 Continue响应，那么，客户端就要发送一个携带了值为100 Continue 的Expect 请求首部。
   如果客户端没有发送实体，就不应该发送100 Continue Expect 首部，因为这样会使服务器误以为客户端要发送一个实体。
   从很多方面来看， 100 Continue 都是一种优化。客户端应用程序只有在避免向服务器发送一个服务器无战处理或使用的大实体时，才应该使用100 Continue 。
2. 服务器与100 Continue
   如果服务器收到了一条带有值为100 Continue 的Expect 首部的请求，它会用100 Continue 响应或一条错误码来进行响应。服务器永远也不应该向没有
   发送100 Continue 期望的客户端发送100 Continue 状态码。但如前所述，有些出错的服务器可能会这么做。
   如果出于某种原因，服务器在有机会发送100 Continue 响应之前就收到了部分（或全部）的实体，就说明客户端已经决定继续发送数据了，这样，服务器就不需要发送这个状态码了。但服务器读完请求之后，还是应该为请求发送一个最终状态码（它可以跳过100 Continue 状态）。
   最后，如果服务器收到了带有100 Continue 期望的请求，而且它决定在读取实体的主体部分之前（比如，因为出错而）结束请求，就不应该仅仅是发送一条响应并关闭连接，因为这样会妨碍客户端接收响应。
3. 代理与100 Continue
   如果代理从客户端收到了一条带有100 Continue 期望的请求，它需要做几件事情。如果代理知道下一跳服务器（在第6 章中讨论）是HπP/1.1 兼容的，或者并不知道下一跳服务器与哪个版本兼容，它都应该将Expect 首部放在请求中向下转发。如果它知道下一跳服务器只能与HTTP/1.1 之前的版本兼容，就应该以417 Expectation Failed 错模进行响应。
   如果代理决定代表与HTTP/1.0 或之前版本兼容的客户端，在其请求中放入Expect 首部和100 Continue 值，那么，（如果它从服务器收到了100 Continue 响应）它就不院该将100 Continue 响应转发给客户端，因为客户端可能不知道该拿它怎么办。

3.4.2 200 - 299——成功状态码

 

3.4.3 300 - 399——重定向状态码

重定向状态码要么告知客户端使用替代位置来访问他们所感兴趣的资源，要么就提供一个替代的响应而不是资源的内容。如果资源已被移动，可发送一个重定向状态码和一个可选的Location 首都来告知客户端资源已被移走，以及现在可以在哪里找到它。这样，浏览器就可以在不打扰使用者的情况下，透明地转入新的位置了。


 

可以通过某些重定向状态码对资源的应用程序本地副本与源端服务器上的资源进行验证。比如， HTTP应用程序可以查看其资源的本地副本是否仍然是最新的，或者在源端服务器上资源是否被修改过。图3-15 显示了一个这样的例子。客户端发送了一个特殊的If - Modified-S.ince 首部，说明只读取1997 年10 月之后修改过的文挡。这个日期之后，此文档并未被修改过，因此，服务器回送了一个304 状态码，而不是文档的内容．


 

---

 


 

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

 

 

3.4.5 500 - 599—-服务器错误状态码

 

 

3.5 首部

• 通用首部
  这些是客户端和服务器都可以使用的通用首部。
• 请求首部
  请求首部是请求报文特有的。
• 响应首部
  响应报文有自己的首部集。
• 实体首部
  实体首部指的是用于应对实体主体部分的首部．
• 扩展首部
  扩展首部是非标准的首部，由应用程序开发者创建，但还未添加到已批准的HTTP 规范中去。

3.5.1 通用首部

 

3.5.2 请求首部

信息性首部


 

1. accept 首部
   
   
    
2. 条件请求首部
   
   
    
3. 安全请求首部
   
   
    
4. 代理请求首部
   
   
    

3.5.3 响应首部

信息性首部


 

1. 协商首部
   
   
    
2. 安全响应首部
   
   
    

3.5.4 实体首部

信息性首部：


 

1. 内容首部
   
   
    
2. 实体缓存首部