消息：
這一類型的狀態碼，表明請求已被接受，須要繼續處理。這類響應是臨時響應，只包含狀態行和某些可選的響應頭信息，並以空行結束。因爲 HTTP/1.0 協議中沒有定義任何 1xx 狀態碼，因此除非在某些試驗條件下，服務器禁止向此類客戶端發送 1xx 響應。html
100 Continue：初始的請求已經接受，客戶應當繼續發送請求的其他部分。 web
101 Switching Protocols：服務器將聽從客戶的請求轉換到另一種協議。 數據庫
102 Processing 由webDAV（RFC 2518）擴展的狀態碼，表明處理將被繼續執行。瀏覽器
成功：
這一類型的狀態碼，表明請求已成功被服務器接收、理解並接收服務器
200 OK：一切正常，對GET和POST請求的應答文檔跟在後面。若是不用SetStatus設置狀態代碼，Servlet默認使用202狀態代碼。 併發
201 Created 服務器已經建立了文檔，Location頭給出了它的URL。 ui
202 Accepted：已經接受請求，但處理還沒有完成。 url
203 Non-Authoritative Information：文檔已經正常地返回，但一些應答頭可能不正確，由於使用的是文檔的拷貝。 代理
204 No Content：沒有新文檔，瀏覽器應該繼續顯示原來的文檔。若是用戶按期地刷新頁面，而Servlet能夠肯定用戶文檔足夠新，這個狀態代碼是頗有用的。 orm
205 Reset Content：沒有新的內容，但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容。
206 Partial Content：客戶發送了一個帶有Range頭的GET請求，服務器完成了它。
207 Multi-Status：由webDAV（RFC2518）擴展的狀態碼，表明以後的消息體將是一個xml消息，而且可能依照以前子請求數量的不一樣，包含一系列獨立的響應代碼。
重定向：
這類狀態碼錶明須要客戶端採起進一步的操做才能完成請求。一般，這些狀態碼用來重定向，後續的請求地址（重定向目標）在本次響應的 Location 域中指明。
當且僅當後續的請求所使用的方法是 GET 或者 HEAD 時，用戶瀏覽器才能夠在沒有用戶介入的狀況下自動提交所須要的後續請求。客戶端應當自動監測無限循環重定向（例如：A->A，或者A->B->C->A），由於這會致使服務器和客戶端大量沒必要要的資源消耗。按照 HTTP/1.0 版規範的建議，瀏覽器不該自動訪問超過5次的重定向。
300 Multiple Choices：客戶請求的文檔能夠在多個位置找到，這些位置已經在返回的文檔內列出。若是服務器要提出優先選擇，則應該在Location應答頭指明。
301 Moved Permanently：客戶請求的文檔在其餘地方，新的URL在Location頭中給出，瀏覽器應該自動地訪問新的URL。
302 Found：相似於301，但新的URL應該被視爲臨時性的替代，而不是永久性的。注意，在HTTP1.0中對應的狀態信息是「MovedTemporatily」，而HttpServletResponse中相應的常量是SC_MOVED_TEMPORARILY，而不是SC_FOUND。出現該狀態代碼時，瀏覽器可以自動訪問新的URL，所以它是一個頗有用的狀態代碼。爲此，Servlet提供了一個專用的方法，即sendRedirect。使用response.sendRedirect（url）比使用response.setStatus（response.SC_MOVED_TEMPORARILY）和response.setHeader（"Location"，url）更好。注意這個狀態代碼有時候能夠和301替換使用。
303 See Other：相似於301/302，不一樣之處在於，若是原來的請求是POST，Location頭指定的重定向目標文檔應該經過GET提取。
304 Not Modified：客戶端有緩衝的文檔併發出了一個條件性的請求（通常是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務器告訴客戶，原來緩衝的文檔還能夠繼續使用。
305 Use Proxy：客戶請求的文檔應該經過Location頭所指明的代理服務器提取。
307 Temporary Redirect：和302（Found）相同。許多瀏覽器會錯誤地響應302應答進行重定向，即便原來的請求是POST，即便它實際上只能在POST請求的應答是303時才能重定向。因爲這個緣由，HTTP 1.1新增了307，以便更加清除地區分幾個狀態代碼：當出現303應答時，瀏覽器能夠跟隨重定向的GET和POST請求若是是307應答，則瀏覽器只能跟隨對GET請求的重定向。注意：HttpServletResponse中沒有爲該狀態代碼提供相應的常量。
請求錯誤：
這類的狀態碼錶明瞭客戶端看起來可能發生了錯誤，妨礙了服務器的處理。除非響應的是一個 HEAD 請求，不然服務器就應該返回一個解釋當前錯誤情況的實體，以及這是臨時的仍是永久性的情況。這些狀態碼適用於任何請求方法。瀏覽器應當向用戶顯示任何包含在此類錯誤響應中的實體內容。
若是錯誤發生時客戶端正在傳送數據，那麼使用TCP的服務器實現應當仔細確保在關閉客戶端與服務器之間的鏈接以前，客戶端已經收到了包含錯誤信息的數據包。若是客戶端在收到錯誤信息後繼續向服務器發送數據，服務器的TCP棧將向客戶端發送一個重置數據包，以清除該客戶端全部還未識別的輸入緩衝，以避免這些數據被服務器上的應用程序讀取並干擾後者
400 Bad Request：請求出現語法錯誤。
401 Unauthorized：客戶試圖未經受權訪問受密碼保護的頁面。應答中會包含一個WWW-Authenticate頭，瀏覽器據此顯示用戶名字/密碼對話框，而後在填寫合適的Authorization頭後再次發出請求。
403 Forbidden：資源不可用。服務器理解客戶的請求，但拒絕處理它。一般因爲服務器上文件或目錄的權限設置致使。
404 Not Found：源沒法找到指定位置的資。這也是一個經常使用的應答，HttpServletResponse專門提供了相應的方法：sendError（message）。
405 Method Not Allowed：請求方法（GET、POST、HEAD、DELETE、PUT、TRACE等）對指定的資源不適用。
406 Not Acceptable：指定的資源已經找到，但它的MIME類型和客戶在Accpet頭中所指定的不兼容。
407 Proxy Authentication Required：相似於401，表示客戶必須先通過代理服務器的受權。
408 Request Timeout：在服務器許可的等待時間內，客戶一直沒有發出任何請求。客戶能夠在之後重複同一請求。
409 Conflict：一般和PUT請求有關。因爲請求和資源的當前狀態相沖突，所以請求不能成功。
410 Gone：所請求的文檔已經再也不可用，並且服務器不知道應該重定向到哪個地址。它和404的不一樣在於，返回407表示文檔永久地離開了指定的位置，而404表示因爲未知的緣由文檔不可用。
411 Length Required：服務器不能處理請求，除非客戶發送一個Content-Length頭。
412 Precondition Failed：請求頭中指定的一些前提條件失敗。
413 Request Entity Too Large：目標文檔的大小超過服務器當前願意處理的大小。若是服務器認爲本身可以稍後再處理該請求，則應該提供一個Retry-After頭。
414 Request URI Too Long：URI太長。
415 Unsupported Media Type:
對於當前請求的方法和所請求的資源，請求中提交的實體並非服務器中所支持的格式，
所以請求被拒絕。
416 Requested Range Not Satisfiable：服務器不能知足客戶在請求中指定的Range頭。
417 Expectation Failed:
在請求頭 Expect 中指定的預期內容沒法被服務器知足，或者這個服務器是一個代理服務器，它有明顯的證據證實在當前路由的下一個節點上，Expect 的內容沒法被知足。
421 too many connections
There are too many connections from your internet address
從當前客戶端所在的IP地址到服務器的鏈接數超過了服務器許可的最大範圍。一般，這裏的IP地址指的是從服務器上看到的客戶端地址（好比用戶的網關或者代理服務器地址）。在這種狀況下，鏈接數的計算可能涉及到不止一個終端用戶。
422 Unprocessable Entity
請求格式正確，可是因爲含有語義錯誤，沒法響應。（RFC 4918 WebDAV）
423 Locked
當前資源被鎖定。（RFC 4918 WebDAV）
424 Failed Dependency
因爲以前的某個請求發生的錯誤，致使當前請求失敗，例如 PROPPATCH。（RFC 4918 WebDAV）
425 Unordered Collection
在WebDav Advanced Collections 草案中定義，可是未出如今《WebDAV 順序集協議》（RFC 3658）中。
426 Upgrade Required
客戶端應當切換到TLS/1.0。（RFC 2817）
449 Retry With
由微軟擴展，表明請求應當在執行完適當的操做後進行重試。
451Unavailable For Legal Reasons
該請求因法律緣由不可用。（RFC 7725）
服務器錯誤：
這類狀態碼錶明瞭服務器在處理請求的過程當中有錯誤或者異常狀態發生，也有多是服務器意識到以當前的軟硬件資源沒法完成對請求的處理。除非這是一個HEAD 請求，不然服務器應當包含一個解釋當前錯誤狀態以及這個情況是臨時的仍是永久的解釋信息實體。瀏覽器應當向用戶展現任何在當前響應中被包含的實體。
這些狀態碼適用於任何響應方法。
500 Internal Server Error：服務器遇到了意料不到的狀況，不能完成客戶的請求。 （服務器端的源代碼出現錯誤時出現）
501 Not Implemented：服務器不支持實現請求所須要的功能。例如，客戶發出了一個服務器不支持的PUT請求。
502 Bad Gateway：服務器做爲網關或者代理時，爲了完成請求訪問下一個服務器，但該服務器返回了非法的應答。
503 Service Unavailable：服務器因爲維護或者負載太重未能應答。例如，Servlet可能在數據庫鏈接池已滿的狀況下返回503。服務器返回503時能夠提供一個Retry-After頭。
504 Gateway Timeout：由做爲代理或網關的服務器使用，表示不能及時地從遠程服務器得到應答。
505 HTTP Version Not Supported：服務器不支持請求中所指明的HTTP版本
506 Variant also negotiates表明服務器存在內部配置錯誤：被請求的協商元資源被配置爲在透明內容協商中使用本身，所以在一個協商處理中不是一個合適的重點。
507 insufficient storage：服務器沒法存儲完成請求所必須的內容，這個情況被認爲是臨時的
509 bandwidth limit exceeded：服務器達到帶寬限制
510 not extented ：獲取資源所須要的策略並無被知足
600 unparseable response headers：源站沒有返回響應頭部，只返回實體內容
服務器響應返回的內容（以http協議爲例）
狀態行：Http/1.0(表明http版本) 200（響應碼） ok（響應描述）
響應頭：Content-type：text/html
Date:Tue,10 Apr 2007 23:00:23 GMT
Server:Apache Tomcat/4.0-b1(Http/1.1 connector)
Connection:close
空行：
消息體：<html>
<head>
...
</head>
</html>
搞笑RFC協議（純屬娛樂搞笑） 1998年愚人節 發佈的（RFC2324-Hyper Text Coffee Pot Control Protocol（HTCPCP/1.0））超文本咖啡茶壺控制協議 錯誤代碼：418 i'm a teapot