HTTP认知（请求与响应）

web的工作是：浏览器发送请求报文 + 服务端返回响应报文

通俗的说一下web工作的一个流程：

　　浏览器向服务端发送HTTP请求报文；这条请求报文组成由请求行、请求头、请求体三大部分组成:

　　　　1、请求行 由 请求方法、请求URL、HTTP协议及版本号 构成（HTTP请求报文的起始行即请求行）。

　　　　　　请求方法是指HTTP访问服务器的方法（文尾细说）；请求URL是指所请求的URL地址和Host，两者完整组成一个 请求URL；

　　　　2、请求头（首部） 包含若干个属性（键值对），服务器依靠属性获取客户端的信息。

　　　　　　每个首部（请求头）字段都包含一个名字和一个值，两者之间中冒号分隔，冒号后面还有一个空格。首部（请求头）以一个空行结束。

　　　　　　请求头和请求行（首部和方法）配合工作，共同决定客户端和服务器能够做什么事。

通用的信息性首部：
Connection：允许客户端和服务器指定与请求 / 响应连接有关的选项。

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

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

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

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

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

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

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

信息性首部
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 首部相同，但这个首部是在与代理建立连接时使用的。

　　　　3、请求体（数据） 将一个页面表单中的组件通过键值对形式编码生成一个格式化窜，可以表示支持多个请求参数的数据。

　　服务器根据客户端的请求返回（响应）一条HTTP响应报文：（下图尾响应报文）

　　　　这条响应报文中包含了HTTP的版本号（HTTP/1.0）+ 一个响应状态码 + 一个描述性的语句 + 响应首部字段 + 响应主体

（响应报文）

（响应状态码）

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

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

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

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

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

2.3.、~299成功状态码
 OK：请求没问题，实体的主体部分包含了所请求的资源。

 Created ：用于创建服务器对象的请求(比如，PUT)。响应的实体主体部分中 应该包含各种引用了已创建的资源的 URL，Location 首部包含的 则是最具体的引用。服务器必须在发送这个状态码之前创建好对象。

 Accepted：请求已被接受，但服务器还未对其执行任何动作。不能保证服务器会 完成这个请求，这只是意味着接受请求时，它看起来是有效的。 服务器应该在实体的主体部分包含对请求状态的描述，或许还应该有 对请求完成时间的估计 （或者包含一个指针，指向可以获取此信息的 位置）。

 Non-Authoritative Information：实体首部包含的信息不是来自于源端服务器，而是来自资源的一份副本。如果中间节点上有一份资源副本，但无法或者没有对它所发送的与资源有关的元信息（首 部）进行验证，就会出现这种情况。 这种响应码并不是非用不可的；如果实体首部来自源端服务器，响应 为  状态的应用程序就可以将其作为一种可选项使用。

 No Content ：响应报文中包含若干首部和一个状态行，但没有实体的主体部分。主 要用于在浏览器不转为显示新文档的情况下，对其进行更新(比如刷新一个表单页面)。

 Reset Content ：另一个主要用于浏览器的代码。负责告知浏览器清除当前页面中的所 有 HTML 表单元素。

 Partial Content ：成功执行了一个部分或 Range（范围）请求。客 户端可以通过一些特殊的首部来获取部分或某个范围内的文档——这 个状态码就说明范围请求成功了。 响应中必须包含 Content-Range、Date 以及 ETag 或 Content- Location 首部。

~:重定向状态码：

 Multiple Choices：客户端请求一个实际指向多个资源的 URL 时会返回这个状态码，比 如服务器上有某个 HTML 文档的英语和法语版本。返回这个代码时 会带有一个选项列表；这样用户就可以选择他希望使用的那一项了。服务器可以在 Location 首部包含首选 URL。

 Moved Permanently：在请求的 URL 已被移除时使用。响应的 Location 首部中应该包含 资源现在所处的 URL。

 Found：与  状态码类似，但是，客户端应该使用 Location 首部给出的 URL 来临时定位资源。将来的请求仍应使用老的 URL。

 See Other：告知客户端应该用另一个 URL 来获取资源。新的 URL 位于响应报文 的 Location 首部。其主要目的是允许 POST 请求的响应将客户端定向到某个资源上去。

 Not Modified：客户端可以通过所包含的请求首部，使其请求变成有条件的。如果客户端发起了一个条件 GET 请求，而最近资源未被修改的话，就可以用这个状态码来说明资源未 被修改。带有这个状态码的响应不应该包含实体的主体部分。

 Use Proxy：用来说明必须通过一个代理来访问资源；代理的位置由 Location 首部给出。很重要的一点是，客户端是相对某个特定资源来解析这 条响应的，不能假定所有请求都通过这个代理进行。如果客户端错误地让代理介入了某条请 求，可能会引发破坏性的行为，而且会造成安全漏洞。

 未使用

 Temporary Redirect：与  、302状态码类似；但客户端应该使用 Location 首部给出的 URL 来临时定位资源。将来的请求应该使用老的 URL。

注意：

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

~499客户端错误状态码
常见错误如格式错误的请求报文、请求不存在的URL。

 Bad Request ：用于告知客户端它发送了一个错误的请求。

 Unauthorized ：与适当的首部一同返回，在这些首部中请求客户端在获取对资源的访问权之前，对自己进行认证。

 Payment Required：现在这个状态码还未使用，但已经被保留，以作未来之用。

 Forbidden ：用于说明请求被服务器拒绝了。如果服务器想说明为什么拒绝请求，可以包含实体的主体部分来对原因进行描述。但这个状态码通常是在服务器不想说明拒绝原因的时候使用的。

 Not Found ：用于说明服务器无法找到所请求的 URL。通常会包含一个实体，以 便客户端应用程序显示给用户看。

 Method Not Allowed ：发起的请求中带有所请求的 URL 不支持的方法时，使用此状态码。应该在响应中包含 Allow 首部，以告知客户端对所请求的资源可以使用哪些方法。

 Not Acceptable ：客户端可以指定参数来说明它们愿意接收什么类型的实体。服务器 没有与客户端可接受的 URL 相匹配的资源时，使用此代码。通常，服务器会包含一些首部，以便客户端弄清楚为什么请求无法满足。

 Proxy Authentication Required ：与 401状态码类似，但用于要求对资源进行认证的代理服务器。

 Request Timeout ：如果客户端完成请求所花的时间太长，服务器可以回送此状态码， 并关闭连接。超时时长随服务器的不同有所不同，但通常对所有的 合法请求来说，都是够长的。

 Conflict ：用于说明请求可能在资源上引发的一些冲突。服务器担心请求会引发冲突时，可以发送此状态码。响应中应该包含描述冲突的主体。

 Gone：与  类似，只是服务器曾经拥有过此资源。主要用于 Web 站点 的维护，这样服务器的管理者就可以在资源被移除的情况下通知客户端了。

 Length Required ：服务器要求在请求报文中包含 Content-Length 首部时使用。

 Precondition Failed ：客户端发起了条件请求，且其中一个条件失败了的时候使用。如客户端包含了 Expect 首部时发起的就是条件请求。

 Request Entity Too Large：客户端发送的实体主体部分比服务器能够或者希望处理的要大时，使用此状态码。

 Request URI Too Long：客户端所发请求中的请求 URL 比服务器能够或者希望处理的要长 时，使用此状态码。

 Unsupported Media Type：服务器无法理解或无法支持客户端所发实体的内容类型时，使用此状态码。

 Requested Range Not Satisfiable：请求报文所请求的是指定资源的某个范围，而此范围无效或无法满 足时，使用此状态码。

 Expectation Failed：请求的 Expect 请求首部包含了一个期望，但服务器无法满足此期 望时，使用此状态码。 如果代理或其他中间应用程序有确切证据说明源端服务器会为某请 求产生一个失败的期望，就可以发送这个响应状态码。

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

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

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

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

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

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

响应状态码

补充：HTTP的常见请求方法：

　　GET、PUT、DELETE、POST、HEAD等，GET和HEAD方法是被认为安全的方法，因为出来进行获取资源信息外，不会有其他意义（作用）。而POST、PUT、DELETE方法是非安全的。

　　GET：用于请求服务器发送（返回）某个（请求）资源。

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

　　POST：用于向服务器发送数据，对数据进行 增删改查 的操作；常用于提交表单。

　　

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

　　

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

　　

　　

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

　　

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

　　　　好处：用于验证请求是否如愿穿过了请求/响应链；用来查看代理和其它应用程序对用户请求所产生的效果。

　　　　缺点：中间应用程序会自行决定对TRACE请求的处理方式；使用TRACE方法容易引发 XST（跨站追踪）攻击。