超文本传输协议响应状态码.pdfVIP

现阶段，基于网络服务的应用越来越多。CGI返回的内容也不再仅仅局限于表现页 面的HTML。例如，提供数据访问的API，AJAX程序的服务器端CGI，对应便携终端 的服务器端程序等等。 响应中承载数据的格式多种多样，有XML、JSON、BSON、带格式的文本（CSV）等 。无论是哪种格式，均需要解析（Parse）操作。只要有操作，就必然存在消耗资 源的行为。如果返回的结果是正常的还好，如果是异常的，解析处理就成了多余 的（当然也不是绝对的）。而响应状态码就可以让客户端程序尽可能早的获取服 务器端返回的是什么，尽可能避免冗余的操作。要知道，现在的技术体系越发的 趋于完善，算法和架构上的性能瓶颈越来越少，所谓的性能改善，大多是一点点 抠出来的。 在很多刚刚参加工作的程序员的观念中，响应结果无外乎成功和失败。但成功和 失败也是分很多种的。智能的程序，需要根据具体情况采取不同的处理办法。人 性化的程序，需要针对不同的原因给出明确的提示信息。这就对服务程序提出了 更多的要求，不能仅仅是成功返回数据，失败返回NULL了。 所以，正确的使用响应状态码，是对客户端和服务器端双方的要求。 如同Java的编码建议，不要创建Exception，尽可能的使用系统定义的Exception 。响应状态码是有RFC标准的。其主体标准是RFC 2616 （Hypertext Transfer Protocol: HTTP/1.1）。也有一些零散的分布在其他的RFC中。 本文尽可能的收集了“规范”中定义的，对应HTTP/1.1的响应状态码。当然，也 只是“尽可能”了。谁知道有多少人会去遵守那些未被正式认可的规划？又有谁 能知道明天会不会出现一个新的规范呢？对于那些非常冷僻的，本文会一带而过 。如果需要详细了解，请去参考RFC2616，或是状态码右侧标注的RFC文档。 作者注：带有★标识的，说明部分是拷贝或翻译来的，作者本人也没有深入了解 1XX 报告 表明请求已被服务器接受，请求正在处理中。这一类状态码标明当前响应是一个 临时性的响应。响应的内容只包括响应的状态行和一些附加的头部信息，以一个 空行结束。客户端在收到常规响应之前，应准备接收一个或多个 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 Processing WebDAV RFC 2518 一个WebDAV请求有可能包括多个涉及文件操作的“子请求”，完成整个请求会花 费较长的时间。这个响应码表示服务器接受了请求，且请求正被处理中，但还没 有完成，所以没有具体的响应。做为指导性原则，如果一个处理所需的时间很长 （例如20秒），那么，应该返回这个状态码，在处理完请求之后，备必发送最终 响应给客户端。这个状态码可以避免客户端误判为超时。 103 Checkpoint 这个状态码源自“可恢复的HTTP请求的提案（Resumable Http Requests Proposal） ”，可以恢复被中断的PUT或POST请求。提案中涉及