HTTP协议（RFC2616）状态码定义

信息性  1xx

    本类状态码表示临时的响应，由单独的状态行和可选的头部组成，终止于空行。本类状
态码没有必须的头部。 由于HTTP/1.0没有定义任何1xx状态码，因此服务器禁止向HTTP/1.0
客户端发送1xx响应，除非在试验时。
 
    客户端必须准备好接收先于一般响应的一个或多个1xx 状态响应， 即使在客户端不期望
100（Continue）状态消息时。非期望的 1xx状态响应可能被用户代理乎略。
 
    代理必须转发1xx 响应，除非代理与它的客户端之间的连接关闭了，或者除非代理自己
请求产生 1xx 响应。（例如，当代理转发请求时加入了“Expect: 100-continue”域时，这时它

就不需转发相应的100（Continue）响应。

100 Continue

    客户端应该继续它的请求。该间歇响应用于提醒客户端服务器已经接收和接受请求的开
始部分。 客户端应该继续发送请求的剩余部分， 或者如果请求已经发送完了， 就乎略该响应。
服务器在请求完成后必须发送最终响应。

101 Switching Protocols

    服务器理解并愿意答应客户端的请求。通过使用Upgrade消息头部域（14.42节），在该
连接上改变应用层协议。 服务器将在101响应的终止空行后立即切换到响应的 Upgrade头部
域中定义的协议。
 
    只有在有优势时才应该切换协议。例如，切换到HTTP的新版本比老版本有优势，切换
到实时、同步协议在递交使用这种特性的资源时可能有优势。

成功  2xx

   这类状态码表示客户端的请求成功被接收、理解和接受了。

200 OK

    请求已经成功。该响应返回的信息取决于请求中使用的方法，例如：
 
     GET与所请求资源相对应的实体将在响应中发送；
     HEAD 与所请求资源相对应的实体头部将在响应中发送，而没有消息体；
     POST描述或包含行为结果的实体；
     TRACE 包含终点服务器收到的请求消息的实体。

201 Created

     请求全部成功，且创建了新资源。可通过响应实体中返回的 URI 引用新创建的资源，
使用Location头部域中给出的最特别的URI。该响应应该包含资源特性和位置清单的实体，
从而用户或用户代理能够从中选择最适当的一个。 实体格式通过在 Content-Type头部域中的
媒体类型指定。 原始服务器必须在返回 201 状态码之前创建资源。 如果该行为不能立即实施，
服务器应该代之以202（Accepted）响应。

     201 响应可能包含 ETag 响应头部域，指示刚创建的请求变量的实体标签的当前值。

202 Accepted

    请求已经接受处理，但是处理还没有完成。当处理实际发生时，请求最后可能会或不会

被执行，如同它可能被拒绝一样。没有设置在这样的异步操作后重发状态码的功能。
 
     202 响应是故意不承担该义务的。它的目的是允许服务器可接收其它过程的请求（可能
是每天只运行一次的面向批处理的过程），而不需要用户便一直连接到服务器，直到处理完
成。该响应返回的实体应该包括请求当前状态的指示和状态显示器或一些估计的指针，使用
户能够预料请求已经完成。

203 Non-Authoritative Information

    实体头部中返回的元信息不是在原始服务器有效的确定集合， 而是从本地或第三方拷贝
收集的。现在的集合可能是原始版本的子集或超集。例如，包括关于资源的本地注释住息可
能导致原始处理器知道元信息的超集。使用该响应码没有要求，且只有响应是 200（OK）
的其它状态时才是适当的。

204 No Content

    服务器已经完成请求，但不需要返回实体，且可能希望返回更新的元信息。响应可能包
括新的或更新的元信息，通过实体头部的形式。如果存在这些头部，则应该与所请求变量相
关。
 
    如果客户是用户代理，则它不能改变引起发送请求的文档视图。该响应主要用于允许输
入行为发生，而不会引起用户代理的活动文档视图的改变，即使任何机新的或更新的元信息
应该应用到当前在用户代理活动视图中的文档。
 
     204响应禁止包括消息体，且始终止于头部域后的首个空行。

205 Reset Content

    服务器已经完成请求且用户代理应该复位引起请求发送的文档视图。该响应主要用于允
许行为输入通过用户输入发生，接着清除给出输入的表单，以使用户能够轻松地开始另一次
输入行为。响应禁止包括实体。

206 Partial Content

    服务器已经完成局部资源的GET请求。请求必须包括 Range头部域来指示
期望的范围，且可能包含If-Range头部域来作为请求条件。
 
    响应必须包含如下的头部域：
 
    · Content-Range头部域指示包含在响应中的范围， 或值为 multipart/byteranges
的Content-Type且各部分都包含Content-Range域。 如果响应中存在 Content-Length头部域，
则它的值必须与在消息体中传输的实际8 位组数相符。
 
    ·Date   

    ·ETag、和/或Content-Location（当相同请求的200 响应中已经发送了该头部）。
 
    ·Expires、Cache-Control、和/或 Vary（当其域值可能与先前的相同变量的任何响应不
同）
 
    如果206 响应是由If-Range请求使用强缓冲验证所引起的，则该响应不
该包含其它实体头部。如果响应是由 If-Range请求使用弱缓冲验证引起的，则响应禁止包含
其它实体头部；这样就可阻止缓存实体与更新头部间的不一致。换句话说，即响应必须包括
相同请求的 200（OK）响应中会返回的所有实体头部。
 
    如果 ETag或Last-Modified头部不能精确匹配， 则缓冲服务器禁止将206 响应与其它以
前的缓存内容组合在一起。

重定向  3xx

    这类状态码指示，需要用户代理采取更进一步的行为来完成请求。当且仅当第二次请求
所使用的方法是GET或HEAD 时，所需要行为可能被用户代理在不通知用户的情况下所提
交。客户端应该检测无限循环重定向，因为这类循环每次重定向都会产生网络流量。
 
    注意：本规范的以前版建议最多5次重定向。内容开发者应该明白，可能有实施这种固
定限制的客户端存在。

 
    不支持Range和Content-Range头部的缓冲服务器禁止缓存 206（Partial）响应。

300 Multiple Choices

    所请求的资源符合表述集合中的任何一个，每个都有它自己的特殊位置。代理驱动的协
商信息提供给用户（或用户代理）来选择喜欢的表述，并重定向请求到它的位置。 
 
    除非是 HEAD 请求，否则响应应该包括含有资源特性和位置清单的实体，以便用户或
用户代理能够选择最适当的一个。该实体格式由 Content-Type 头部域中给出的媒体类型规
定。取决于格式和用户代理的能力，作出最适当的选择可能会自动执行。然而，本规范没有
定义任何这类自动选择算法。
 
    如果服务器对表述有喜欢的选择，它应该在 Location域中包括该表述的指定 URI；用户
代理可能使用 Location域值来作出自动重定向。该响应可缓存，除非有特别指示。

301 Moved Permanently

    所请求的资源已经指定到一个新的永久 URI， 且将来任何对该资源的引用都应该使用所
返回的 URI 之一。如果可能的话，客户端有修改链接的能力应该自动重链接引用该
Request-URI到服务器所返回的新引用的一个或多个。该响应可缓存，除非有特别指示。

 

    新的永久 URI 应该在响应中的 Location 域中给出。除非请求方法是 HEAD，否则响应
实体应该包含链接到新的URI的简短的超文本说明。
 
    如果非GET或HEAD请求收到了 301 状态码响应，则用户代理禁止自动重定向请求，
除非它得到了用户的确认。因为这可能改变请求发生的条件。
 
    当自动重定向收到 301 状态码的 POST 请求时，一些现有的 HTTP/1.0 用户代理将会错
误地将其变为GET请求。

302 Found

    所请求的资源临时存在于不同的 URI。由于重定向随时可会改变，客户端应该继续在将
来的请求中使用该 Request-URI。只有通过 Cache-Control 或 Expires 头部域指示下，该响应
才是可缓存的。
 
    临时的 URI 应该在响应中的 Location 域中给出。除非请求方法是 HEAD，否则响应实
体中应该包含链接到新URI的简短超文本说明。
 
    如果非GET或HEAD请求收到了302状态码的响应， 则用户代理禁止自动重定向请求，
除非它能够获得用户的确认。因为这可能导致发出请求的条件改变。
 
    注意：RFC 1945和RFC 2068指出，不允许客户端在重定向请求时改变方法。然而，大
多数现存的用户代理实现都将 302 作为 303 响应，且执行到 Location 域值的 GET，而不管
原始请求方法。303和307状态码已经加到服务器，希望客户端作出所期望的有明显区别的
不同类的返应。

303 See Other

    请求的响应可以在不同的URI中发现，且应该使用GET方法到该资源来获取它。存在
该方法中要是用于允许由POST激活的脚本输出重定向用户代理到所选择的资源。 新的 URI
不是原始请求资源的代替引用。禁止缓存 303响应，但到第二个（重定向的）请求的响应可
能可缓存。
 
    不同 URI 应该在响应中通过 Location 域给出。除非请求方法是 HEAD，响应实体应该
链接到新的URI的简短的超文本说明。
 
    注意：许多先于 HTTP/1.1 的用户便不理解 303状态。当与这种客户端交互时要当心，
可使用302状态码代替，因为大多数用户代理将这里描述的 303作为 302来处理。

304 Not Modified

     如果客户端执行条件 GET 请求，且允许访问，但文档没有变化，服务器应该用该响应
码响应。304响应禁止包含消息体，因此它始终止于头部域后的首个空行。

 

    该响应必须包括如下头部域：
 
    ·Date 
 
    如果无时钟的原始服务器服从该规则，且代理和客户端添加它们自己的 Date 到任何所
收到的没有Date的响应中（如已经在[RFC 2068），缓存将会正确操作。
 
    ·ETag、和/或Content-Location（如果头部已经在相同请求的 200 响应中发送过）
 
    ·Expires、Cache-Control、和/或 Vary（如果域值与任何以前相同变量的响应发送过的
不同）
 
    如果条件 GET使用强制缓冲验证，则响应不该包括其它实体头部。否则
（如，条件使用弱验证），响应禁止包括其它实体头部；这会阻止缓存实体与更新头部之间
的不一致。
 
    如果 304 响应指示实体没有缓存，这时缓存必须不理会该响应，并无条件重复该请求。 
 
    如果缓冲服务器使用所收到的304响应来更新缓存条目， 则缓冲服务器必须更新反映响
应中给出的任何新域值的条目。

 

 305 Use Proxy

    所请求的资源必须通过Location域中给出的代理来访问。Location域给出代理的 URI。
期户接收方通过代理重复这次请求。305响应必须只由原始服务器产生。
 
    注意：RFC  2068 没有说清，305 用于重定向单次请求，且只由原始服务器生成。没注
意到这些限制已有明显的安全性后果。

306 (Unused)

     306状态码在前版规范中使用，现在没用了，应保留该代码。

307 Temporary Redirect

    所请求资源临时存在于不同的URI。由于重定向可能随时会改变，所以客户端应该继续
在以后的请求中使用 Request-URI。只有通过 Cache-Control 或 Expires 头部域指示，该响应
才是可缓存的。
 
    临时 URI 应该通过响应中的 Location 域给出。除非请求方法是 HEAD，否则响应实体
应该包含链接到新 URI 的简短超文本说明，由于许多先于 HTTP/1.1 的用户代理不理解 307
状态。因此，该说明应该包含必要的信息来帮助用户重复原始请求到新的 URI。
 
    如果 307 状态码响应不是在 GET或 HEAD 请求时收到，则用户代理禁止自动重定向请

求，除非它能够得到用户的确认，因为这可能会改变发生请求的条件。 

客户端错误  4xx

     4xx类的状态码用于看起来客户端有错误的情况下。除了相应的 HEAD 请求，服务器应
该包括解释错误状况的实体，不管是临时还是永久的条件下。该状态码可应用到所有请求方
法。
 
    用户代理应该显示实体给用户。如果客户端正在发送数据，使用 TCP 实现的服务器应
该小心确保，在服务器关闭输入连接前，客户已经确认其所收到的包含响应的包。如果客户
端在关闭后继续发送数据到服务器，则服务器的 TCP 协议栈将发送复位包到客户端，这将
会引起在HTTP应用读和解析之前清除客户端没有确认的输入缓冲。

400 Bad Request

    服务器不能理解请求，由于畸形的语法。客户端不应该重复没经修改的请求。

401 Unauthorized

    请求需要用户认证。响应必须包括 WWW-authenticate 头部域其中包含对
所请求资源的适用的要求。客户端可以使用合适的 Authorization头部域来重复该
请求。如果请求已经包括 Autoorization证书，这时 401 响应表示该证书的认证被拒绝了。如
果401响应包含与先前的响应相同的要求，且用户代理已经尝试认证了至少一次，这时应该
将响应中给出的实体提示给用户，因为该实体可能包含有关的诊断信息。HTTP访问认证的
解释见“HTTP Authentication: Basic and Digest Access Authentication”。

402 Payment Required

    该代码留作将来使用。

403 Forbidden

    服务器理解请求， 但拒绝完成它。 认证也没用， 请求不该重复。 如果请求方法不是 HEAD，
且服务器希望公开为什么没有完成请求，则它应该在实体上描述拒绝的原因。如果服务器不
希望向客户端给出该信息，则可用状态码 404（Not Found）代替。

404 Not Found

    服务器不能发现匹配Request-URI的任何东西。 没有表明这种状况是临时的还是永久的。
如果服务器通过一些内部配置机制，知道旧资源永久不可用了，且没有转发的地址，则应该
使用410（Gone）状态码。本状态码通常用于服务器不希望透露为什么拒绝请求，或没有其
它响应可用时。

405 Method Not Allowed

     Request-Line 中指定的方法不允许用到由 Request-URI 标识的资源。该响应必须包括
Allow头部，并在其中包含对所请求资源有效的方法清单。

406 Not Acceptable

    请求所标识的资源的内容特性不被请求中所发送的接受头部所接受，所以不能生成响
应。除非是 HEAD 请求，响应应该包括实体，其中包含有效的实体特性和位置，以便用户
或用户代理能够选择最适当的一个。 实体格式通过Content-Type头部域中给出的媒体类型指
定。取决于该格式和用户代理的能力，作出最适当选择可以自动执行。然而，本规范没有定
义任何标准的这种自动选择算法。
 
    注意：HTTP/1.1 服务器允许返回不被请示发送的接受头部所接受的响应。在某种条件
下，这可能甚至要好于发送406 响应。
 
    鼓励用户代理检测接收的响应头部，以判断是否可接受。如果响应不可接受，用户代理
应该临时停止接收更多数据，并询问用户作出更进一步的选择。

407 Proxy Authentication Required

    该代码与401（Unauthorized）类似，但指示客户端必须首先向代理认证它自己。
 
    代理必须返回 Proxy-Authenticate 头部域在其中包含为所请求资源对代理
有效的需求。 客户端可能使用适当的 Proxy-Authoriztion头部域来重复请求。 HTTP
访问认证解释见“HTTP Authentication: Basic and Digest Access Authentication”。

408 Request Timeout

    在服务器准备接收等待的时间内，客户端没有产生任何请求。客户端可能在以后的任何
时候重复该没经修改的请求。

409 Conflict

    请求没有完成，因为对资源现有状态的冲突。该代码只在如下情况下允许，即希望用户
能够解决该冲突并重新提交该请求。响应体应该包括足够的信息为用户识别冲突源。典型例
子是，响应实体可能包括足够信息为用户或用户代理解决问题；然而，这可能会不可能且没
必要。
 
    冲突大多发生在PUT请求的响应中。例如，如果使用版本控制，且 PUT包括的实体改
变资源，这会与早先（第三方）请求作出的相冲突，服务器可能会使用 409响应表明它不能
完成请求。在这种情况下，响应实体将可能以响应 Content-Type定义的格式包含这两个版本
的区别清单。

410 Gone

    所请求资源不在服务器上有效，且不知道转发地址。该状态期户是永久的。客户端有链
接修改能力应该在用户同意的情况下删除到该 Request-URI的引用。如果服务器不知道，或
没有判断机制，不管状态是否是永久的，都应该使用状态码 404（Not Found）来代替。该响
应可缓存，除非另行指明。
 
     410 响应主要用于辅助 WEB 维护任务，通过提示接收者，源故意不可用，且服务器拥
有都希望删除到该资源的远程链接。
 
    这种事件通常是限时的，升级服务和属于个人的资源在服务器站点没有使用。没必要标
识所有永久不可用资源为“消失”，或保持标志任何时长——这留给服务器拥有都考虑。

411 Length Required

    服务器拒绝接受没有定义 Content-Length 的请求。客户端可以通过添加有效的
Content-Length头部域并包含请求消息中的消息体的长度来重复该请求。

412 Precondition Failed

    在一个或多个请求头部域给出的前提在服务器上测试评估失败。该响应代码允许客户端
在当前资源元信息 （头部域数据） 中放置前提， 这将阻止所请求方法应用到不需要的资源上。

413 Request Entity Too Large

    服务器拒绝处理请求，因为请求实体长于服务器愿意或能够处理的长度。服务器可以关
闭连接来阻止客户端继续请求。如果状态是临时的，服务器应该包括 Retry-After 头部域来
表示这是临时的，且在该时间后客户端可以重试。

414 Request-URI Too Long

    服务器拒绝服务请求，因为Request-URI长于服务器愿意解析的长度。该罕见的状态只
好像发生在，当客户端使用长请求信息不正确转换 POST 请求为 GET 请示时，当客户端已
经降入URI重定向“黑洞”时（例如，重定向 URI前缀指向它自己的后缀），或当服务器被
客户端试图利用在某些服务器中存在的安全漏洞（使用固定长度缓冲来读取或控制
Request-URI）发起攻击时。

415 Unsupported Media Type

    服务器拒绝服务请求，因为请求的实体是请求方法所请求的资源所不支持的格式。

416 Requested Range Not Satisfiable

    服务器应该返回该状态码的响应，如果请求包括Range请求头部域，且该域
中的范围指定值没有覆盖任何所选择资源的当前长度， 且请求没有包括If-Range请求头部域

（对于byte-ranges，这意未着所有byte-range-spec值的 first-byte-pos都大于所选资源的当前
长度。）
 
    当 byte-range 请求返回该状态码时，响应应该包括 Content-Range 实体实部域，并指定
选择资源的当前长度。该响应禁止使用 multipart/byteranges内容类型。

417 Expectation Failed

     Expect请求头部域（见14.20 节）中给出的期望不能满足服务器，或者，如果服务器是
代理，服务器已经明确证明请求不能满足下一跳的服务器。

服务器错误  5xx

    由数字“5”打头的响应状态码表示服务器已经明显处于错误的状况下或没有能力执行
请求。除了相应的 HEAD 请求，服务器应该包括解释错误状态的实体，且不管理是临时或
永久状态。用户代理应该显示实体中包括的任何东西给用户。这些响应码可用于任何请求方
法。

500 Internal Server Error

    服务器发生非预期状况，阻止它完成请求。

501 Not Implemented

    服务器不提供完成请求所需的功能。这是适当的响应，当服务器不认识请求方法或没有
能力在任何资源上支持它。

502 Bad Gateway

    当作为网关或代理时，服务器从它靠近的上游服务器收到试图完成请求的无效响应。

503 Service Unavailable

   服务器当前不能处理请求，因为临时性的负载过重或服务器维护中。
 
    其涵义是临时性状况将会在一些时延后缓和。如果可知，时延长度可以能过 Retry-After
头部指示。如果没有给出Retry-After，客户端应该如500 响应一样处理响应。
 
    注意：存在503状态码并不意未着服务器在开始负载过重时必须使用它。一些服务器可
能希望简单地拒绝连接请求。

504 Gateway Timeout

    当作为网关或代理时， 服务器试图完成请求时没有从 URI （例如， HTTP、 FTP或 LDAP）

指定我上流服务器或一些其它所需来访问的辅助服务器（如，DNS）收到定时响应。
 
    注意：实现者需注意，一些已布置的代理在DNS查询超时后已知会返回 400或 500。

505 HTTP Version Not Supported

    服务器不支持，或拒绝支持，请求消息中使用的HTTP协议版本。服务器指示它不能或
不愿意使用与客户端相同的主版本来完成请求，而是返回该错误消息。响
应中应该包括实体，来描述为什么不支持该版本和服务器还支持其它什么协议。