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)+ 一个响应状态码 + 一个描述性的语句 + 响应首部字段 + 响应主体

 

 (响应报文)

(响应状态码)

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.2200~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 首部。


300~399:重定向状态码:

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。

注意:

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


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

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:服务器收到的请求使用了它无法或不愿支持的协议版本时,使用此 状态码。有些服务器应用程序会选择不支持协议的早期版本。
响应状态码

 

 

补充: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(跨站追踪)攻击。

 

posted @ 2019-08-27 22:26  Mirror王宇阳  阅读(646)  评论(0编辑  收藏  举报