Http 100 状态码
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 响应报文时，则不应当向客户端转发这条响应，因为客户端很可能不知道如何处理该报文。
