HTTP报文中的100状态码

HTTP状态码(status codes)是HTTP协议中，响应报文的起始行中包含的一种服务器用于向客户端说明操作状态的三位数字。例如在一个正常的GET请求完成后，服务器会向客户端返回

HTTP/1.0  OK

在这个例子中，状态码就是 200

状态码的第一位数字表示了响应状态的类型，其中

• 1xx 信息提示
• 2xx 成功
• 3xx 重定向
• 4xx 客户端错误
• 5xx 服务器错误

今天我们主要讨论1xx的状态码，即消息状态码。由于当前的HTTP版本只为每种类型的状态码定义了少数一部分，而HTTP协议具有可拓展性，随着协议的发展，状态码将不断完善，较老版本的HTTP应用就不能识别较新的状态码，而这个特性也就使得不同版本的HTTP应用在通讯时产生了一些问题。由于 HTTP/0.9 版本的响应报文只包含实体部分，没有状态码或原因短语的存在，故不做讨论。

1xx状态码是 HTTP/1.1 版本新定义的，用来表示请求被正常接受，会进行进一步处理。这些状态码相对较新，并且 HTTP/1.0 版本无法识别，所以原则上不应该向HTTP/1.0版本的客户端发送任何1xx状态码。

100 Continue

该状态码说明服务器收到了请求的初始部分，并且请客户端继续发送。在服务器发送了 100 Continue 状态码之后，如果收到客户端的请求，则必须进行响应。

这个状态码实际上是对如下场景的一种优化：客户端有一个较大的文件需要上传并保存，但是客户端不知道服务器是否愿意接受这个文件，所以希望在消耗网络资源进行传输之前，先询问一下服务器的意愿。实际操作为客户端发送一条特殊的请求报文，报文的头部应包含

Expect: -continue

此时，如果服务器愿意接受，就会返回 100 Continue 状态码，反之则返回 417 Expectation Failed 状态码。对于客户端而言，如果客户端没有发送实际请求的打算，则不应该发送包含 100 Continue Expect 的报文，因为这样会让服务器误以为客户端将要发送一个请求。

之前提到过，并不是所有的HTTP应用都支持 100 Continue 这个状态码（例如HTTP/1.0及之前的版本的代理或服务器）所以客户端不应该在发送 100 Continue Expect 后一直等待服务器的响应，在一定时间后，客户端应当直接发送计划发送的内容。

而对于服务器而言，也不应当把 100 Continue 当作一个严格的判断方法。服务器有可能在发送回应之前就受到了客户端发来的主体报文。此时服务器就不需要再发送 100 Continue 作为回应了。但仍然需要在接受完成后返回适当的状态码。理论上，当服务器收到一个 100 Continue Expect 请求时，应当进行响应。但服务器永远也不应向没有发送 100 Continue Expect 请求的客户端发送100 Continue 状态码作为回应。这里提到的应当进行响应是指：假设服务器不打算接收客户端将要发送的主体报文，也应当做适当的响应（例如发送 417 Expectation Failed）而不是单纯的关闭连接，这样会对客户端在网络层面上产生影响。

特别的，作为代理的HTTP应用在收到带有 100 Continue Expect 的请求时，需要进行额外的判断。假设代理服务器明确知道报文下游的HTTP版本是兼容 HTTP/1.1 的，或者代理服务器不知道报文下游的版本，它都应当转发这条 100 Continue Expect 请求。但是如果代理服务器明确知道报文下游的应用无法处理 100 Continue Expect 的话，则应当直接向客户端返回 417 Expectation Failed 作为响应。而这也并非唯一的解决办法，另一种可行的办法是直接向客户端返回 100 Continue ，然后向下游传递删除了 100 Continue Expect 的报文。

另外，如果代理服务器决定为 HTTP/1.0 及之前的版本服务的话，那么当它收到来自服务器的 100 Continue 响应报文时，则不应当向客户端转发这条响应，因为客户端很可能不知道如何处理该报文。