2、事务

Web事务是怎样工作的？

一个HTTP事务=一条请求命令报文+一个响应报文。

HTTP 使用术语流入（inbound）和流出（outbound）来描述事务处理(transaction) 的方向。

如下图：浏览器请求资源http://www.joes-hardware.com/tools.html

浏览器发送了一条 HTTP 请求报文。这条请求的起始行中有一个 HTTP方法即GET命令，且本地资源为 /tools.html。这条请求说明它使用的是 1.0 版的 HTTP 协议。如果请 求报文没有主体，因为从服务器上 GET 一个简单的文档不需要请求数据。 服务器会回送一条 HTTP 响应报文。这条响应中包含了 HTTP 的版本号(HTTP/1.0)、 一个成功状态码(200)、一个描述性的原因短语(OK)，以及响应首部字 段，在所有这些内容之后跟着包含了所请求文档的响应主体。Content-Length 首部说明了响应主体的长度，Content-Type 首部说明了文档的 MIME 类型。

Web事务是怎么工作的？

2.1、HTTP 通信所使用的报文格式

报文：HTTP 报文是简单的格式化数据块，由一行一行的简单字符串组成的。

2.1.1、HTTP 报文包括以下三个部分

  • 起始行：报文的第一行就是起始行，在请求报文中称为请求行，用来说明要做些什么；在响应报文中称为响应行，说明出现了什么情况。
  • 首部字段：起始行后面有零个或多个首部字段。每个首部字段都包含一个名字和一个值，两者之间用冒号（:）来分隔，冒号有个可选的空格。首部以一个空行结束。
  • 主体（可选）：空行之后就是可选的报文主体，请求主体中包括 了要发送给 Web 服务器的数据；响应主体中装载了要返回给客户端的数据。起始行和首部都是文本形式且都是结构化的，而主体可以包含文本或任意 的二进制数据(比如图片、视频、音轨、软件程序)。

2.1.2、格式详解

请求报文的格式：

<method> <request-URL> <version>
<headers>

<entity-body>

请求报文，主体为空，如：

请求报文格式

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

<version> <status> <reason-phrase>
<headers>

<entity-body>

响应报文如：

响应报文格式

另外需要注意HTTP/0.9 报文也由请求和响应组成，但请求中只包含方法和请求 URL，响应中只包含实体，缺点是灵活性差，有局限性。

下面是各部分的描述：

  • method：客户端希望服务器对资源执行的动作，如常见的HTTP七种方法：

http七种方法

  • request-URL ：命名了所请求资源，或者 URL 路径组件的完整 URL。
  • version：告知服务器，客户端使用哪种HTTP版本，格式HTTP/.。在HTTP/1.0之前不要求包含HTTP版本号。目的在于为使用HTTP的应用程序提供一种线索，以便互相了解对方的能力和报文格式。注意，版本号不能当作小数来处理，major和minor被当作一个单独的数字来处理，如HTTP/2.22比HTTP/2.3的版本高。

  • status-code：状态码告诉客户端发生了什么事。status-code 常见的比如：200 OK表示成功；401 Unauthorized表示未授权，需要输入用户名和密码；404 Not Found表示服务器无法找到所请求URL对应的资源。

  • reason-phrase：描述操作状态的文本形式的原因短语，数字状态码的可读版本，便于人们理解。

  • headers：首部。
  • entity-body：实体的主体部分。

2.2、常见HTTP方法

GET、PUT、DELETE、POST、HEAD。GET方法和HEAD方法被认为是安全方法，因为出来进行获取资源信息外，不会有其他意义。而POST、PUT、DELETE方法是非安全的，应该告知客户可能的后果。

2.2.1、GET

用于请求服务器发送某个资源。HTTP/1.1 要求服务器 实现此方法。

GET

2.2.2、HEAD

与GET类似，但是仅请求响应首部。客户端在未获取实际资源的情况下，对资源的首部进行检查。使用HEAD，可以在不获取资源的情况下了解资源的情况，比如，判断资源的类型；通过查看响应中的状态码，看看某个对象是否存在； 通过查看首部，测试资源是否被修改了。

遵循 HTTP/1.1 规范，就必须实现 HEAD 方法。

HEAD

2.2.3、POST

用于向服务器发送数据，对数据进行增删和更新操作，常用于提交表单。

POST

2.2.4、PUT

与 GET 从服务器读取文档相反，PUT 方法会向服务器写入（存储）文档。要求在请求报文的主体中包含文件内容，然后文件保存到请求URI指定的位置。

PUT

2.2.5、DELETE

按请求URI删除指定的资源文件，和PUT方法相反。但是客户端无法保证删除操作一定会被执行，因为HTTP规范允许服务器自行撤销请求而不告知客户端。

DELETE

2.2.6、OPTIONS

请求web服务器告知其支持的各种功能。

OPTIONS

2.2.7、TRACE

让WEB服务器端将之前的请求通信环回给客户端，通信环回可能包括防火墙、代理、网关或其他一些应用程序， 每个中间节点可能都会修改原始的HTTP请求，最后一个节点返回一条TRACE响应，并在响应主体中携带它收到的原始请求报文。

  • 好处：用于验证请求是否如愿穿过了请求 / 响应 链；用来查看代理和其他应用程序对用户请求所产生的效果。
  • 缺点：中间应用程序会自行决 定对 TRACE 请求的处理方式；使用TRACE方法容易引发XST（Cross-Site Tracing，跨站追踪）攻击。

TRACE 请求中不能带有实体的主体部分。TRACE 响应的实体主体部分包含了响应 服务器收到的请求的精确副本：

TRACE

2.2.8、扩展方法

即WebDAV HTTP 扩展中的方法，没有在HTTP/1.1 规范中定义。

可能大部分 HTTP 应用程序都无法理解你自己定义的扩展方法。处理扩展方法的原则：对所发送的内容要求严一点，对所接收的内容宽容一些。

2.3、状态码（三位数字）

五大类HTTP状态码：

状态码

2.3.1、100~199信息性状态码

HTTP/1.1 向协议中引入了信息性状态码。这些状态码相对较新，关于其复杂性和感 知价值存在一些争论，而受到限制。

  • 100 Continue说明收到了请求的初始部分，请客户端继续。它的目的是对这样的情况进行优化:HTTP客 户端应用程序有一个实体的主体部分要发送给服务器，但希望在发送之前查看一下 服务器是否会接受这个实体。
  • 101 Switching Protocols 说明服务器正在根据客户端的指定，将协议切换成Update首部所列的协议。
100 Continue

客户端：

100 Continue都是一种优化。但是客户端应用程序只有在避免向服务 器发送一个服务器无法处理或使用的大实体时，才应该使用 100 Continue。不过客户端不应该傻等着服务器的响应是否发送实体，超过一定时间就要发送实体出去。

服务端： 收到100 Continue的请求则会用100 Continue响应或一条错误码来响应。当服务端有机会发送100 Continue响应之前就收到部分或全部实体，在结束请求之后则可跳过100 Continue响应，只发送一个最终状态码。

代理： 代理收到100 Continue请求，在知道下一跳服务器与HTTP/1.1兼容或不知道它与哪个版本兼容，会将Expect首部放在请求中向下转发；但是知道下一跳服务器只能与 HTTP/1.1 之前的版本兼容，就应该以 417 Expectation Failed 错误进行响应，或者向客户端先返回 100 Continue，在向服务器转发请求时，删掉 Expect 首部。 如果代理代表与 HTTP/1.0 或之前版本兼容的客户端，在其请求中放入 Expect 首部和100 Continue值，如果从服务器收到了100 Continue响应，则不应该将 100 Continue 响应转发给客户端，因为客户端可能不知道该拿它怎么办。

2.3.2、200~299成功状态码

  • 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 或 Content- Location 首部。

2.3.3、300~399 重定向状态码

重定向状态码告知客户端使用替代位置（可能是提供Location首部或者使用本地副本等）来访问他们所感兴趣的资源，或者提 供一个替代的响应而不是资源的内容。

重定向状态码

已定义的重定向状态码：

  • 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 、302状态码类似；但客户端应该使用 Location 首部给出的 URL 来临时定位资源。将来的请求应该使用老的 URL。

注意：

302、303 和 307 状态码之间存在一些交叉，大部分差别都源于 HTTP/1.0 和 HTTP/1.1 应用程序对 这些状态码处理方式的不同： HTTP/1.1 规范使用302状态码以及HTTP/1.1 规范使用 303 状态码来实现同样的行为：服务器发送状态码来重定向客户端的 POST 请求，在它后面跟上一个 GET 请求。 为了避开这个问题，HTTP/1.1 规范指出，对于 HTTP/1.1 客户端，用 307 状态码取代 302 状态码来进行临时重定向。

2.3.4、400~499客户端错误状态码

常见错误如格式错误的请求报文、请求不存在的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 请求首部包含了一个期望，但服务器无法满足此期 望时，使用此状态码。 如果代理或其他中间应用程序有确切证据说明源端服务器会为某请 求产生一个失败的期望，就可以发送这个响应状态码。

2.3.5、500~599服务器错误状态码

  • 500 Internal Server Error：服务器遇到一个妨碍它为请求提供服务的错误时，使用此状态码。

  • 501 Not Implemented：客户端发起的请求超出服务器的能力范围(比如，使用了服务器不支持的请求方法)时，使用此状态码。

  • 502 Bad Gateway：作为代理或网关使用的服务器从请求响应链的下一条链路上收到了 一条伪响应(比如，它无法连接到其父网关)时，使用此状态码。

  • 503 Service Unavailable ：用来说明服务器现在无法为请求提供服务，但将来可以。如果服务 器知道什么时候资源会变为可用的，可以在响应中包含一个Retry- After 首部。

  • 504 Gateway Timeout ：与状态码 408 类似，只是这里的响应来自一个网关或代理，它们在等待另一服务器对其请求进行响应时超时了。

  • 505 HTTP Version Not Supported：服务器收到的请求使用了它无法或不愿支持的协议版本时，使用此 状态码。有些服务器应用程序会选择不支持协议的早期版本。

2.4、首部

首部：起始行后面有零个或多个首部字段。每个首部字段都包含一个名字和一个值，两者之间用冒号（:）来分隔，冒号后面还有个空格。首部以一个空行结束。 首部和方法配合工作，共同决定了客户端和服务器能做什么事情。

首部分类:

  • 通用首部
  • 请求首部
  • 响应首部
  • 实体首部：描述主体的长度和内容，或资源自身
  • 扩展首部：规范没有定义的新首部

常见的首部实例：

首部实例

当一行首部过长时，将其分为多行，多出来的每行至少有一个空格或制表符tab。如下Server 首部，其值被划分成了多个个延续行，完整值为Test Server Version 1.0：

首部延续行

2.4.1、通用首部

客户端和服务器都可以使用，如Date首部。

通用的信息性首部：

  • Connection：允许客户端和服务器指定与请求 / 响应连接有关的选项。

  • Date：提供日期和时间标志，说明报文是什么时间创建的。

  • MIME-Version：给出了发送端使用的 MIME 版本。

  • Trailer：如果报文采用了分块传输编码（chunked transfer encoding）方式，就可 以用这个首部列出位于报文拖挂（trailer）部分的首部集合。

  • Transfer-Encoding：告知接收端为了保证报文的可靠传输，对报文采用了什么编码方式。

  • Update：给出了发送端可能想要“升级”使用的新版本或协议。

  • Via：显示了报文经过的中间节点(代理、网关)。

通用缓存首部
  • Cache-Control：用于随报文传送缓存指示，使用优于Pragma。
  • Pragma：另一种随报文传送指示的方式，但并不专用于缓存。

2.4.2、请求首部

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

信息性首部
  • Client-IP：提供了运行客户端的机器的IP地址。RFC 2616没有定义此首部，但很多程序实现了，还包括了UA-*首部。
  • From：提供了客户端用户的 E-mail 地址，使用RFC 822 E--mail地址格式。
  • Host：给出了接收请求的服务器的主机名和端口号。
  • Referer：提供了包含当前请求 URI 的文档的 URL。
  • UA-Color：提供了与客户端显示器的显示颜色有关的信息。
  • UA-CPU：给出了客户端 CPU 的类型或制造商。
  • UA-Disp：提供了与客户端显示器(屏幕)能力有关的信息。
  • UA-OS：给出了运行在客户端机器上的操作系统名称及版本。
  • UA-Pixels：提供了客户端显示器的像素信息。
  • User-Agent：将发起请求的应用程序名称告知服务器。
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 支持一种简单的机制：要求客户端在获取特定的资源之前，先对自身进行认证，使事务稍微安全一些。

  • Authorization: 包含了客户端提供给服务器，以便对其自身进行认证的数据。
  • Cookie：客户端用它向服务器传送一个令牌——它并不是真正的安全首部，但确实 隐含了安全功能。RFC 2616 并没有定义 Cookie 首部。
  • Cookie2 ：用来说明请求端支持的 cookie 版本。
代理请求首部
  • Max-Forward ：在通往源端服务器的路径上，将请求转发给其他代理或网关的最大次 数——与 TRACE 方法一同使用。
  • Proxy-Authorization：与 Authorization 首部相同，但这个首部是在与代理进行认证时使用的。
  • Proxy-Connection ：与 Connection 首部相同，但这个首部是在与代理建立连接时使用的。

2.4.3、响应首部

响应报文特有的，如谁在发送响应、响应者的功能，甚至与响应相关的一些特殊指令。

信息性首部

  • Age：(从最初创建开始)响应持续时间。暗示响应是通过中间节点，很可能是从代理的缓存传送过来的。

  • Public：服务器为其资源支持的请求方法列表。Public 首部是在 RFC 2068 中定义的，但在最新的 HTTP 定义(RFC 2616)中并没有出现。

  • Retry-After：如果资源不可用的话，在此日期或时间重试。

  • Server：服务器应用程序软件的名称和版本。

  • Title：对 HTML 文档来说，就是 HTML 文档的源端给出的标题。

  • Warning：比原因短语中更详细一些的警告报文。

协商首部

HTTP/1.1 可以为服务器和客户端提供对资源进行协商的能力，服务器可以用协商首部来传递与可协商资源有关的信息。

  • Accept-Ranges：对此资源来说，服务器可接受的范围类型。
  • Vary ：服务器查看的其他首部的列表，可能会使响应发生变化;也就是说，这是 一个首部列表，服务器会根据这些首部的内容挑选出最适合的资源版本发 送给客户端。
安全响应首部

HTTP 的质询 / 响应认证机 制的响应侧。基本的安全响应首部：

  • Proxy-Authenticate：来自代理的对客户端的质询列表。

  • Set-Cookie：不是真正的安全首部，但隐含有安全功能；可以在客户端设置一个令牌，以便服务器对客户端进行标识。

  • Set-Cookie2：与 Set-Cookie 类似，RFC 2965 Cookie 定义。

  • WWW-Authenticate ：来自服务器的对客户端的质询列表。

2.4.4、实体首部

用于应对实体主体部分的首部，如说明实 体主体部分的数据类型Content-Type。

信息性首部
  • Allow ：列出了可以对此实体执行的请求方法。
  • Location ：告知客户端实体实际上位于何处；用于将接收端定向到资源的(可能是新 的)位置(URL)上去。
内容首部
  • Content-Base：解析主体中的相对 URL 时使用的基础 URL。RFC 2616 中没有定义 Content-Base 首部。
  • Content-Encoding：对主体执行的任意编码方式。
  • Content-Language：理解主体时最适宜使用的自然语言。
  • Content-Length：主体的长度或尺寸。
  • Content-Location：资源实际所处的位置。
  • Content-MD5：主体的 MD5 校验和。
  • Content-Range：在整个资源中此实体表示的字节范围。
  • Content-Type：主体的对象类型。
实体缓存首部

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

  • ETag：与此实体相关的实体标记，即某个特定资源版本的标识符。
  • Expires：实体不再有效，要从原始的源端再次获取此实体的日期和时间。
  • Last-Modified：这个实体最后一次被修改的日期和时间。