情况码 意义
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 恳求,那么浏览器制止主动进行重定向,除非得到用户的承认,因为恳求的条件或许因而产生改动。
303 对应当时恳求的照应能够在另一个 URI 上被找到,而且客户端应当选用 GET 的办法拜访那个资源。这个办法的存在首要是为了答应由脚本激活的POST恳求输出重定向到一个新的资源。这个新的 URI 不是原始资源的代替引证。一起,303照应制止被缓存。当然,第二个恳求(重定向)或许被缓存。   新的 URI 应当在照应的 Location 域中回来。除非这是一个 HEAD 恳求,不然照应的实体中应当包括指向新的 URI 的超链接及简略阐明。
304 假设客户端发送了一个带条件的 GET 恳求且该恳求已被答应,而文档的内容(自前次拜访以来或许依据恳求的条件)并没有改动,则服务器应当回来这个情况码。304照应制止包括音讯体,因而一直以音讯头后的第一个空行完毕。
305 被恳求的资源有必要经过指定的署理才干被拜访。Location 域中将给出指定的署理地点的 URI 信息,接纳者需求重复发送一个独自的恳求,经过这个署理才干拜访相应资源。只要原始服务器才干树立305照应。
306 在最新版的规范中,306情况码现已不再被运用。
307 恳求的资源现在暂时从不同的URI 照应恳求。因为这样的重定向是暂时的,客户端应当持续向原有地址发送今后的恳求。只要在Cache-Control或Expires中进行了指定的情况下,这个照应才是可缓存的。   新的暂时性的URI 应当在照应的 Location 域中回来。除非这是一个HEAD 恳求,不然照应的实体中应当包括指向新的URI 的超链接及简略阐明。因为部分浏览器不能辨认307照应,因而需求增加上述必要信息以便用户能够了解并向新的 URI 宣布拜访恳求。   假设这不是一个GET 或许 HEAD 恳求,那么浏览器制止主动进行重定向,除非得到用户的承认,因为恳求的条件或许因而产生改动。
400 1、语义有误,当时恳求无法被服务器了解。除非进行修正,不然客户端不该该重复提交这个恳求。   2、恳求参数有误。
401 当时恳求需求用户验证。该照应有必要包括一个适用于被恳求资源的 WWW-Authenticate 信息头用以问询用户信息。客户端能够重复提交一个包括恰当的 Authorization 头信息的恳求。假设当时恳求现已包括了 Authorization 证书,那么401照应代表着服务器验证现已回绝了那些证书。假设401照应包括了与前一个照应相同的身份验证问询,且浏览器现已至少测验了一次验证,那么浏览器应当向用户展现照应中包括的实体信息,因为这个实体信息中或许包括了相关确诊信息。拜见RFC 2617。
402 该情况码是为了将来或许的需求而预留的。
403 服务器现已了解恳求,可是回绝履行它。与401照应不同的是,身份验证并不能供给任何协助,而且这个恳求也不该该被重复提交。假设这不是一个 HEAD 恳求,而且服务器期望能够讲清楚为何恳求不能被履行,那么就应该在实体内描绘回绝的原因。当然服务器也能够回来一个404照应,假设它不期望让客户端取得任何信息。
404 恳求失利,恳求所期望得到的资源未被在服务器上发现。没有信息能够奉告用户这个情况究竟是暂时的仍是永久的。假设服务器知道情况的话,应当运用410情况码来奉告旧资源因为某些内部的装备机制问题,现已永久的不可用,而且没有任何能够跳转的地址。404这个情况码被广泛应用于当服务器不想提醒究竟为何恳求被回绝或许没有其他适宜的照应可用的情况下。
405 恳求行中指定的恳求办法不能被用于恳求相应的资源。该照应有必要回来一个Allow 头信息用以表明出当时资源能够承受的恳求办法的列表。   鉴于 PUT,DELETE 办法会对服务器上的资源进行写操作,因而绝大部分的网页服务器都不支撑或许在默许装备下不答应上述恳求办法,关于此类恳求均会回来405过错。
406 恳求的资源的内容特性无法满意恳求头中的条件,因而无法生成照应实体。   除非这是一个 HEAD 恳求,不然该照应就应当回来一个包括能够让用户或许浏览器从中挑选最适宜的实体特性以及地址列表的实体。实体的格局由 Content-Type 头中界说的媒体类型决议。浏览器能够依据格局及本身才干自行作出最佳挑选。可是,规范中并没有界说任何作出此类主动挑选的规范。
407  与401照应相似,只不过客户端有必要在署理服务器上进行身份验证。署理服务器有必要回来一个 Proxy-Authenticate 用以进行身份问询。客户端能够回来一个 Proxy-Authorization 信息头用以验证。拜见RFC 2617。
408 恳求超时。客户端没有在服务器准备等候的时刻内完结一个恳求的发送。客户端能够随时再次提交这一恳求而无需进行任何更改。
409 因为和被恳求的资源的当时情况之间存在抵触,恳求无法完结。这个代码只答应用在这样的情况下才干被运用:用户被以为能够处理抵触,而且会从头提交新的恳求。该照应应当包括满意的信息以便用户发现抵触的源头。   抵触一般产生于对 PUT 恳求的处理中。例如,在选用版别查看的环境下,某次 PUT 提交的对特定资源的修正恳求所顺便的版别信息与之前的某个(第三方)恳求向抵触,那么此刻服务器就应该回来一个409过错,奉告用户恳求无法完结。此刻,照应实体中很或许会包括两个抵触版别之间的差异比较,以便用户从头提交归并今后的新版别。
410 被恳求的资源在服务器上现已不再可用,而且没有任何已知的转发地址。这样的情况应当被以为是永久性的。假设或许,具有链接修正功用的客户端应当在取得用户答应后删去一切指向这个地址的引证。假设服务器不知道或许无法承认这个情况是否是永久的,那么就应该运用404情况码。除非额定阐明,不然这个照应是可缓存的。   410照应的意图首要是协助网站管理员保护网站,奉告用户该资源现已不再可用,而且服务器具有者期望一切指向这个资源的远端衔接也被删去。这类事情在限时、增值服务中很遍及。相同,410照应也被用于奉告客户端在当时服务器站点上,本来归于某个个人的资源现已不再可用。当然,是否需求把一切永久不可用的资源符号为'410 Gone',以及是否需求坚持此符号多长时刻,彻底取决于服务器具有者。
411 服务器回绝在没有界说 Content-Length 头的情况下承受恳求。在增加了标明恳求音讯体长度的有用 Content-Length 头之后,客户端能够再次提交该恳求。
412 服务器在验证在恳求的头字段中给出先决条件时,没能满意其间的一个或多个。这个情况码答应客户端在获取资源时在恳求的元信息(恳求头字段数据)中设置先决条件,以此防止该恳求办法被应用到其期望的内容以外的资源上。
413 服务器回绝处理当时恳求,因为该恳求提交的实体数据巨细超越了服务器乐意或答应以处理的规模。此种情况下,服务器能够封闭衔接避免客户端持续发送此恳求。   假设这个情况是暂时的,服务器应当回来一个 Retry-After 的照应头,以奉告客户端能够在多少时刻今后从头测验。
414 恳求的URI 长度超越了服务器能够解说的长度,因而服务器回肯定该恳求供给服务。这比较罕见,一般的情况包括:   本应运用POST办法的表单提交变成了GET办法,导致查询字符串(Query String)过长。   重定向URI “黑洞”,例如每次重定向把旧的 URI 作为新的 URI 的一部分,导致在若干次重定向后 URI 超长。   客户端正在测验运用某些服务器中存在的安全缝隙进犯服务器。这类服务器运用固定长度的缓冲读取或操作恳求的 URI,当 GET 后的参数超越某个数值后,或许会产生缓冲区溢出,导致恣意代码被履行[1]。没有此类缝隙的服务器,应当回来414情况码。
415 关于当时恳求的办法和所恳求的资源,恳求中提交的实体并不是服务器中所支撑的格局,因而恳求被回绝。
416 假设恳求中包括了 Range 恳求头,而且 Range 中指定的任何数据规模都与当时资源的可用规模不重合,一起恳求中又没有界说 If-Range 恳求头,那么服务器就应当回来416情况码。   假设 Range 运用的是字节规模,那么这种情况就是指恳求指定的一切数据规模的首字节方位都超越了当时资源的长度。服务器也应当在回来416情况码的一起,包括一个 Content-Range 实体头,用以指明当时资源的长度。这个照应也被制止运用 multipart/byteranges 作为其 Content-Type。
417 在恳求头 Expect 中指定的预期内容无法被服务器满意,或许这个服务器是一个署理服务器,它有显着的依据证明在当时路由的下一个节点上,Expect 的内容无法被满意。
421 从当时客户端地点的IP地址到服务器的衔接数超越了服务器答应的最大规模。一般,这儿的IP地址指的是从服务器上看到的客户端地址(比方用户的网关或许署理服务器地址)。在这种情况下,衔接数的核算或许涉及到不止一个终端用户。
422 从当时客户端地点的IP地址到服务器的衔接数超越了服务器答应的最大规模。一般,这儿的IP地址指的是从服务器上看到的客户端地址(比方用户的网关或许署理服务器地址)。在这种情况下,衔接数的核算或许涉及到不止一个终端用户。
422 恳求格局正确,可是因为含有语义过错,无法照应。(RFC 4918 WebDAV)423 Locked   当时资源被确定。(RFC 4918 WebDAV)
424 因为之前的某个恳求产生的过错,导致当时恳求失利,例如 PROPPATCH。(RFC 4918 WebDAV)
425 在WebDav Advanced Collections 草案中界说,可是未呈现在《WebDAV 次序集协议》(RFC 3658)中。
426 客户端应当切换到TLS/1.0。(RFC 2817)
449 由微软扩展,代表恳求应当在履行完恰当的操作后进行重试。
500 服务器遇到了一个未曾意料的情况,导致了它无法完结对恳求的处理。一般来说,这个问题都会在服务器的程序码犯错时呈现。
501 服务器不支撑当时恳求所需求的某个功用。当服务器无法辨认恳求的办法,而且无法支撑其对任何资源的恳求。
502 作为网关或许署理作业的服务器测验履行恳求时,从上游服务器接纳到无效的照应。
503 因为暂时的服务器保护或许过载,服务器当时无法处理恳求。这个情况是暂时的,而且将在一段时刻今后康复。假设能够估计延迟时刻,那么照应中能够包括一个 Retry-After 头用以标明这个延迟时刻。假设没有给出这个 Retry-After 信息,那么客户端应当以处理500照应的办法处理它。   留意:503情况码的存在并不意味着服务器在过载的时分有必要运用它。某些服务器只不过是期望回绝客户端的衔接。
504 作为网关或许署理作业的服务器测验履行恳求时,未能及时从上游服务器(URI标识出的服务器,例如HTTP、FTP、LDAP)或许辅佐服务器(例如DNS)收到照应。   留意:某些署理服务器在DNS查询超时时会回来400或许500过错
505 服务器不支撑,或许回绝支撑在恳求中运用的 HTTP 版别。这暗示着服务器不能或不肯运用与客户端相同的版别。照应中应当包括一个描绘了为何版别不被支撑以及服务器支撑哪些协议的实体。
506 由《通明内容洽谈协议》(RFC 2295)扩展,代表服务器存在内部装备过错:被恳求的洽谈变元资源被装备为在通明内容洽谈中运用自己,因而在一个洽谈处理中不是一个适宜的要点。
507 服务器无法存储完结恳求一切必要的内容。这个情况被以为是暂时的。WebDAV (RFC 4918)
509 服务器到达带宽约束。这不是一个官方的情况码,可是仍被广泛运用。
510 获取资源所需求的战略并没有没满意。(RFC 2774)

ASCII码介绍

HTTP情况码(HTTP Status Code)用来表明web服务器照应客户端的HTTP情况。首要有一下5种情况类型。
1xx音讯
2xx成功
3xx重定向
4xx客户端过错
5xx服务器过错