HyperText Transfer Tansfer Protocol 超文本傳輸協議，是一種基於TCP的應用層協議，也是目前爲止最爲流行的應用層協議之一，可以說HTTP協議是萬維網的基石。歷經了0.9、HTTP/1.0、HTTP/1.1、HTTP/2幾個版本(關於HTTP協議的歷史，這裏有一片文章介紹的比較詳細)，目前流行的還是HTTP1.1這個版本，HTTP2還在推廣中，我這裏複習的也僅僅是HTTP1.1(HTTP2還不是瞭解，只知道增加了很多加密技術)。
首先需要明白HTTP是一種客戶端請求、服務器應答式的應用層傳輸協議，也就是說服務器端是不可能主動向客戶端發送數據的，如果服務器能主動向客戶端發送數據那這個世界就亂套了，同時還說明了在網絡正常的情況下請求和響應都是一一對應的。而這個請求和響應也就是後端開發人員經常看到的Request和Response。
Request|Response–>HTTP請求報文格式與響應報文格式
請求
POST /index.html HTTP/1.1
HOST: www.XXX.com
User-Agent: Mozilla/5.0(Windows NT 6.1;rv:15.0) Firefox/15.0
Username=admin&password=admin
響應
HTTP/1.1 200 OK
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
this is http response
當然上面的是最簡單的報文內容，實際上的報文內容肯定比這個複雜。下面對重要的參數詳細解釋一下。
- 請求方式Method：
（1）GET方法意思是獲取URL指定的資源，這個請求方式是最簡單的也是最常用的。使用GET 方法時，可以將請求參數和對應的值附加在 URI 後面，利用一個問號(“?”)將資源的URI和請求參數隔開，參數之間使用與符號(“&”)隔開，因此傳遞參數長度也受到了限制，而且與隱私相關的信息也直接暴露在URI中。比如/index.jsp?username=holmofy&password=123123
（2）HEAD 方法與GET用法相同，但沒有響應體，使用場合沒有GET多。比如下載前使用HEAD發送請求，通過ContentLength響應字段，來了解網絡資源的大小；或者通過LastModified響應字段來判斷本地緩存資源是否要更新。
（3）POST 方法一般用提交信息或數據，請求服務器進行處理（例如提交表單或者上傳文件）。表單使用POST相對GET來說還是比較隱祕的，而且GET的URL有長度限制，而上傳大文件就必須要使用POST了。
（4）OPTIONS方法比較少見，該方法用於請求服務器告知其支持哪些其他的功能和方法。通過OPTIONS 方法，可以詢問服務器具體支持哪些方法，或者服務器會使用什麼樣的方法來處理一些特殊資源。可以說這是一個探測性的方法，客戶端通過該方法可以在不訪問服務器上實際資源的情況下就知道處理該資源的最優方式。這個選項在跨域HTTP請求的情況出現的比較多，這裏有一片關於跨域請求的文章，其中有一張圖很好的解釋了什麼是跨域HTTP請求。
（5）PUT：用於向指定資源位置上傳其最新內容(原來沒有就上傳，有就上傳並覆蓋原來的內容)
（6）DELETE：請求服務器刪除Request-URI所標識的資源。
（7）TRACE：回顯服務器收到的請求，主要用於測試或診斷。比較少見。
（8）CONNECT：HTTP/1.1協議中預留給能夠將連接改爲管道方式的代理服務器。通常用於SSL加密服務器的鏈接（經由非加密的HTTP代理服務器）。
其中GET和POST是最常用的，其次是HEAD和OPTIONS；像PUT和DELETE屬於危險方法，服務器都會關閉；TRACE和CONNECT非常少見
Request-URI
URI 的最常見形式是統一資源定位符 (URL)，它也被稱爲 Web地址。這種網址是我們經常見到的。
http://example.org/absolute/path/resource.txt
1在請求的URI中還有一種相對路徑的，對於這種請求來說在請求頭信息中一般有Host值來指定服務器主機。比如：
GET /Test.jsp HTTP/1.1
…
Host:www.example.com
…
Http響應碼
客戶端發出HTTP請求，服務端接收後，會向客戶端發送響應信息，其中HTTP響應中的第一行中，最重要的就是HTTP的狀態碼。比如：
HTTP/1.0 200 OK
1
這個狀態碼是200，表示請求成功。HTTP協議中狀態碼有三位數字組成，第一位數字定義了響應的類別，有以下五種：
1XX：信息提示。表示請求已被服務器接受，但需要繼續處理，範圍爲100~101。
2XX：請求成功。服務器成功處理了請求。範圍爲200~206。
3XX：客戶端重定向。重定向狀態碼用於告訴客戶端瀏覽器，它們訪問的資源已被移動，並告訴客戶端新的資源位置。客戶端收到重定向會重新對新資源發起請求。範圍爲300~305。
4XX：客戶端信息錯誤。客戶端可能發送了服務器無法處理的東西，比如請求的格式錯誤，或者請求了一個不存在的資源。範圍爲400~415。
5XX：服務器出錯。客戶端發送了有效的請求，但是服務器自身出現錯誤，比如Web程序運行出錯。範圍是500~505。
常見的狀態碼務必要熟悉：
200：客戶端請求成功。
302：重定向。
404：請求資源不存在。
400：請求語法錯誤，服務器無法理解。
403：服務器收到請求，但拒絕提供服務。
500：服務器內部錯誤。
503：服務器當前不能處理客戶端請求，可能需要一段時間後才能恢復正常。
HTTP頭信息
常見請求頭
Host Host用於指定請求資源的主機名和端口號(可選，默認80)。比如：
Host: www.baidu.com
1User-Agent
用戶請求的代理軟件，包括用戶的操作系統，瀏覽器等相關屬性。比如：
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.110 Safari/537.36
2Referer
代表當前訪問的URL的上一個URL，也就是用戶是從什麼地方轉到本頁面的。比如說html中有圖片需要顯示，請求圖片是就會加上該html所在的url。
Referer: https://www.baidu.com/
3Cookie
Cookie是個非常重要的請求頭，常用來表示請求者的身份。比如有些會話信息(SesssionId)會存在Cookie中。
Cookie:BAIDUID=AAABBBCCCDDDEEEFFFGGG;BIDUPSID=ZYXWVUOPQRST;PSTM=1494145048;__cfduid=d9a1edfb6fa7a6a21167d12a07558b2551494568096;BD_CK_SAM=1;PSINO=1;BD_HOME=1;H_PS_PSSID=1421_21079_21672_20927;BD_UPN=12314353;sugstore=1
4Range
請求實體內容的一部分，多線程下載一定會用到該請求頭。
Accept
客戶端接受什麼類型的信息。類型用MIME表示。
比如：
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8
1MIME的更多信息可以查看附錄
Accept-Charset
客戶端接受什麼字符集的文本內容。常用的如UTF-8，GBK，iso-8859-1等。
Accept-Language
客戶端接受什麼語言的文本內容。
Accept-Encoding
客戶端接受什麼壓縮格式的內容。如gzip壓縮格式，deflate壓縮，sdch壓縮。
更多的請求頭信息可以查看附錄
常見響應頭
Server
服務器所使用的Web服務器名稱。攻擊者可以通過查看該頭信息，來探測Web服務器名稱。所以一般服務器端會對該頭信息進行修改。
Server: Apache/2.4.6 (CentOS)
1Set-Cookie
向客戶端設置Cookie。與Cookie請求頭相互對應。Set-Cookie頭是服務器向客戶端設置Cookie，Cookie頭是客戶端向服務器傳客戶端已經保存的Cookie信息。
Set-Cookie: __bsi=12777267876439010180_00_68_R_N_70_0303_C027_N_I_I_0; expires=Thu, 18-May-17 16:32:52 GMT; domain=www.baidu.com; path=/
1Last-Modified
服務器通過該頭信息告訴瀏覽器，資源最後的修改時間。從而讓客戶端及時地更新緩存內容。
Location
服務器通過該頭信息告訴瀏覽器去訪問那個頁面，瀏覽器接收到這樣的響應信息後，通常會立刻訪問Location頭所指向的頁面。這個頭通常配合302重定向狀態碼使用。
Refresh
服務器通過Refresh頭信息讓瀏覽器定時刷新。
比如下面這個頭信息定時三秒後，刷新到百度頁面。
Refresh: 3;url=“http://www.baidu.com”
1Cache-Control
指定客戶端對頁面的緩存策略。
比如下面的頭信息表示指定客戶端不緩存該頁面內容。
Cache-Control: no-cache
1響應實體頭信息
Content-Type
響應實體的內容類型。
Content-Type: text/html;charset=utf-8
1Content-Encoding
響應實體的編碼方式
Content-Encoding: gzip
1Content-Length
常用響應頭信息列表
| 響應頭 | 說明 |
|---|---|
| Access-Control-Allow-Origin | 指定哪些網站可以跨域源資源共享Access-Control-Allow-Origin:* |
| Accept-Patch | 指定服務器所支持的文檔補丁格式 Accept-Patch:text/example;charset=utf-8 |
| Accept-Ranges | 服務器所支持的內容範圍 Accept-Ranges:bytes |
| Age | 響應對象在代理緩存中存在的時間，以秒爲單位 Age:12 |
| Allow | 對於特定資源的有效動作; Allow:GET,HEAD |
| Cache-Control | 通知從服務器到客戶端內的所有緩存機制，表示它們是否可以緩存這個對象及緩存有效時間。其單位爲秒 Cache-Control:max-age=3600 |
| Connection | 針對該連接所預期的選項 Connection:close |
| Content-Disposition | 對已知MIME類型資源的描述，瀏覽器可以根據這個響應頭決定是對返回資源的動作，如：將其下載或是打開。 Content-Disposition:attachment;filename=”fname.ext” |
| Content-Encoding | 響應資源所使用的編碼類型。 Content-Encoding:gzip |
| Content-Language | Content-Language:zh-cn |
| Content-Length | 響應消息體的長度，用8進制字節表示 Content-Length:348 |
| Content-Location | 所返回的數據的一個候選位置 Content-Location:/index.htm |
| Content-MD5 | 響應內容的二進制MD5散列值，以Base64方式編碼 Content-MD5:IDK0iSsgSW50ZWd0DiJUi== |
| Content-Range | 如果是響應部分消息，表示屬於完整消息的哪個部分 Content-Range:bytes21010-47021/47022 |
| Content-Type | 當前內容的MIME類型 Content-Type:text/html;charset=utf-8 |
| Date | 此條消息被髮送時的日期和時間 |
| Accept | 指定客戶端能夠接收的內容類型 Accept: text/plain, text/html |
| Accept-Charset | 瀏覽器可以接受的字符編碼集。 Accept-Charset: iso-8859-5 |
| Accept-Encoding | 指定瀏覽器可以支持的web服務器返回內容壓縮編碼類型。 Accept-Encoding: compress, gzip |
| Accept-Language | 瀏覽器可接受的語言 Accept-Language: en,zh |
| Accept-Ranges | 以請求網頁實體的一個或者多個子範圍字段 Accept-Ranges: bytes |
| Authorization | HTTP授權的授權證書 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Cache-Control | 指定請求和響應遵循的緩存機制 Cache-Control: no-cache |
| Connection | 表示是否需要持久連接。（HTTP 1.1默認進行持久連接） Connection: close |
| Cookie | HTTP請求發送時，會把保存在該請求域名下的所有cookie值一起發送給web服務器。 Cookie: $Version=1; Skin=new; |
| Content-Length | 請求的內容長度 Content-Length: 348 |
| Content-Type | 請求的與實體對應的MIME信息 Content-Type: application/x-www-form-urlencoded |
| Date | 請求發送的日期和時間 Date: Tue, 15 Nov 2010 08:12:31 GMT |
| Expect | 請求的特定的服務器行爲 Expect: 100-continue |
| From | 發出請求的用戶的Email From: [email protected] |
| Host | 指定請求的服務器的域名和端口號 Host: www.zcmhi.com |
Response響應碼列表
| 狀態碼 | 含義 |
|---|---|
| 100 | 客戶端應當繼續發送請求。這個臨時響應是用來通知客戶端它的部分請求已經被服務器接收，且仍未被拒絕。客戶端應當繼續發送請求的剩餘部分，或者如果請求已經完成，忽略這個響應。服務器必須在請求完成後向客戶端發送一個最終響應。 |
| 101 | 客戶端採用不同的協議來完成這個請求。在發送完這個響應最後的空行後，服務器將會切換到在Upgrade 消息頭中定義的那些協議。 只有在切換新的協議更有好處的時候才應該採取類似措施。例如，切換到新的HTTP 版本比舊版本更有優勢，或者切換到一個實時且同步的協議以傳送利用此類特性的資源。 |
| 102 | 由WebDAV（RFC 2518）擴展的狀態碼，代表處理將被繼續執行。 |
| 200 | 請求已成功，請求所希望的響應頭或數據體將隨此響應返回。 |
| 201 | 請求已經被實現，而且有一個新的資源已經依據請求的需要而建立，且其 URI 已經隨Location 頭信息返回。假如需要的資源無法及時建立的話，應當返回 ‘202 Accepted’。 |
| 202 | 服務器已接受請求，但尚未處理。正如它可能被拒絕一樣，最終該請求可能會也可能不會被執行。在異步操作的場合下，沒有比發送這個狀態碼更方便的做法了。 返回202狀態碼的響應的目的是允許服務器接受其他過程的請求（例如某個每天只執行一次的基於批處理的操作），而不必讓客戶端一直保持與服務器的連接直到批處理操作全部完成。在接受請求處理並返回202狀態碼的響應應當在返回的實體中包含一些指示處理當前狀態的信息，以及指向處理狀態監視器或狀態預測的指針，以便用戶能夠估計操作是否已經完成。 |
| 203 | 服務器已成功處理了請求，但返回的實體頭部元信息不是在原始服務器上有效的確定集合，而是來自本地或者第三方的拷貝。當前的信息可能是原始版本的子集或者超集。例如，包含資源的元數據可能導致原始服務器知道元信息的超級。使用此狀態碼不是必須的，而且只有在響應不使用此狀態碼便會返回200 OK的情況下才是合適的。 |
| 204 | 服務器成功處理了請求，但不需要返回任何實體內容，並且希望返回更新了的元信息。響應可能通過實體頭部的形式，返回新的或更新後的元信息。如果存在這些頭部信息，則應當與所請求的變量相呼應。 如果客戶端是瀏覽器的話，那麼用戶瀏覽器應保留髮送了該請求的頁面，而不產生任何文檔視圖上的變化，即使按照規範新的或更新後的元信息應當被應用到用戶瀏覽器活動視圖中的文檔。 由於204響應被禁止包含任何消息體，因此它始終以消息頭後的第一個空行結尾。 |
| 205 | 服務器成功處理了請求，且沒有返回任何內容。但是與204響應不同，返回此狀態碼的響應要求請求者重置文檔視圖。該響應主要是被用於接受用戶輸入後，立即重置表單，以便用戶能夠輕鬆地開始另一次輸入。 與204響應一樣，該響應也被禁止包含任何消息體，且以消息頭後的第一個空行結束。 |
| 206 | 服務器已經成功處理了部分 GET 請求。類似於 FlashGet 或者迅雷這類的 HTTP 下載工具都是使用此類響應實現斷點續傳或者將一個大文檔分解爲多個下載段同時下載。 該請求必須包含 Range 頭信息來指示客戶端希望得到的內容範圍，並且可能包含 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 頭部不能精確匹配的話，則客戶端緩存應禁止將206響應返回的內容與之前任何緩存過的內容組合在一起。 任何不支持 Range 以及 Content-Range 頭的緩存都禁止緩存206響應返回的內容。 |
| 207 | 由WebDAV(RFC 2518)擴展的狀態碼，代表之後的消息體將是一個XML消息，並且可能依照之前子請求數量的不同，包含一系列獨立的響應代碼。 |
| 300 | 被請求的資源有一系列可供選擇的回饋信息，每個都有自己特定的地址和瀏覽器驅動的商議信息。用戶或瀏覽器能夠自行選擇一個首選的地址進行重定向。 除非這是一個 HEAD 請求，否則該響應應當包括一個資源特性及地址的列表的實體，以便用戶或瀏覽器從中選擇最合適的重定向地址。這個實體的格式由 Content-Type 定義的格式所決定。瀏覽器可能根據響應的格式以及瀏覽器自身能力，自動作出最合適的選擇。當然，RFC 2616規範並沒有規定這樣的自動選擇該如何進行。 如果服務器本身已經有了首選的回饋選擇，那麼在 Location 中應當指明這個回饋的 URI；瀏覽器可能會將這個 Location 值作爲自動重定向的地址。此外，除非額外指定，否則這個響應也是可緩存的。 |
| 301 | 被請求的資源已永久移動到新位置，並且將來任何對此資源的引用都應該使用本響應返回的若干個 URI 之一。如果可能，擁有鏈接編輯功能的客戶端應當自動把請求的地址修改爲從服務器反饋回來的地址。除非額外指定，否則這個響應也是可緩存的。 新的永久性的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求，否則響應的實體中應當包含指向新的 URI 的超鏈接及簡短說明。 如果這不是一個 GET 或者 HEAD 請求，因此瀏覽器禁止自動進行重定向，除非得到用戶的確認，因爲請求的條件可能因此發生變化。 注意：對於某些使用 HTTP/1.0 協議的瀏覽器，當它們發送的 POST 請求得到了一個301響應的話，接下來的重定向請求將會變成 GET 方式。 |
| 302 | 請求的資源現在臨時從不同的 URI 響應請求。由於這樣的重定向是臨時的，客戶端應當繼續向原有地址發送以後的請求。只有在Cache-Control或Expires中進行了指定的情況下，這個響應纔是可緩存的。 新的臨時性的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求，否則響應的實體中應當包含指向新的 URI 的超鏈接及簡短說明。 如果這不是一個 GET 或者 HEAD 請求，那麼瀏覽器禁止自動進行重定向，除非得到用戶的確認，因爲請求的條件可能因此發生變化。 注意：雖然RFC 1945和RFC 2068規範不允許客戶端在重定向時改變請求的方法，但是很多現存的瀏覽器將302響應視作爲303響應，並且使用 GET 方式訪問在 Location 中規定的 URI，而無視原先請求的方法。狀態碼303和307被添加了進來，用以明確服務器期待客戶端進行何種反應。 |
| 303 | 對應當前請求的響應可以在另一個 URI 上被找到，而且客戶端應當採用 GET 的方式訪問那個資源。這個方法的存在主要是爲了允許由腳本激活的POST請求輸出重定向到一個新的資源。這個新的 URI 不是原始資源的替代引用。同時，303響應禁止被緩存。當然，第二個請求（重定向）可能被緩存。 新的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求，否則響應的實體中應當包含指向新的 URI 的超鏈接及簡短說明。 注意：許多 HTTP/1.1 版以前的 瀏覽器不能正確理解303狀態。如果需要考慮與這些瀏覽器之間的互動，302狀態碼應該可以勝任，因爲大多數的瀏覽器處理302響應時的方式恰恰就是上述規範要求客戶端處理303響應時應當做的。 |
| 304 | 如果客戶端發送了一個帶條件的 GET 請求且該請求已被允許，而文檔的內容（自上次訪問以來或者根據請求的條件）並沒有改變，則服務器應當返回這個狀態碼。304響應禁止包含消息體，因此始終以消息頭後的第一個空行結尾。 該響應必須包含以下的頭信息： Date，除非這個服務器沒有時鐘。假如沒有時鐘的服務器也遵守這些規則，那麼代理服務器以及客戶端可以自行將 Date 字段添加到接收到的響應頭中去（正如RFC 2068中規定的一樣），緩存機制將會正常工作。 ETag 和/或 Content-Location，假如同樣的請求本應返回200響應。 Expires, Cache-Control，和/或Vary，假如其值可能與之前相同變量的其他響應對應的值不同的話。 假如本響應請求使用了強緩存驗證，那麼本次響應不應該包含其他實體頭；否則（例如，某個帶條件的 GET 請求使用了弱緩存驗證），本次響應禁止包含其他實體頭；這避免了緩存了的實體內容和更新了的實體頭信息之間的不一致。 假如某個304響應指明瞭當前某個實體沒有緩存，那麼緩存系統必須忽視這個響應，並且重複發送不包含限制條件的請求。 假如接收到一個要求更新某個緩存條目的304響應，那麼緩存系統必須更新整個條目以反映所有在響應中被更新的字段的值。 |
| 305 | 被請求的資源必須通過指定的代理才能被訪問。Location 域中將給出指定的代理所在的 URI 信息，接收者需要重複發送一個單獨的請求，通過這個代理才能訪問相應資源。只有原始服務器才能建立305響應。 注意：RFC 2068中沒有明確305響應是爲了重定向一個單獨的請求，而且只能被原始服務器建立。忽視這些限制可能導致嚴重的安全後果。 |
| 306 | 在最新版的規範中，306狀態碼已經不再被使用。 |
| 307 | 請求的資源現在臨時從不同的URI 響應請求。由於這樣的重定向是臨時的，客戶端應當繼續向原有地址發送以後的請求。只有在Cache-Control或Expires中進行了指定的情況下，這個響應纔是可緩存的。 新的臨時性的URI 應當在響應的 Location 域中返回。除非這是一個HEAD 請求，否則響應的實體中應當包含指向新的URI 的超鏈接及簡短說明。因爲部分瀏覽器不能識別307響應，因此需要添加上述必要信息以便用戶能夠理解並向新的 URI 發出訪問請求。 如果這不是一個GET 或者 HEAD 請求，那麼瀏覽器禁止自動進行重定向，除非得到用戶的確認，因爲請求的條件可能因此發生變化。 |
| 400 | 1、語義有誤，當前請求無法被服務器理解。除非進行修改，否則客戶端不應該重複提交這個請求。 2、請求參數有誤。 |
| 401 | 當前請求需要用戶驗證。該響應必須包含一個適用於被請求資源的 WWW-Authenticate 信息頭用以詢問用戶信息。客戶端可以重複提交一個包含恰當的 Authorization 頭信息的請求。如果當前請求已經包含了 Authorization 證書，那麼401響應代表着服務器驗證已經拒絕了那些證書。如果401響應包含了與前一個響應相同的身份驗證詢問，且瀏覽器已經至少嘗試了一次驗證，那麼瀏覽器應當向用戶展示響應中包含的實體信息，因爲這個實體信息中可能包含了相關診斷信息。參見RFC 2617。 |
| 402 | 該狀態碼是爲了將來可能的需求而預留的。 |
| 403 | 服務器已經理解請求，但是拒絕執行它。與401響應不同的是，身份驗證並不能提供任何幫助，而且這個請求也不應該被重複提交。如果這不是一個 HEAD 請求，而且服務器希望能夠講清楚爲何請求不能被執行，那麼就應該在實體內描述拒絕的原因。當然服務器也可以返回一個404響應，假如它不希望讓客戶端獲得任何信息。 |
| 404 | 請求失敗，請求所希望得到的資源未被在服務器上發現。沒有信息能夠告訴用戶這個狀況到底是暫時的還是永久的。假如服務器知道情況的話，應當使用410狀態碼來告知舊資源因爲某些內部的配置機制問題，已經永久的不可用，而且沒有任何可以跳轉的地址。404這個狀態碼被廣泛應用於當服務器不想揭示到底爲何請求被拒絕或者沒有其他適合的響應可用的情況下。 |
| 405 | 請求行中指定的請求方法不能被用於請求相應的資源。該響應必須返回一個Allow 頭信息用以表示出當前資源能夠接受的請求方法的列表。 鑑於 PUT，DELETE 方法會對服務器上的資源進行寫操作，因而絕大部分的網頁服務器都不支持或者在默認配置下不允許上述請求方法，對於此類請求均會返回405錯誤。 |
| 406 | 請求的資源的內容特性無法滿足請求頭中的條件，因而無法生成響應實體。 除非這是一個 HEAD 請求，否則該響應就應當返回一個包含可以讓用戶或者瀏覽器從中選擇最合適的實體特性以及地址列表的實體。實體的格式由 Content-Type 頭中定義的媒體類型決定。瀏覽器可以根據格式及自身能力自行作出最佳選擇。但是，規範中並沒有定義任何作出此類自動選擇的標準。 |
| 407 | 與401響應類似，只不過客戶端必須在代理服務器上進行身份驗證。代理服務器必須返回一個 Proxy-Authenticate 用以進行身份詢問。客戶端可以返回一個 Proxy-Authorization 信息頭用以驗證。參見RFC 2617。 |
| 408 | 請求超時。客戶端沒有在服務器預備等待的時間內完成一個請求的發送。客戶端可以隨時再次提交這一請求而無需進行任何更改。 |
| 409 | 由於和被請求的資源的當前狀態之間存在衝突，請求無法完成。這個代碼只允許用在這樣的情況下才能被使用：用戶被認爲能夠解決衝突，並且會重新提交新的請求。該響應應當包含足夠的信息以便用戶發現衝突的源頭。 衝突通常發生於對 PUT 請求的處理中。例如，在採用版本檢查的環境下，某次 PUT 提交的對特定資源的修改請求所附帶的版本信息與之前的某個（第三方）請求向衝突，那麼此時服務器就應該返回一個409錯誤，告知用戶請求無法完成。此時，響應實體中很可能會包含兩個衝突版本之間的差異比較，以便用戶重新提交歸併以後的新版本。 |
| 410 | 被請求的資源在服務器上已經不再可用，而且沒有任何已知的轉發地址。這樣的狀況應當被認爲是永久性的。如果可能，擁有鏈接編輯功能的客戶端應當在獲得用戶許可後刪除所有指向這個地址的引用。如果服務器不知道或者無法確定這個狀況是否是永久的，那麼就應該使用404狀態碼。除非額外說明，否則這個響應是可緩存的。 410響應的目的主要是幫助網站管理員維護網站，通知用戶該資源已經不再可用，並且服務器擁有者希望所有指向這個資源的遠端連接也被刪除。這類事件在限時、增值服務中很普遍。同樣，410響應也被用於通知客戶端在當前服務器站點上，原本屬於某個個人的資源已經不再可用。當然，是否需要把所有永久不可用的資源標記爲’410 Gone’，以及是否需要保持此標記多長時間，完全取決於服務器擁有者。 |
| 411 | 服務器拒絕在沒有定義 Content-Length 頭的情況下接受請求。在添加了表明請求消息體長度的有效 Content-Length 頭之後，客戶端可以再次提交該請求。 |
| 412 | 服務器在驗證在請求的頭字段中給出先決條件時，沒能滿足其中的一個或多個。這個狀態碼允許客戶端在獲取資源時在請求的元信息（請求頭字段數據）中設置先決條件，以此避免該請求方法被應用到其希望的內容以外的資源上。 |
| 413 | 服務器拒絕處理當前請求，因爲該請求提交的實體數據大小超過了服務器願意或者能夠處理的範圍。此種情況下，服務器可以關閉連接以免客戶端繼續發送此請求。 如果這個狀況是臨時的，服務器應當返回一個 Retry-After 的響應頭，以告知客戶端可以在多少時間以後重新嘗試。 |
| 414 | 請求的URI 長度超過了服務器能夠解釋的長度，因此服務器拒絕對該請求提供服務。這比較少見，通常的情況包括： 本應使用POST方法的表單提交變成了GET方法，導致查詢字符串（Query String）過長。 重定向URI “黑洞”，例如每次重定向把舊的 URI 作爲新的 URI 的一部分，導致在若干次重定向後 URI 超長。 客戶端正在嘗試利用某些服務器中存在的安全漏洞攻擊服務器。這類服務器使用固定長度的緩衝讀取或操作請求的 URI，當 GET 後的參數超過某個數值後，可能會產生緩衝區溢出，導致任意代碼被執行[1]。沒有此類漏洞的服務器，應當返回414狀態碼。 |
| 415 | 對於當前請求的方法和所請求的資源，請求中提交的實體並不是服務器中所支持的格式，因此請求被拒絕。 |
| 416 | 如果請求中包含了 Range 請求頭，並且 Range 中指定的任何數據範圍都與當前資源的可用範圍不重合，同時請求中又沒有定義 If-Range 請求頭，那麼服務器就應當返回416狀態碼。 假如 Range 使用的是字節範圍，那麼這種情況就是指請求指定的所有數據範圍的首字節位置都超過了當前資源的長度。服務器也應當在返回416狀態碼的同時，包含一個 Content-Range 實體頭，用以指明當前資源的長度。這個響應也被禁止使用 multipart/byteranges 作爲其 Content-Type。 |
| 417 | 在請求頭 Expect 中指定的預期內容無法被服務器滿足，或者這個服務器是一個代理服務器，它有明顯的證據證明在當前路由的下一個節點上，Expect 的內容無法被滿足。 |
| 421 | 從當前客戶端所在的IP地址到服務器的連接數超過了服務器許可的最大範圍。通常，這裏的IP地址指的是從服務器上看到的客戶端地址（比如用戶的網關或者代理服務器地址）。在這種情況下，連接數的計算可能涉及到不止一個終端用戶。 |
| 500 | 服務器遇到了一個未曾預料的狀況，導致了它無法完成對請求的處理。一般來說，這個問題都會在服務器的程序碼出錯時出現。 |
501 服務器不支持當前請求所需要的某個功能。當服務器無法識別請求的方法，並且無法支持其對任何資源的請求。
502 |作爲網關或者代理工作的服務器嘗試執行請求時，從上游服務器接收到無效的響應。
503 |由於臨時的服務器維護或者過載，服務器當前無法處理請求。這個狀況是臨時的，並且將在一段時間以後恢復。如果能夠預計延遲時間，那麼響應中可以包含一個 Retry-After 頭用以標明這個延遲時間。如果沒有給出這個 Retry-After 信息，那麼客戶端應當以處理500響應的方式處理它。 注意：503狀態碼的存在並不意味着服務器在過載的時候必須使用它。某些服務器只不過是希望拒絕客戶端的連接。
504 |作爲網關或者代理工作的服務器嘗試執行請求時，未能及時從上游服務器（URI標識出的服務器，例如HTTP、FTP、LDAP）或者輔助服務器（例如DNS）收到響應。 注意：某些代理服務器在DNS查詢超時時會返回400或者500錯誤
505 |服務器不支持，或者拒絕支持在請求中使用的 HTTP 版本。這暗示着服務器不能或不願使用與客戶端相同的版本。響應中應當包含一個描述了爲何版本不被支持以及服務器支持哪些協議的實體。