這個暫時響應是用來通知client它的部分請求已經被server接收。且仍未被拒絕。

client應當繼續發送請求的剩余部分。或者假設請求已經完畢，忽略這個響應。server必須在請求完畢后向client發送一個終于響應。

　　僅僅有在切換新的協議更有優點的時候才應該採取類似措施。比如，切換到新的HTTP 版本號比舊版本號更有優勢，或者切換到一個實時且同步的協議以傳送利用此類特性的資源。

在異步操作的場合下，沒有比發送這個狀態碼更方便的做法了。 　　返回202狀態碼的響應的目的是同意server接受其它過程的請求（比如某個每天僅僅運行一次的基于批處理的操作），而不必讓client一直保持與server的連接直到批處理操作所有完畢。在接受請求處理并返回202狀態碼的響應應當在返回的實體中包括一些指示處理當前狀態的信息。以及指向處理狀態監視器或狀態預測的指針，以便用戶可以預計操作是否已經完畢。

當前的信息可能是原始版本號的子集或者超集。比如，包括資源的元數據可能導致原始server知道元信息的超級。

使用此狀態碼不是必須的。并且僅僅有在響應不使用此狀態碼便會返回200 OK的情況下才是合適的。

響應可能通過實體頭部的形式。返回新的或更新后的元信息。假設存在這些頭部信息，則應當與所請求的變量相呼應。 　　假設client是瀏覽器的話，那么用戶瀏覽器應保留發送了該請求的頁面。而不產生不論什么文檔視圖上的變化，即使依照規范新的或更新后的元信息應當被應用到用戶瀏覽器活動視圖中的文檔。 　　因為204響應被禁止包括不論什么消息體，因此它始終以消息頭后的第一個空行結尾。

類似于 FlashGet 或者迅雷這類的 HTTP 下載工具都是使用此類響應實現斷點續傳或者將一個大文檔分解為多個下載段同一時候下載。 　　該請求必須包括 Range 頭信息來指示client希望得到的內容范圍。而且可能包括 If-Range 來作為請求條件。 　　響應必須包括例如以下的頭部域： 　　Content-Range 用以指示本次響應中返回的內容的范圍；假設是 Content-Type 為 multipart/byteranges 的多段下載，則每一 multipart 段中都應包括 Content-Range 域用以指示本段的內容范圍。假如響應中包括 Content-Length，那么它的數值必須匹配它返回的內容范圍的真實字節數。 　　Date 　　ETag 和/或 Content-Location，假如相同的請求本應該返回200響應。

　　Expires, Cache-Control，和/或 Vary。假如其值可能與之前相同變量的其它響應相應的值不同的話。 　　假如本響應請求使用了 If-Range 強緩存驗證，那么本次響應不應該包括其它實體頭；假如本響應的請求使用了 If-Range 弱緩存驗證，那么本次響應禁止包括其它實體頭；這避免了緩存的實體內容和更新了的實體頭信息之間的不一致。否則，本響應就應當包括全部本應該返回200響應中應當返回的全部實體頭部域。 　　假如 ETag 或 Last-Modified 頭部不能精確匹配的話，則client緩存應禁止將206響應返回的內容與之前不論什么緩存過的內容組合在一起。

　　不論什么不支持 Range 以及 Content-Range 頭的緩存都禁止緩存206響應返回的內容。

　　除非這是一個 HEAD 請求。否則該響應應當包含一個資源特性及地址的列表的實體，以便用戶或瀏覽器從中選擇最合適的重定向地址。這個實體的格式由 Content-Type 定義的格式所決定。

瀏覽器可能依據響應的格式以及瀏覽器自身能力，自己主動作出最合適的選擇。

當然，RFC 2616規范并沒有規定這種自己主動選擇該怎樣進行。

　　假設server本身已經有了首選的回饋選擇。那么在 Location 中應當指明這個回饋的 URI。瀏覽器可能會將這個 Location 值作為自己主動重定向的地址。此外，除非額外指定，否則這個響應也是可緩存的。

假設可能，擁有鏈接編輯功能的client應當自己主動把請求的地址改動為從server反饋回來的地址。除非額外指定，否則這個響應也是可緩存的。

　　新的永久性的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求。否則響應的實體中應當包括指向新的 URI 的超鏈接及簡短說明。 　　假設這不是一個 GET 或者 HEAD 請求，因此瀏覽器禁止自己主動進行重定向，除非得到用戶的確認，由于請求的條件可能因此發生變化。 　　注意：對于某些使用 HTTP/1.0 協議的瀏覽器。當它們發送的 POST 請求得到了一個301響應的話。接下來的重定向請求將會變成 GET 方式。

由于這種重定向是暫時的，client應當繼續向原有地址發送以后的請求。僅僅有在Cache-Control或Expires中進行了指定的情況下，這個響應才是可緩存的。 　　新的暫時性的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求。否則響應的實體中應當包括指向新的 URI 的超鏈接及簡短說明。

　　假設這不是一個 GET 或者 HEAD 請求。那么瀏覽器禁止自己主動進行重定向，除非得到用戶的確認，由于請求的條件可能因此發生變化。

　　注意：盡管RFC 1945和RFC 2068規范不同意client在重定向時改變請求的方法，可是非常多現存的瀏覽器將302響應視作為303響應。而且使用 GET 方式訪問在 Location 中規定的 URI，而無視原先請求的方法。

狀態碼303和307被加入了進來。用以明白server期待client進行何種反應。

當然，第二個請求（重定向）可能被緩存。

　　新的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求，否則響應的實體中應當包括指向新的 URI 的超鏈接及簡短說明。

　　注意：很多 HTTP/1.1 版曾經的 瀏覽器不能正確理解303狀態。假設須要考慮與這些瀏覽器之間的互動。302狀態碼應該能夠勝任，由于大多數的瀏覽器處理302響應時的方式恰恰就是上述規范要求client處理303響應時應當做的。

　　ETag 和/或 Content-Location，假如相同的請求本應返回200響應。

　　Expires, Cache-Control，和/或Vary，假如其值可能與之前同樣變量的其它響應相應的值不同的話。 　　假如本響應請求使用了強緩存驗證，那么本次響應不應該包括其它實體頭；否則（比如，某個帶條件的 GET 請求使用了弱緩存驗證），本次響應禁止包括其它實體頭；這避免了緩存了的實體內容和更新了的實體頭信息之間的不一致。 　　假如某個304響應指明了當前某個實體沒有緩存，那么緩存系統必須忽視這個響應。而且反復發送不包括限制條件的請求。

　　假如接收到一個要求更新某個緩存條目的304響應，那么緩存系統必須更新整個條目以反映全部在響應中被更新的字段的值。

Location 域中將給出指定的代理所在的 URI 信息，接收者須要反復發送一個單獨的請求，通過這個代理才干訪問對應資源。僅僅有原始server才干建立305響應。 　　注意：RFC 2068中沒有明白305響應是為了重定向一個單獨的請求，并且僅僅能被原始server建立。忽視這些限制可能導致嚴重的安全后果。

由于這種重定向是暫時的，client應當繼續向原有地址發送以后的請求。僅僅有在Cache-Control或Expires中進行了指定的情況下，這個響應才是可緩存的。 　　新的暫時性的URI 應當在響應的 Location 域中返回。

除非這是一個HEAD 請求，否則響應的實體中應當包括指向新的URI 的超鏈接及簡短說明。

由于部分瀏覽器不能識別307響應。因此須要加入上述必要信息以便用戶可以理解并向新的 URI 發出訪問請求。 　　假設這不是一個GET 或者 HEAD 請求，那么瀏覽器禁止自己主動進行重定向，除非得到用戶的確認。由于請求的條件可能因此發生變化。

當然server也可以返回一個404響應，假如它不希望讓client獲得不論什么信息。

假如server知道情況的話，應當使用410狀態碼來告知舊資源由于某些內部的配置機制問題，已經永久的不可用。并且沒有不論什么可以跳轉的地址。404這個狀態碼被廣泛應用于當server不想揭示究竟為何請求被拒絕或者沒有其它適合的響應可用的情況下。

　　除非這是一個 HEAD 請求，否則該響應就應當返回一個包括能夠讓用戶或者瀏覽器從中選擇最合適的實體特性以及地址列表的實體。實體的格式由 Content-Type 頭中定義的媒體類型決定。瀏覽器能夠依據格式及自身能力自行作出最佳選擇。可是。規范中并未定義不論什么作出此類自己主動選擇的標準。

參見RFC 2617。

這個代碼僅僅同意用在這種情況下才干被使用：用戶被覺得可以解決沖突。而且會又一次提交新的請求。該響應應當包括足夠的信息以便用戶發現沖突的源頭。

　　沖突通常發生于對 PUT 請求的處理中。比如，在採用版本號檢查的環境下。某次 PUT 提交的對特定資源的改動請求所附帶的版本號信息與之前的某個（第三方）請求向沖突，那么此時server就應該返回一個409錯誤。告知用戶請求無法完畢。此時，響應實體中非常可能會包括兩個沖突版本號之間的差異比較，以便用戶又一次提交歸并以后的新版本號。

這種狀況應當被覺得是永久性的。

假設可能，擁有鏈接編輯功能的client應當在獲得用戶許可后刪除全部指向這個地址的引用。

假設server不知道或者無法確定這個狀況是否是永久的，那么就應該使用404狀態碼。除非額外說明，否則這個響應是可緩存的。 　　410響應的目的主要是幫助站點管理員維護站點。通知用戶該資源已經不再可用。并且server擁有者希望全部指向這個資源的遠端連接也被刪除。這類事件在限時、增值服務中非常普遍。

相同。410響應也被用于通知client在當前server站點上，原本屬于某個個人的資源已經不再可用。當然，是否須要把全部永久不可用的資源標記為'410 Gone'，以及是否須要保持此標記多長時間，全然取決于server擁有者。

　　假設這個狀況是暫時的，server應當返回一個 Retry-After 的響應頭，以告知client能夠在多少時間以后又一次嘗試。

沒有此類漏洞的server，應當返回414狀態碼。

　　假如 Range 使用的是字節范圍，那么這樣的情況就是指請求指定的全部數據范圍的首字節位置都超過了當前資源的長度。server也應當在返回416狀態碼的同一時候。包括一個 Content-Range 實體頭，用以指明當前資源的長度。這個響應也被禁止使用 multipart/byteranges 作為其 Content-Type。

通常，這里的IP地址指的是從server上看到的client地址（比方用戶的網關或者代理server地址）。在這樣的情況下，連接數的計算可能涉及到不止一個終端用戶。

（RFC 4918 WebDAV）423 Locked 　　當前資源被鎖定。

（RFC 4918 WebDAV）

（RFC 4918 WebDAV）

一般來說，這個問題都會在server的程序碼出錯時出現。

當server無法識別請求的方法，而且無法支持其對不論什么資源的請求。

假設沒有給出這個 Retry-After 信息，那么client應當以處理500響應的方式處理它。 　　注意：503狀態碼的存在并不意味著server在過載的時候必須使用它。某些server僅僅只是是希望拒絕client的連接。

這暗示著server不能或不愿使用與client同樣的版本號。

響應中應當包括一個描寫敘述了為何版本號不被支持以及server支持哪些協議的實體。