HTTP 100 狀態(tài)碼

100(繼續(xù))請求者應當繼續(xù)提出請求。服務器返回此代碼表示已收到請求的第一部分,正在等待其余部分。

服務器根據(jù)客戶端的請求頭判斷是否接受客戶端的請求。如果接受請求則響應100狀態(tài)碼，服務端根據(jù)是否存在 Expect: 100-continue 請求頭判斷是否是Expect請求（有部分web服務器不能正確的處理Expect請求）

該狀態(tài)碼說明服務器收到了請求的初始部分，并且請客戶端繼續(xù)發(fā)送。在服務器發(fā)送了 100 Continue 狀態(tài)碼之后，如果收到客戶端的請求，則必須進行響應。

這個狀態(tài)碼實際上是對如下場景的一種優(yōu)化：客戶端有一個較大的文件需要上傳并保存，但是客戶端不知道服務器是否愿意接受這個文件，所以希望在消耗網(wǎng)絡資源進行傳輸之前，先詢問一下服務器的意愿。實際操作為客戶端發(fā)送一條特殊的請求報文，報文的頭部應包含

Expect: 100-continue

此時，如果服務器愿意接受，就會返回 100 Continue 狀態(tài)碼，反之則返回 417 Expectation Failed 狀態(tài)碼。對于客戶端而言，如果客戶端沒有發(fā)送實際請求的打算，則不應該發(fā)送包含 100 Continue Expect 的報文，因為這樣會讓服務器誤以為客戶端將要發(fā)送一個請求。

之前提到過，并不是所有的HTTP應用都支持 100 Continue 這個狀態(tài)碼（例如HTTP/1.0及之前的版本的代理或服務器）所以客戶端不應該在發(fā)送 100 Continue Expect 后一直等待服務器的響應，在一定時間后，客戶端應當直接發(fā)送計劃發(fā)送的內(nèi)容。

而對于服務器而言，也不應當把 100 Continue 當作一個嚴格的判斷方法。服務器有可能在發(fā)送回應之前就受到了客戶端發(fā)來的主體報文。此時服務器就不需要再發(fā)送 100 Continue 作為回應了。但仍然需要在接受完成后返回適當?shù)臓顟B(tài)碼。理論上，當服務器收到一個 100 Continue Expect 請求時，應當進行響應。但服務器永遠也不應向沒有發(fā)送 100 Continue Expect 請求的客戶端發(fā)送100 Continue 狀態(tài)碼作為回應。這里提到的應當進行響應是指：假設服務器不打算接收客戶端將要發(fā)送的主體報文，也應當做適當?shù)捻憫ɡ绨l(fā)送 417 Expectation Failed）而不是單純的關(guān)閉連接，這樣會對客戶端在網(wǎng)絡層面上產(chǎn)生影響。

特別的，作為代理的HTTP應用在收到帶有 100 Continue Expect 的請求時，需要進行額外的判斷。假設代理服務器明確知道報文下游的HTTP版本是兼容 HTTP/1.1 的，或者代理服務器不知道報文下游的版本，它都應當轉(zhuǎn)發(fā)這條 100 Continue Expect 請求。但是如果代理服務器明確知道報文下游的應用無法處理 100 Continue Expect 的話，則應當直接向客戶端返回 417 Expectation Failed 作為響應。而這也并非唯一的解決辦法，另一種可行的辦法是直接向客戶端返回 100 Continue ，然后向下游傳遞刪除了 100 Continue Expect 的報文。

另外，如果代理服務器決定為 HTTP/1.0 及之前的版本服務的話，那么當它收到來自服務器的 100 Continue 響應報文時，則不應當向客戶端轉(zhuǎn)發(fā)這條響應，因為客戶端很可能不知道如何處理該報文。