首頁 > 文章 > web前端 > 前端開發者必須知道的http協定相關知識

前端開發者必須知道的http協定相關知識

little bottle轉載: 2019-04-10 09:26:292772瀏覽

http（超文本傳輸協定）是一個基於請求與回應模式的、無狀態的、應用層的協議，常基於TCP的連接方式。本文講述的是前端開發者必須知道的http協定相關知識，做想做前端和正在做前端的小夥伴一定要知道哦。

1.概念

http（超文字傳輸協定）是基於請求與回應模式的、無狀態的、應用層的協議，常基於TCP的連接方式，HTTP1.1版本給出一種持續連接的機制，絕大多數的Web開發，都是建構在HTTP協定之上的Web應用。

2.發展

0.9版本（只支援get）—1.0—1.1—2.0（開發中）

0.9版本只能算是試用版，不做介紹。主要講講1.0和1.1的區別。

2.1 持續連接與非持續連接

1.0版本支援非持久連接，也就是說經過tcp協定（http是基於TCP的應用層協定）三次握手建立連接後，服務端只能發送一個對象給瀏覽器，然後鏈接即斷開，如果網頁中包含其他內聯對象，如圖片，js文件，css文件等，則需要建立多次鏈接，這其中就會導致多次建立/斷開連線的開銷。而1.1版本則支援持續鏈接，一個連接建立後，可以發送多個對象，因而在理論上，1.1版本要比1.0更節約資源，更快，但也有網友表示1.0反而要快一些，這就不得而知了。

2.2 Host域

Host頭域指定要求資源的Intenet主機和連接埠號碼，必須表示請求url的原始伺服器或網關的位置。 HTTP/1.1請求必須包含主機頭域，否則系統會以400狀態碼回傳。這個域感覺可有可無，也許是為了提高速度吧。畢竟直接指定HOST，能更快找到對應主機，如果該主機不存在，也能更快發現。

2.3 頻寬最佳化

1.1版本支援資源部分請求，可只要求資源的一部分。同時，1.1版本支援100狀態碼，當請求實體較大時，可以先發送帶有100狀態碼的頭域，先確認服務端是否回應該請求，如果能回應，則再次發送請求實體，從而在某些無法回應的情況下節省頻寬。

特定流程：客戶端－發送帶有100狀態碼的請求頭－服務端確認是否能回應，若不能，回傳對應狀態碼（如401，未認證），若能，則傳回100狀態碼－客戶端根據傳回狀態碼，確認是否繼續傳送請求。

2.4 請求方法與狀態碼

HTTP1.1增加了OPTIONS, PUT, DELETE, TRACE, CONNECTRequest 狀態回應碼，錯誤或警告的提示不夠具體。 HTTP/1.1引入了一個Warning頭域，增加錯誤或警告訊息的描述。

在HTTP/1.1中新增了24個狀態回應碼，如409（Conflict）表示請求的資源與資源的目前狀態衝突；410（Gone）表示伺服器上的某個資源被永久性的刪除。

3.http通訊流程（1）根據URL查詢DNS，找出web伺服器，並與之建立tcp連線（http下層的協議）。

（2）隨後web瀏覽器向伺服器發送請求。

請求一般包含：|請求方法uri http版本號碼|請求頭|請求正文範例：

# Accept:image/gif.image/jpeg#

Accept-Language:zh-cn

Connection:Keep.

User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)

（3）網路伺服器回應。回應包一般包含： |協定版本狀態碼描述|回應頭|回應文字

HTTP/1.1 200 OK

Date:Mon,6 Oct 2017 13:23:42 GMT

4. http頭域

這部分內容太細太多，直接上表。

請求標頭：

##表示是否需要持久連線。（HTTP 1.1預設為持久連接）Connection: close#CookieHTTP請求發送時，會把保存在該請求網域下的所有cookie值一起傳送給web伺服器。 Cookie: $Version=1; Skin=new;#Content-Length請求的內容長度Content- Length: 348Content-Type要求的與實體對應的MIME資訊Content-Type: application/x-www-form- urlencodedDate請求發送的日期和時間Date: Tue, 15 Nov 2010 08:12:31 GMTExpect要求的特定的伺服器行為Expect: 100-continueFrom#發出請求的使用者的EmailFrom: user@email.com#Host指定要求的伺服器的網域名稱和連接埠號碼Host: www.zcmhi.comIf-Match只有請求內容與實體相符才有效If-Match: “737060cd8c284d8af7ad3082f209582d”If-Modified-Since#如果請求的部分在指定時間之後被修改則請求成功，未被修改則返回304代碼如果請求的部分在指定時間之後被修改則請求成功，未被修改則返回304代碼If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMTIf-None-Match如果內容未改變回傳304程式碼，參數為伺服器先前發送的Etag，與伺服器回應的Etag比較判斷是否改變If-None-Match: “737060cd8c284d8af7ad3082f209582d”#If-Range##If-Range如果實體未改變，伺服器發送客戶端遺失的部分，否則發送整個實體。參數也為EtagIf-Range: “737060cd8c284d8af7ad3082f209582d”#If-Unmodified-Since#只在指定時間之後未被修改才要求成功If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMTMax-Forwards限制訊息透過代理程式和網關傳送的時間Max-Forwards: 10#Pragma用來包含實作特定的指令#Pragma : no-cacheProxy-Authorization#連接到代理程式的授權憑證Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==#Range只要求實體的一部分，指定範圍Range: bytes=500-999

Header	解釋	範例
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











		##1

Header	#解釋	範例
Accept-Ranges	表示伺服器是否支援指定範圍要求及哪種類型的分段請求	Accept-Ranges: bytes
#Age	從原始伺服器到代理快取形成的估算時間（以秒計，非負）	Age: 12
Allow	對某網路資源的有效的請求行為，不允許則回傳405	Allow: GET, HEAD
Cache-Control	告訴所有的快取機制是否可以快取及哪一個型別	Cache-Control: no-cache
Content-Encoding	web伺服器支援的返回內容壓縮編碼類型。	Content-Encoding: gzip
Content-Language	回應體的語言	Content-Language: en,zh
Content-Length	回應體的長度	Content-Length: 348
Content-Location	請求資源可取代的備用的另一個位址	Content-Location: /index.htm
Content-MD5	傳回資源的MD5校驗值	Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Range	在整個回傳體中本部分的位元組位置	Content-Range: bytes 21010-47021/47022
Content-Type	#傳回內容的MIME類型	Content-Type: text/html; charset=utf-8
#Date	原始伺服器訊息發出的時間	Date: Tue, 15 Nov 2010 08:12:31 GMT
ETag	請求變數的實體標籤的目前值	ETag: “737060cd8c284d8af7ad3082f209582d”
Expires	回應過期的日期和時間	Expires: Thu, 01 Dec 2010 16:00:00 GMT
#Last-Modified	請求資源的最後修改時間	Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT
# Location	用來重定向接收者到非請求網址的位置來完成請求或識別新的資源	Location: http://www.zcmhi.com/archives/94.html
Pragma	包含實作特定的指令，它可套用到回應鏈上的任何接收方	Pragma: no-cache
Proxy-Authenticate	它指出認證方案和可套用到代理程式的該URL上的參數	Proxy-Authenticate: Basic
refresh	應用於重定向或一個新的資源被創造，在5秒之後重定向（由網景提出，被大部分瀏覽器支援）	# Refresh: 5; url= http://www.zcmhi.com/archives/94.html
#Retry-After	如果實體暫時不可取，通知客戶端在指定時間之後再嘗試	Retry-After: 120
Server	web伺服器軟體名稱	Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Set-Cookie	設定Http Cookie	Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
Trailer	指出頭域在分塊傳輸編碼的尾部存在	Trailer: Max-Forwards
Transfer-Encoding	檔案傳輸編碼	Transfer-Encoding:chunked
Vary	告訴下游代理程式是使用快取回應還是從原始伺服器請求	Vary: *
Via	告知代理客戶端回應是透過哪裡發送的	Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning	警告實體可能存在的問題	Warning: 199 Miscellaneous warning
WWW- Authenticate	表示客戶端請求實體應該使用的授權方案	WWW-Authenticate: Basic

狀態碼	狀態碼英文名稱	中文描述
1開頭的狀態碼
100	Continue	繼續。客戶端應繼續其請求
101	Switching Protocols	#切換協定。伺服器根據客戶端的請求切換協定。只能切換到更進階的協議，例如，切換到HTTP的新版本協定
#2開頭的狀態碼
200	OK	請求成功。一般用於GET與POST請求
201	Created	已建立。成功請求並建立了新的資源
202	Accepted	已接受。已接受請求，但未處理完成
203	Non-Authoritative Information	非授權資訊。請求成功。但傳回的meta資訊不在原始的伺服器，而是副本
204	No Content	無內容。伺服器成功處理，但未傳回內容。在未更新網頁的情況下，可確保瀏覽器繼續顯示目前文件
205	Reset Content	重設內容。伺服器處理成功，使用者終端（例如：瀏覽器）應重設文件視圖。可透過此回傳碼清除瀏覽器的表單域
206	Partial Content	部分內容。伺服器成功處理了部分GET請求
3開頭的狀態碼
300	Multiple Choices	#多種選擇。請求的資源可包含多個位置，對應可傳回一個資源特徵與位址的清單用於使用者終端（例如：瀏覽器）選擇
#301	Moved Permanently	永久移動。請求的資源已被永久的移動到新URI，返回資訊會包括新的URI，瀏覽器會自動定向到新URI。今後任何新的請求都應使用新的URI代替
302	Found	暫時移動。與301類似。但資源只是臨時被移動。用戶端應繼續使用原有URI
303	See Other	來檢視其它位址。與301類似。使用GET和POST請求查看
304	Not Modified	未修改。所請求的資源未修改，伺服器傳回此狀態碼時，不會傳回任何資源。客戶端通常會快取存取過的資源，透過提供一個頭資訊指出客戶端希望只傳回指定日期之後修改的資源
305	Use Proxy	使用代理程式。所請求的資源必須透過代理程式存取
306	Unused	已經被廢棄的HTTP狀態碼















		#########412######Precondition Failed######客戶端請求訊息的先決條件錯誤############413######Request Entity Too Large######由於請求的實體過大，伺服器無法處理，因此拒絕請求。為防止客戶端的連續請求，伺服器可能會關閉連線。如果只是伺服器暫時無法處理，則會包含一個Retry-After的回應訊息
414	Request-URI Too Large	請求的URI過長（URI通常為網址），伺服器無法處理
415	Unsupported Media Type	伺服器無法處理請求附帶的媒體格式
416	Requested range not satisfiable	客戶端請求的範圍無效
417	Expectation Failed	伺服器無法滿足Expect的請求頭資訊
#5開頭的狀態碼
500	Internal Server Error	伺服器內部錯誤，無法完成請求
#501	Not Implemented

狀態碼	意義
#100	用戶端要繼續發送請求。這個臨時回應是用來通知客戶端它的部分請求已經被伺服器接收，且仍未被拒絕。客戶端應繼續發送請求的剩餘部分，或者如果請求已經完成，忽略這個回應。伺服器必須在請求完成後向客戶端發送最終回應。
101	伺服器已經瞭解了客戶端的請求，並將透過Upgrade 訊息標頭通知客戶端採用不同的協定來完成這個請求。在發送完這個回應最後的空白行後，伺服器將會切換到在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位址指的是從伺服器上看到的客戶端位址（例如用戶的網關或代理伺服器位址）。在這種情況下，連線數的計算可能涉及不只一個終端用戶。
422	從目前客戶端所在的IP位址到伺服器的連線數超過了伺服器授權的最大範圍。通常，這裡的IP位址指的是從伺服器上看到的客戶端位址（例如用戶的網關或代理伺服器位址）。在這種情況下，連線數的計算可能涉及不只一個終端用戶。
422	請求格式正確，但由於含有語意錯誤，無法回應。（RFC 4918 WebDAV）423 Locked 　　目前資源被鎖定。（RFC 4918 WebDAV）
424	由於先前的某個請求發生的錯誤，導致目前請求失敗，例如 PROPPATCH。（RFC 4918 WebDAV）
425	在WebDav Advanced Collections 草案中定義，但未出現在《WebDAV 順序集協定》（RFC 3658）中。
426	客戶端應切換到TLS/1.0。（RFC 2817）
449	由微軟擴展，代表請求應在執行完適當的操作後進行重試。
500	伺服器遇到了一個未曾預料的狀況，導致了它無法完成對請求的處理。一般來說，這個問題都會在伺服器的程式碼出錯時出現。
501	伺服器不支援目前請求所需要的某個功能。當伺服器無法識別請求的方法，並且無法支援其對任何資源的請求。
502	當網關或代理程式工作的伺服器嘗試執行請求時，從上游伺服器接收到無效的回應。
503	由於臨時的伺服器維護或過載，伺服器目前無法處理請求。這個狀況是臨時的，並且將在一段時間以後恢復。如果能夠預期延遲時間，那麼回應中可以包含一個 Retry-After 頭用以標示這個延遲時間。如果沒有給予這個 Retry-After 訊息，那麼客戶端應以處理500回應的方式處理它。　　注意：503狀態碼的存在並不意味著伺服器在過載的時候必須使用它。某些伺服器只不過是希望拒絕客戶端的連線。
504	當網關或代理程式工作的伺服器嘗試執行請求時，未能及時從上游伺服器（URI標識出的伺服器，例如HTTP、FTP、LDAP ）或輔助伺服器（例如DNS）收到回應。注意：某些代理伺服器在DNS查詢逾時時會傳回400或500錯誤
#505	伺服器不支持，或拒絕支援在請求中使用的HTTP 版本。這暗示著伺服器不能或不願使用與客戶端相同的版本。回應中應包含一個描述了為何版本不被支援以及伺服器支援哪些協定的實體。
506	由《透明內容協商協議》（RFC 2295）擴展，代表伺服器存在內部配置錯誤：被要求的協商變元資源被配置為在透明內容協商中使用自己，因此在一個協商處理中不是一個合適的重點。
507	伺服器無法儲存完成請求所必須的內容。這個狀況被認為是臨時的。 WebDAV (RFC 4918)
#509	#伺服器達到頻寬限制。這不是一個官方的狀態碼，但仍被廣泛使用。
510	取得資源所需的策略並沒有沒滿足。（RFC 2774）

############################################################################################################################################################################n ####先前網頁的位址，目前請求網頁緊接著,即來路######Referer: http://www.zcmhi.com/archives/71.html####### #####TE######客戶端願意接受的傳輸編碼，並通知伺服器接受接受尾加頭資訊######TE: trailers,deflate;q=0.5###### ######Upgrade######向伺服器指定某種傳輸協定以便伺服器進行轉換（如果支援）######Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/ x11############User-Agent######User-Agent的內容包含發出要求的使用者資訊######User-Agent: Mozilla/5.0 (Linux; X11 )############Via######通知中間網關或代理伺服器位址，通訊協定######Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) ############Warning######關於訊息實體的警告訊息######Warn: 199 Miscellaneous warning############

回應頭：

Header #解釋範例

Accept-Ranges 表示伺服器是否支援指定範圍要求及哪種類型的分段請求 Accept-Ranges: bytes

#Age 從原始伺服器到代理快取形成的估算時間（以秒計，非負） Age: 12

Allow 對某網路資源的有效的請求行為，不允許則回傳405 Allow: GET, HEAD

Cache-Control 告訴所有的快取機制是否可以快取及哪一個型別 Cache-Control: no-cache

Content-Encoding web伺服器支援的返回內容壓縮編碼類型。 Content-Encoding: gzip

Content-Language 回應體的語言 Content-Language: en,zh

Content-Length 回應體的長度 Content-Length: 348

Content-Location 請求資源可取代的備用的另一個位址 Content-Location: /index.htm

Content-MD5 傳回資源的MD5校驗值 Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==

Content-Range 在整個回傳體中本部分的位元組位置 Content-Range: bytes 21010-47021/47022

Content-Type #傳回內容的MIME類型 Content-Type: text/html; charset=utf-8

#Date 原始伺服器訊息發出的時間 Date: Tue, 15 Nov 2010 08:12:31 GMT

ETag 請求變數的實體標籤的目前值 ETag: “737060cd8c284d8af7ad3082f209582d”

Expires 回應過期的日期和時間 Expires: Thu, 01 Dec 2010 16:00:00 GMT

#Last-Modified 請求資源的最後修改時間 Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT

# Location 用來重定向接收者到非請求網址的位置來完成請求或識別新的資源 Location: http://www.zcmhi.com/archives/94.html

Pragma 包含實作特定的指令，它可套用到回應鏈上的任何接收方 Pragma: no-cache

Proxy-Authenticate 它指出認證方案和可套用到代理程式的該URL上的參數 Proxy-Authenticate: Basic

refresh 應用於重定向或一個新的資源被創造，在5秒之後重定向（由網景提出，被大部分瀏覽器支援）
#

Refresh: 5; url=

http://www.zcmhi.com/archives/94.html

#Retry-After 如果實體暫時不可取，通知客戶端在指定時間之後再嘗試 Retry-After: 120

Server web伺服器軟體名稱 Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)

Set-Cookie 設定Http Cookie Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1

Trailer 指出頭域在分塊傳輸編碼的尾部存在 Trailer: Max-Forwards

Transfer-Encoding 檔案傳輸編碼 Transfer-Encoding:chunked

Vary 告訴下游代理程式是使用快取回應還是從原始伺服器請求 Vary: *

Via 告知代理客戶端回應是透過哪裡發送的 Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Warning 警告實體可能存在的問題 Warning: 199 Miscellaneous warning

WWW- Authenticate 表示客戶端請求實體應該使用的授權方案 WWW-Authenticate: Basic

#
5. http request方法

     GET     請求取得Request-URI所識別的資源
     POST  資源後附加新的資料
     HEAD    請求取得由Request-URI所識別的資源的回應訊息標頭
     PUT     請求伺服器儲存一個資源，並以Request-URI 作為其識別碼作為其識別碼作為其識別碼URI所識別的資源
     TRACE   請求伺服器回傳收到的請求訊息，主要用於測試或診斷
     CONNECT 保留將來使用
     OPTIONS 查詢與伺服器的效能，或查詢要求與資源相關的選項和需求

6. 狀態碼
#Response 訊息中的第一行叫做狀態行，由HTTP協定版本號，狀態碼，狀態訊息三部分組成。
　　狀態碼用來告訴HTTP客戶端，HTTP伺服器是否產生了預期的Response.
　　HTTP/1.1中定義了5類狀態碼，狀態碼由三位數字組成，第三個數字組成，第一個數字一個數字定義了回應的類別
　　1XX 提示訊息- 表示請求已被成功接收，繼續處理，表示還需要繼續接受資料才能完成請求的意思。
　　2XX 成功- 表示請求已被成功接收，理解，接受
　　3XX 重定向- 要完成請求必須進行更進一步的處理
　　4XX 客戶端錯誤- 請求有語法錯誤或請求無法實現
　　5XX 伺服器端錯誤-   伺服器未能實現合法的請求
狀態嗎碼大全
#表1（簡單介紹表，介紹簡介簡潔清晰，推薦先查看此表，如有不懂，再查看下面的表2）
##307Temporary Redirect#暫時重定向。與302類似。使用GET請求重定向4開頭的狀態碼#400Bad Request客戶端請求的語法錯誤，伺服器無法理解401#Unauthorized要求使用者的身份認證402Payment Required保留，將來使用403Forbidden#伺服器理解請求客戶端的請求，但是拒絕執行此請求404Not Found伺服器無法根據客戶端的請求找到資源（網頁）。透過此程式碼，網站設計人員可設定"您所要求的資源無法找到"的個性頁面#405Method Not Allowed客戶端請求中的方法被禁止406Not Acceptable伺服器無法根據客戶端請求的內容特性完成請求407Proxy Authentication Required要求要求代理程式的認證，與401類似，但請求者應使用代理程式進行授權#408Request Time-out伺服器等待客戶端發送的請求時間過長，逾時409Conflict伺服器完成客戶端的PUT請求是可能傳回此程式碼，伺服器處理請求時發生了衝突410Gone客戶端請求的資源已經不存在。 410不同於404，如果資源以前有現在被永久刪除了可使用410程式碼，網站設計人員可透過301程式碼指定資源的新位置411 Length Required伺服器無法處理客戶端發送的不含Content-Length的請求資訊##伺服器不支援請求的功能，無法完成請求502Bad Gateway充當網關或代理的伺服器，從遠端伺服器接收了無效的請求503Service Unavailable由於超載或系統維護，伺服器暫時的無法處理客戶端的請求。延時的長度可包含在伺服器的Retry-After頭資訊中504Gateway Time-out#充當網關或代理程式的伺服器，未及時從遠端伺服器取得請求505HTTP Version not supported伺服器不支援請求的HTTP協定的版本，無法完成處理
表2 詳細介紹表格
#

狀態碼狀態碼英文名稱中文描述

1開頭的狀態碼

100 Continue 繼續。客戶端應繼續其請求

101 Switching Protocols #切換協定。伺服器根據客戶端的請求切換協定。只能切換到更進階的協議，例如，切換到HTTP的新版本協定

#2開頭的狀態碼

200 OK 請求成功。一般用於GET與POST請求

201 Created 已建立。成功請求並建立了新的資源

202 Accepted 已接受。已接受請求，但未處理完成

203 Non-Authoritative Information 非授權資訊。請求成功。但傳回的meta資訊不在原始的伺服器，而是副本

204 No Content 無內容。伺服器成功處理，但未傳回內容。在未更新網頁的情況下，可確保瀏覽器繼續顯示目前文件

205 Reset Content 重設內容。伺服器處理成功，使用者終端（例如：瀏覽器）應重設文件視圖。可透過此回傳碼清除瀏覽器的表單域

206 Partial Content 部分內容。伺服器成功處理了部分GET請求

3開頭的狀態碼

300 Multiple Choices #多種選擇。請求的資源可包含多個位置，對應可傳回一個資源特徵與位址的清單用於使用者終端（例如：瀏覽器）選擇

#301 Moved Permanently 永久移動。請求的資源已被永久的移動到新URI，返回資訊會包括新的URI，瀏覽器會自動定向到新URI。今後任何新的請求都應使用新的URI代替

302 Found 暫時移動。與301類似。但資源只是臨時被移動。用戶端應繼續使用原有URI

303 See Other 來檢視其它位址。與301類似。使用GET和POST請求查看

304 Not Modified 未修改。所請求的資源未修改，伺服器傳回此狀態碼時，不會傳回任何資源。客戶端通常會快取存取過的資源，透過提供一個頭資訊指出客戶端希望只傳回指定日期之後修改的資源

305 Use Proxy 使用代理程式。所請求的資源必須透過代理程式存取

306 Unused 已經被廢棄的HTTP狀態碼

#########412######Precondition Failed######客戶端請求訊息的先決條件錯誤############413######Request Entity Too Large######由於請求的實體過大，伺服器無法處理，因此拒絕請求。為防止客戶端的連續請求，伺服器可能會關閉連線。如果只是伺服器暫時無法處理，則會包含一個Retry-After的回應訊息

414 Request-URI Too Large 請求的URI過長（URI通常為網址），伺服器無法處理

415 Unsupported Media Type 伺服器無法處理請求附帶的媒體格式

416 Requested range not satisfiable 客戶端請求的範圍無效

417 Expectation Failed 伺服器無法滿足Expect的請求頭資訊

#5開頭的狀態碼

500 Internal Server Error 伺服器內部錯誤，無法完成請求

#501 Not Implemented

狀態碼意義

#100 用戶端要繼續發送請求。這個臨時回應是用來通知客戶端它的部分請求已經被伺服器接收，且仍未被拒絕。客戶端應繼續發送請求的剩餘部分，或者如果請求已經完成，忽略這個回應。伺服器必須在請求完成後向客戶端發送最終回應。

101 伺服器已經瞭解了客戶端的請求，並將透過Upgrade 訊息標頭通知客戶端採用不同的協定來完成這個請求。在發送完這個回應最後的空白行後，伺服器將會切換到在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位址指的是從伺服器上看到的客戶端位址（例如用戶的網關或代理伺服器位址）。在這種情況下，連線數的計算可能涉及不只一個終端用戶。

422 從目前客戶端所在的IP位址到伺服器的連線數超過了伺服器授權的最大範圍。通常，這裡的IP位址指的是從伺服器上看到的客戶端位址（例如用戶的網關或代理伺服器位址）。在這種情況下，連線數的計算可能涉及不只一個終端用戶。

422 請求格式正確，但由於含有語意錯誤，無法回應。（RFC 4918 WebDAV）423 Locked 　　目前資源被鎖定。（RFC 4918 WebDAV）

424 由於先前的某個請求發生的錯誤，導致目前請求失敗，例如 PROPPATCH。（RFC 4918 WebDAV）

425 在WebDav Advanced Collections 草案中定義，但未出現在《WebDAV 順序集協定》（RFC 3658）中。

426 客戶端應切換到TLS/1.0。（RFC 2817）

449 由微軟擴展，代表請求應在執行完適當的操作後進行重試。

500 伺服器遇到了一個未曾預料的狀況，導致了它無法完成對請求的處理。一般來說，這個問題都會在伺服器的程式碼出錯時出現。

501 伺服器不支援目前請求所需要的某個功能。當伺服器無法識別請求的方法，並且無法支援其對任何資源的請求。

502 當網關或代理程式工作的伺服器嘗試執行請求時，從上游伺服器接收到無效的回應。

503 由於臨時的伺服器維護或過載，伺服器目前無法處理請求。這個狀況是臨時的，並且將在一段時間以後恢復。如果能夠預期延遲時間，那麼回應中可以包含一個 Retry-After 頭用以標示這個延遲時間。如果沒有給予這個 Retry-After 訊息，那麼客戶端應以處理500回應的方式處理它。　　注意：503狀態碼的存在並不意味著伺服器在過載的時候必須使用它。某些伺服器只不過是希望拒絕客戶端的連線。

504 當網關或代理程式工作的伺服器嘗試執行請求時，未能及時從上游伺服器（URI標識出的伺服器，例如HTTP、FTP、LDAP ）或輔助伺服器（例如DNS）收到回應。注意：某些代理伺服器在DNS查詢逾時時會傳回400或500錯誤

#505 伺服器不支持，或拒絕支援在請求中使用的HTTP 版本。這暗示著伺服器不能或不願使用與客戶端相同的版本。回應中應包含一個描述了為何版本不被支援以及伺服器支援哪些協定的實體。

506 由《透明內容協商協議》（RFC 2295）擴展，代表伺服器存在內部配置錯誤：被要求的協商變元資源被配置為在透明內容協商中使用自己，因此在一個協商處理中不是一個合適的重點。

507 伺服器無法儲存完成請求所必須的內容。這個狀況被認為是臨時的。 WebDAV (RFC 4918)

#509 #伺服器達到頻寬限制。這不是一個官方的狀態碼，但仍被廣泛使用。

510 取得資源所需的策略並沒有沒滿足。（RFC 2774）

最後，大部分資料都由網路上整理所得，感謝所有奉獻的前輩同仁！

【推薦課程：http影片教學】

以上是前端開發者必須知道的http協定相關知識的詳細內容。更多資訊請關注PHP中文網其他相關文章！

陳述：

本文轉載於：csdn.net。如有侵權，請聯絡admin@php.cn刪除

上一篇：html如何為圖片加連結下一篇：html如何為圖片加連結

看更多