http报文是http协议的核心所在,http客户端和http服务端正是通过交换http报文进行通信的。http报文以一些文本形式的元信息(meta-information)开头,这些信息描述了报文的内容及含义,后面跟着可选的数据部分。
http报文总是向下游流动的。对于客户端而言,代理和服务器就是它的下游,请求报文会流向代理,然后在流向服务器;对于服务器而言,代理和客户端就是它的下游,报文会流向代理和客户端。如图所示:
http报文由三个部分组成:对报文进行描述的起始行(start line)、包含属性的首部(header)块,以及可选的、包含数据的主体(body)部分。
起始行和首部就是由行分隔的 ASCII 文本。每行都以一个由两个字符组成的行终止序列作为结束,其中包括一个回车符(ASCII 码 13)和一个换行符(ASCII 码 10)。这个行终止序列可以写做 CRLF。需要指出的是,尽管 HTTP 规范中说明应该用CRLF 来表示行终止,但稳健的应用程序也应该接受单个换行符作为行的终止。有些老的,或不完整的 HTTP 应用程序并不总是既发送回车符,又发送换行符。
报文的主体(或者就称为主体)是一个可选的数据块。与起始行和首部不同的是,主体中可以包含文本或二进制数据,也可以为空。
所有的 HTTP 报文都可以分为两类:请求 报文(request message)和响应报文(response message)。请求报文会向 Web 服务器请求一个动作。响应报文会将请求的结果返回给客户端。请求和响应报文的基本报文结构相同。
<method> <request-URL> <version>
<headers>
<entity-body>
<version> <status> <reason-phrase>
<headers>
<entity-body>
请求报文和响应报文的格式基本一致,它们只有起始行的语法有所不同。下面对请求报文和响应报文中各部分做一个描述。
所有的 HTTP 报文都以一个起始行作为开始。请求报文的起始行说明了要做些什么。响应报文的起始行说明发生了什么。
请求行 请求行包括了方法,url,以及http协议版本。这三个字段之间由空格符分隔。例如:
POST /api/post HTTP/1.1
这表示请求方法为 POST,请求 URL 为 /api/post,http协议的版本为1.1;请求方法用来告知服务器要做些什么,url是用来定位资源的位置,http版本将自己所遵循的协议版本告知对方,以便互相了解对方的能力和报文格式。
响应行
响应行包括了http协议版本,响应状态码以及原因短语。这三个字段之间由空格符分隔,例如:
HTTP/1.1 200 OK
这表示http版本是1.1,响应状态码是200,原因短语是OK。响应状态码的作用是告诉客户端,发生了什么事情,而原因短语是为了更便于人们理解,所有的处理过程使用的都是响应状态码。
在http1.0之前,并不要求在请求行和响应行中包含http协议版本,现在应该没有web服务使用http1.0之前的协议了,我们平时几乎也见不到http1.0协议。
在起始行中,http版本形式是:
HTTP/<major>.<minor>
其中主要版本号(major)和次要版本号(minor)都是整数。 注意,版本号不会被当作小数来处理。版本中的每个数字(比如 HTTP/1.0 中的 1和 0)都会被当作一个单独的数字来处理。因此,在比较 HTTP 版本时,每个数字都必须单独进行比较,以便确定哪个版本更高。比如,HTTP/2.22 就比 HTTP/2.3 的版本要高,因为 22 比 3 大。
方法用来告诉服务器执行什么动作,主要是http的设计者们把一切都抽象为资源,而方法就是对资源执行的动作。如果一台服务器要与 HTTP 1.1 兼容,那么只要为其资源实现 GET 方法和 HEAD 方法就可以了。http提供了一些方法,即使服务器实现了所有这些方法,某些方法的使用很可能也是受限的,这些是可以通过在服务器的配置中进行设置的。例如有的服务器只允许get,head,options以及post请求。
另外就是HTTP方法在报文中必须是大写的。
HTTP 定义了一组被称为安全方法的方法。GET 方法和 HEAD 方法都被认为是安全的,这就意味着使用 GET 或 HEAD 方法的 HTTP 请求不会在服务器上产生修改资源的操作。但是这并不是一定的,因为web开发者也可以让GET方法修改资源,这是由开发者决定的。通常大多数开发者都是开发RESTful风格的api,GET方法不会产生修改资源的效果。
http方法 | 作用 |
---|---|
GET | GET 是最常用的方法。通常用于请求服务器发送某个资源。HTTP/1.1 要求服务器实现此方法。通常用在获取资源的场景下。 |
HEAD | HEAD 方法与 GET 方法的行为很类似,但服务器在响应中只返回首部。不会返回实体的主体部分。这就允许客户端在未获取实际资源的情况下,对资源的首部进行检查。服务器开发者必须确保返回的首部与 GET 请求所返回的首部完全相同。遵循HTTP/1.1 规范,就必须实现 HEAD 方法。 |
PUT | PUT 方法的语义就是让服务器用请求的主体部分来创建一个由所请求的 URL 命名的新文档,或者,如果那个 URL 已经存在的话,就用这个主体来替代它。通常用在修改资源的场景下。 |
POST | POST 方法是用来向服务器输入数据的,通常在新增资源的场景下使用。 |
TRACE | 客户端发起一个请求时,这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的 HTTP 请求。TRACE 方法允许客户端在最终将请求发送给服务器时,看看它变成了什么样子。TRACE 方法主要用于诊断;也就是说,用于验证请求是否如愿穿过了请求或者响应链。它也是一种很好的工具,可以用来查看代理和其他应用程序对用户请求所产生效果。TRACE 请求中不能带有实体的主体部分。TRACE 响应的实体主体部分包含了响应服务器收到的请求的精确副本。 |
OPTIONS | OPTIONS 方法请求 Web 服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法,或者对某些特殊资源支持哪些方法。这为客户端应用程序提供了一种手段,使其不用实际访问那些资源就能判定访问各种资源的最优方式。 |
DELETE | DELETE 方法所做的事情就是请服务器删除请求 URL 所指定的资源。但是,客户端应用程序无法保证删除操作一定会被执行。因为 HTTP 规范允许服务器在不通知客户端的情况下撤销请求。 |
下图是trace请求的示例。
HTTP 被设计成字段可扩展的,这样新的特性就不会使老的软件失效了。扩展方法指的就是没有在 HTTP/1.1 规范中定义的方法。服务器会为它所管理的资源实现一些 HTTP 服务,这些方法为开发者提供了一种扩展这些 HTTP 服务能力的手段。通常情况下,我们是不会使用扩展方法的。
状态码为客户端提供了一种理解事务处理结果的便捷方式。尽管并没有实际的规范对原因短语的确切文本进行说明。HTTP 状态码被分成了五大类。
HTTP/1.1 向协议中引入了信息性状态码,并已定义两个状态码。
状态码 | 原因短语 | 含义 |
---|---|---|
100 | Continue | 说明收到了请求的初始部分,请客户端继续。发送了这个状态码之后,服务器在收到请求之后必须进行响应。 |
101 | Switching Protocols | 说明服务器正在根据客户端的指定,将协议切换成 Update 首部所列的协议 |
100 Continue 状态码尤其让人糊涂。它的目的是对这样的情况进行优化:HTTP 客户端应用程序有一个实体的主体部分要发送给服务器,但希望在发送之前查看一下服务器是否会接受这个实体。
如果客户端在向服务器发送一个实体,并且愿意在发送实体之前等待 100 Continue响应,那么,客户端就要发送一个携带了值为 100 Continue 的 Expect 请求首部如果客户端没有发送实体,就不应该发送 100 Continue Expect 首部,因为这样会使服务器误以为客户端要发送一个实体。
从很多方面来看,100 Continue 都是一种优化。客户端应用程序只有在避免向服务器发送一个服务器无法处理或使用的大实体时,才应该使用 100 Continue。
发送了值为 100 Continue 的 Expect 首部的客户端不应该永远在那儿等待服务器发送 100 Continue 响应。超时一定时间之后,客户端应该直接将实体发送出去。
如果服务器收到了一条带有值为 100 Continue 的 Expect 首部的请求,它会用 100 Continue 响应或一条错误码来进行响应。服务器永远也不应该向没有发送 100 Continue 期望的客户端发送 100 Continue 状态码。如果出于某种原因,服务器在有机会发送 100 Continue 响应之前就收到了部分(或全部)的实体,就说明客户端已经决定继续发送数据了,这样,服务器就不需要发送这个状态码了。但服务器读完请求之后,还是应该为请求发送一个最终状态码(它可以跳过 100 Continue 状态)。
客户端发起请求时,这些请求通常都是成功的。服务器有一组用来表示成功的状态码,分别对应于不同类型的请求。下面是已定义的成功状态码。
状态码 | 原因短语 | 含义 |
---|---|---|
200 | OK | 请求没问题,实体的主体部分包含了所请求的资源 |
201 | Created | 用于创建服务器对象的请求(比如,PUT)。响应的实体主体部分中应该包含各种引用了已创建的资源的 URL,Location 首部包含的则是最具体的引用。服务器必须在发送这个状态码之前创建好对象 |
202 | Accepted | 请求已被接受,但服务器还未对其执行任何动作。不能保证服务器会完成这个请求;这只是意味着接受请求时,它看起来是有效的。服务器应该在实体的主体部分包含对请求状态的描述,或许还应该有对请求完成时间的估计(或者包含一个指针,指向可以获取此信息的位置) |
203 | Non-Authoritative Information | 实体首部包含的信息不是来自于源端服务器,而是来自资源的一份副本。如果中间节点上有一份资源副本,但无法或者没有对它所发送的与资源有关的元信息(首部)进行验证,就会出现这种情况。这种响应码并不是非用不可的;如果实体首部来自源端服务器,响应为 200 状态的应用程序就可以将其作为一种可选项使用 |
204 | No Content | 响应报文中包含若干首部和一个状态行,但没有实体的主体部分。主要用于在浏览器不转为显示新文档的情况下,对其进行更新(比如刷新一个表单页面) |
205 | Reset Content | 另一个主要用于浏览器的代码。负责告知浏览器清除当前页面中的所有 HTML 表单元素 |
206 | Partial Content | 成功执行了一个部分或 Range(范围)请求。稍后我们会看到,客户端可以通过一些特殊的首部来获取部分或某个范围内的文档——这个状态码就说明范围请求成功了。206 响应中必须包含 Content-Range、Date 以及 ETag 或 ContentLocation 首部 |
重定向状态码要么告知客户端使用替代位置来访问他们所感兴趣的资源,要么就提供一个替代的响应而不是资源的内容。如果资源已被移动,可发送一个重定向状态码和一个可选的 Location 首部来告知客户端资源已被移走,以及现在可以在哪里找到它。这样,浏览器就可以在不打扰使用者的情况下,透明地转入新的位置了。
可以通过某些重定向状态码对资源的应用程序本地副本与源端服务器上的资源进行验证。比如,HTTP 应用程序可以查看其资源的本地副本是否仍然是最新的,或者在源端服务器上资源是否被修改过。下图显示了一个这样的例子。客户端发送了一个特殊的 If-Modified-Since 首部,说明只读取 1997 年 10 月之后修改过的文档。这个日期之后,此文档并未被修改过,因此,服务器回送了一个 304 状态码,而不是文档的内容。
在对那些包含了重定向状态码的非 HEAD 请求进行响应时,最好要包含一个实体,并在实体中包含描述信息和指向(多个)重定向 URL 的链接。下表列出了已定义的重定向状态码。
状态码 | 原因短语 | 含义 |
---|---|---|
300 | Multiple Choices | 客户端请求一个实际指向多个资源的 URL 时会返回这个状态码,比如服务器上有某个 HTML 文档的英语和法语版本。返回这个代码时会带有一个选项列表;这样用户就可以选择他希望使用的那一项了。有多个版本可用时,客户端需要沟通解决,服务器可以在 Location 首部包含首选 URL |
301 | Moved Permanently | 在请求的 URL 已被移除时使用。响应的 Location 首部中应该包含资源现在所处的 URL |
302 | Found | 与 301 状态码类似;但是,客户端应该使用 Location 首部给出的URL 来临时定位资源。将来的请求仍应使用老的 URL |
303 | See Other | 告知客户端应该用另一个 URL 来获取资源。新的 URL 位于响应报文的 Location 首部。其主要目的是允许 POST 请求的响应将客户端定向到某个资源上去 |
304 | Not Modified | 客户端可以通过所包含的请求首部,使其请求变成有条件的。如果客户端发起了一个条件 GET请求,而最近资源未被修改的话,就可以用这个状态码来说明资源未被修改。带有这个状态码的响应不应该包含实体的主体部分 |
305 | Use Proxy | 用来说明必须通过一个代理来访问资源;代理的位置由 Location首部给出。很重要的一点是,客户端是相对某个特定资源来解析这条响应的,不能假定所有请求,甚至所有对持有所请求资源的服务器的请求都通过这个代理进行。如果客户端错误地让代理介入了某条请求,可能会引发破坏性的行为,而且会造成安全漏洞 |
306 | 当前未使用 | 当前未使用 |
307 | Temporary Redirect | 与 301 状态码类似;但客户端应该使用 Location 首部给出的 URL来临时定位资源。将来的请求应该使用老的URL |
302、303 和 307 状态码之间存在一些交叉。这些状态码的用法有着细微的差别,大部分差别都源于 HTTP/1.0 和 HTTP/1.1 应用程序对这些状态码处理方式的不同。
当 HTTP/1.0 客户端发起一个 POST 请求,并在响应中收到 302 重定向状态码时,它会接受 Location 首部的重定向 URL,并向那个 URL 发起一个 GET 请求(而不会像原始请求中那样发起 POST 请求)。
HTTP/1.0 服务器希望 HTTP/1.0 客户端这么做——如果 HTTP/1.0 服务器收到来自HTTP/1.0 客户端的 POST 请求之后发送了 302 状态码,服务器就期望客户端能够接受重定向 URL,并向重定向的 URL 发送一个 GET 请求。
问题出在 HTTP/1.1。HTTP/1.1 规范使用 303 状态码来实现同样的行为(服务器发送 303 状态码来重定向客户端的 POST 请求,在它后面跟上一个 GET 请求)。为了避开这个问题,HTTP/1.1 规范指出,对于 HTTP/1.1 客户端,用 307 状态码取代 302 状态码来进行临时重定向。这样服务器就可以将 302 状态码保留起来,为HTTP/1.0 客户端使用了。这样一来,服务器要选择适当的重定向状态码放入重定向响应中发送,就需要查看客户端的 HTTP 版本了。
有时客户端会发送一些服务器无法处理的东西,比如格式错误的请求报文,或者最常见的是,请求一个不存在的 URL。
状态码 | 原因短语 | 含义 |
---|---|---|
400 | Bad Request | 用于告知客户端它发送了一个错误的请求 |
401 | Unauthorized | 与适当的首部一同返回,在这些首部中请求客户端在获取对资源的访问权之前,对自己进行认证。 |
402 | Payment Required | 现在这个状态码还未使用,但已经被保留,以作未来之用 |
403 | Forbidden | 用于说明请求被服务器拒绝了。如果服务器想说明为什么拒绝请求,可以包含实体的主体部分来对原因进行描述。但这个状态码通常是在服务器不想说明拒绝原因的时候使用的 |
404 | Not Found | 用于说明服务器无法找到所请求的 URL。通常会包含一个实体,以便客户端应用程序显示给用户看 |
405 | Method Not Allowed | 发起的请求中带有所请求的 URL 不支持的方法时,使用此状态码。应该在响应中包含 Allow 首部,以告知客户端对所请求的资源可以使用哪些方法。 |
406 | Not Acceptable | 客户端可以指定参数来说明它们愿意接收什么类型的实体。服务器没有与客户端可接受的 URL 相匹配的资源时,使用此代码。通常,服务器会包含一些首部,以便客户端弄清楚为什么请求无法满足。 |
407 | Proxy Authentication Required | 与 401 状态码类似,但用于要求对资源进行认证的代理服务器 |
408 | Request Timeout | 如果客户端完成请求所花的时间太长,服务器可以回送此状态码,并关闭连接。超时时长随服务器的不同有所不同,但通常对所有的合法请求来说,都是够长的 |
409 | Conflict | 用于说明请求可能在资源上引发的一些冲突。服务器担心请求会引发冲突时,可以发送此状态码。响应中应该包含描述冲突的主体 |
410 | Gone | 与 404 类似,只是服务器曾经拥有过此资源。主要用于 Web 站点的维护,这样服务器的管理者可以在资源被移除的情况下通知客户端了 |
411 | Length Required | 服务器要求在请求报文中包含 Content-Length 首部时使用。 |
412 | Precondition Failed | 客户端发起了条件请求,且其中一个条件失败了的时候使用。客户端包含了 Expect 首部时发起的就是条件请求。 |
413 | Request Entity Too Large | 客户端发送的实体主体部分比服务器能够或者希望处理的要大时,使用此状态码 |
414 | Request URI Too Long | 客户端所发请求中的请求 URL 比服务器能够或者希望处理的要长时,使用此状态码 |
415 | Unsupported Media Type | 服务器无法理解或无法支持客户端所发实体的内容类型时,使用此状态码 |
416 | Requested Range Not Satisfiable | 请求报文所请求的是指定资源的某个范围,而此范围无效或无法满足时,使用此状态码 |
417 | Expectation Failed | 请求的 Expect 请求首部包含了一个期望,但服务器无法满足此期望时,使用此状态码。如果代理或其他中间应用程序有确切证据说明源端服务器会为某请求产生一个失败的期望,就可以发送这个响应状态码 |