好学若饥 - 让我们一起前行!

m88-中国教育学习资讯渠道!Haoxuee.COM



当时方位: m88主页 > IT教育 > dedecms >

http状况码汇总详解

时刻:2018-06-22 15:46来历:m88 作者:haoxuee 点击:
状况码意义 100客户端应当持续发送恳求。这个暂时照应是用来告诉客户端它的部分恳求现已被服务器接纳,且仍未被回绝。客户端应当持续发送恳求的剩下部分,或许假设恳求现已完结,疏忽这个照应。服务器有必要在恳求完结后向客户端发送一个终究照应。 101服务器

       状况码 意义
100 客户端应当持续发送恳求。这个暂时照应是用来告诉客户端它的部分恳求现已被服务器接纳,且仍未被回绝。客户端应当持续发送恳求的剩下部分,或许假设恳求现已完结,疏忽这个照应。服务器有必要在恳求完结后向客户端发送一个终究照应。
101 服务器现已理解了客户端的恳求,并将经过Upgrade 音讯头告诉客户端选用不同的协议来完结这个恳求。在发送完这个照应终究的空行后,服务器将会切换到在Upgrade 音讯头中界说的那些协议。   只要在切换新的协议更有优点的时分才应该采纳相似办法。例如,切换到新的HTTP 版别比旧版别更有优势,或许切换到一个实时且同步的协议以传送运用此类特性的资源。
102 由WebDAV(RFC 2518)扩展的状况码,代表处理将被持续履行。
200 恳求已成功,恳求所期望的照应头或数据体将随此照应回来。
201 恳求现已被完结,并且有一个新的资源现已依据恳求的需求而树立,且其 URI 现已随Location 头信息回来。假设需求的资源无法及时树立的话,应当回来 '202 Accepted'。
202 服务器已承受恳求,但没有处理。正如它或许被回绝相同,终究该恳求或许会也或许不会被履行。在异步操作的场合下,没有比发送这个状况码更便利的做法了。   回来202状况码的照应的意图是答应服务器承受其他进程的恳求(例如某个每天只履行一次的依据批处理的操作),而不必让客户端一向坚持与服务器的衔接直到批处理操作悉数完结。在承受恳求处理并回来202状况码的照应应当在回来的实体中包括一些指示处理当时状况的信息,以及指向处理状况监视器或状况猜测的指针,以便用户能够估量操作是否现已完结。
203 服务器已成功处理了恳求,但回来的实体头部元信息不是在原始服务器上有用的断定调集,而是来自本地或许第三方的复制。当时的信息或许是原始版别的子集或许超集。例如,包括资源的元数据或许导致原始服务器知道元信息的超级。运用此状况码不是有必要的,并且只要在照应不运用此状况码便会回来200 OK的情况下才是适宜的。
204 服务器成功处理了恳求,但不需求回来任何实体内容,并且期望回来更新了的元信息。照应或许经过实体头部的办法,回来新的或更新后的元信息。假设存在这些头部信息,则应当与所恳求的变量相照应。   假设客户端是浏览器的话,那么用户浏览器应保存发送了该恳求的页面,而不发生任何文档视图上的改动,即便按照标准新的或更新后的元信息应当被应用到用户浏览器活动视图中的文档。   由于204照应被制止包括任何音讯体,因而它一直以音讯头后的第一个空行完毕。
205 服务器成功处理了恳求,且没有回来任何内容。可是与204照应不同,回来此状况码的照应要求恳求者重置文档视图。该照应首要是被用于承受用户输入后,当即重置表单,以便用户能够轻松地开端另一次输入。   与204照应相同,该照应也被制止包括任何音讯体,且以音讯头后的第一个空行完毕。
206 服务器现已成功处理了部分 GET 恳求。相似于 FlashGet 或许迅雷这类的 HTTP 下载工具都是运用此类照应完结断点续传或许将一个大文档分解为多个下载段一起下载。   该恳求有必要包括 Range 头信息来指示客户端期望得到的内容规模,并且或许包括 If-Range 来作为恳求条件。   照应有必要包括如下的头部域:   Content-Range 用以指示本次照应中回来的内容的规模;假设是 Content-Type 为 multipart/byteranges 的多段下载,则每一 multipart 段中都应包括 Content-Range 域用以指示本段的内容规模。假设照应中包括 Content-Length,那么它的数值有必要匹配它回来的内容规模的实在字节数。   Date   ETag 和/或 Content-Location,假设相同的恳求本应该回来200照应。   Expires, Cache-Control,和/或 Vary,假设其值或许与之前相同变量的其他照应对应的值不同的话。   假设本照应恳求运用了 If-Range 强缓存验证,那么本次照应不应该包括其他实体头;假设本照应的恳求运用了 If-Range 弱缓存验证,那么本次照应制止包括其他实体头;这避免了缓存的实体内容和更新了的实体头信息之间的不一致。不然,本照应就应当包括一切本应该回来200照应中应当回来的一切实体头部域。   假设 ETag 或 Last-Modified 头部不能准确匹配的话,则客户端缓存应制止将206照应回来的内容与之前任何缓存过的内容组合在一起。   任何不支持 Range 以及 Content-Range 头的缓存都制止缓存206照应回来的内容。
207 由WebDAV(RFC 2518)扩展的状况码,代表之后的音讯体将是一个XML音讯,并且或许按照之前子恳求数量的不同,包括一系列独立的照应代码。
300 被恳求的资源有一系列可供挑选的回馈信息,每个都有自己特定的地址和浏览器驱动的协商信息。用户或浏览器能够自行挑选一个首选的地址进行重定向。   除非这是一个 HEAD 恳求,不然该照应应当包括一个资源特性及地址的列表的实体,以便用户或浏览器从中挑选最适宜的重定向地址。这个实体的格局由 Content-Type 界说的格局所决议。浏览器或许依据照应的格局以及浏览器自身才能,主动作出最适宜的挑选。当然,RFC 2616标准并没有规则这样的主动挑选该怎样进行。   假设服务器自身现已有了首选的回馈挑选,那么在 Location 中应当指明这个回馈的 URI;浏览器或许会将这个 Location 值作为主动重定向的地址。此外,除非额定指定,不然这个照应也是可缓存的。
301 被恳求的资源已永久移动到新方位,并且将来任何对此资源的引证都应该运用本照应回来的若干个 URI 之一。假设或许,具有链接修改功用的客户端应当主动把恳求的地址修改为从服务器反响回来的地址。除非额定指定,不然这个照应也是可缓存的。   新的永久性的 URI 应当在照应的 Location 域中回来。除非这是一个 HEAD 恳求,不然照应的实体中应当包括指向新的 URI 的超链接及简略阐明。   假设这不是一个 GET 或许 HEAD 恳求,因而浏览器制止主动进行重定向,除非得到用户的承认,由于恳求的条件或许因而发生改动。   留意:关于某些运用 HTTP/1.0 协议的浏览器,当它们发送的 POST 恳求得到了一个301照应的话,接下来的重定向恳求将会变成 GET 办法。
302 恳求的资源现在暂时从不同的 URI 照应恳求。由于这样的重定向是暂时的,客户端应当持续向原有地址发送今后的恳求。只要在Cache-Control或Expires中进行了指定的情况下,这个照应才是可缓存的。   新的暂时性的 URI 应当在照应的 Location 域中回来。除非这是一个 HEAD 恳求,不然照应的实体中应当包括指向新的 URI 的超链接及简略阐明。   假设这不是一个 GET 或许 HEAD 恳求,那么浏览器制止主动进行重定向,除非得到用户的承认,由于恳求的条件或许因而发生改动。   留意:尽管RFC 1945和RFC 2068标准不答应客户端在重定向时改动恳求的办法,可是许多现存的浏览器将302照应视作为303照应,并且运用 GET 办法拜访在 Location 中规则的 URI,而无视原先恳求的办法。状况码303和307被添加了进来,用以清晰服务器等待客户端进行何种反响。
303 对应当时恳求的照应能够在另一个 URI 上被找到,并且客户端应当选用 GET 的办法拜访那个资源。这个办法的存在首要是为了答应由脚本激活的POST恳求输出重定向到一个新的资源。这个新的 URI 不是原始资源的代替引证。一起,303照应制止被缓存。当然,第二个恳求(重定向)或许被缓存。   新的 URI 应当在照应的 Location 域中回来。除非这是一个 HEAD 恳求,不然照应的实体中应当包括指向新的 URI 的超链接及简略阐明。   留意:许多 HTTP/1.1 版曾经的 浏览器不能正确理解303状况。假设需求考虑与这些浏览器之间的互动,302状况码应该能够担任,由于大多数的浏览器处理302照应时的办法恰恰就是上述标准要求客户端处理303照应时应当做的。(责任修改:haoxuee)



赞一个
(0)
0%
嘘一下
(0)
0%
------分隔线----------------------------