一、概念

• 由客户端向服务端发出

• 报文的所有字段都是ASCII码

二、格式

• 请求行
• 首部行
• 主体部分

换行符的概念（CRLF）

• 在请求行与首部行的每一行末尾，都由一个换行符，用来标记改行的结束。
• 另外，在首部行的所有结束部分和主体部分之间又有一个换行符用来标记请求行、首部行的结束以及主体部分的开始。但由于历史原因，很多客户端和服务器都在没有实 体的主体部分时，（错误地）省略了最后的 CRLF。为了与这些流行但不符合规则的 实现进行互通，客户端和服务器都应该接受那些没有最后那个 CRLF 的报文
• 换行符由两个字符组成：包括一个回车符（ASCII码 13）和一个换行符（ASCII码10）
• 注意事项：需要指出的是，尽管HTTP规范中说明应该用CRLF来表示行终止，但稳健的应用程序也应该接受单个换行符作为行的终止

三、请求行

• 由“方法、请求URL、版本”组成。每一个字段之间用空格隔开

方法

• 客户端希望服务器对资源执行的动作。是一个单独的词，比如 GET、HEAD 或 POST
• 并不是所有服务器都实现了这些方法。而且，由于 HTTP 设计得易于扩展，所以除了这些方法之外，其他服务器可能还会实现一些自己的请求方法（被称为扩展方法）
• 即使服务器实现了所有这些方法，这些方法的使用很可能也是受限的。例如，支持 DELETE 方法或 PUT 方法的服务器可能并不希望任何人都能够删除或存储资源。这些限制通常都是在服务器的配置中进行设置的，因此会随着站点和服务器的不同而有所不同

方　　法	描　　述	是否包含主体
GET	从服务器获取一份文档	否
HEAD	只从服务器获取文档的首部，不获取主体部分数据	否
POST	向服务器发送需要处理的数据	是
PUT	将请求的主体部分存储在服务器上	是
TRACE	对可能经过代理服务器传送到服务器上去的报文进行追踪	否
OPTIONS	决定检测客户端可以在服务器上执行哪些方法	否
OPTION	查询特定选项
DELETE	从服务器上删除一份文档	否
CONNECT	用于代理服务器

安全方法：

• HTTP 定义了一组被称为安全方法的方法。GET 方法和 HEAD 方法都被认为是安全 的，这就意味着使用 GET 或 HEAD 方法的 HTTP 请求都不会产生什么动作
• 不产生动作，在这里意味着 HTTP 请求不会在服务器上产生什么结果。例如，你在 Joe 的五金商店购物时，点击了“提交购买”按钮。点击按钮时会提交一个带有信 用卡信息的 POST 请求（稍后讨论），那么在服务器上，就会为你执行一个动作。在 这种情况下，为购买行为支付信用卡就是所执行的动作
• 安全方法并不一定是什么动作都不执行的（实际上，这是由 Web 开发者决定的）。 使用安全方法的目的就是当使用可能引发某一动作的不安全方法时，允许 HTTP 应 用程序开发者通知用户。在 Joe 的五金商店的例子中，你的 Web 浏览器可能会弹出 一条警告消息，说明你正在用不安全的方法发起请求，这样可能会在服务器上引发 一些事件（比如用你的信用卡支付费用）

GET：

• GET 是最常用的方法。通常用于请求服务器发送某个资源。HTTP/1.1 要求服务器 实现此方法

HEAD：

HEAD 方法与 GET 方法的行为很类似，但服务器在响应中只返回首部。不会返回实体的主体部分。这就允许客户端在未获取实际资源的情况下，对资源的首部进行检查（服务器开发者必须确保返回的首部与 GET 请求所返回的首部完全相同。遵循 HTTP/1.1 规范，就必须实现 HEAD 方法）

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

PUT：

• 与GET从服务器读取文档相反，PUT 方法会向服务器写入文档。有些发布系统允许用户创建Web页面，并用PUT直接将其安装到Web服务器上去
• PUT方法的语义就是让服务器用请求的主体部分来创建一个由所请求的URL命名的新文档，或者，如果那个URL已经存在的话，就用这个主体来替代它
• 安全机制：因为PUT允许用户对内容进行修改，所以很多Web服务器都要求在执行PUT之前，用密码登录

POST：

• POST方法起初是用来向服务器输入数据的 。实际上，通常会用它来支持HTML的表单。表单中填好的数据通常会被送给服务器，然后由服务器将其发送到它要去的地方（通俗的说，就是向服务器输入数据）
• 比如，将数据送到一个服务器网关程序中，然后由这个程序对数据进行处理

TRACE：

• 用途：客户端发起一个请求时，这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。TRACE 请求会在目的服务器端发起一个“环回”诊断。行程最后一站的服务器会弹回一条 TRACE 响应，并在响应主体中携带它收到的原始请求报文。这样客户端 就可以查看在所有中间 HTTP 应用程序组成的请求 / 响应链上，原始报文是否，以及如何被毁坏或修改过
• 缺陷：尽管 TRACE 可以很方便地用于诊断，但它确实也有缺点，它假定中间应用程序对各种不同类型请求（不同的方法——GET、HEAD、POST 等）的处理是相同的。 很多 HTTP 应用程序会根据方法的不同做出不同的事情——比如，代理可能会将 POST 请求直接发送给服务器，而将 GET 请求发送给另一个 HTTP 应用程序（比如 Web 缓存）。TRACE 并不提供区分这些方法的机制。通常，中间应用程序会自行决定对 TRACE 请求的处理方式
• TRACE请求中不能带有实体的主体部分。TRACE 响应的实体主体部分包含了响应服务器收到的请求的精确副本

OPTIONS

• OPTIONS 方法请求Web服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法，或者对某些特殊资源支持哪些方法。（有些服务器可能只支持对一些特殊类型的对象使用特定的操作）

DELETE

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

扩展方法

• 概念：HTTP 被设计成字段可扩展的，这样新的特性就不会使老的软件失效了。扩展方法指的就是没有在 HTTP/1.1 规范中定义的方法
• 对扩展方法的处理：并不是所有的扩展方法都是在正式规范中定义的，因此如果你定义了一个扩展方法，很可能大部分 HTTP 应用程序都无法理解。同样，你的 HTTP 应用程序也可能会遇到一些其他应用程序在用的，而它并不理解的扩展方法。在这些情况下，最好对扩展方法宽容一些。如果能够在不破坏端到端行为的情况下将带有未知方法的报文传递给服务器，代理应尝试传递这些报文。如果可能破坏端到端行为则应以501 Not Implemented（无法实现）状态码进行响应
• 下面列举了一些WebDAV HTTP扩展包含的所有方法，这些方法有助于通过HTTP将Web内容发布到 Web 服务器上去

请求URL

• 命名了所请求资源，或者 URL 路径组件的完整 URL。如果直接与服务器进行对话，只要 URL 的路径组件是资源的绝对路径

版本

• 报文所使用的 HTTP 版本
• 格式：HTTP/<主版本>.<次要版本>

注意事项：

• 使用版本号的目的是为使用 HTTP 的应用程序提供一种线索，以便互相了解对方的 能力和报文格式
• 版本号不会被当作小数来处理。版本中的每个数字（比如 HTTP/1.0 中的 1 和 0）都会被当作一个单独的数字来处理。比如，HTTP/2.22 就比 HTTP/2.3 的 版本要高，因为 22 比 3 大

四、首部行

• 可以有零个或多个首部
• 格式：它们是一 些名 / 值对的列表。先是一个名称，后面跟着一个冒号（:），然后是一个可选的空格，接着是一个值，最后是一个CRLF表示该行结束

首部行的分类

• 通用首部：客户端和服务器都可以使用
• 请求首部：只有客户端可以使用
• 响应首部：只有服务端可以使用
• 实体首部：（客户端和服务器都可以使用）实体首部指的是用于应对实体主体部分的首部。比如，可以用实体首部来说明实 体主体部分的数据类型
• 扩展首部：扩展首部是非标准的首部，由应用程序开发者创建，但还未添加到已批准的 HTTP 规范中去。即使不知道这些扩展首部的含义，HTTP 程序也要接受它们并 对其进行转发

①通用首部：

• 有些首部提供了与报文相关的最基本的信息，它们被称为通用首部。它们像和事佬儿一样，不论报文是何类型，都为其提供一些有用信息

首　　部	描　　述
Connection	允许客户端和服务器指定与请求 / 响应连接有关的选项
Date	提供日期和时间标志，说明报文是什么时间创建的
MIME-Version	给出了发送端使用的 MIME 版本
Trailer	如果报文采用了分块传输编码（chunked transfer encoding）方式，就可 以用这个首部列出位于报文拖挂（trailer）部分的首部集合
Transfer-Encoding	告知接收端为了保证报文的可靠传输，对报文采用了什么编码方式
Update	给出了发送端可能想要“升级”使用的新版本或协议
Via	显示了报文经过的中间节点（代理、网关）

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

首　　部	描　　述
Cache-Control	用于随报文传送缓存指示
Pragma	另一种随报文传送指示的方式，但并不专用于缓存

②请求首部

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

首　　部	描　　述
Client-IP	提供了运行客户端的机器的 IP 地址
From	提供了客户端用户的 E-mail 地址
Host	给出了接收请求的服务器的主机名和端口号
Referer	提供了包含当前请求 URI 的文档的 URL
UA-Color	提供了与客户端显示器的显示颜色有关的信息
UA-CPU1	给出了客户端 CPU 的类型或制造商
UA-Disp	提供了与客户端显示器（屏幕）能力有关的信息
UA-OS	给出了运行在客户端机器上的操作系统名称及版本
UA-Pixels	提供了客户端显示器的像素信息
User-Agent	将发起请求的应用程序名称告知服务器

• Accept首部：Accept 首部为客户端提供了一种将其喜好和能力告知服务器的方式，包括它们想要什么，可以使用什么，以及最重要的，它们不想要什么。这样，服务器就可以根据这些额外信息，对要发送的内容做出更明智的决定。Accept首部会使连接的两端都受益。客户端会得到它们想要的内容，服务器则不会浪费其时间和带宽来发送客户端无法使用的东西

首　　部	描　　述
Accept	告诉服务器能够发送哪些媒体类型
Accept-Charset	告诉服务器能够发送哪些字符集
Accept-Encoding	告诉服务器能够发送哪些编码方式
Accept-Language	告诉服务器能够发送哪些语言
TE	告诉服务器可以使用哪些扩展传输编码

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

首　　部	描　　述
Expect	允许客户端列出某请求所要求的服务器行为
If-Match	如果实体标记与文档当前的实体标记相匹配，就获取这份文档
If-Modified-Since	除非在某个指定的日期之后资源被修改过，否则就限制这个请求
If-None-Match	如果提供的实体标记与当前文档的实体标记不相符，就获取文档
If-Range	允许对文档的某个范围进行条件请求
If-Unmodified-Since	除非在某个指定日期之后资源没有被修改过，否则就限制这个请求
Range	如果服务器支持范围请求，就请求资源的指定范围

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

首　　部	描　　述
Authorization	包含了客户端提供给服务器，以便对其自身进行认证的数据
Cookie	客户端用它向服务器传送一个令牌——它并不是真正的安全首部，但确实 隐含了安全功能
Cookie2	用来说明请求端支持的cookie版本

• 代理请求首部：随着因特网上代理的普遍应用，人们定义了几个首部来协助其更好地工作。第6章对这些首部进行了详细的讨论。

首　　部	描　　述
Max-Forward	在通往源端服务器的路径上，将请求转发给其他代理或网关的最大次 数——与 TRACE 方法一同使用
Proxy-Authorization	与 Authorization 首部相同，但这个首部是在与代理进行认证时使用的
Proxy-Connection	Connection 首部相同，但这个首部是在与代理建立连接时使用的

③实体首部

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

首　　部	描　　述
Allow	列出了可以对此实体执行的请求方法
Location	告知客户端实体实际上位于何处；用于将接收端定向到资源的（可能是新 的）位置（URL）上去

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

首　　部	描　　述
Content-Base	解析主体中的相对 URL 时使用的基础 URL
Content-Encoding	对主体执行的任意编码方式
Content-Language	理解主体时最适宜使用的自然语言
Content-Length	主体的长度或尺寸
Content-Location	资源实际所处的位置
Content-MD5	主体的 MD5 校验和
Content-Range	在整个资源中此实体表示的字节范围
Content-Type	这个主体的对象类型

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

首　　部	描　　述
ETag	与此实体相关的实体标记
Expires	实体不再有效，要从原始的源端再次获取此实体的日期和时间
Last-Modified	这个实体最后一次被修改的日期和时间

五、实体部分

• HTTP报文的第三部分是可选的实体主体部分。实体的主体是HTTP报文的负荷，就是 HTTP 要传输的内容。并不是所有的报文都包含实体的主体部分，有时，报文只是以一个CRLF结束
• HTTP 报文可以承载很多类型的数字数据：图片、视频、HTML 文档、软件应用程 序、信用卡事务、电子邮件等