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 回應封包時，則不應當向客戶端轉發這條回應，因為客戶端很可能不知道如何處理該報文。