HTTP狀態碼(status codes)是HTTP協議中，響應報文的起始行中包含的一種服務器用於向客戶端說明操作狀態的三位數字。例如在一個正常的GET請求完成后，服務器會向客戶端返回
HTTP/1.0 200 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: 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 響應報文時，則不應當向客戶端轉發這條響應，因為客戶端很可能不知道如何處理該報文。