HTTP系列（一）：报文

一、组成部分

1.报文语法

HTTP 报文是简单的格式化数据块。每条报文都包含一条来自客户端的请求,或者一条来自服务器的响应。它们由三个部分组成:对报文进行描述的起始行(start line)、包含属性的首部(header)块,以及可选的、包含数据的主体(body)部分。 

起始行和首部就是由行分隔的 ASCII文本。每行都以一个由两个字符组成的行终止序列作为结束,其中包括一个回车符(ASCII码13)和一个换行符(ASCII码10)。这个行终止序列可以写做CRLF。 

与起始行和首部不同的是,主体中可以包含文本或二进制数据,也可以为空。 

这是请求报文的格式:

<method> <request-URL> <version>

<headers>

<entity-body>

这是响应报文的格式(注意,只有起始行的语法有所不同):

<version> <status> <reason-phrase>

<headers>

<entity-body> 

2.起始行

1.方法

下文会对这些方法进行详细解释。

2.状态码

方法是用来告诉服务器做什么事情的,状态码则用来告诉客户端,发生了什么事情。 状态码位于响应的起始行中。比如,在行 HTTP/1.0 200 OK 中,状态码就是 200。 

状态码是在每条响应报文的起始行中返回的。会返回一个数字状态和一个可读的状态。数字码便于程序进行差错处理,而原因短语则更便于人们理解。

可以通过三位数字代码对不同状态码进行分类:

200到299之间的状态码表示成功;

300到399之间的代码表示资源已经被移走了;

400到499之间的代码表示客户端的请求出错了;

500到599之间的代码表示服务器出错了。 

下文会详细列出已经定义的状态码及其含义。

3.版本号

版本号会以 HTTP/x.y的形式出现在请求和响应报文的起始行中。为HTTP应用程序提供了一种将自己所遵循的协议版本告知对方的方式。 

注意,版本号不会被当作小数来处理。版本中的每个数字(比如HTTP/1.0中的1和0)都会被当作一个单独的数字来处理。因此,在比较HTTP版本时,每个数字都必须单独进行比较,以便确定哪个版本更高。比如,HTTP/2.22就比HTTP/2.3的版本要高,因为22比3大。 

3.首部

分类：

HTTP规范定义了几种首部字段。应用程序也可以随意发明自己所用的首部。HTTP

首部可以分为以下几类。

• 通用首部既可以出现在请求报文中,也可以出现在响应报文中。

• 请求首部 提供更多有关请求的信息。

• 响应首部提供更多有关响应的信息。

• 实体首部描述主体的长度和内容,或者资源自身。

• 扩展首部规范中没有定义的新首部。 

0. 每个 HTTP首部都有一种简单的语法:名字后面跟着冒号( :),然后跟上可选的空格,再跟上字段值,最后是一个CRLF。

首部延续行

将长的首部行分为多行可以提高可读性,多出来的每行前面至少要有一个空格或制表符(tab)。例如:

HTTP/1.0 200 OK

Content-Type: image/gif

Content-Length: 8572

Server: Test Server

Version 1.0

在这个例子中,响应报文里包含了一个 Server首部,其值被划分成了多个延续行。该首部的完整值为Test Server Version 1.0。 

4.主体

HTTP报文的第三部分是可选的实体主体部分。实体的主体是HTTP报文的负荷。就是HTTP要传输的内容。

HTTP报文可以承载很多类型的数字数据:图片、视频、HTML文档、软件应用程序、信用卡事务、电子邮件等。 

二、方法

并不是每个服务器都实现了所有的方法。如果一台服务器要与HTTP 1.1兼容,那么只要为其资源实现GET方法和HEAD方法就可以了。 即使服务器实现了所有这些方法,这些方法的使用很可能也是受限的。例如,支持DELETE方法或PUT方法(本节稍后介绍)的服务器可能并不希望任何人都能够删除或存储资源。这些限制通常都是在服务器的配置中进行设置的,因此会随着站点和服务器的不同而有所不同。 

1.安全方法

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

安全方法并不一定是什么动作都不执行的(实际上,这是由Web开发者决定的)。使用安全方法的目的就是当使用可能引发某一动作的不安全方法时,允许HTTP应用程序开发者通知用户。 

2.GET和HEAD

GET是最常用的方法。通常用于请求服务器发送某个资源。 

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

•在不获取资源的情况下了解资源的情况(比如,判断其类型);

•通过查看响应中的状态码,看看某个对象是否存在;
•通过查看首部,测试资源是否被修改了。 

3.PUT

与GET从服务器读取文档相反,PUT方法会向服务器写入文档。 

4.POST

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

5.TRACE

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

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

6.OPTIONS

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

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

7.DELETE

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

三、状态码

1. 100~199 信息性状态码

2. 200~299 成功状态码

3.300~399 重定向状态码

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

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

4.400~499 客户端错误状态码

5.500~599 服务器错误状态码

四、首部

• 通用首部

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

Date: Tue, 3 Oct 1974 02:16:00 GMT

• 请求首部

从名字中就可以看出,请求首部是请求报文特有的。它们为服务器提供了一些额外信息,比如客户端希望接收什么类型的数据。例如,下面的Accept首部就用来告知服务器客户端会接受与其请求相符的任意媒体类型:

Accept: */*

• 响应首部

响应报文有自己的首部集,以便为客户端提供信息(比如,客户端在与哪种类型的服务器进行交互)。例如,下列Server首部就用来告知客户端它在与一个版 

本 1.0的 Tiki-Hut服务器进行交互:

Server: Tiki-Hut/1.0

• 实体首部

实体首部指的是用于应对实体主体部分的首部。比如,可以用实体首部来说明实体主体部分的数据类型。例如,可以通过下列Content-Type首部告知应用程序,数据是以iso-latin-1 字符集表示的HTML 文档:

Content-Type: text/html; charset=iso-latin-1 

1.通用首部

2.请求首部

3.响应首部

4.实体首部