现阶段，基于网络服务的应用越来越多。CGI返回的内容也不再仅仅局限于表现页面的HTML。例如，提供数据访问的API，AJAX程序的服务器端CGI，对应便携终端的服务器端程序等等。
响应中承载数据的格式多种多样，有XML、JSON、BSON、带格式的文本（CSV）等。无论是哪种格式，均需要解析（Parse）操作。只要有操作，就必然存在消耗资源的行为。如果返回的结果是正常的还好，如果是异常的，解析处理就成了多余的（当然也不是绝对的）。而响应状态码就可以让客户端程序尽可能早的获取服务器端返回的是什么，尽可能避免冗余的操作。要知道，现在的技术体系越发的趋于完善，算法和架构上的性能瓶颈越来越少，所谓的性能改善，大多是一点点抠出来的。
在很多刚刚参加工作的程序员的观念中，响应结果无外乎成功和失败。但成功和失败也是分很多种的。智能的程序，需要根据具体情况采取不同的处理办法。人性化的程序，需要针对不同的原因给出明确的提示信息。这就对服务程序提出了更多的要求，不能仅仅是成功返回数据，失败返回NULL了。
所以，正确的使用响应状态码，是对客户端和服务器端双方的要求。
如同Java的编码建议，不要创建Exception，尽可能的使用系统定义的Exception。响应状态码是有RFC标准的。其主体标准是RFC 2616 （Hypertext TransferProtocol: HTTP/1.1）。也有一些零散的分布在其他的RFC中。
本文尽可能的收集了“规范”中定义的，对应HTTP/1.1的响应状态码。当然，也只是“尽可能”了。谁知道有多少人会去遵守那些未被正式认可的规划？又有谁能知道明天会不会出现一个新的规范呢？对于那些非常冷僻的，本文会一带而过。如果需要详细了解，请去参考RFC2616，或是状态码右侧标注的RFC文档。
作者注：带有★标识的，说明部分是拷贝或翻译来的，作者本人也没有深入了解
表明请求已被服务器接受，请求正在处理中。这一类状态码标明当前响应是一个临时性的响应。响应的内容只包括响应的状态行和一些附加的头部信息，以一个空行结束。客户端在收到常规响应之前，应准备接收一个或多个 1xx 响应。注：HTTP/1.0没有定义任何1系的状态码。
100 Continue
客户端应该继续它的请求。这个临时的应答用来通知客户端：请求的初始部分（头部）已经被接收并且没有被拒绝。客户端应该将剩余的部分继续发送给服务器。如果请求已全部发送，则可以不用理会此应答。
在使用curl做POST的时候, 当要POST的数据大于1024字节的时候, curl并不会直接就发
起POST请求, 而是会分为俩步：1. 发送一个请求, 包含一个Expect:100-continue, 询问Server使用愿意接受数据
2. 接收到Server返回的100-continue应答以后, 才把数据POST给Server
于是,这样就有了一个问题, 并不是所有的Server都会正确应答100-continue, 比如
lighttpd, 就会返回417 “Expectation Failed”, 则会造成逻辑出错。一个解决的办
法是禁用curl的Expect头。
101 Switching Protocols
这个响应是服务器接受了客户端发起的“转换协议”的请求，在此响应之后，服务器的响应会使用切换后的协议。例如，服务器使用HTTP/1.1，客户端要求服务器转为HTTP/1.0，服务器接受转换要求后，将使用HTTP/1.0。
102 ProcessingWebDAVRFC 2518一个WebDAV请求有可能包括多个涉及文件操作的“子请求”，完成整个请求会花费较长的时间。这个响应码表示服务器接受了请求，且请求正被处理中，但还没有完成，所以没有具体的响应。做为指导性原则，如果一个处理所需的时间很长（例如20秒），那么，应该返回这个状态码，在处理完请求之后，备必发送最终响应给客户端。这个状态码可以避免客户端误判为超时。
103 Checkpoint
这个状态码源自“可恢复的HTTP请求的提案（Resumable Http Requests
Proposal） ”，可以恢复被中断的PUT或POST请求。提案中涉及另一个状态码418，但与RFC2324发生了“冲突”。
这个是针对上传用于“断点续传”。向服务器传输大文件时（例如100M），可以考虑将
文件分割为多个部分（如1M）。在发起请求时，需要包含Expect头：
Expect: 103-checkpoint; resume=[Etag]; bytes=0-99999/1234567
服务器在做出响应时，返回这个状态码，并带有一个Etag头，用于标识这个文件。
参考：
http://code.google.com/p/diplodocus/wiki/ResumableHttpRequestsProposal
122 Request-URI too long这不是一个标准的状态码，只适用于IE7。表示URI的长度超过了2083字符。（参考状态码414）
这类状态代码表示服务器接收到客户端发起的请求，理解并接受，然后成功地处理了这个请求。
200 OK
这应该是最最常见的状态码。表求请求已经成功。通常对于GET请求，返回请求所对应的实体。对于POST请求，返回请求动作的结果。
201 Created
请求被完成并导致一个新资源被创建。响应中应该带有访问这个新资源所需要的信息。例如使用Location头给出这个新资源的URI；可以使用ETag头给出这个新资源的ID；使用Content-Type头给出这个新资源的类型。创建动作会在返回状态码之前完成，如果不能被立即执行，服务器应该用状态码202进行替代。
202 Accepted
请求被接收，但处理还没有完成。因为请求可能在处理过程中被拒绝，所以这个请求可能会被执行，也可能不被执行。服务器的应答中应该包含一个指明请求当前状态的标识，以及一个用于监控状态的指针（如URL），或是一些用户可以期望请求何时被完成的估计。很明显，这个状态码适用于异步请求和批处理类型的应203 Non-Authoritative Informationsince HTTP/1.1服务器成功的处理了请求，但返回的Header中可能包含有来自其他资源的内容。204 No Content
请求已被成功的处理，但不需要返回实体内容。应答中可以带有Header，包含新的或是更新过的信息。
205 Reset Content
请求已被成功的处理，但不返回任何实体内容。与204不同的是，这个状态码要求客户端重置文档视图（例如浏览器中显示的表单）。
206 Partial Content
服务器返回的仅是整个响应的一部分。客户端发起请求时，在Header中必须包含一个Range字段，用于指明想要的范围，也可以包含一个If-Range字段，给出请求的条件。而应答的Header中则需要包含一个表示范围的Content-Range字段，或是一个包含有范围信息的Content-Type。另外还有一些其他的约束，详情请参照RFC2612。典型的应用如断点续传。
207 Multi-StatusWebDAVRFC 4918消息主体是一个XML消息，可以包含一个数字，标明响应被分割成几个部分。具体数量依赖于有多少了子请求。
208 Already ReportedWebDAV
表示请求的DAV成员在上一次请求时已回应了，不会再次返回。RFC 5842
RFC 3229
226 IM Used
服务器已经满足了对指定资源的GET请求，并且响应是适用于当前实例的一个或多个实例操作的结果的表现。
客户端浏览器必须采取更多操作来完成请求（例如，浏览器必须请求服务器上的不同的页面，或使用代理服务器重复该请求），这些操作如果是GET或HEADER类型的请求，那么是不需要用户参与的，可以由客户端浏览器自动完成。客户端处理重定向请求时应该不超过5次，因为这种情况通常代表着无限循环。
300 Multiple Choices
被请求的资源有多种表现形式，返回的实体中应该包括所有可用形式的列表，用户可以从中选择一个最合适的资源。例如，请求的资源是一段视频，在不确定客户端可以处理哪种格式之前，服务器可以返回带有不同扩展名的文件列表，avi、mpeg、rmvb、……如果服务器有一个表示的首选项，那么它应该在Location字段中包含明确的URI，那么客户端就可以对其自动重定向。除非有其他情况明确指
一个具体的实体，W3C的 http://www.w3.org/TR/xhtml11/DTD/xhtml11.html 。
301 Moved Permanently
被请求的资源已经被永久性的移动到另一个URI，任何将来对此资源的引用都应该使用新的URI。除非有其他情况明确指出，本应答是可以缓的。应答中的Location字段应该指向新的URI。除非请求方法是HEAD，应答的实体中应该包含一个指向新URI的超链接和简短的超文本注释。如果请求方法即不是GET或是HEAD，那么当服务器返回301状态码时，除非得到了用户的确认，客户端一定不能自动重定向请求，因为这可能改变请求所提出时的条件。
当在拉收到一个301状态码后自动重定向一个POST请求时，某些已经存在的HTTP/1.0客
户端可能错误地将它改变为一个GET请求。
302 Found
被请求的资源临时性的位于一个不同的URI。因为重定向有时会被更改，客户端应该在后续的请求中继续使用这个URI。应答只有在被Cache-Control或Expires报头字段指出时才是可缓存的。应答中的Location字段应该指向临时性的URI。除非请求方法是HEAD，应答的实体中应该包含一个指向临时URI的超链接和简短的超文本注释。如果请求方法即不是GET或是HEAD，那么当服务器返回302状态码时，除非得到了用户的确认，客户端一定不能自动重定向请求，因为这可能改变请求所提
RFC1945和RFC2068规定不允许客户端改变重定向请求的方法。然而，绝大多数现有的浏
览器将302作为303应答对待，在Location字段值上执行一个GET方法而忽略初始的请求
方法。状态码303和307已经添加给那些愿意确定客户端所期望反应种类的服务器。
303 See Othersince HTTP/1.1请求的URI可以在另外的URI下找到，并且应该使用一个GET方法来重新获取资源。这个方法主要是为了允许POST激法脚本的输出将客户端重定向到一个已经被选择的资源。新URI不是初始被请求资源的替代引用，所以303应答一定不能被缓存，但对第二个请求的应答是可以被缓存的。这个不同的URI应该由应答的Location字段绘出。除非请求方法是HEAD，应答的实体中应该包含一个指向新URI的超链接和
很多HTTP/1.1前的客户端不识别303状态。这种情况下，应该使用302代替。
304 Not Modified如果客户端发起了一个有条件的GET请求（如带有If-Modified-Since报头的请求），但是文档并没有被修改，服务器应该返回这个状态码。应答中必须包括以下报头：●Date；●如果报头已经用200应答发送给同一个请求的，那么报头字段是Etag和（或）Content-Location；●如果字段值可能与之前为同一变量发送的应答所不同，那么报头字段是Expires、Cache-Control和（或）Vary。
305 Use Proxysince HTTP/1.1被请求的资源必须通过Location报头给出的代理进行访问。很多HTTP客户端(如Mozilla和IE)不能正确的处理这个状态码，主要是为了安全的原因。
306 Switch Proxy
原先的含义是“接下来的请求，必须使用指定的代理服务器”。这个状态码是在HTTP规范发布以前使用的，现在已经不再使用，仅做为保留值。
307 Temporary Redirectsince HTTP/1.1被请求的资源临时性的位于一个不同的URI。临时性的URI由Location字段给出。与303不同的是，再次发起的请求所使用的方法应该与初始请求的方法一致。308 Resume Incomplete
这个代码用于Resumable HTTP Requests Proposal，用于恢复PUT或POST请求。
4xx类别的状态码是在客户端看起来出错时使用的。除了对HEAD类型的请求，服务器应该返回一个对错误情形进行解释的实体，。
400 Bad Requestsince HTTP/1.1因语法错误，服务器不能理解该请求。典形的情况是参数不正确。
401 Unauthorized
该请求要求用户验证。应答必须包含一个WWW-Authenticate报头。
微软对这个状态码进行了扩展：
401.1 - 登录失败。
401.2 - 服务器配置导致登录失败。
401.3 - 由于 ACL 对资源的限制而未获得授权。
401.4 - 筛选器授权失败。
401.5 - ISAPI/CGI 应用程序授权失败。
401.7 – 访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专
402 Payment Required
为将来保留的代码。
403 Forbidden
服务器了解该请求，但是拒绝完成它。与401不同，即使通过了认证，情况也不会改变。如果请求方法不是HEAD，并且服务器愿意公布请求被拒绝的原因，它应该在实体里进行描述。如果服务器不希望客户端知道这个消息，它可以使用404代替
微软对这个状态码进行了扩展：
403.1 - 执行访问被禁止。
403.2 - 读访问被禁止。
403.3 - 写访问被禁止。
403.4 - 要求 SSL。
403.5 - 要求 SSL 128。
403.6 - IP 地址被拒绝。
403.7 - 要求客户端证书。
403.8 - 站点访问被拒绝。
403.9 - 用户数过多。
403.10 - 配置无效。
403.11 - 密码更改。
403.12 - 拒绝访问映射表。
403.13 - 客户端证书被吊销。
403.14 - 拒绝目录列表。
403.15 - 超出客户端访问许可。
403.16 - 客户端证书不受信任或无效。
403.17 - 客户端证书已过期或尚未生效。
403.18 - 在当前的应用程序池中不能执行所请求的 URL。这个错误代码为 IIS 6.0 所
专用。
403.19 - 不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专
404 Not Found
服务器没有找到任何匹配请求的URI的资源。这种情形是临时性的还是永久性的，确切信息并没有给出。如果服务器通过一些内部机制知道这是一个永久性的不可用，并且没有替代的地址，它应该使用410。这个状态码通过用于这种情况：服务器不想告知为什么请求被拒绝了，或者没有其他合适的应答时。
微软对这个状态码进行了扩展：
404.0 - (无) – 未找到文件或目录。
404.1 - 无法通过请求的端口访问网站。
404.2 - Web 服务扩展锁定策略阻止本请求。
404.3 - MIME 映射策略阻止了此请求。
405 Method Not Allowed
请求的URI指定的资源不接收该请求所使用的方法。应答必须包含一个Allow报头，标题可用的方法列表（方法之间用逗号分隔）。
406 Not Acceptable
请求中通常会有一个Accept报头，这个报头包含了客户端能够接受的所有资源类型的列表。如果被请求的资源能够生成的实体不属于这个列表，那么应该返回这407 Proxy Authentication Required
类似于401，不过它意味着客户端首先要通过代理服务器的认证。代理服务器必须返回一个Proxy-Authenticate报头。
408 Request Timeout
客户端没有在服务器所能等待的时间里产生请求。客户端可以稍后无需更改重发请求。注意，这个状态码指的是服务器“等”客户端，而不是客户端“等”服务409 Conflict
资源的当前状态有冲突，导致该请求无法完成。该代码只有在预计用户有能力解决冲突并重新提交请求的情况下使用。应答主体应该包含足够的信息来让用户识别出冲突产生的根源。
在操作SVN时，如果想要提交的文件已经被他人修改了，你的提交行为就会被中止，因
为了有“冲突”。虽然SVN也是基于HTTP协议的，但它是否使用了409状态码来实现这个功能，我就不清楚了。这个例子只是为了让读者便于理解。
410 Gone
被请求的资源在服务器上不可再用，而且没有替代的地址。这种情况被认为是永久性的。如果服务器上无法判断这种情况是否为永久性的，那么应该使用404。411 Length Required
服务器拒绝接收一个没有定义Content-Length的请求。
412 Precondition Failed
请求报头中给出的前提，在服务器上进行测试时评估为失败。
413 Request Entity Too Large
请求的实体太大，服务器无法处理。服务器可能会关闭与客户端的连接来防止客户端继续请求。
414 Request-URI Too Long
URI的长度对服务器来说太长了，服务器拒绝服务。
415 Unsupported Media Type
请求的实体是服务器不支持的。例如客户端上传了一个image/svg+xml的图片，但服务器要求使用其他格式的图片。
416 Requested Range Not Satisfiable
如果一个请求包含一个Range报头，并且该字段指定的值与诅求的资源的当前范围重叠，而请求又没有包含If-Range报头，那么服务器应该返回该状态码。（对于bytep-ranges来说，这意味着所有字节范围指定值的第一个字节位置要大于选中资源的当前长度。）当该状态码返回给byte-ranges请求时，应答应该包含一个Content-Range实体报头字段指出的所选资源的当前长度。这个应答一定不能使用multipart/byteranges内容类型。
417 Expectation Failed
Except请求报头字段给出的期望不能被本服务器所满足。
418 I'm a teapotRFC 2324这个状态码来自1998年的一个愚人节的笑话，RFC2324《超文字咖啡壶控制协定（Hyper Text Coffee Pot Control Protocol）》。原本没有期望它被实现，但这个状态码确实被使用了。Nginx HTTP服务器使用这个状态码来实现类似GOTO的420 Enhance Your Calm
Twitter Search和Trands API在客户端被评估的次数过多时使用这个状态码。其他的服务或许希望使用429来代替。
422 Unprocessable Entity
请求的格式是正确的，但语义有错误。
423 Locked
被请求的资源已被加锁。
424 Failed Dependency
前一个失败的请求，导致本次请求失败。WebDAVRFC 4918WebDAVRFC 4918WebDAVRFC 4918
425 Unordered CollectionRFC 3648在《WebDAV Advanced Collections Protocol》草案中被定义，但是在《WebDistributed Authoring and Versioning (WebDAV) Ordered CollectionsProtocol》中没有被实现。
426 Upgrade Required
客户端应该使用其他协议，如TLS/1.0。RFC 2817
428 Precondition Required
客户端发送 HTTP 请求时，如果想要请求能成功必须满足一些预设的条件。一个好的例子就是 If-None-Match报头，经常在GET请求中使用，如果指定了If-None-Match，那么客户端只在响应中的 ETag 改变后才会重新接收回应。另外一个例子就是If-Match头，这个一般用在PUT请求上用于指示只更新没被改变的资源，这在多个客户端使用HTTP服务时用来防止彼此间不会覆盖相同内容。当服务器端使用428状态码时，表示客户端必须发送上述的请求头才能执行请求，这个方法为服务
429 Too Many Requests
当用户发出的请求已经超过了服务器所愿意接受的总数时，可以返回这个状态码，限制用户继续发起请求。如果希望限制客户端对服务的请求数，可使用429状态码，同时包含一个Retry-After报头，告诉客户端多长时间后可以再次请求服务431 Request Header Fields Too Large
某些情况下，客户端发送 HTTP 请求头会变得很大，那么服务器可发送 431Request Header Fields Too Large 来指明该问题。
444 No Response
Nginx HTTP服务器的扩展。当服务器不返回任何内容，同时关闭连接时，使用这个449 Retry With
微软的扩展。表示应该在某些指定的行为之后再次发起请求。
450 Blocked by Windows Parental Controls
微软的扩展。
499 Client Closed Request
Nginx HTTP服务器扩展。
5xx系列的状态码表明服务器知道自己出错，或者服务器没有能力执行请求。除应答HEAD请求外，响应中应该包含一个实体来解决错误状况，并且解释该状况是临时性的还是永久性的。
500 Internal Server Error
最常见的错误状态码，表明服务器遇到意外情况，致使其无法完成请求。
微软对这个状态码进行了扩展：
500.12 - 应用程序正忙于在 Web 服务器上重新启动。500.13 - Web 服务器太忙。
500.15 - 不允许直接请求 Global.asa。
500.16 – UNC 授权凭据不正确。这个错误代码为 IIS 6.0 所专用。
500.18 – URL 授权存储不能打开。这个错误代码为 IIS 6.0 所专用。
500.100 - 内部 ASP 错误。
501 Not Implemented
服务器不支持完成请求所需要的功能。当服务器不能识别请求方法，以及没有能力支持方法所需要的资源时，应该返回此状态码。
502 Bad Gateway
当服务器作为一个网关或代理时，在尝试实现请求时从访问的上游服务器接收到一个无效的应答。
微软对这个状态码进行了扩展：
502.1 - CGI 应用程序超时。
502.2 - CGI 应用程序出错
503 Service Unavailable
由于暂时负载过重或者服务器维护，当前服务器不能处理请求。这意味着只是一个暂时的状况，稍后会得到缓解。如果能够知道，延迟的长度可以用一个Retry-After报头指出。
504 Gateway Timeout
服务器作为一个网关或代理时，没有从URI指定的上游服务器，或是完成需求所需要访问的辅助服务器（如DNS）那里及时的得到应答。
505 HTTP Version Not Supported
服务器不支持请求中使用的HTTP版本。
506 Variant Also NegotiatesRFC 2295由《透明内容协商协议》（RFC 2295）扩展，代表服务器存在内部配置错误。507 Insufficient Storage
服务器无法保存用于完成请求的表现。
508 Loop Detected
服务器在处理请求时，检测到无限循环。WebDAVRFC 4918WebDAVRFC 5842
509 Bandwidth Limit Exceeded (Apache bw/limited extension)
这个状态码被许多服务器使用了。但它没有在任何一个RFC中被定义。
510 Not Extended
服务器需要更多的扩展功能才能完成请求。
511 Network Authentication Required
客户端需要认证后才能访问网络。例如WI-FI接入点所需要的认证。RFC 2774
现阶段，基于网络服务的应用越来越多。CGI返回的内容也不再仅仅局限于表现页面的HTML。例如，提供数据访问的API，AJAX程序的服务器端CGI，对应便携终端的服务器端程序等等。
响应中承载数据的格式多种多样，有XML、JSON、BSON、带格式的文本（CSV）等。无论是哪种格式，均需要解析（Parse）操作。只要有操作，就必然存在消耗资源的行为。如果返回的结果是正常的还好，如果是异常的，解析处理就成了多余的（当然也不是绝对的）。而响应状态码就可以让客户端程序尽可能早的获取服务器端返回的是什么，尽可能避免冗余的操作。要知道，现在的技术体系越发的趋于完善，算法和架构上的性能瓶颈越来越少，所谓的性能改善，大多是一点点抠出来的。
在很多刚刚参加工作的程序员的观念中，响应结果无外乎成功和失败。但成功和失败也是分很多种的。智能的程序，需要根据具体情况采取不同的处理办法。人性化的程序，需要针对不同的原因给出明确的提示信息。这就对服务程序提出了更多的要求，不能仅仅是成功返回数据，失败返回NULL了。
所以，正确的使用响应状态码，是对客户端和服务器端双方的要求。
如同Java的编码建议，不要创建Exception，尽可能的使用系统定义的Exception。响应状态码是有RFC标准的。其主体标准是RFC 2616 （Hypertext TransferProtocol: HTTP/1.1）。也有一些零散的分布在其他的RFC中。
本文尽可能的收集了“规范”中定义的，对应HTTP/1.1的响应状态码。当然，也只是“尽可能”了。谁知道有多少人会去遵守那些未被正式认可的规划？又有谁能知道明天会不会出现一个新的规范呢？对于那些非常冷僻的，本文会一带而过。如果需要详细了解，请去参考RFC2616，或是状态码右侧标注的RFC文档。
作者注：带有★标识的，说明部分是拷贝或翻译来的，作者本人也没有深入了解
表明请求已被服务器接受，请求正在处理中。这一类状态码标明当前响应是一个临时性的响应。响应的内容只包括响应的状态行和一些附加的头部信息，以一个空行结束。客户端在收到常规响应之前，应准备接收一个或多个 1xx 响应。注：HTTP/1.0没有定义任何1系的状态码。
100 Continue
客户端应该继续它的请求。这个临时的应答用来通知客户端：请求的初始部分（头部）已经被接收并且没有被拒绝。客户端应该将剩余的部分继续发送给服务器。如果请求已全部发送，则可以不用理会此应答。
在使用curl做POST的时候, 当要POST的数据大于1024字节的时候, curl并不会直接就发
起POST请求, 而是会分为俩步：1. 发送一个请求, 包含一个Expect:100-continue, 询问Server使用愿意接受数据
2. 接收到Server返回的100-continue应答以后, 才把数据POST给Server
于是,这样就有了一个问题, 并不是所有的Server都会正确应答100-continue, 比如
lighttpd, 就会返回417 “Expectation Failed”, 则会造成逻辑出错。一个解决的办
法是禁用curl的Expect头。
101 Switching Protocols
这个响应是服务器接受了客户端发起的“转换协议”的请求，在此响应之后，服务器的响应会使用切换后的协议。例如，服务器使用HTTP/1.1，客户端要求服务器转为HTTP/1.0，服务器接受转换要求后，将使用HTTP/1.0。
102 ProcessingWebDAVRFC 2518一个WebDAV请求有可能包括多个涉及文件操作的“子请求”，完成整个请求会花费较长的时间。这个响应码表示服务器接受了请求，且请求正被处理中，但还没有完成，所以没有具体的响应。做为指导性原则，如果一个处理所需的时间很长（例如20秒），那么，应该返回这个状态码，在处理完请求之后，备必发送最终响应给客户端。这个状态码可以避免客户端误判为超时。
103 Checkpoint
这个状态码源自“可恢复的HTTP请求的提案（Resumable Http Requests
Proposal） ”，可以恢复被中断的PUT或POST请求。提案中涉及另一个状态码418，但与RFC2324发生了“冲突”。
这个是针对上传用于“断点续传”。向服务器传输大文件时（例如100M），可以考虑将
文件分割为多个部分（如1M）。在发起请求时，需要包含Expect头：
Expect: 103-checkpoint; resume=[Etag]; bytes=0-99999/1234567
服务器在做出响应时，返回这个状态码，并带有一个Etag头，用于标识这个文件。
参考：
http://code.google.com/p/diplodocus/wiki/ResumableHttpRequestsProposal
122 Request-URI too long这不是一个标准的状态码，只适用于IE7。表示URI的长度超过了2083字符。（参考状态码414）
这类状态代码表示服务器接收到客户端发起的请求，理解并接受，然后成功地处理了这个请求。
200 OK
这应该是最最常见的状态码。表求请求已经成功。通常对于GET请求，返回请求所对应的实体。对于POST请求，返回请求动作的结果。
201 Created
请求被完成并导致一个新资源被创建。响应中应该带有访问这个新资源所需要的信息。例如使用Location头给出这个新资源的URI；可以使用ETag头给出这个新资源的ID；使用Content-Type头给出这个新资源的类型。创建动作会在返回状态码之前完成，如果不能被立即执行，服务器应该用状态码202进行替代。
202 Accepted
请求被接收，但处理还没有完成。因为请求可能在处理过程中被拒绝，所以这个请求可能会被执行，也可能不被执行。服务器的应答中应该包含一个指明请求当前状态的标识，以及一个用于监控状态的指针（如URL），或是一些用户可以期望请求何时被完成的估计。很明显，这个状态码适用于异步请求和批处理类型的应203 Non-Authoritative Informationsince HTTP/1.1服务器成功的处理了请求，但返回的Header中可能包含有来自其他资源的内容。204 No Content
请求已被成功的处理，但不需要返回实体内容。应答中可以带有Header，包含新的或是更新过的信息。
205 Reset Content
请求已被成功的处理，但不返回任何实体内容。与204不同的是，这个状态码要求客户端重置文档视图（例如浏览器中显示的表单）。
206 Partial Content
服务器返回的仅是整个响应的一部分。客户端发起请求时，在Header中必须包含一个Range字段，用于指明想要的范围，也可以包含一个If-Range字段，给出请求的条件。而应答的Header中则需要包含一个表示范围的Content-Range字段，或是一个包含有范围信息的Content-Type。另外还有一些其他的约束，详情请参照RFC2612。典型的应用如断点续传。
207 Multi-StatusWebDAVRFC 4918消息主体是一个XML消息，可以包含一个数字，标明响应被分割成几个部分。具体数量依赖于有多少了子请求。
208 Already ReportedWebDAV
表示请求的DAV成员在上一次请求时已回应了，不会再次返回。RFC 5842
RFC 3229
226 IM Used
服务器已经满足了对指定资源的GET请求，并且响应是适用于当前实例的一个或多个实例操作的结果的表现。
客户端浏览器必须采取更多操作来完成请求（例如，浏览器必须请求服务器上的不同的页面，或使用代理服务器重复该请求），这些操作如果是GET或HEADER类型的请求，那么是不需要用户参与的，可以由客户端浏览器自动完成。客户端处理重定向请求时应该不超过5次，因为这种情况通常代表着无限循环。
300 Multiple Choices
被请求的资源有多种表现形式，返回的实体中应该包括所有可用形式的列表，用户可以从中选择一个最合适的资源。例如，请求的资源是一段视频，在不确定客户端可以处理哪种格式之前，服务器可以返回带有不同扩展名的文件列表，avi、mpeg、rmvb、……如果服务器有一个表示的首选项，那么它应该在Location字段中包含明确的URI，那么客户端就可以对其自动重定向。除非有其他情况明确指
一个具体的实体，W3C的 http://www.w3.org/TR/xhtml11/DTD/xhtml11.html 。
301 Moved Permanently
被请求的资源已经被永久性的移动到另一个URI，任何将来对此资源的引用都应该使用新的URI。除非有其他情况明确指出，本应答是可以缓的。应答中的Location字段应该指向新的URI。除非请求方法是HEAD，应答的实体中应该包含一个指向新URI的超链接和简短的超文本注释。如果请求方法即不是GET或是HEAD，那么当服务器返回301状态码时，除非得到了用户的确认，客户端一定不能自动重定向请求，因为这可能改变请求所提出时的条件。
当在拉收到一个301状态码后自动重定向一个POST请求时，某些已经存在的HTTP/1.0客
户端可能错误地将它改变为一个GET请求。
302 Found
被请求的资源临时性的位于一个不同的URI。因为重定向有时会被更改，客户端应该在后续的请求中继续使用这个URI。应答只有在被Cache-Control或Expires报头字段指出时才是可缓存的。应答中的Location字段应该指向临时性的URI。除非请求方法是HEAD，应答的实体中应该包含一个指向临时URI的超链接和简短的超文本注释。如果请求方法即不是GET或是HEAD，那么当服务器返回302状态码时，除非得到了用户的确认，客户端一定不能自动重定向请求，因为这可能改变请求所提
RFC1945和RFC2068规定不允许客户端改变重定向请求的方法。然而，绝大多数现有的浏
览器将302作为303应答对待，在Location字段值上执行一个GET方法而忽略初始的请求
方法。状态码303和307已经添加给那些愿意确定客户端所期望反应种类的服务器。
303 See Othersince HTTP/1.1请求的URI可以在另外的URI下找到，并且应该使用一个GET方法来重新获取资源。这个方法主要是为了允许POST激法脚本的输出将客户端重定向到一个已经被选择的资源。新URI不是初始被请求资源的替代引用，所以303应答一定不能被缓存，但对第二个请求的应答是可以被缓存的。这个不同的URI应该由应答的Location字段绘出。除非请求方法是HEAD，应答的实体中应该包含一个指向新URI的超链接和
很多HTTP/1.1前的客户端不识别303状态。这种情况下，应该使用302代替。
304 Not Modified如果客户端发起了一个有条件的GET请求（如带有If-Modified-Since报头的请求），但是文档并没有被修改，服务器应该返回这个状态码。应答中必须包括以下报头：●Date；●如果报头已经用200应答发送给同一个请求的，那么报头字段是Etag和（或）Content-Location；●如果字段值可能与之前为同一变量发送的应答所不同，那么报头字段是Expires、Cache-Control和（或）Vary。
305 Use Proxysince HTTP/1.1被请求的资源必须通过Location报头给出的代理进行访问。很多HTTP客户端(如Mozilla和IE)不能正确的处理这个状态码，主要是为了安全的原因。
306 Switch Proxy
原先的含义是“接下来的请求，必须使用指定的代理服务器”。这个状态码是在HTTP规范发布以前使用的，现在已经不再使用，仅做为保留值。
307 Temporary Redirectsince HTTP/1.1被请求的资源临时性的位于一个不同的URI。临时性的URI由Location字段给出。与303不同的是，再次发起的请求所使用的方法应该与初始请求的方法一致。308 Resume Incomplete
这个代码用于Resumable HTTP Requests Proposal，用于恢复PUT或POST请求。
4xx类别的状态码是在客户端看起来出错时使用的。除了对HEAD类型的请求，服务器应该返回一个对错误情形进行解释的实体，。
400 Bad Requestsince HTTP/1.1因语法错误，服务器不能理解该请求。典形的情况是参数不正确。
401 Unauthorized
该请求要求用户验证。应答必须包含一个WWW-Authenticate报头。
微软对这个状态码进行了扩展：
401.1 - 登录失败。
401.2 - 服务器配置导致登录失败。
401.3 - 由于 ACL 对资源的限制而未获得授权。
401.4 - 筛选器授权失败。
401.5 - ISAPI/CGI 应用程序授权失败。
401.7 – 访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专
402 Payment Required
为将来保留的代码。
403 Forbidden
服务器了解该请求，但是拒绝完成它。与401不同，即使通过了认证，情况也不会改变。如果请求方法不是HEAD，并且服务器愿意公布请求被拒绝的原因，它应该在实体里进行描述。如果服务器不希望客户端知道这个消息，它可以使用404代替
微软对这个状态码进行了扩展：
403.1 - 执行访问被禁止。
403.2 - 读访问被禁止。
403.3 - 写访问被禁止。
403.4 - 要求 SSL。
403.5 - 要求 SSL 128。
403.6 - IP 地址被拒绝。
403.7 - 要求客户端证书。
403.8 - 站点访问被拒绝。
403.9 - 用户数过多。
403.10 - 配置无效。
403.11 - 密码更改。
403.12 - 拒绝访问映射表。
403.13 - 客户端证书被吊销。
403.14 - 拒绝目录列表。
403.15 - 超出客户端访问许可。
403.16 - 客户端证书不受信任或无效。
403.17 - 客户端证书已过期或尚未生效。
403.18 - 在当前的应用程序池中不能执行所请求的 URL。这个错误代码为 IIS 6.0 所
专用。
403.19 - 不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专
404 Not Found
服务器没有找到任何匹配请求的URI的资源。这种情形是临时性的还是永久性的，确切信息并没有给出。如果服务器通过一些内部机制知道这是一个永久性的不可用，并且没有替代的地址，它应该使用410。这个状态码通过用于这种情况：服务器不想告知为什么请求被拒绝了，或者没有其他合适的应答时。
微软对这个状态码进行了扩展：
404.0 - (无) – 未找到文件或目录。
404.1 - 无法通过请求的端口访问网站。
404.2 - Web 服务扩展锁定策略阻止本请求。
404.3 - MIME 映射策略阻止了此请求。
405 Method Not Allowed
请求的URI指定的资源不接收该请求所使用的方法。应答必须包含一个Allow报头，标题可用的方法列表（方法之间用逗号分隔）。
406 Not Acceptable
请求中通常会有一个Accept报头，这个报头包含了客户端能够接受的所有资源类型的列表。如果被请求的资源能够生成的实体不属于这个列表，那么应该返回这407 Proxy Authentication Required
类似于401，不过它意味着客户端首先要通过代理服务器的认证。代理服务器必须返回一个Proxy-Authenticate报头。
408 Request Timeout
客户端没有在服务器所能等待的时间里产生请求。客户端可以稍后无需更改重发请求。注意，这个状态码指的是服务器“等”客户端，而不是客户端“等”服务409 Conflict
资源的当前状态有冲突，导致该请求无法完成。该代码只有在预计用户有能力解决冲突并重新提交请求的情况下使用。应答主体应该包含足够的信息来让用户识别出冲突产生的根源。
在操作SVN时，如果想要提交的文件已经被他人修改了，你的提交行为就会被中止，因
为了有“冲突”。虽然SVN也是基于HTTP协议的，但它是否使用了409状态码来实现这个功能，我就不清楚了。这个例子只是为了让读者便于理解。
410 Gone
被请求的资源在服务器上不可再用，而且没有替代的地址。这种情况被认为是永久性的。如果服务器上无法判断这种情况是否为永久性的，那么应该使用404。411 Length Required
服务器拒绝接收一个没有定义Content-Length的请求。
412 Precondition Failed
请求报头中给出的前提，在服务器上进行测试时评估为失败。
413 Request Entity Too Large
请求的实体太大，服务器无法处理。服务器可能会关闭与客户端的连接来防止客户端继续请求。
414 Request-URI Too Long
URI的长度对服务器来说太长了，服务器拒绝服务。
415 Unsupported Media Type
请求的实体是服务器不支持的。例如客户端上传了一个image/svg+xml的图片，但服务器要求使用其他格式的图片。
416 Requested Range Not Satisfiable
如果一个请求包含一个Range报头，并且该字段指定的值与诅求的资源的当前范围重叠，而请求又没有包含If-Range报头，那么服务器应该返回该状态码。（对于bytep-ranges来说，这意味着所有字节范围指定值的第一个字节位置要大于选中资源的当前长度。）当该状态码返回给byte-ranges请求时，应答应该包含一个Content-Range实体报头字段指出的所选资源的当前长度。这个应答一定不能使用multipart/byteranges内容类型。
417 Expectation Failed
Except请求报头字段给出的期望不能被本服务器所满足。
418 I'm a teapotRFC 2324这个状态码来自1998年的一个愚人节的笑话，RFC2324《超文字咖啡壶控制协定（Hyper Text Coffee Pot Control Protocol）》。原本没有期望它被实现，但这个状态码确实被使用了。Nginx HTTP服务器使用这个状态码来实现类似GOTO的420 Enhance Your Calm
Twitter Search和Trands API在客户端被评估的次数过多时使用这个状态码。其他的服务或许希望使用429来代替。
422 Unprocessable Entity
请求的格式是正确的，但语义有错误。
423 Locked
被请求的资源已被加锁。
424 Failed Dependency
前一个失败的请求，导致本次请求失败。WebDAVRFC 4918WebDAVRFC 4918WebDAVRFC 4918
425 Unordered CollectionRFC 3648在《WebDAV Advanced Collections Protocol》草案中被定义，但是在《WebDistributed Authoring and Versioning (WebDAV) Ordered CollectionsProtocol》中没有被实现。
426 Upgrade Required
客户端应该使用其他协议，如TLS/1.0。RFC 2817
428 Precondition Required
客户端发送 HTTP 请求时，如果想要请求能成功必须满足一些预设的条件。一个好的例子就是 If-None-Match报头，经常在GET请求中使用，如果指定了If-None-Match，那么客户端只在响应中的 ETag 改变后才会重新接收回应。另外一个例子就是If-Match头，这个一般用在PUT请求上用于指示只更新没被改变的资源，这在多个客户端使用HTTP服务时用来防止彼此间不会覆盖相同内容。当服务器端使用428状态码时，表示客户端必须发送上述的请求头才能执行请求，这个方法为服务
429 Too Many Requests
当用户发出的请求已经超过了服务器所愿意接受的总数时，可以返回这个状态码，限制用户继续发起请求。如果希望限制客户端对服务的请求数，可使用429状态码，同时包含一个Retry-After报头，告诉客户端多长时间后可以再次请求服务431 Request Header Fields Too Large
某些情况下，客户端发送 HTTP 请求头会变得很大，那么服务器可发送 431Request Header Fields Too Large 来指明该问题。
444 No Response
Nginx HTTP服务器的扩展。当服务器不返回任何内容，同时关闭连接时，使用这个449 Retry With
微软的扩展。表示应该在某些指定的行为之后再次发起请求。
450 Blocked by Windows Parental Controls
微软的扩展。
499 Client Closed Request
Nginx HTTP服务器扩展。
5xx系列的状态码表明服务器知道自己出错，或者服务器没有能力执行请求。除应答HEAD请求外，响应中应该包含一个实体来解决错误状况，并且解释该状况是临时性的还是永久性的。
500 Internal Server Error
最常见的错误状态码，表明服务器遇到意外情况，致使其无法完成请求。
微软对这个状态码进行了扩展：
500.12 - 应用程序正忙于在 Web 服务器上重新启动。500.13 - Web 服务器太忙。
500.15 - 不允许直接请求 Global.asa。
500.16 – UNC 授权凭据不正确。这个错误代码为 IIS 6.0 所专用。
500.18 – URL 授权存储不能打开。这个错误代码为 IIS 6.0 所专用。
500.100 - 内部 ASP 错误。
501 Not Implemented
服务器不支持完成请求所需要的功能。当服务器不能识别请求方法，以及没有能力支持方法所需要的资源时，应该返回此状态码。
502 Bad Gateway
当服务器作为一个网关或代理时，在尝试实现请求时从访问的上游服务器接收到一个无效的应答。
微软对这个状态码进行了扩展：
502.1 - CGI 应用程序超时。
502.2 - CGI 应用程序出错
503 Service Unavailable
由于暂时负载过重或者服务器维护，当前服务器不能处理请求。这意味着只是一个暂时的状况，稍后会得到缓解。如果能够知道，延迟的长度可以用一个Retry-After报头指出。
504 Gateway Timeout
服务器作为一个网关或代理时，没有从URI指定的上游服务器，或是完成需求所需要访问的辅助服务器（如DNS）那里及时的得到应答。
505 HTTP Version Not Supported
服务器不支持请求中使用的HTTP版本。
506 Variant Also NegotiatesRFC 2295由《透明内容协商协议》（RFC 2295）扩展，代表服务器存在内部配置错误。507 Insufficient Storage
服务器无法保存用于完成请求的表现。
508 Loop Detected
服务器在处理请求时，检测到无限循环。WebDAVRFC 4918WebDAVRFC 5842
509 Bandwidth Limit Exceeded (Apache bw/limited extension)
这个状态码被许多服务器使用了。但它没有在任何一个RFC中被定义。
510 Not Extended
服务器需要更多的扩展功能才能完成请求。
511 Network Authentication Required
客户端需要认证后才能访问网络。例如WI-FI接入点所需要的认证。RFC 2774