100(继续)请求者应当继续提出请求。服务器返回此代码表示已收到请求的第一部分,正在等待其余部分。
服务器根据客户端的请求头判断是否接受客户端的请求。如果接受请求则响应100状态码,服务端根据是否存在 Expect: 100-continue 请求头判断是否是Expect请求(有部分web服务器不能正确的处理Expect请求)
该状态码说明服务器收到了请求的初始部分,并且请客户端继续发送。在服务器发送了 100 Continue 状态码之后,如果收到客户端的请求,则必须进行响应。
这个状态码实际上是对如下场景的一种优化:客户端有一个较大的文件需要上传并保存,但是客户端不知道服务器是否愿意接受这个文件,所以希望在消耗网络资源进行传输之前,先询问一下服务器的意愿。实际操作为客户端发送一条特殊的请求报文,报文的头部应包含
Expect: 100-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 响应报文时,则不应当向客户端转发这条响应,因为客户端很可能不知道如何处理该报文。