HTTP頭部資訊和錯誤程式碼詳解-《HTTP權威指南》

最近在調試前後端分離的請求測試，遇到了一個405錯誤，無法接受，於是開始了人肉搜索405。

最後還是HTTP頭部資訊里的Accept:application/json 這個Accept 導致的，後端設置了只允許application/json 這種形式，so前端模擬請求的時候，你也要和後端溝通好，然後發送請求參數，就可以了！

正好，也忘得差不多了，下面我們就來總結和回顧一下HTTP 的一些參數和錯誤碼等等。

本文為多篇「HTTP請求頭相關文章」及《HTTP權威指南》一書的閱讀後個人匯總整理版，以便於理解。

通常HTTP消息包括客戶機向伺服器的請求消息和伺服器向客戶機的響應消息。客戶端向伺服器發送一個請求，請求頭包含請求的方法、URI、協議版本、以及包含請求修飾符、客戶資訊和內容的類似於MIME的消息結構。伺服器以一個狀態行作為響應，相應的內容包括消息協議的版本，成功或者錯誤編碼加上包含伺服器資訊、實體元資訊以及可能的實體內容。

Http協議定義了很多與伺服器交互的方法，最基本的有4種，分別是GET、POST、PUT、DELETE。一個URL地址用於描述一個網路上的資源，而HTTP中的GET、POST、PUT、 DELETE就對應著對這個資源的查、改、增、刪4個操作，我們最常見的就是GET和POST了。GET一般用於獲取/查詢資源資訊，而POST一般用於更新資源資訊。

HTTP頭資訊解讀

HTTP的頭域包括通用頭、請求頭、響應頭和實體頭四個部分。每個頭域由一個域名，冒號（:）和域值三部分組成。

通用頭部是客戶端和伺服器都可以使用的頭部，可以在客戶端、伺服器和其他應用程式之間提供一些非常有用的通用功能，如Date頭部。

請求頭部是請求報文特有的，它們為伺服器提供了一些額外資訊，比如客戶端希望接收什麼類型的數據，如Accept頭部。

響應頭部便於客戶端提供資訊，比如，客服端在與哪種類型的伺服器進行交互，如Server頭部。

實體頭部指的是用於應對實體主體部分的頭部，比如，可以用實體頭部來說明實體主體部分的數據類型，如Content-Type頭部。

HTTP通用頭

通用頭域包含請求和響應消息都支援的頭域，通用頭域包含快取頭部Cache-Control、Pragma及資訊性頭部Connection、Date、Transfer-Encoding、Update、Via。

1、Cache-Control(快取控制)

Cache-Control指定請求和響應遵循的快取機制。在請求消息或響應消息中設置 Cache-Control並不會修改另一個消息處理過程中的快取處理過程。請求時的快取指令包括no-cache、no-store、max-age、 max-stale、min-fresh、only-if-cached，響應消息中的指令包括public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age。各個消息中的指令含義如下：

no-cache：指示請求或響應消息不能快取，實際上是可以存儲在本地快取區中的，只是在與原始伺服器進行新鮮度驗證之前，快取不能將其提供給客戶端使用。　
no-store：快取應該儘快從存儲器中刪除文檔的所有痕迹，因為其中可能會包含敏感資訊。
max-age：快取無法返回快取時間長於max-age規定秒的文檔，若不超規定秒瀏覽器將不會發送對應的請求到伺服器，數據由快取直接返回；超過這一時間段才進一步由伺服器決定是返回新數據還是仍由快取提供。若同時還發送了max-stale指令，則使用期可能會超過其過期時間。
min-fresh：至少在未來規定秒內文檔要保持新鮮，接受其新鮮生命期大於其當前 Age 跟 min-fresh 值之和的快取對象。
max-stale：指示客戶端可以接收過期響應消息，如果指定max-stale消息的值，那麼客戶端可以接收過期但在指定值之內的響應消息。
only-if-cached：只有當快取中有副本存在時，客戶端才會獲得一份副本。
Public：指示響應可被任何快取區快取，可以用快取內容回應任何用戶。
Private：指示對於單個用戶的整個或部分響應消息，不能被共享快取處理，只能用快取內容回應先前請求該內容的那個用戶。

2、Pragma

Pragma頭域用來包含實現特定的指令，最常用的是Pragma:no-cache。在HTTP/1.1協議中，它的含義和Cache- Control:no-cache相同。

3、Connection

Connection表示是否需要持久連接。如果Servlet看到這裡的值為「Keep-Alive」，或者看到請求使用的是HTTP 1.1（HTTP 1.1默認進行持久連接），它就可以利用持久連接的優點，當頁面包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現這一點，Server需要在應答中發送一個Content-Length頭，最簡單的實現方法是：先把內容寫入ByteArrayOutputStream，然後在正式寫出內容之前計算它的大小。

Close：告訴WEB伺服器或者代理伺服器，在完成本次請求的響應後，斷開連接，不要等待本次連接的後續請求了。
Keepalive：告訴WEB伺服器或者代理伺服器，在完成本次請求的響應後，保持連接，等待本次連接的後續請求。
Keep-Alive：如果瀏覽器請求保持連接，則該頭部表明希望 WEB 伺服器保持連接多長時間（秒），如Keep-Alive：300。

4、Date

Date頭域表示消息發送的時間，伺服器響應中要包含這個頭部，因為快取在評估響應的新鮮度時要用到，其時間的描述格式由RFC822定義。例如，Date:Mon, 31 Dec 2001 04:25:57 GMT。Date描述的時間表示世界標準時，換算成本地時間，需要知道用戶所在的時區。

5、Transfer-Encoding(傳輸編碼)

WEB 伺服器表明自己對本響應消息體（不是消息體裡面的對象）作了怎樣的編碼，比如是否分塊（chunked），例如：Transfer-Encoding: chunked

6、Upgrade

它可以指定另一種可能完全不同的協議，如HTTP/1.1客戶端可以向伺服器發送一條HTTP/1.0請求，其中包含值為「HTTP/1.1」的Update頭部，這樣客戶端就可以測試一下伺服器是否也使用HTTP/1.1了。

7、Via(經過)

列出從客戶端到 OCS 或者相反方向的響應經過了哪些代理伺服器，他們用什麼協議（和版本）發送的請求。

當客戶端請求到達第一個代理伺服器時，該伺服器會在自己發出的請求裡面添加 Via 頭部，並填上自己的相關資訊，當下一個代理伺服器收到第一個代理伺服器的請求時，會在自己發出的請求裡面複製前一個代理伺服器的請求的Via頭部，並把自己的相關資訊加到後面，以此類推，當 OCS 收到最後一個代理伺服器的請求時，檢查 Via 頭部，就知道該請求所經過的路由。例如：Via：1.0 236-81.D07071953.sina.com.cn:80 (squid/2.6.STABLE13)

HTTP請求頭

請求頭用於說明是誰或什麼在發送請求、請求源於何處，或者客戶端的喜好及能力。伺服器可以根據請求頭部給出的客戶端資訊，試著為客戶端提供更好的響應。請求頭域可能包含下列欄位Accept、Accept-Charset、Accept- Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If-Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、Referer、User-Agent。對請求頭域的擴展要求通訊雙方都支援，如果存在不支援的請求頭域，一般將會作為實體頭域處理。

8、Accept(接受)

告訴WEB伺服器自己接受什麼介質類型，/ 表示任何類型，type/* 表示該類型下的所有子類型，type/sub-type。

9、Accept-Charset(接受字符集)

瀏覽器告訴伺服器自己能接收的字符集。

10、Accept-Encoding(接受編碼方法)

瀏覽器申明自己接收的編碼方法，通常指定壓縮方法，是否支援壓縮，支援什麼壓縮方法（gzip，deflate）。

11、Accept-Language(接受語言)

瀏覽器申明自己接收的語言。語言跟字符集的區別：中文是語言，中文有多種字符集，比如big5，gb2312，gbk等等。

12、Authorization(授權)

當客戶端接收到來自WEB伺服器的 WWW-Authenticate 響應時，用該頭部來回應自己的身份驗證資訊給WEB伺服器。

13、If-Match

如果對象的 ETag 沒有改變，其實也就意味著對象沒有改變，才執行請求的動作，獲取文檔。

14、If-None-Match

如果對象的 ETag 改變了，其實也就意味著對象也改變了，才執行請求的動作，獲取文檔。

15、If-Modified-Since(如果已修改)

如果請求的對象在該頭部指定的時間之後修改了，才執行請求的動作（比如返回對象），否則返回程式碼304，告訴瀏覽器該對象沒有修改。例如：If-Modified-Since：Thu, 10 Apr 2008 09:14:42 GMT

16、If-Unmodified-Since(如果未修改)

如果請求的對象在該頭部指定的時間之後沒修改過，才執行請求的動作（比如返回對象）。

17、If-Range

瀏覽器告訴 WEB 伺服器，如果我請求的對象沒有改變，就把我缺少的部分給我，如果對象改變了，就把整個對象給我。瀏覽器通過發送請求對象的ETag 或者自己所知道的最後修改時間給 WEB 伺服器，讓其判斷對象是否改變了。總是跟 Range 頭部一起使用。

18、Range

瀏覽器（比如 Flashget 多執行緒下載時）告訴 WEB 伺服器自己想取對象的哪部分。例如：Range: bytes=1173546

19、Proxy-Authenticate(代理驗證)

代理伺服器響應瀏覽器，要求其提供代理身份驗證資訊。

20、Proxy-Authorization(代理授權)

瀏覽器響應代理伺服器的身份驗證請求，提供自己的身份資訊。

21、Host

客戶端指定自己想訪問的WEB伺服器的域名/IP 地址和埠號。如Host：rss.sina.com.cn

22、Referer

瀏覽器向WEB 伺服器表明自己是從哪個網頁URL獲得點擊當前請求中的網址/URL，例如：Referer：//www.ecdoer.com/

23、User-Agent

瀏覽器表明自己的身份（是哪種瀏覽器）。例如：User-Agent：Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN;rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

HTTP響應頭

響應頭向客戶端提供一些額外資訊，比如誰在發送響應、響應者的功能，甚至與響應相關的一些特殊指令。這些頭部有助於客戶端處理響應，並在將來發起更好的請求。響應頭域包含Age、Location、Proxy-Authenticate、Public、Retry- After、Server、Vary、Warning、WWW-Authenticate。對響應頭域的擴展要求通訊雙方都支援，如果存在不支援的響應頭域，一般將會作為實體頭域處理。

24、Age

當代理伺服器用自己快取的實體去響應請求時，用該頭部表明該實體從產生到現在經過多長時間了。

25、Server

WEB 伺服器表明自己是什麼軟體及版本等資訊。例如：Server：Apache/2.0.61 (Unix)

26、Accept-Ranges

WEB伺服器表明自己是否接受獲取其某個實體的一部分（比如文件的一部分）的請求。bytes：表示接受，none：表示不接受。

27、Vary

WEB伺服器用該頭部的內容告訴 Cache 伺服器，在什麼條件下才能用本響應所返回的對象響應後續的請求。假如源WEB伺服器在接到第一個請求消息時，其響應消息的頭部為：Content-Encoding: gzip; Vary: Content-Encoding，那麼Cache伺服器會分析後續請求消息的頭部，檢查其Accept-Encoding，是否跟先前響應的Vary頭部值一致，即是否使用相同的內容編碼方法，這樣就可以防止Cache伺服器用自己Cache 裡面壓縮後的實體響應給不具備解壓能力的瀏覽器。例如：Vary：Accept-Encoding。

HTTP實體頭

實體頭部提供了有關實體及其內容的大量資訊，從有關對象類型的資訊，到能夠對資源使用的各種有效的請求方法。總之，實體頭部可以告知接收者它在對什麼進行處理。請求消息和響應消息都可以包含實體資訊，實體資訊一般由實體頭域和實體組成。實體頭域包含關於實體的原資訊，實體頭包括資訊性頭部Allow、Location，內容頭部Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type，快取頭部Etag、Expires、Last-Modified、extension-header。

28、Allow

伺服器支援哪些請求方法（如GET、POST等）。

29、Location(位置)

表示客戶應當到哪裡去提取文檔，用於將接收端定位到資源的位置（URL）上。Location通常不是直接設置的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設置狀態程式碼為302。

30、Content-Base(基礎內容)

解析主體中的相對URL時使用的基礎URL。

31、Content-Encoding(內容編碼)

WEB伺服器表明自己使用了什麼壓縮方法（gzip，deflate）壓縮響應中的對象。例如：Content-Encoding：gzip

32、Content-Language(內容語言)

WEB 伺服器告訴瀏覽器理解主體時最適宜使用的自然語言。

33、Content-Length(內容長度)

WEB伺服器告訴瀏覽器自己響應的對象的長度或尺寸，例如：Content-Length: 26012

34、Content-Location(內容位置)

資源實際所處的位置。

35、Content-MD5(內容MD5校驗)

主體的MD5校驗和。

36、Content-Range

實體頭用於指定整個實體中的一部分的插入位置，他也指示了整個實體的長度。在伺服器向客戶返回一個部分響應，它必須描述響應覆蓋的範圍和整個實體長度。一般格式： Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth。例如，傳送頭500個位元組次欄位的形式：Content-Range:bytes0- 499/1234如果一個http消息包含此節（例如，對範圍請求的響應或對一系列範圍的重疊請求），Content-Range表示傳送的範圍，Content-Length表示實際傳送的位元組數。

37、Content-Type(內容類型)

WEB 伺服器告訴瀏覽器自己響應的對象的類型。例如：Content-Type：application/xml

38、Etag

就是一個對象（比如URL）的標誌值，就一個對象而言，比如一個html文件，如果被修改了，其Etag也會別修改，所以，ETag的作用跟Last-Modified的作用差不多，主要供WEB伺服器判斷一個對象是否改變了。比如前一次請求某個html文件時，獲得了其 ETag，當這次又請求這個文件時，瀏覽器就會把先前獲得ETag值發送給WEB伺服器，然後WEB伺服器會把這個ETag跟該文件的當前ETag進行對比，然後就知道這個文件有沒有改變了。

39、Expires

WEB伺服器表明該實體將在什麼時候過期，對於過期了的對象，只有在跟WEB伺服器驗證了其有效性後，才能用來響應客戶請求。是 HTTP/1.0 的頭部。例如：Expires：Sat, 23 May 2009 10:02:12 GMT

40、Last-Modified

WEB伺服器認為對象的最後修改時間，比如文件的最後修改時間，動態頁面的最後產生時間等等。例如：Last-Modified：Tue, 06 May 2008 02:42:43 GMT

1、HTTP請求方式

如下表：

請求方式	詳解
GET	向Web伺服器請求一個文件
POST	向Web伺服器發送數據讓Web伺服器進行處理
PUT	向Web伺服器發送數據並存儲在Web伺服器內部
HEAD	檢查一個對象是否存在
DELETE	從Web伺服器上刪除一個文件
CONNECT	對通道提供支援
TRACE	跟蹤到伺服器的路徑
OPTIONS	查詢Web伺服器的性能

說明：

主要使用到「GET」和「POST」。

實例：

POST /test/tupian/cm HTTP/1.1

分成三部分：
（1）POST：HTTP請求方式
（2）/test/tupian/cm：請求Web伺服器的目錄地址（或者指令）
（3）HTTP/1.1: URI（Uniform Resource Identifier，統一資源標識符）及其版本

備註：

在Ajax中，對應method屬性設置。

2、Host

說明：

請求的web伺服器域名地址

3、User-Agent

說明：

HTTP客戶端運行的瀏覽器類型的詳細資訊。通過該頭部資訊，web伺服器可以判斷到當前HTTP請求的客戶端瀏覽器類別。

實例：

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

4、Accept

說明：

指定客戶端能夠接收的內容類型，內容類型中的先後次序表示客戶端接收的先後次序。

例如：

Accept:text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,/;q=0.5

備註：

在Prototyp（1.5）的Ajax程式碼封裝中，將Accept默認設置為「text/javascript, text/html, application/xml, text/xml, /」。這是因為Ajax默認獲取伺服器返回的Json數據模式。

在Ajax程式碼中，可以使用XMLHttpRequest 對象中setRequestHeader函數方法來動態設置這些Header資訊。

5、Accept-Language

說明：

指定HTTP客戶端瀏覽器用來展示返回資訊所優先選擇的語言。

實例：

Accept-Language: zh-cn,zh;q=0.5

這裡默認為中文。

6、Accept-Encoding

說明：

指定客戶端瀏覽器可以支援的web伺服器返回內容壓縮編碼類型。表示允許伺服器在將輸出內容發送到客戶端以前進行壓縮，以節約頻寬。而這裡設置的就是客戶端瀏覽器所能夠支援的返回壓縮格式。

實例：

Accept-Encoding: gzip,deflate

備註：

其實在百度很多產品線中，apache在給客戶端返回頁面數據之前，將數據以gzip格式進行壓縮。

7、Accept-Charset

說明：

瀏覽器可以接受的字元編碼集。

實例：

Accept-Charset: gb2312,utf-8;q=0.7,*;q=0.7

8、Content-Type

說明：

顯示此HTTP請求提交的內容類型。一般只有post提交時才需要設置該屬性。

實例：

Content-type: application/x-www-form-urlencoded;charset:UTF-8

有關Content-Type屬性值可以如下兩種編碼類型：

（1）「application/x-www-form-urlencoded」：表單數據向伺服器提交時所採用的編碼類型，默認的預設值就是「application/x-www-form-urlencoded」。然而，在向伺服器發送大量的文本、包含非ASCII字元的文本或二進位數據時這種編碼方式效率很低。

（2）「multipart/form-data」：在文件上載時，所使用的編碼類型應當是「multipart/form-data」，它既可以發送文本數據，也支援二進位數據上載。

當提交為單單數據時，可以使用「application/x-www-form-urlencoded」；當提交的是文件時，就需要使用「multipart/form-data」編碼類型。

在Content-Type屬性當中還是指定提交內容的charset字元編碼。一般不進行設置，它只是告訴web伺服器post提交的數據採用的何種字元編碼。

一般在開發過程，是由前端工程與後端UI工程師商量好使用什麼字元編碼格式來post提交的，然後後端ui工程師按照固定的字元編碼來解析提交的數據。所以這裡設置的charset沒有多大作用。

9、Connection

說明：

表示是否需要持久連接。如果web伺服器端看到這裡的值為「Keep-Alive」，或者看到請求使用的是HTTP 1.1（HTTP 1.1默認進行持久連接），它就可以利用持久連接的優點，當頁面包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現這一點， web伺服器需要在返回給客戶端HTTP頭資訊中發送一個Content-Length（返回資訊正文的長度）頭，最簡單的實現方法是：先把內容寫入ByteArrayOutputStream，然後在正式寫出內容之前計算它的大小。

實例：

Connection: keep-alive

10、Keep-Alive

說明：

顯示此HTTP連接的Keep-Alive時間。使客戶端到伺服器端的連接持續有效，當出現對伺服器的後繼請求時，Keep-Alive功能避免了建立或者重新建立連接。

以前HTTP請求是一站式連接，從HTTP/1.1協議之後，就有了長連接，即在規定的Keep-Alive時間內，連接是不會斷開的。

實例：

Keep-Alive: 300

說明：

HTTP請求發送時，會把保存在該請求域名下的所有cookie值一起發送給web伺服器。

12、Referer

說明：

包含一個URL，用戶從該URL代表的頁面出發訪問當前請求的頁面

http返回錯誤碼

一、HTTP響應碼響應碼由三位十進位數字組成，它們出現在由HTTP伺服器發送的響應的第一行。

響應碼分五種類型，由它們的第一位數字表示：

1xx：資訊，請求收到，繼續處理
100 繼續    
101 分組交換協議

2xx：成功，行為被成功地接受、理解和採納
200 OK
201 被創建	
202 被採納 
203 非授權資訊	
204 無內容			
205 重置內容			
206 部分內容 

3xx：重定向，為了完成請求，必須進一步執行的動作
300 多選項			
301 永久重定向	
302 臨時重定向		
303 參見其他 
304 未改動       	 
305 使用代理        
307 暫時重定向   

4xx：客戶端錯誤，請求包含語法錯誤或者請求無法實現
400 錯誤請求 
401 未授權       	 
402 要求付費        
403 禁止          		 
404 未找到 
405 不允許方法    
406 不被採納    	
407 要求代理授權	
408 請求超時 
409 衝突          	 
410 過期的       	 
411 要求的長度        
412 前提不成立 
413 請求實例太大    
414 請求URI太大         
415 不支援的媒體類型
416 無法滿足的請求範圍       
417 失敗的預期       

5xx：伺服器錯誤，伺服器不能實現一種明顯無效的請求
500 內部伺服器錯誤 
501 未被使用    
502 網關錯誤    
503 不可用的服務    
504 網關超時 
505 HTTP版本未被支援

Tags: TCP協議棧及各類網路協議