HTTP超文本传输协议-HTTP/1.1[10.状态代码定义]

10.状态代码定义

每一段状态代码在下面被描述,包括他所能遵循的方法的描述和在应答中所必需的维护信息.

10.1 信息 1xx

状态代码的类简单描述了一个临时的回答,只是由状态行和可选择的报头所组成,并且由空行所决定,状态代码类没有所需的报头.自从HTTP/1.0没有定义 任何1xx状态代码,在实验的条件下服务器严禁发送一个1xx应答给HTTP/1.0客户. 客户必须准备在接受通常应答之前接受一个或者多个1xx应答,甚至客户并不期待一个100状态的报文.不被期待出现的1xx状态应答也许会被用户端的代理 所忽略. 代理服务器必须转寄1xx应答,除非代理服务器和客户之间的联系被切断,或者除非代理服务器本身请求1xx应答的发生.(举例说明如果一个代理服务器在它 转寄一个请求时会加上一个"期望:100-----继续区域",它接下来就不需要转寄100回答应答).

10.1.1 100 继续

客户应该和他自己的请求继续.中间的应答被用于告知客户请求的初始部分已经收到并且还没有被服务器所拒绝.客户应该继续发送剩下的请求,或者如果请求早已 完成,那就忽略请求.服务器必须发送一个初始回答应答当请求完成时.如果想知道这部分状态代码用法及操作处理的详细讨论,那么请看8.2.3章节.

10.1.2 101转换协议

服务器了解并且愿意顺从客户的请求,经过升级的报文报头区域,为的就是一个应用协议的变化使之能够在连接中使用.服务器会转换协议使之成为那些通过应答升 级报头的区域定义的立即在决定101应答的空行之后的协议. 协议应该仅仅在这样做有利的时候实行转换.比如,转换成为一个新版本的HTTP协议与老版本相比更加有利,转换成为一个实时同步的协议也许会有利,当被传 送的资源需要利用这样的特征

10.2 成功 2xx

这种状态代码类简要的说明了客户的请求被成功的接收,理解,和接受

10.2.1 200 OK

请求已经成功.连同应答一起返回的信息是依赖于在请求中使用方法的.例如: GET 与被请求的资源相应的实体在应答中一起发送. HEAD 与被请求资源相对应的没有报文正文的报头区域在应答中发送. POST 描述或者包含行动结果的实体. TRACE 底端服务器已经接收的包含请求报文的实体

10.2.2 201 创建

请求已经完成同时导致新的资源被创造.新创造的资源和地址报头区域给出资源的最专业的URI可以被随应答实体返回的URI参考.应答应该包含用户或者用户 代理可以从中选择出的一系列最最合适资源的特征和地址.实体的格式通过在内容形式报头区域给出的媒体形式来详细说明.最初的服务器必须在返回201 状态代码以前创造资源.如果行动不能马上执行,服务器应该以202接受应答来应答它. 一个201应答可以由一个为了刚刚创造出的请求变量而显示出来的当前实体标记符的值的Etag应答报头区域,参见14.19节..

10.2.3 202 接受.

为了处理,请求被接受,但是处理并没有完成.请求最终有可能或者不可能遵照行事,因为在处理过程实际发生时,它有可能被不允许.没有什么设备可以从如此的 异步操作中重新发送状态代码 202应答是故意无委托的.它的目的就在于为了其他一些过程,在没有要求用户代理直到过程执行结束还坚持连接到服务器的情况下,允许服务器接受请求 (也许是一批有所指向的一天只处理一次).实体和应答返回应该包括当前的请求状态,和或者一个指向状态监听器的指针或者关于什么时间用户期待请求完成的估 计. .

10.2.4 203 非权威信息

在实体报头中返回的维护信息并不是原服务器可用的最终的设置,但是他们是从一个本地的或是第三方的拷贝.提出的设置也许是原始版本的子集或是父集.举例来 说,包括有关于也许导致被原服务器识别的维护信息的父集的本地注解信息.这种应答代码的用法并不必需,而且只有当应答为200时才适用.

10.2.5 204 没有内容

服务器完成请求并不需要返回实体的正文,并且也许想返回升级过的维护信息.应答也许包含新的或者是升级过的的实体报头形式的维护信息,如果这些当前的可以 与请求的变量相关联. 如果客户是个用户代理,她就不应该改变它的文件观点以区别于那个导致请求被发送的文件观点.这样的应答主要是故意允许为了行动的输入发生在没有导致对用户 代理主动的文件观点改变的情况下,尽管任何新的或者是升了级的维护信息应该是适应于用户代理现在的主动观点的. 204应答严禁包含报文正文,并且这样总是由在报头区域之后的第一个空行决定的.

10.2.6 205 重置内容

服务器已经完成了请求,用户代理应该重新设置导致请求被发送的文件观点.这种应答主要是故意允许输入行动通过用户输入发生,伴随而来的是对给出形式的清理 为了让用户可以轻松开始另一个输入行动.应答严禁包含任何实体.

10.2.7 206 局部内容

服务器对于资源已经完成了部分GET请求.请求必须包含一个范围报头区域(14.35节), 指出了想要的范围,而且也有可能包含一个使请求条件化如果-范围报头区域 应答必须包含以下的报头区域: 或者是一个内容范围报头区域指出包含此现应答的范围,或者是对每个部分来说一个多部分的/字节范围的内容形式都包含内容范围报头.如果内容长度报头区域在 当前应答中,那么它的值必须和实际在报文正文重传送的OCTET相匹配. -日期 -Etag或者内容位置,如果能够在一个200应答中对于同一个请求发送报头. -终止,缓存控制,和/或者变化,如果区域值与对于同一个变量以前发送的应答中的区域值不一样. 如果206应答是一个使用强缓存确认的的如果范围请求的结果,那么应答不应该包含其他实体报头. 如果应答是一个使用弱缓存确认的的如果范围请求的结果,那么应答严禁包含其他实体报头,这么做是为了防止缓存实体正文和升级报头之间的矛盾性.否则,应答 必须包含所有对同一个请求返回的200应答中的实体报头. 如果Etag或者上次更改的报头不严格匹配,缓存严禁将一个206请求与其他以前缓存的内容连接起来 一个并不支持范围和内容范围的缓存严禁缓存206(部分)应答.

10.3 重新定向 3xx.

这种状态代码类指出了为了完成请求用户代理而所需要做的更进一步的行动.必需的行动 可以被没有与用户发生交互作用的用户代理执行并且在当且仅当在第二个请求中所需的方法是GET 或者是HEAD.客户应该侦察最终的重新定向环路,因为对于每一个重新定向来说这样的环路产生网络交通. 注解:老版本的规范推荐最大数量为5的重新定向.内容开发者应该知道也许有贯彻这样复杂限制的客户.

10.3.1 300 多样选择.

被请求的资源符合任何一套表示法之一,每种资源和她自己的特定地址,并且为了使用户可以选择一个首选的表示法和依照那个地址重新定向, 代理驱动的协商信息可以被提供出来. 除非它是一个HEAD请求,应答都应该有包含一系列用户或者用户代理可以从中选择的最最合适的资源特性和地址.实体格式被在内容形式报头区域给出的煤体形 式详细说明.依靠用户代理的格式和容量,最最合适的那个选择有可能自动完成.不管怎样,这种规范并没有定义自动选择的标准.如果服务器有了一个陈述的首 选, 那么它应该包含为了关于那个陈述的特定的URI;用户代理为了自动重新定向可以使用地址区域值.除非指出另外的那么应答就可以缓存.

10.3.2 301 永久移动

被请求的资源已经分配了一个新的永久的URI,任何对资源的未来参考应该使用返回的URI中的一个.有编辑连接能力的客户应该对于被请求的URI从可能的 服务器中返回的一个或者多个参考中实现自动连接参考.这种应答是可以缓存的除非它指出其他的. 新的永久的URI应该在应答中的地址区域给出.除非请求方法是HEAD,应答的实体应该包括一个段指向新的URI的超文本文本注解 如果301状态编码在对应于HEAD或者GEI方法中收到,用户代理严禁自动的重新定向请求除非它可以被用户确认,因为这样可能会改变请求发生的条件. 注解:当在接受到一个301状态编码后自动重新定向某一邮政请求,一些现存的HTTP/1.0用户代理将错误的将它改成GET方法.

10.3.3 302 创立

被请求的资源已经分配了一个新的永久的URI,任何对资源的未来参考应该使用返回的URI中的一个.有编辑连接能力的客户应该对于被请求的URI从可能的 服务器中返回的一个或者多个参考中实现自动连接参考.这种应 答是可以缓存的除非它指出其他的. 对临时的URI应该给予地址区域.除非请求的方法是HEAD,相应的实体应该包含一个短的指向一个新的URI的超级连接的超文本提示 如果302状态代码在一个应答非GEI或者HEAD请求中的过程中被接收到,那么用户代理严禁自动重新定位除非它可以被用户证实,因为它可能变化它的请求 实现的条件. 注解: RFC 1945 和 RFC 2068 详细说明了客户不被允许改变在重新定位请求使用的方法.但是大多数存在的用户代理将302视为一个303应答, 不管最初的请求方法而在位置区域值实现一个GET方法.状态代码303和307被加在服务器上以希望它能够清楚客户所期待的那种反作用.

10.3.4 303 观察别的部分

对请求的应答可以在不同的URI中找到,并且应答应该在对资源的GET方法中重新得到.这种方法存在主要是为了允许邮政活性的输出脚本重新定向用户代理于 一个选择的资源.新的URI不是一个最初请求资源的替代参考.303应答严禁缓存,但是对于第二个请求(重新定向)可以缓存. 不同的URI应该在相应的位置区域给出除非请求的方法是HEAD,相应的实体应该包含一个短的指向一个新的URI的超级连接的超文本提示. 注解: 许多HTTP/1.1以前的用户不理解303状态.当客户之间的协同工作能力被关注时,302状态代码也许会作为替代而使用,因为大多数用户代理就向这里 描述的303那样反作用于302应答.

10.3.5 304 只读

如果客户提出一个条件的GET请求并且访问也已经允许,但是文档并没有修改,服务器应该应答这些状态编码.304应答严禁包含报文正文,并且总是由报头区 域之后的第一个空行决定的. 应答必须包括以下报头区域: -日期,除非数据亢长是14.18.1部分必须的. 如果一个无时钟原服务器遵守这些规则,并且代理服务器和客户将自己的日期加入任何成标准的应答中去,缓存会工作正常. -Etag或者内容位置,如果能够在一个200应答中对于同一个请求发送报头. -终止,缓存控制,和/或者变化,如果区域值与对于同一个变量以前发送的应答中的区域 值不一样. 如果条件化的GET使用了强的缓存??(请参阅13.3.3部分内容),那么应答中就不应该有其他实体报头.否则,应答中严禁包含其他实体报头,这样子保 护了缓存实体正文和升级报头之间的矛盾性 如果304应答指出了当前尚未缓存的实体,那么缓存就必须忽视应答并且无条件的重复请求 如果缓存使用成为标准的204应答取胜疾缓存的入口,缓存就必须升级自己的入口以反映在应答中给出的任何新的区域值.

10.3.6 305 使用代理服务器

地址区域的被请求的资源必须通过代理服务器.地址区域给除了代理服务器的URI. 期望容纳者通过代理服务器重复这一单一请求.305应答必须由原服务器产生. 注解: RFC2068并不清晰于305有意于重新定向一个单一请求,并且此请求还只能由原服务器产生.不留心这些限制会产生相当严重的安全后果.

10.3.7 306(没有用的)

306状态编码在以前的规范中使用,现在已经不再用了,代码也保留了下来.

10.3.8 307临时重发.

请求的资源临时存在在另一个不同的URI下.由于重新定位有时可能变化,客户应该继续使用请求URI以备将来用途.这个应答只有当被缓存控制或是终止报头 区域指出时才是可以存储的. 临时的URI应该在应答中的地址区域给出.除非请求的方法是HEAD,应答的实体应该包括一个短的指向一个新的URI的超文本提示, 许多HTTP/1.1以前的用户不理解307状态.因此,提示应该包括用户在新的URI中为了重复原始请求所必需的信息. 如果307状态代码作为应答不仅仅是GET或者HEAD等方法而接收,那么用户严禁重新定向请求除非它可以被用户确认,这也是可能的.

10.4 客户错误 4xx

状态代码4xx类是专门使用在客户看上去错误的情形下的.除非当应答一个HEAD请求时,服务器因该有一个包括错误情形的解释的实体,以及它是否一个临时 或者终了的条件.这些状态编码可以应用于任何请求方法.用户代理应该向用户显示任何包括的实体. 如果客户在发送数据,使用TCP的服务器的实现应该小心以保证在服务器关掉了所有的输入连接时客户承认收到包含应答的包.在关掉之后如果客户继续发送数据 给服务器,服务器TCP堆会发送一个重制包,也许这样子会在服务器开始被访问以及HTTP应用程序被解释的情况下,会擦掉客户不知道的输入缓冲.

10.4.1 400 坏请求

请求由于畸形的语法而不被服务器所理解.客户不应该重复自己的请求在没有改变的情况下.

10.4.2 401 未授权的

请求需要用户的鉴定.应答必需有用于对被请求资源的挑战的包含WWW鉴定报头区域.如有合适的认证报头区域,客户可以重复请求.如果请求已经包含了认证的 信任书,那么401应答就指出了认证由于这些信任书而被拒绝.如果401应答包括和上一个应答同样的挑战并且用户代理已经尝试认证了至少一次,那么应该给 用户在应答中给出的实体,因为实体中可能包含相应的诊断信息.HTTP访问认证在"HTTP Authentication: Basic and Digest Access Authentication" 中有所解释.

10.4.3 402 必需的支付

这种代码被保存下来以便将来使用.

10.4.4 403 禁用

服务器理解了请求,但是拒绝实现它.认证不会帮助,请求也不应该重复.如果请求的方法不是HEAD并且服务器愿意将请求为什么没有实现告诉大家,它应该在 实体中描述拒绝的理由.如果服务器并不想将这条信息告诉客户,状态代码404(没找到)可以替代使用之.

10.4.5 404 没有找到

服务器并没有找到任何可以匹配请求URI.条件是永久的还是暂时的也没有任何的迹象.410状态编码应该在服务器知道老的资源是永远不可以得到的并且没有 以前的地址的情况下,通过一些内在的可配置的机构,才应该使用.这种状态编码当服务器不想精确展示为什么请求被拒绝或者何时没有其他的应答可以利用的时候 被广泛的应用.

10.4.6 405 不被允许的方法

在请求行中特殊指定的方法不允许访问由请求URI指定的资源.应答必需有一个包括一些对于被请求的资源有效的方法的允许报头.

10.4.7 406 不接受

请求指定的资源只可能产生依照在发送请求中的接受报头有不接受的内容特性的应答实体. 除非它是一个HEAD请求,应答应该有包括一系列可兹利用的实体特性和位置,从中用户和用户代理可以找出最最适合的.实体的格式由在内同形式报头区域给出 的媒体形式所指定.依靠此格式和用户代理的性能,最佳的选择可能自动的完成.然而,这中规范并没有定义任何针对此自动选择的标准 注解: HTTP/1.1服务器允许返回依照在请求中发送的接受报头不被接受的应答.在某些情况下,发送一个406应答甚至更加有利.用户代理被鼓励去检查输入应 答的报头以判断是否可以接受. 如果应答不被接受,那么用户代理应该暂时停止接收更多数据并且向用户查询是否需要更进一步的行动决定.

10.4.8 407 代理服务器认证所必需

这种代码很相近于401,但是它指出了客户必须和代理服务器之间认证自己.代理服务器必需返回一个代理服务器----认证报头区域,该区域包括是为了被请 求的资源而用于代理服务器的挑战.客户可能随着一个合适的代理服务器认证报头区域一起重复它的请求. HTTP访问认证在" HTTP Authentication: Basic and Digest Access Authentication"中有解释.

10.4.9 408 请求超时

在服务器准备等待的时间段内,客户并没有产生请求.客户也许会在以后的任意一时间内重复请求.

10.4.10 409 冲突

由于与资源的现在状态的冲突请求游客能不能完成.代码只有在用户被期待有可能解决冲突和提交请求的地方的情况下允许使用.应答体应该包括对于用户认识冲突 来源的足够多的信息.理想的,应答体应该有对于用户和用户代理可以解决问题的足够多的信息量.然而,这也许是不可能的或者是不必需的. 冲突通常会发生在应答PUT请求的时候.例如,版本正在被使用而且正在PUT的实体有和以前请求(第三方)冲突的资源的变更的话,服务器会使用409应答 来指出它不能完成请求.在这种情形下,应答实体可能会包括一系列在内容形式应答中定义的两种版本的区别之处.

10.4.11 410 停止

服务器上的被请求的资源不再可用,而且不知道以前的地址.我们期望此条件被认为是永远的.有连接编辑能力的客户在用户同意的情况下,应该删掉对请求URI 的参考.如果服务器并不知道,或者没有设备去决定是否条件是永久的,状态代码404(未找到)此时应该使用.这种应答是不可被缓存的除非另外指出. 410应答主要是通过通告请求者资源有意不可获得和服务器主人希望那些远方连接到资源的连接都被请除掉这两条信息用于援助WEB维护.这样的事情很普通发 生在时间受限,增加的服务和不再服务器端工作的的属于私人性质的资源这些情况下.我们并不需要标注所有的永久不可用的资源"没了"或是标注上任意一段长度 的时间-----这些交给那些服务器的主人自己去判断吧.

10.4.12 411 必需的长度

服务器拒绝接受没有定义的内容长度的请求. 如果加上了一个有效的"包含有请求报文正文中的长度"的内容长度报头区域,那么客户可能重复请求.

10.4.13 412 预处理失败

在一个或者多个请求中给出的预处理在被服务器验证的时候会被评价为错误的.这种应答代码允许客户将预处理放在当前资源维护信息(报头区域数据),并且这样 作以防止有其他的适应资源请求的法的而非所要的那一个.

10.4.14 413 请求实体太大

服务器拒绝处理一个请求因为请求比服务器所能和所愿处理的还要大.服务器可能关掉连接以防止客户继续请求. 如果条件是暂时的,服务器应该有一个重新试-在之后报头区域以便于指出这是暂时的在什么时间以后客户可以再试一次.

10.4.15 414 请求的URI过长

服务器拒绝请求的服务因为请求的URI比服务器所愿意解释的要长.这种比较珍稀的条件之可能发生在党课互补恰当的将POST请求变为有长查询信息的 GET请求的情况下,或是客户落到了一个重新定向的URI黑洞中时,再或者是在一些使用固定长度缓冲区用以读或者处理请求的URI的服务器遭到钻安全漏洞 的黑客的攻击的时候.

10.4.16 415 不被支持的媒体类型

服务器拒绝提供服务给请求因为请求的实体所请求的方法是在一种不被请求资源支持的格式下.

10.4.17 416 请求范围不满足

如果请求包括范围请求报头区域,或者是在区域内没有范围说明符的值溢出当前选择资源的延伸,再或者是请求没有包含如果--范围请求--报头区域,服务器应 该返回连同状态代码的一个应答.(对于字节-范围,它意味着所有的字节范围说明中的第一字节???的值比当前选择资源的长度要大) 当状态代码返回一个字节范围请求时,应答应该包含一个详细说明选择资源的长度的内容范围区域.(请参阅14.16).应答严禁使用多部分/字节范围的内容 形式.

10.4.18 417 期望失败

在请求报头区域给出的预料不可能被服务器实现,或者,如果服务器是代理服务器,服务器有请求不可能被下一个??服务器实现的模糊的证据

10.5 服务器错误 5xx

应答状态代码用阿拉伯数字"5"表示服务器知道它自己有错误或者自己不能实现请求等这些情况.除了当应答一个HEAD请求,服务器应该有一个包括错误形式 的解释的实体和它是否暂时或者永久的条件的解释的实体.用户代理应该显示任何包括的实体给用户.这些应答代码对于任何请求的方法都是适用的.

10.5.1 500 服务器内部错误

服务器遇到预料到的防止它完成请求的情况.

10.5.2 501 不能实现

服务器不支持完成请求所必需的功能性. 当服务器并不认识请求的方法并且没有能力对于任何资源支持时,这是合适的应答

10.5.3 502 坏网关

服务器,当被用作一个网关或者是代理服务器时,就会从上流的服务器收到无效的应答以试图完成请求的访问.

10.5.4 503 难以获得的服务.

由于暂时的过载或者服务器维护,服务器此时不能处置请求.这说明了这是一个暂时的条件过一些耽搁会减轻.如果知道,耽搁的长度应会在重新试-在之后报头中 指出.如果没有重新试-在之后给出,客户应该处理处置应答就像处理一个500应答一样. 注解:503状态代码的存在并不暗示着服务器必需使用它当它变得过载时.有些服务器只想简单的拒绝连接.

10.5.5 504 网关超时

服务器,当被用作是网关或者是代理服务器时, 由于URI指定的上游服务器或者其他一些辅助服务器以有资格尝试完成请求,并没有收到及时的应答. 注解:设备注解:一些展开的代理服务器都知道返回400或者500当DNS查找时间过长时.

10.5.6 505 HTTP版本不支持

服务器并不支持,或者拒绝支持,在请求信息中用到了HTTP协议版本.服务器指出它不能或是不愿完成使用与客户端一样的版本的请求,就像在章节3.1中描 述的那样,???????.应答应该包含描述为什么那个版本不为支持而为什么其他协议被服务器支持的实体..