HTTP情况码对比表

2021-01-20 10:02 jianzhan

HTTP情况码对比表


短视頻,自新闻媒体,达人种草1站服务

当访问者浏览1个网页页面时,访问者的访问器会向网页页面所属服务器传出恳求。当访问器接受并显示信息网页页面前,此网页页面所属的服务器会回到1个包括HTTP情况码的信息内容头(server header)用以回应访问器的恳求。

HTTP情况码的英文为HTTP Status Code。下面是普遍的HTTP情况码:

200 恳求取得成功

301 資源(网页页面等)被永久性迁移到其它URL

404 恳求的資源(网页页面等)不存在

500 內部服务器不正确

HTTP情况码的归类

HTTP情况码由3个10进制数据构成,第1个10进制数据界定了情况码的种类,后两个数据沒有归类的功效。HTTP情况码共分成5类型型:

归类归类叙述

1**信息内容,服务器收到恳求,必须恳求者再次实行实际操作

2**取得成功,实际操作被取得成功接受并解决

3**重定项,必须进1步的实际操作以进行恳求

4**顾客端不正确,恳求包括英语的语法不正确或没法进行恳求

5**服务器不正确,服务器在解决恳求的全过程中产生了不正确

HTTP情况码表(版本号1) 此表含情况码英文名字

情况 码情况码英文名字汉语叙述

1开始的情况码

100Continue再次。顾客端应再次其恳求

101Switching Protocols切换协议书。服务器依据顾客端恳求切换协议书。只能切换到更高級的协议书,比如,切换到HTTP的新版本号协议书

2开始的情况码

200OK恳求取得成功。1般用于GET与POST恳求

201Created已建立。取得成功恳求并建立了新的資源

202Aepted已接纳。早已接纳恳求,但未解决进行

203Non-Authoritative Information非受权信息内容。恳求取得成功。但回到的meta信息内容不在初始的服务器,而是1个副本

204No Content无內容。服务器取得成功解决,但未回到內容。在未升级网页页面的状况下,可保证访问器再次显示信息当今文本文档

205Reset Content重设內容。服务器解决取得成功,客户终端设备(比如:访问器)应重设文本文档主视图。可根据此回到码消除访问器的表单域

206Partial Content一部分內容。服务器取得成功解决了一部分GET恳求

3开始的情况码

300Multiple Choices多种多样挑选。恳求的資源可包含好几个部位,相应可回到1个資源特点与详细地址的目录用于客户终端设备(比如:访问器)挑选

301Moved Permanently永久性挪动。恳求的資源已被永久性的挪动到新URI,回到信息内容会包含新的URI,访问器会全自动定项到新URI。将来任何新的恳求都应应用新的URI替代

302Found临时性挪动。与301相近。但資源只是临时性被挪动。顾客端应再次应用原来URI

303See Other查询其它详细地址。与301相近。应用GET和POST恳求查询

304Not Modified未改动。所恳求的資源未改动,服务器回到此情况码时,不容易回到任何資源。顾客端一般会缓存文件浏览过的資源,根据出示1个头信息内容指出顾客端期待只回到在特定时间以后改动的資源

305Use Proxy应用代理商。所恳求的資源务必根据代理商浏览

306Unused早已被废料的HTTP情况码

307Temporary Redirect临时性重定项。与302相近。应用GET恳求重定项

4开始的情况码

400Bad Request顾客端恳求的英语的语法不正确,服务器没法了解

401Unauthorized恳求规定客户的身份验证

402Payment Required保存,未来应用

403Forbidden服务器了解恳求顾客端恳求,可是回绝实行此恳求

404Not Found服务器没法依据顾客端恳求寻找資源(网页页面)。根据此编码,网站制作人员可设定 您所恳求的資源没法寻找 的个性化网页页面

405Method Not Allowed顾客端恳求中的方式被严禁

406Not Aeptable服务器没法依据顾客端恳求的內容特点进行恳求

407Proxy Authentication Required恳求规定代理商的身份验证,与401相近,但恳求者理应应用代理商开展受权

408Request Time-out服务器等候顾客端推送的恳求時间太长,请求超时

409Conflict服务器进行顾客端PUT恳求是将会回到此编码,服务器解决恳求时产生了矛盾

410Gone顾客端恳求的資源早已不存在。410不一样于404,假如資源之前有如今被永久性删掉了可以使用410编码,网站制作人员可根据301编码特定資源的新部位

411Length Required服务器没法解决顾客端推送的不带Content-Length的恳求信息内容

412Precondition Failed顾客端恳求信息内容的先决标准不正确

413Request Entity Too Large因为恳求的实体线过大,服务器没法解决,因而回绝恳求。为避免顾客端持续恳求,服务器将会会关掉联接。假如只是服务器临时没法解决,则会包括1个Retry-After的回应信息内容

414Request-URI Too Large恳求的URI太长(URI一般为网站地址),服务器没法解决

415Unsupported Media Type服务器没法解决恳求附带的新闻媒体文件格式

416Requested range not satisfiable顾客端恳求的范畴失效

417Expectation Failed服务器没法考虑Expect的恳求头信息内容

5开始的情况码

500Internal Server Error服务器內部不正确,没法进行恳求

501Not Implemented服务器不适用恳求的作用,没法进行恳求

502Bad Gateway当做网关或代理商的服务器,从远端服务器接受到了1个失效的恳求

503Service Unavailable因为超载或系统软件维护保养,服务器临时的没法解决顾客端恳求。延时的长度可包括在服务器的Retry-After头信息内容中

504Gateway Time-out当做网关或代理商的服务器,未立即从远端服务器获得恳求

505HTTP Version not supported服务器不适用恳求的HTTP协议书的版本号,没法进行解决

HTTP情况码目录(版本号2) 此表的叙述更详尽些

情况码含意

100顾客端理应再次推送恳求。这个临时性回应是用来通告顾客端它的一部分恳求早已被服务器接受,且仍未被回绝。顾客端理应再次推送恳求的剩下一部分,或假如恳求早已进行,忽视这个回应。服务器务必在恳求进行后向顾客端推送1个最后回应。

101服务器早已了解了顾客端恳求,并将根据Upgrade 信息头通告顾客端选用不一样的协议书来进行这个恳求。在推送完这个回应最终的空行后,服务器可能切换到在Upgrade 信息头中界定的那些协议书。

仅有在切换新的协议书更有益处的情况下才应当采用相近对策。比如,切换到新的HTTP 版本号比旧版本号更有优点,或切换到1个即时且同歩的协议书以传输运用此类特点的資源。

102由WebDAV(RFC 2518)拓展的情况码,意味着解决将被再次实行。

200恳求已取得成功,恳求所期待的回应头或数据信息体将随此回应回到。

201恳求早已被完成,并且有1个新的資源早已根据恳求的必须而创建,且其 URI 早已随Location 头信息内容回到。倘若必须的資源没法立即创建的话,理应回到 202 Aepted 。

202服务器已接纳恳求,但并未解决。正如它将会被回绝1样,最后该恳求将会会也将会不容易被实行。在多线程实际操作的场所下,沒有比推送这个情况码更便捷的做法了。

回到202情况码的回应的目地是容许服务器接纳别的全过程的恳求(比如某个每日只实行1次的根据批解决的实际操作),而无须让顾客端1直维持与服务器的联接直至批解决实际操作所有进行。在接纳恳求解决并回到202情况码的回应理应在回到的实体线中包括1些标示解决当今情况的信息内容,和指向解决情况监控器或情况预测分析的指针,便于客户可以估算实际操作是不是早已进行。

203服务器已取得成功解决了恳求,但回到的实体线头顶部元信息内容并不是在初始服务器上合理确实定结合,而是来自当地或第3方的复制。当今的信息内容将会是初始版本号的非空子集或超集。比如,包括資源的元数据信息将会致使初始服务器了解元信息内容的非常。应用此情况码并不是务必的,并且仅有在回应不应用此情况码便会回到200 OK的状况下才是适合的。

204服务器取得成功解决了恳求,但不必须回到任何实体线內容,而且期待回到升级了的元信息内容。回应将会根据实体线头顶部的方式,回到新的或升级后的元信息内容。假如存在这些头顶部信息内容,则理应与所恳求的自变量相映衬。

假如顾客端是访问器的话,那末客户访问器应保存推送了该恳求的网页页面,而不造成任何文本文档主视图上的转变,即便依照标准新的或升级后的元信息内容理应被运用到客户访问器主题活动主视图中的文本文档。

因为204回应被严禁包括任何信息体,因而它自始至终以信息头后的第1个空行末尾。

205服务器取得成功解决了恳求,且沒有回到任何內容。可是与204回应不一样,回到此情况码的回应规定恳求者重设文本文档主视图。该回应关键是被用于接纳客户键入后,马上重设表单,便于客户可以轻轻松松地刚开始另外一次键入。

与204回应1样,该回应也被严禁包括任何信息体,且以信息头后的第1个空行完毕。

206服务器早已取得成功解决了一部分 GET 恳求。相近于 FlashGet 或迅雷这类的 HTTP 免费下载专用工具全是应用此类回应完成断点续传或将1个大文本文档溶解为好几个免费下载段另外免费下载。

该恳求务必包括 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 弱缓存文件认证,那末本次回应严禁包括别的实体线头;这防止了缓存文件的实体线內容和升级了的实体线头信息内容之间的不1致。不然,本回应就理应包括全部本应当回到200回应中理应回到的全部实体线头顶部域。

倘若 ETag 或 Last-Modified 头顶部不可以精准配对的话,则顾客端缓存文件应严禁将206回应回到的內容与以前任何缓存文件过的內容组成在1起。

任为何不适用 Range 和 Content-Range 头的缓存文件都严禁缓存文件206回应回到的內容。

207由WebDAV(RFC 2518)拓展的情况码,意味着以后的信息体将是1个XML信息,而且将会按照以前子恳求数量的不一样,包括1系列单独的回应编码。

300被恳求的資源有1系列可供挑选的回馈信息内容,每一个都有自身特殊的详细地址和访问器驱动器的商讨信息内容。客户或访问器可以自主挑选1个首选的详细地址开展重定项。

除非这是1个 HEAD 恳求,不然该回应理应包含1个資源特点及详细地址的目录的实体线,便于客户或访问器从选中择最适合的重定项详细地址。这个实体线的文件格式由 Content-Type 界定的文件格式所决策。访问器将会依据回应的文件格式和访问器本身工作能力,全自动作出最适合的挑选。自然,RFC 2616标准并沒有要求这样的全自动挑选该怎样开展。

假如服务器自身早已有了首选的回馈挑选,那末在 Location 中理应指明这个回馈的 URI;访问器将会会将这个 Location 值做为全自动重定项的详细地址。另外,除非附加特定,不然这个回应也是可缓存文件的。

301被恳求的資源已永久性挪动到新部位,而且未来任何对此資源的引入都应当应用本回应回到的若干个 URI 之1。假如将会,有着连接编写作用的顾客端理应全自动把恳求的详细地址改动为从服务器意见反馈回家的详细地址。除非附加特定,不然这个回应也是可缓存文件的。

新的永久性性的 URI 理应在回应的 Location 域中回到。除非这是1个 HEAD 恳求,不然回应的实体线中理应包括指向新的 URI 的超连接及简洁明了表明。

假如这并不是1个 GET 或 HEAD 恳求,因而访问器严禁全自动开展重定项,除非获得客户确实认,由于恳求的标准将会因而产生转变。

留意:针对一些应用 HTTP/1.0 协议书的访问器,当它们推送的 POST 恳求获得了1个301回应的话,接下来的重定项恳求可能变为 GET 方法。

302恳求的資源如今临时性从不一样的 URI 回应恳求。因为这样的重定项是临时性的,顾客端理应再次向原来详细地址推送之后的恳求。仅有在Cache-Control或Expires中开展了特定的状况下,这个回应才是可缓存文件的。

新的临时性性的 URI 理应在回应的 Location 域中回到。除非这是1个 HEAD 恳求,不然回应的实体线中理应包括指向新的 URI 的超连接及简洁明了表明。

假如这并不是1个 GET 或 HEAD 恳求,那末访问器严禁全自动开展重定项,除非获得客户确实认,由于恳求的标准将会因而产生转变。

留意:尽管RFC 1945和RFC 2068标准不容许顾客端在重定项时更改恳求的方式,可是许多现存的访问器将302回应看作为303回应,而且应用 GET 方法浏览在 Location 中要求的 URI,而疏忽本来恳求的方式。情况码303和307被加上了进来,用以确立服务器希望顾客端开展何种反映。

303对理应前恳求的回应能够在另外一个 URI 上被寻找,并且顾客端理应选用 GET 的方法浏览那个資源。这个方式的存在关键是以便容许由脚本制作激活的POST恳求輸出重定项到1个新的資源。这个新的 URI 并不是初始資源的取代引入。另外,303回应严禁被缓存文件。自然,第2个恳求(重定项)将会被缓存文件。

新的 URI 理应在回应的 Location 域中回到。除非这是1个 HEAD 恳求,不然回应的实体线中理应包括指向新的 URI 的超连接及简洁明了表明。

留意:很多 HTTP/1.1 版之前的 访问器不可以正确了解303情况。假如必须考虑到与这些访问器之间的互动交流,302情况码应当能够担任,由于大多数数的访问器解决302回应时的方法刚好便是上述标准规定顾客端解决303回应时理应做的。

304假如顾客端推送了1个带标准的 GET 恳求且该恳求已被容许,而文本文档的內容(自之前浏览以来或依据恳求的标准)并沒有更改,则服务器理应回到这个情况码。304回应严禁包括信息体,因而自始至终以信息头后的第1个空行末尾。

该回应务必包括下列的头信息内容:

Date,除非这个服务器沒有数字时钟。倘若沒有数字时钟的服务器也遵循这些标准,那末代理商服务器和顾客端能够自主将 Date 字段加上到接受到的回应头中去(正如RFC 2068中要求的1样),缓存文件体制可能一切正常工作中。

ETag 和/或 Content-Location,倘若一样的恳求本应回到200回应。

Expires, Cache-Control,和/或Vary,倘若其值将会与以前同样自变量的别的回应对应的值不一样的话。

倘若本回应恳求应用了强缓存文件认证,那末本次回应不可该包括别的实体线头;不然(比如,某个带标准的 GET 恳求应用了弱缓存文件认证),本次回应严禁包括别的实体线头;这防止了缓存文件了的实体线內容和升级了的实体线头信息内容之间的不1致。

倘若某个304回应指明了当今某个实体线沒有缓存文件,那末缓存文件系统软件务必忽略这个回应,而且反复推送不包括限定标准的恳求。

倘若接受到1个规定升级某个缓存文件条目地304回应,那末缓存文件系统软件务必升级全部条目以反应全部在回应中被升级的字段的值。

305被恳求的資源务必根据特定的代理商才可以被浏览。Location 域中将得出特定的代理商所属的 URI 信息内容,接受者必须反复推送1个独立的恳求,根据这个代理商才可以浏览相应資源。仅有初始服务器才可以创建305回应。

留意:RFC 2068中沒有确立305回应是以便重定项1个独立的恳求,并且只能被初始服务器创建。忽略这些限定将会致使比较严重的安全性不良影响。

306在全新版的标准中,306情况码早已已不被应用。

307恳求的資源如今临时性从不一样的URI 回应恳求。因为这样的重定项是临时性的,顾客端理应再次向原来详细地址推送之后的恳求。仅有在Cache-Control或Expires中开展了特定的状况下,这个回应才是可缓存文件的。

新的临时性性的URI 理应在回应的 Location 域中回到。除非这是1个HEAD 恳求,不然回应的实体线中理应包括指向新的URI 的超连接及简洁明了表明。由于一部分访问器不可以鉴别307回应,因而必须加上上述必要信息内容便于客户可以了解并向新的 URI 传出浏览恳求。

假如这并不是1个GET 或 HEAD 恳求,那末访问器严禁全自动开展重定项,除非获得客户确实认,由于恳求的标准将会因而产生转变。

4001、词义有误,当今恳求没法被服务器了解。除非开展改动,不然顾客端不可该反复递交这个恳求。

2、恳求主要参数有误。

401当今恳求必须客户认证。该回应务必包括1个可用于被恳求資源的 WWW-Authenticate 信息内容头用以了解客户信息内容。顾客端能够反复递交1个包括适当的 Authorization 头信息内容的恳求。假如当今恳求早已包括了 Authorization 资格证书,那末401回应意味着着服务器认证早已回绝了那些资格证书。假如401回应包括了与前1个回应同样的身份认证了解,且访问器早已最少尝试了1次认证,那末访问器理应向客户展现回应中包括的实体线信息内容,由于这个实体线信息内容中将会包括了有关确诊信息内容。参照RFC 2617。

402该情况码是以便未来将会的要求而预留的。

403服务器早已了解恳求,可是回绝实行它。与401回应不一样的是,身份认证其实不能出示任何协助,并且这个恳求也不可该被反复递交。假如这并不是1个 HEAD 恳求,并且服务器期待可以讲明楚为什么恳求不可以被实行,那末就应当在实体线内叙述回绝的缘故。自然服务器还可以回到1个404回应,倘若它不期待让顾客端得到任何信息内容。

404恳求不成功,恳求所期待获得的資源未被在服务器上发现。沒有信息内容可以告知客户这个情况究竟是临时的還是永久性的。倘若服务器了解状况的话,理应应用410情况码来告之旧資源由于一些內部的配备体制难题,早已永久性的不能用,并且沒有任何能够自动跳转的详细地址。404这个情况码被普遍运用于当服务器不想揭露究竟为什么恳求被回绝或沒有别的合适的回应能用的状况下。

405恳求行中特定的恳求方式不可以被用于恳求相应的資源。该回应务必回到1个Allow 头信息内容用以表明出当今資源可以接纳的恳求方式的目录。

鉴于 PUT,DELETE 方式会对服务器上的資源开展写实际操作,因此绝绝大多数的网页页面服务器都不适用或在默认设置配备下不容许上述恳求方式,针对此类恳求均会回到405不正确。

406恳求的資源的內容特点没法考虑恳求头中的标准,因此没法转化成回应实体线。

除非这是1个 HEAD 恳求,不然该回应就理应回到1个包括可让客户或访问器从选中择最适合的实体线特点和详细地址目录的实体线。实体线的文件格式由 Content-Type 头中界定的新闻媒体种类决策。访问器能够依据文件格式及本身工作能力自主作出最好挑选。可是,标准中并沒有界定任何作出此类全自动挑选的规范。

407与401回应相近,只但是顾客端务必在代理商服务器勤奋行身份认证。代理商服务器务必回到1个 Proxy-Authenticate 用以开展身份了解。顾客端能够回到1个 Proxy-Authorization 信息内容头用以认证。参照RFC 2617。

408恳求请求超时。顾客端沒有在服务器准备等候的時间内进行1个恳求的推送。顾客端能够随时再度递交这1恳求而不用开展任何变更。

409因为和被恳求的資源确当前情况之间存在矛盾,恳求没法进行。这个编码只容许用在这样的状况下才可以被应用:客户被觉得可以处理矛盾,而且会再次递交新的恳求。该回应理应包括充足的信息内容便于客户发现矛盾的根源。

矛盾一般产生于对 PUT 恳求的解决中。比如,在选用版本号查验的自然环境下,某次 PUT 递交的对特殊資源的改动恳求所附带的版本号信息内容与以前的某个(第3方)恳求向矛盾,那末此时服务器就应当回到1个409不正确,告之客户恳求没法进行。此时,回应实体线中极可能会包括两个矛盾版本号之间的差别较为,便于客户再次递交归并之后的新版本号。

410被恳求的資源在服务器上早已已不能用,并且沒有任何已知的转发详细地址。这样的情况理应被觉得是永久性性的。假如将会,有着连接编写作用的顾客端理应在得到客户批准后删掉全部指向这个详细地址的引入。假如服务器不知道道或没法明确这个情况是不是是永久性的,那末就应当应用404情况码。除非附加表明,不然这个回应是可缓存文件的。

410回应的目地关键是协助网站后台管理员维护保养网站,通告客户该資源早已已不能用,而且服务器有着者期待全部指向这个資源的远端联接也被删掉。这类恶性事件在限时、升值服务中很广泛。一样,410回应也被用于通告顾客端在当今服务器站点上,本来属于某个本人的資源早已已不能用。自然,是不是必须把全部永久性不能用的資源标识为 410 Gone ,和是不是必须维持此标识多长期,彻底取决于服务器有着者。

411服务器回绝在沒有界定 Content-Length 头的状况下接纳恳求。在加上了说明恳求信息体长度的合理 Content-Length 头以后,顾客端能够再度递交该恳求。

412服务器在认证在恳求的头字段中得出先决标准时,没能考虑在其中的1个或好几个。这个情况码容许顾客端在获得資源时在恳求的元信息内容(恳求头字段数据信息)中设定先决标准,以此防止该恳求方式被运用到其期待的內容之外的資源上。

413服务器回绝解决当今恳求,由于该恳求递交的实体线数据信息尺寸超出了服务器想要或可以解决的范畴。此种状况下,服务器能够关掉联接以防顾客端再次推送此恳求。

假如这个情况是临时性的,服务器理应回到1个 Retry-After 的回应头,以告之顾客端能够在是多少時间之后再次尝试。

414恳求的URI 长度超出了服务器可以解释的长度,因而服务器回绝对该恳求出示服务。这较为罕见,一般的状况包含:

本应应用POST方式的表单递交变为了GET方式,致使查寻标识符串(Query String)太长。

重定项URI 黑洞 ,比如每次重定项把旧的 URI 做为新的 URI 的1一部分,致使在若干次重定项后 URI 较长。

顾客端正在尝试运用一些服务器中存在的安全性系统漏洞进攻服务器。这类服务器应用固定不动长度的缓存载入或实际操作恳求的 URI,当 GET 后的主要参数超出某个标值后,将会会造成缓存区外溢,致使随意编码被实行[1]。沒有此类系统漏洞的服务器,理应回到414情况码。

415针对当今恳求的方式和所恳求的資源,恳求中递交的实体线其实不是服务器中所适用的文件格式,因而恳求被回绝。

416假如恳求中包括了 Range 恳求头,而且 Range 中特定的任何数据信息范畴都与当今資源的能用范畴不重叠,另外恳求中又沒有界定 If-Range 恳求头,那末服务器就理应回到416情况码。

倘若 Range 应用的是字节范畴,那末这类状况便是指恳求特定的全部数据信息范畴的首字节部位都超出了当今資源的长度。服务器也理应在回到416情况码的另外,包括1个 Content-Range 实体线头,用以指明当今資源的长度。这个回应也被严禁应用 multipart/byteranges 做为其 Content-Type。

417在恳求头 Expect 中特定的预期限内容没法被服务器考虑,或这个服务器是1个代理商服务器,它有显著的直接证据证实在当今路由器的下1个连接点上,Expect 的內容没法被考虑。

421从当今顾客端所属的IP详细地址到服务器的联接数超出了服务器批准的最大范畴。一般,这里的IP详细地址指的是从服务器上看到的顾客端详细地址(例如客户的网关或代理商服务器详细地址)。在这类状况下,联接数的测算将会涉及到到不止1个终端设备客户。

422从当今顾客端所属的IP详细地址到服务器的联接数超出了服务器批准的最大范畴。一般,这里的IP详细地址指的是从服务器上看到的顾客端详细地址(例如客户的网关或代理商服务器详细地址)。在这类状况下,联接数的测算将会涉及到到不止1个终端设备客户。

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服务器遇到了1个未曾意料的情况,致使了它没法进行对恳求的解决。1般来讲,这个难题都会在服务器的程序流程码错误时出現。

501服务器不适用当今恳求所必须的某个作用。当服务器没法鉴别恳求的方式,而且没法适用其对任何資源的恳求。

502做为网关或代理商工作中的服务器尝试实行恳求时,从上游服务器接受到失效的回应。

503因为临时性的服务器维修或过载,服务器当今没法解决恳求。这个情况是临时性的,而且将在1段時间之后修复。假如可以预计延迟时间時间,那末回应中能够包括1个 Retry-After 头用以标出这个延迟时间時间。假如沒有得出这个 Retry-After 信息内容,那末顾客端理应以解决500回应的方法解决它。

留意:503情况码的存在其实不代表着服务器在过载的情况下务必应用它。一些服务器只但是是期待回绝顾客端联接。

504做为网关或代理商工作中的服务器尝试实行恳求时,未能立即从上游服务器(URI标志出的服务器,比如HTTP、FTP、LDAP)或輔助服务器(比如DNS)收到回应。

留意:一些代理商服务器在DNS查寻请求超时时会回到400或500不正确

505服务器不适用,或回绝适用在恳求中应用的 HTTP 版本号。这暗示着服务器不可以或不肯应用与顾客端同样的版本号。回应中理应包括1个叙述了为什么版本号不被适用和服务器适用哪些协议书的实体线。

506由《全透明內容商议协议书》(RFC 2295)拓展,意味着服务器存在內部配备不正确:被恳求的商议变元資源被配备为在全透明內容商议中应用自身,因而在1个商议解决中并不是1个适合的关键。

507服务器没法储存进行恳求所务必的內容。这个情况被觉得是临时性的。WebDAV (RFC 4918)

509服务器做到带宽限定。这并不是1个官方的情况码,可是仍被普遍应用。

510获得資源所必须的对策并沒有没考虑。(RFC 2774)