1xx表示請求已被接受，但需要後續處理。例如：
100（Continue）
客戶端應繼續發送請求。
101（Switching Protocols）
需要切換協議，服務器通過的Upgrade響應頭字段通知客戶端。
HTML5引入的WebSocket便是這樣工作的。首先客戶端請求websocket所在的URL，服務器返回101，然後便建立了全雙工的TCP連接。 註意Upgrade和Connection頭字段屬於Hop-by-hop字段，設置Websocket代理時需要繼續設置這兩個字段，而不是簡單地轉發請求。
2xx
請求已成功被服務器接收、理解、並接受。
200（OK）
請求已成功，請求所希望的響應頭或數據體將隨此響應返回。
201（Created）
請求已經被實現，而且有壹個新的資源已經依據請求的需要而創建。在RESTFul風格的URL設計中，通常用來響應POST請求。
202（Accepted）
服務器已接受請求，但尚未處理。比如POST壹個資源應當返回201，但由於性能原因未能立即創建，可以返回202。
204（No Content）
服務器成功處理了請求，但不需要返回任何實體內容，204響應禁止包含任何消息體。瀏覽器收到該響應後不應產生文檔視圖的變化。
205（Reset Content）
服務器成功處理了請求，但不需要返回任何實體內容，205響應禁止包含任何消息體。 與204不同的是，返回此狀態碼的響應要求請求者重置文檔視圖。比如用戶剛剛提交壹個表單，返回205後頁面重置，用戶可以立即填寫下壹個表單。
206（Partial Content）
HTTP協議允許分片傳輸。請求頭中包含Range字段時，響應需要只返回Range指定的那壹段。響應中應包含Content-Range來指示返回內容的範圍。
其他
203（Non-Authoritative Information）
207（Multi-Status）
3xx
這類狀態碼代表需要客戶端采取進壹步的操作才能完成請求。通常，這些狀態碼用來重定向， 重定向目標在本次響應的Location頭字段中指明。
301（Moved Permanently）
被請求的資源已永久移動到新位置，並且將來任何對此資源的引用都應該使用本響應返回的若幹個URI之壹。如果該請求不是GET/HEAD， 瀏覽器通常會要求用戶確認重定向。
301通常用於網站遷移時，服務器對舊的URL進行301重定向到新的URL。這樣搜索引擎可以正確地更新原有的頁面排名等信息。
302（Found）
請求的資源現在臨時從不同的URI響應請求。除非指定了Cache-Control或Expires，否則該響應不可緩存。 如果當前請求非HEAD或GET，瀏覽器需取得用戶確認，再進行重定向。
這很好理解，因為上下文發生了變化，比如POST請求不是冪等的。
303（See Other）
對應當前請求的響應可以在另壹個URI上被找到，而且客戶端應當采用GET的方式訪問那個資源。 這個方法的存在主要是為了允許由腳本激活的POST請求輸出重定向到壹個新的資源。 303響應禁止被緩存。
303會使得瀏覽器直接GET那個資源，不需用戶同意。這是Web應用中最常見的重定向方式。
304（Not Modified）
如果客戶端發送了壹個帶條件的GET請求且該請求已被允許，而文檔的內容（自上次訪問以來或者根據請求的條件）並沒有改變。 304響應禁止包含消息體。
304響應也是壹種緩存機制。Web服務器對靜態資源文件通常會采取緩存，因此在Web開發中妳可以看到大量的304響應。 服務器給出的相應中通常會包含Etag來標識資源ID，比如：
ETag: "686897696a7c876b7e"
客戶端在下次訪問同壹URL時會設置頭字段If-None-Match（這是壹個請求條件）：
If-None-Match: "686897696a7c876b7e"
服務器返回資源前會判斷Etag是否與客戶端提供的If-None-Match匹配，如果匹配則說明資源未發生改變，此時應返回304.