HTTP报文
[toc]
HTTP报文流
HTTP报文是在HTTP应用程序之间发送的数据块，这些数据块的形式是文本形式的元信息(meta-information)开头，这些信息描述了报文的内容及含义，后面跟着可选的数据部分。
报文的组成部分
HTTP报文是简单的数据块。每一条报文都包含一条来自客户端的请求，或者一条来自服务器的响应。它们都由三部分组成；对报文进行描述的起始行(start line)、包含属性的首部(header)块，以及可选的，包含数据的主体(body)部分。
起始行和首部是由分隔的ASCII文本，每行都以一个有两个字符组成的行终止符作为结束，分别是：
- 回车符(ASCII码13)
- 换行符(ASCII码10)
这两个符号可以简写为CRLF。
实体的主体或者报文的主体是一个可选的数据块。与起始行和首部不同的是，主体中可以包含二进制数据，也可以为空。
其中，首部中给出了一些与主体先关的信息。
HTTP语法
所有的报文可以分为两类：请求报文(request message)和响应报文(response message)。请求报文会向Web服务器请求一个动作。响应报文会将请求的结果返回给客户端。请求报文和响应报文的结构很相似。
请求报文的格式如下：
<method> <request-url> <version>
<headers>
<entity-body>
这是响应报文的格式：
<version> <status-code> <reason-phrase>
<headers>
nn
<entity-body>
注意，请求报文和响应报文只有起始行的语法不同。
-
其中method指的HTTP方法
-
request-url指的是请求的URL。
-
版本(version):指的是HTTP协议的版本。
-
状态码(status-code)
-
原因短语：对于返回这种状态的解释。原因只对人有意义，对于机器是没有意义的。
-
首部(header)，也就是请求/响应头，每一个首部都有一个名字，后面跟着一个冒号（:），首部是有一个空行(CRLF)结束的，表示了首部列表的结束和实体部分的开始。
-
实体的主体部分（entity-body）:实体部分包含一个由任意数据组成的数据块。并不是所有的报文都包含实体的主体部分，有时，报文只有一个以CRLF结束。
HTTP方法
请求的起始行以方法作为开始，用来告诉服务器要做些什么。
下面的是HTTP常用的方法
| 方法 | 描述 | 是否包含主体 |
|---|---|---|
| GET | 从服务器中获取信息 | 否 |
| POST | 向服务器中发送需要处理的数据 | 否 |
| HEAD | 只从服务器获取文档的首部 | 否 |
| PUT | 将请求主体部分存储在服务器上 | 是 |
| TRACE | 对可能经过代理服务器传送到服务处上去的报文进行追踪 | 否 |
| OPTIONS | 决定可以在服务器上执行那些方法 | 否 |
| DELETE | 从服务器上删除一份文档 | 否 |
状态码
方法是用来告诉服务器做什么事情的，状态码则是告诉客户端，发生了什么事情。
状态码位于响应的起始行。比如，在行HTTP/1.0 200 OK中，状态码就是200。
下表列出了状态码的分类。
| 状态码分类 | 定义范围 | 分类 |
|---|---|---|
| 100-199 | 100-101 | 信息提示 |
| 200-299 | 200-206 | 成功 |
| 300-399 | 300-305 | 重定向 |
| 400-499 | 400-415 | 客户端错误 |
| 500-599 | 500-505 | 服务器错误 |
原因短语，它为状态码提供了文本形式的解释。比如在HTTP/1.0 OK 中OK就是原因短语。
原因短语是和状态码成对出现的。原因短语是状态码的可读版本。
| 状态码 | 原因短语 | 含义 |
|---|---|---|
| 200 | OK | 请求成功，实体的主体部分包含了请求的资源 |
| 201 | Created | 用于创建服务器对象的请求（比如，PUT）。响应中主体中包含了各种引用了已创建资源的URL，Location首部中包含的则是最具体的引用。 |
| 202 | Accepted | 请求已被接受，但服务器还未对其执行任何动作。不能b保证服务器会完成这个请求。 |
| 203 | Non-Authoritative Information | 实体首部包含的信息不是来自于资源服务器，而是来自于资源的一份副本，但无法或者没有对它所发送的与资源有关的元信息 |
| 204 | Not Content | 响应报文中包含若干首部和一个状态行，但是没有实体的主体部分，主要用于浏览器在不转为信息新文档的情况下，对其进行更新 |
| 205 | Reset Content | 主要用于浏览器，负责告诉浏览器清除当前页面中的所有HTML表单元素 |
| 206 | Partial Content | 成功执行了一部分或Range(范围)请求。客户端可以通过特殊的首部来获取部分或某个范围内的文档。 |
| 300 | Multiple Choices | 客户端请求一个实际指向多个资源的URL时会返回这个状态码，比如服务器上的某一个资源有两个版本。返回这个状态码时就会相待一个选项列表；这样就可以选择他希望使用的那一项了。 |
| 301 | Moved Permanently | 在请求URL已被移出时使用。响应的Location首部中应该包含资源现在所处的URL |
| 302 | Found | 与301状态码类似；但是，客户端应该使用Location首部给出的URL来临时定位资源。将来的请求仍应使用老的URL |
| 303 | See Other | 告知客户端仍使用另一个URL来获取资源。新的URL位于响应报文的Location首部。其主要目的是允许POST请求的响应将客户端的请求定向到某个资源上去。 |
| 304 | Not Modified | 如果客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态码。304响应禁止包含消息体，因此始终以消息头后的第一个空行结尾。 |
| 305 | User Proxy | 用来说明必须使用代理来访问资源；代理的位置由Location首部给出。很重要的一点，客户端是相对某个特定的资源来解析这条响应的，不能假定所有请求，甚至对所有持有请求资源的服务器都通过这个代理进行。如果客户端错误地让地理介入了某条请求，可能引发破坏性行为，而且会造成安全漏洞。 |
| 306 | (未使用) | 当前未使用 |
| 307 | Temporary Redirect | 与301状态码类似；但客户端应该使用Location首部给出的URL来临时定位资源。将来的请求应该使用老的URL |
| 400 | Bad Request | 用于告知客户端它发送了一个错误的请求 |
| 401 | Unauthorized | 当前请求需要用户验证。该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息。客户端可以重复提交一个包含恰当的 Authorization 头信息的请求。如果当前请求已经包含了 Authorization 证书，那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问，且浏览器已经至少尝试了一次验证，那么浏览器应当向用户展示响应中包含的实体信息，因为这个实体信息中可能包含了相关诊断信息。参见RFC 2617。 |
| 402 | 该状态码是为了将来可能的需求而预留的。 | |
| 403 | Forbidden | 服务器已经理解请求，但是拒绝执行它。与401响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交。如果这不是一个 HEAD 请求，而且服务器希望能够讲清楚为何请求不能被执行，那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个404响应，假如它不希望让客户端获得任何信息。 |
| 404 | Not Found | 用于说明服务器无法找到所请求的URL。通常会包含一个实体，以便客户端应用程序展示给用户看 |
| 405 | Method Not Allowed | 发起的请求中带有的URL不支持的方法,使用此状态码。应该在响应中包含Allow首部，已告知客户端对所请求的资源可以使用哪些方法。 |
| 406 | Not Accepted | 客户端可以使用指定的参数来说明它们愿意接收什么类型的实体。服务器没有与客户端可接受的URL相匹配的资源时，使用此状态码。通常服务器会包含一些首部，以便客户端弄请求为什么请求无法满足。 |
| 407 | Proxy Authentication Required | 与401响应类似，只不过客户端必须在代理服务器上进行身份验证。代理服务器必须返回一个 Proxy-Authenticate 用以进行身份询问。客户端可以返回一个 Proxy-Authorization 信息头用以验证。 |
| 408 | Request Timeout | 请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。 |
| 409 | Conflict | 由于和被请求的资源的当前状态之间存在冲突，请求无法完成。这个代码只允许用在这样的情况下才能被使用：用户被认为能够解决冲突，并且会重新提交新的请求。该响应应当包含足够的信息以便用户发现冲突的源头。 冲突通常发生于对 PUT 请求的处理中。例如，在采用版本检查的环境下，某次 PUT 提交的对特定资源的修改请求所附带的版本信息与之前的某个（第三方）请求向冲突，那么此时服务器就应该返回一个409错误，告知用户请求无法完成。此时，响应实体中很可能会包含两个冲突版本之间的差异比较，以便用户重新提交归并以后的新版本。 |
| 410 | Gone | 被请求的资源在服务器上已经不再可用，而且没有任何已知的转发地址。这样的状况应当被认为是永久性的。如果可能，拥有链接编辑功能的客户端应当在获得用户许可后删除所有指向这个地址的引用。如果服务器不知道或者无法确定这个状况是否是永久的，那么就应该使用404状态码。除非额外说明，否则这个响应是可缓存的。 410响应的目的主要是帮助网站管理员维护网站，通知用户该资源已经不再可用，并且服务器拥有者希望所有指向这个资源的远端连接也被删除。这类事件在限时、增值服务中很普遍。同样，410响应也被用于通知客户端在当前服务器站点上，原本属于某个个人的资源已经不再可用。当然，是否需要把所有永久不可用的资源标记为'410 Gone'，以及是否需要保持此标记多长时间，完全取决于服务器拥有者。 |
| 411 | Lenth Require | 服务器拒绝在没有定义 Content-Length 头的情况下接受请求。在添加了表明请求消息体长度的有效 Content-Length 头之后，客户端可以再次提交该请求。 |
| 412 | Precondition Failed | 服务器在验证在请求的头字段中给出先决条件时，没能满足其中的一个或多个。这个状态码允许客户端在获取资源时在请求的元信息（请求头字段数据）中设置先决条件，以此避免该请求方法被应用到其希望的内容以外的资源上。 |
| 413 | Request Entity Too Large | 服务器拒绝处理当前请求，因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下，服务器可以关闭连接以免客户端继续发送此请求。 如果这个状况是临时的，服务器应当返回一个 Retry-After 的响应头，以告知客户端可以在多少时间以后重新尝试。 |
| 414 | Request URL Too Long | 客户端发送请求的URL比服务器能够或者希望处理的URL上的时候，使用此状态码 |
| 415 | Unsupported Media Type | 服务器无法理解或无法支持客户端所发送的实体内容时，使用此状态码 |
| 416 | Request Range Not Satisfiable | 请求报文所请求的是指定资源的某个范围，而此范围无法无效或者无法满足时，使用此状态码 |
| 417 | Exception Failed | 在请求头 Expect 中指定的预期内容无法被服务器满足，或者这个服务器是一个代理服务器，它有明显的证据证明在当前路由的下一个节点上，Expect 的内容无法被满足。 |
| 500 | Internal Server Error | 服务器在处理请求的过程中遇到了错误，使用此状态码 |
| 501 | Not Implemented | 客户端发起的请求超出了服务器的能力范围 |
| 502 | Bad Gateway | 作为代理或网关使用的服务器从请求响应链的下一条链路收到一条伪响应（比如，无法连接到其他父网关）时，使用此状态码 |
| 503 | Service Unavailable | 用来说明服务器现在无法为请求提供服务，但将来可以。如果服务器知道资源什么时候可用，可以在响应中包含一个Retry-After首部。 |
| 504 | Gateway Timeout | 与状态码408类似，只是这里的响应来自一个代理或网关，它们在等待另一台服务器对其请求进行响应时超时了 |
| 505 | Http Version Not Support | 服务器不支持，或者拒绝支持在请求中使用的 HTTP 版本。这暗示着服务器不能或不愿使用与客户端相同的版本。响应中应当包含一个描述了为何版本不被支持以及服务器支持哪些协议的实体。 |
首部
首部分类
HTTP首部分为如下几类：
- 通用首部：既可以出现在请求报文中，也可以出现在响应报文中。
- 请求首部
- 提供更多关于请求的信息
- 响应首部：提供更多关于响应的信息
- 实体首部：描述主体的长度和内容，或者资源本身。
- 扩展首部：规范中没有定义的首部。
常见的首部如下实例
| 首部实例 | 描述 |
|---|---|
| Date: Wed, 19 Sep 2018 02:13:18 GMT | 服务器响应的日期 |
| Content-Length: 267 | 实体包含了267字节的数据 |
| Content-Type: image/gif | 实体的部分是一个GIF图片 |
| Accept: image/webp,image/apng,image/,/*;q=0.8 | 客户端可以接受图片 |
通用首部
为HTTP报文提供最基本信息的首部被称为通用首部。也就是基本上所有的报文都会有的。
| 首部 | 描述 |
|---|---|
| Connection | 允许客户端和服务器指定与请求/响应连接有关的选项，通常为“keep-alive” |
| Date | 提供时间 |
通用的缓存首部
HTTP/1.0引入了第一个允许HTTP应用缓存对象副本的本地副本首部，这样就不用需要总是从源端服务器获取了。
| 首部 | 描述 |
|---|---|
| Cache-Control | 用于随报文传送的缓存指示 |
请求首部
请求首部指示在请求报文中有意义的首部，用于说明是谁在发送请求、请求来自何处。
常用的请求信息首部如下：
| 首部 | 描述 |
|---|---|
| HOST | 给出请求服务器的主机名（IP或者域名）和端口号 |
| Referer | 提供了包含当前请求URI的文档的URL |
| User-Agent | 将发起的请求的应用程序名称告诉服务器 |
Accept首部
Accept首部为客户端提供了告知服务器自己的喜好和能力，包括它们想要什么，可以使用什么。
| 首部 | 描述 |
|---|---|
| Accept | 告诉服务器能够发送什么媒体类型 |
| Accept-Charset | 告诉服务器能过发送那些字符集 |
| Accept-Encoding | 告诉服务器能够发送什么编码格式 |
| Accept-Language | 告诉服务器能够发送哪些语法 |
条件请求首部
有时客户端希望为请求加上某些限制。
常用的如下：
| 首部 | 描述 |
|---|---|
| Except | 允许客户端列出某请求所要求的服务器行为。 |
| Range | 如果服务器支持范围请求，就请求资源的指定范围。 |
安全请求首部
HTTP本身就支持一种简单的机制，可以对请求进行质询/响应认证。这种机制要求客户端在获取特定资源之前，先对自身进行认证，这样就可以使得HTTP请求变得安全。
下面列出了关于安全的首部：
| 首部 | 描述 |
|---|---|
| Authorization | 包含了客户端提供给服务器，对其进行安全认证的数据 |
| Cookie | 客户端用它向服务器发送一个令牌。 |
响应首部
响应首部可以为客户端提供一些信息，比如谁在发送响应，响应者的功能等。
常见的响应首部如下：
| 首部 | 描述 |
|---|---|
| Server | 服务器应用程序的版本和名称 |
安全响应首部
| 首部 | 描述 |
|---|---|
| Set-Cookie | 客户通过Set-Cookie发送一个令牌或者其他的，不是真正的安全首部 |
实体首部
| 首部 | 描述 |
|---|---|
| Allow | 列出可以对此实体执行的请求方法 |
| Location | 告知客户端实体实际处于何处，用于客户端定向到资源的URL上去 |
| Content-Encoding | 对主体执行的任意编码方式 |
| Content-Language | 主体使用的自然语言 |
| Content-Length | 主体的长度 |
| Content-Location | 资源实际所处的位置 |
| Content-MD5 | 主体的MD5校验 |
| Content-Range | 在整个主体中此实体表示的字节范围 |
| Content-Type | 这个主体的对象类型 |
实体的主体部分
HTTP 报文中的实体的主体是可选的。实体的主体是HTTP报文的负荷。就是HTTP传输的东西。
HTTP报文可以承载很多类型的数据：图片、视频，文本等。
网友评论