一般HTTP消息包括客戶機向服務器的請求消息和服務器向客戶機的響應消息。客戶端向服務器發送一個請求,請求頭包含請求的方法、URI、協議版本、以及包含請求修飾符、客戶信息和內容的相似於MIME的消息結構。服務器以一個狀態行做爲響應,相應的內容包括消息協議的版本,成功或者錯誤編碼加上包含服務器信息、實體元信息以及可能的實體內容。javascript
Http協議定義了不少與服務器交互的方法,最基本的有4種,分別是GET、POST、PUT、DELETE。一個URL地址用於描述一個網絡上的資源,而HTTP中的GET、POST、PUT、 DELETE就對應着對這個資源的查、改、增、刪4個操做,咱們最多見的就是GET和POST了。GET通常用於獲取/查詢資源信息,而POST通常用於更新資源信息。html
HTTP的頭域包括通用頭、請求頭、響應頭和實體頭四個部分。每一個頭域由一個域名,冒號(:)和域值三部分組成。前端
通用頭部:是客戶端和服務器均可以使用的頭部,能夠在客戶端、服務器和其餘應用程序之間提供一些很是有用的通用功能,如Date頭部。java
請求頭部:是請求報文特有的,它們爲服務器提供了一些額外信息,好比客戶端但願接收什麼類型的數據,如Accept頭部。web
響應頭部:便於客戶端提供信息,好比,客服端在與哪一種類型的服務器進行交互,如Server頭部。apache
實體頭部:指的是用於應對實體主體部分的頭部,好比,能夠用實體頭部來講明實體主體部分的數據類型,如Content-Type頭部。後端
通用頭域包含請求和響應消息都支持的頭域,通用頭域包含緩存頭部Cache-Control、Pragma及信息性頭部Connection、Date、Transfer-Encoding、Update、Via。瀏覽器
一、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:指示對於單個用戶的整個或部分響應消息,不能被共享緩存處理,只能用緩存內容迴應先前請求該內容的那個用戶。
二、Pragma
Pragma頭域用來包含實現特定的指令,最經常使用的是Pragma:no-cache。在HTTP/1.1協議中,它的含義和Cache- Control:no-cache相同。
三、Connection
Connection表示是否須要持久鏈接。若是Servlet看到這裏的值爲「Keep-Alive」,或者看到請求使用的是HTTP 1.1(HTTP 1.1默認進行持久鏈接),它就能夠利用持久鏈接的優勢,當頁面包含多個元素時(例如Applet,圖片),顯著地減小下載所須要的時間。要實現這一點,Servlet須要在應答中發送一個Content-Length頭,最簡單的實現方法是:先把內容寫入ByteArrayOutputStream,而後在正式寫出內容以前計算它的大小。
Close:告訴WEB服務器或者代理服務器,在完成本次請求的響應後,斷開鏈接,不要等待本次鏈接的後續請求了。
Keepalive:告訴WEB服務器或者代理服務器,在完成本次請求的響應後,保持鏈接,等待本次鏈接的後續請求。
Keep-Alive:若是瀏覽器請求保持鏈接,則該頭部代表但願 WEB 服務器保持鏈接多長時間(秒),如Keep-Alive:300。
四、Date
Date頭域表示消息發送的時間,服務器響應中要包含這個頭部,由於緩存在評估響應的新鮮度時要用到,其時間的描述格式由RFC822定義。例如,Date:Mon, 31 Dec 2001 04:25:57 GMT。Date描述的時間表示世界標準時,換算成本地時間,須要知道用戶所在的時區。
五、Transfer-Encoding
WEB 服務器代表本身對本響應消息體(不是消息體裏面的對象)做了怎樣的編碼,好比是否分塊(chunked),例如:Transfer-Encoding: chunked
六、Upgrade
它能夠指定另外一種可能徹底不一樣的協議,如HTTP/1.1客戶端能夠向服務器發送一條HTTP/1.0請求,其中包含值爲「HTTP/1.1」的Update頭部,這樣客戶端就能夠測試一下服務器是否也使用HTTP/1.1了。
七、Via
列出從客戶端到 OCS 或者相反方向的響應通過了哪些代理服務器,他們用什麼協議(和版本)發送的請求。
當客戶端請求到達第一個代理服務器時,該服務器會在本身發出的請求裏面添加 Via 頭部,並填上本身的相關信息,當下一個代理服務器 收到第一個代理服務器的請求時,會在本身發出的請求裏面複製前一個代理服務器的請求的Via頭部,並把本身的相關信息加到後面,以此類推,當 OCS 收到最後一個代理服務器的請求時,檢查 Via 頭部,就知道該請求所通過的路由。例如:Via:1.0 236-81.D07071953.sina.com.cn:80 (squid/2.6.STABLE13)
請求頭用於說明是誰或什麼在發送請求、請求源於何處,或者客戶端的喜愛及能力。服務器能夠根據請求頭部給出的客戶端信息,試着爲客戶端提供更好的響應。請求頭域可能包含下列字段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。對請求頭域的擴展要求通信雙方都支持,若是存在不支持的請求頭域,通常將會做爲實體頭域處理。
八、Accept
告訴WEB服務器本身接受什麼介質類型,*/* 表示任何類型,type/* 表示該類型下的全部子類型,type/sub-type。
九、Accept-Charset
瀏覽器告訴服務器本身能接收的字符集。
十、Accept-Encoding
瀏覽器申明本身接收的編碼方法,一般指定壓縮方法,是否支持壓縮,支持什麼壓縮方法(gzip,deflate)。
十一、Accept-Language
瀏覽器申明本身接收的語言。語言跟字符集的區別:中文是語言,中文有多種字符集,好比big5,gb2312,gbk等等。
十二、Authorization
當客戶端接收到來自WEB服務器的 WWW-Authenticate 響應時,用該頭部來回應本身的身份驗證信息給WEB服務器。
1三、If-Match
若是對象的 ETag 沒有改變,其實也就意味著對象沒有改變,才執行請求的動做,獲取文檔。
1四、If-None-Match
若是對象的 ETag 改變了,其實也就意味著對象也改變了,才執行請求的動做,獲取文檔。
1五、If-Modified-Since
若是請求的對象在該頭部指定的時間以後修改了,才執行請求的動做(好比返回對象),不然返回代碼304,告訴瀏覽器該對象沒有修改。例如:If-Modified-Since:Thu, 10 Apr 2008 09:14:42 GMT
1六、If-Unmodified-Since
若是請求的對象在該頭部指定的時間以後沒修改過,才執行請求的動做(好比返回對象)。
1七、If-Range
瀏覽器告訴 WEB 服務器,若是我請求的對象沒有改變,就把我缺乏的部分給我,若是對象改變了,就把整個對象給我。瀏覽器經過發送請求對象的ETag 或者本身所知道的最後修改時間給 WEB 服務器,讓其判斷對象是否改變了。老是跟 Range 頭部一塊兒使用。
1八、Range
瀏覽器(好比 Flashget 多線程下載時)告訴 WEB 服務器本身想取對象的哪部分。例如:Range: bytes=1173546
1九、Proxy-Authenticate
代理服務器響應瀏覽器,要求其提供代理身份驗證信息。
20、Proxy-Authorization
瀏覽器響應代理服務器的身份驗證請求,提供本身的身份信息。
2一、Host
客戶端指定本身想訪問的WEB服務器的域名/IP 地址和端口號。如Host:rss.sina.com.cn
2二、Referer
瀏覽器向WEB 服務器代表本身是從哪一個網頁URL得到點擊當前請求中的網址/URL,例如:Referer:http://www.ecdoer.com/
2三、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
響應頭向客戶端提供一些額外信息,好比誰在發送響應、響應者的功能,甚至與響應相關的一些特殊指令。這些頭部有助於客戶端處理響應,並在未來發起更好的請求。響應頭域包含Age、Location、Proxy-Authenticate、Public、Retry- After、Server、Vary、Warning、WWW-Authenticate。對響應頭域的擴展要求通信雙方都支持,若是存在不支持的響應頭域,通常將會做爲實體頭域處理。
2四、Age
當代理服務器用本身緩存的實體去響應請求時,用該頭部代表該實體從產生到如今通過多長時間了。
2五、Server
WEB 服務器代表本身是什麼軟件及版本等信息。例如:Server:Apache/2.0.61 (Unix)
2六、Accept-Ranges
WEB服務器代表本身是否接受獲取其某個實體的一部分(好比文件的一部分)的請求。bytes:表示接受,none:表示不接受。
2七、Vary
WEB服務器用該頭部的內容告訴 Cache 服務器,在什麼條件下才能用本響應所返回的對象響應後續的請求。假如源WEB服務器在接到第一個請求消息時,其響應消息的頭部爲:Content-Encoding: gzip; Vary: Content-Encoding,那麼Cache服務器會分析後續請求消息的頭部,檢查其Accept-Encoding,是否跟先前響應的Vary頭部值一致,便是否使用相同的內容編碼方法,這樣就能夠防止Cache服務器用本身Cache 裏面壓縮後的實體響應給不具有解壓能力的瀏覽器。例如:Vary:Accept-Encoding。
實體頭部提供了有關實體及其內容的大量信息,從有關對象類型的信息,到可以對資源使用的各類有效的請求方法。總之,實體頭部能夠告知接收者它在對什麼進行處理。請求消息和響應消息均可以包含實體信息,實體信息通常由實體頭域和實體組成。實體頭域包含關於實體的原信息,實體頭包括信息性頭部Allow、Location,內容頭部Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD五、Content-Range、Content-Type,緩存頭部Etag、Expires、Last-Modified、extension-header。
2八、Allow
服務器支持哪些請求方法(如GET、POST等)。
2九、Location
表示客戶應當到哪裏去提取文檔,用於將接收端定位到資源的位置(URL)上。Location一般不是直接設置的,而是經過HttpServletResponse的sendRedirect方法,該方法同時設置狀態代碼爲302。
30、Content-Base
解析主體中的相對URL時使用的基礎URL。
3一、Content-Encoding
WEB服務器代表本身使用了什麼壓縮方法(gzip,deflate)壓縮響應中的對象。例如:Content-Encoding:gzip
3二、Content-Language
WEB 服務器告訴瀏覽器理解主體時最適宜使用的天然語言。
3三、Content-Length
WEB服務器告訴瀏覽器本身響應的對象的長度或尺寸,例如:Content-Length: 26012
3四、Content-Location
資源實際所處的位置。
3五、Content-MD5
主體的MD5校驗和。
3六、Content-Range
實體頭用於指定整個實體中的一部分的插入位置,他也指示了整個實體的長度。在服務器向客戶返回一個部分響應,它必須描述響應覆蓋的範圍和整個實體長度。通常格式: Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth。例如,傳送頭500個字節次字段的形式:Content-Range:bytes0- 499/1234若是一個http消息包含此節(例如,對範圍請求的響應或對一系列範圍的重疊請求),Content-Range表示傳送的範圍,Content-Length表示實際傳送的字節數。
3七、Content-Type
WEB 服務器告訴瀏覽器本身響應的對象的類型。例如:Content-Type:application/xml
3八、Etag
就是一個對象(好比URL)的標誌值,就一個對象而言,好比一個html文件,若是被修改了,其Etag也會別修改,因此,ETag的做用跟Last-Modified的做用差很少,主要供WEB服務器判斷一個對象是否改變了。好比前一次請求某個html文件時,得到了其 ETag,當此次又請求這個文件時,瀏覽器就會把先前得到ETag值發送給WEB服務器,而後WEB服務器會把這個ETag跟該文件的當前ETag進行對比,而後就知道這個文件有沒有改變了。
3九、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
一、HTTP請求方式
說明:主要使用到「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屬性設置。
二、Host
說明:請求的web服務器域名地址
三、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
四、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信息。
五、Accept-Language
說明:指定HTTP客戶端瀏覽器用來展現返回信息所優先選擇的語言。
實例:Accept-Language: zh-cn,zh;q=0.5 這裏默認爲中文。
六、Accept-Encoding
說明:指定客戶端瀏覽器能夠支持的web服務器返回內容壓縮編碼類型。表示容許服務器在將輸出內容發送到客戶端之前進行壓縮,以節約帶寬。而這裏設置的就是客戶端瀏覽器所可以支持的返回壓縮格式。
實例:Accept-Encoding: gzip,deflate
備註:其實在百度不少產品線中,apache在給客戶端返回頁面數據以前,將數據以gzip格式進行壓縮。
七、Accept-Charset
說明:瀏覽器能夠接受的字符編碼集。
實例:Accept-Charset: gb2312,utf-8;q=0.7,*;q=0.7
八、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沒有多大做用。
九、Connection
說明:表示是否須要持久鏈接。若是web服務器端看到這裏的值爲「Keep-Alive」,或者看到請求使用的是HTTP 1.1(HTTP 1.1默認進行持久鏈接),它就能夠利用持久鏈接的優勢,當頁面包含多個元素時(例如Applet,圖片),顯著地減小下載所須要的時間。要實現這一點, web服務器須要在返回給客戶端HTTP頭信息中發送一個Content-Length(返回信息正文的長度)頭,最簡單的實現方法是:先把內容寫入ByteArrayOutputStream,然 後在正式寫出內容以前計算它的大小。
實例:Connection: keep-alive
十、Keep-Alive
說明:顯示此HTTP鏈接的Keep-Alive時間。使客戶端到服務器端的鏈接持續有效,當出現對服務器的後繼請求時,Keep-Alive功能避免了創建或者從新創建鏈接。之前HTTP請求是一站式鏈接,從HTTP/1.1協議以後,就有了長鏈接,即在規定的Keep-Alive時間內,鏈接是不會斷開的。
實例:Keep-Alive: 300
十一、cookie
說明:HTTP請求發送時,會把保存在該請求域名下的全部cookie值一塊兒發送給web服務器。
十二、Referer
說明:包含一個URL,用戶從該URL表明的頁面出發訪問當前請求的頁面
1三、HTTP Response的Header信息
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 | 用來重定向接收方到非請求URL的位置來完成請求或標識新的資源 | 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 |
HTTP響應碼響應碼由三位十進制數字組成,它們出如今由HTTP服務器發送的響應的第一行。響應碼分五種類型,由它們的第一位數字表示:
1xx:信息,請求收到,繼續處理
2xx:成功,行爲被成功地接受、理解和採納
3xx:重定向,爲了完成請求,必須進一步執行的動做
4xx:客戶端錯誤,請求包含語法錯誤或者請求沒法實現
5xx:服務器錯誤,服務器不能實現一種明顯無效的請求
下表顯示每一個響應碼及其含義:
100 繼續 | 101 分組交換協 | 200 OK | 201 被建立 | 202 被採納 |
203 非受權信息 | 204 無內容 | 205 重置內容 | 206 部份內容 | 300 多選項 |
301 永久地傳送 | 302 找到 | 303 參見其餘 | 304 未改動 | 305 使用代理 |
307 暫時重定向 | 400 錯誤請求 | 401 未受權 | 402 要求付費 | 403 禁止 |
404 未找到 | 405 不容許的方法 | 406 不被採納 | 407 要求代理受權 | 408 請求超時 |
409 衝突 | 410 過時的 | 411 要求的長度 | 412 前提不成立 | 413 請求實例太大 |
414 請求URI太大 | 415 不支持的媒體類型 | 416 沒法知足的請求範圍 | 417 失敗的預期 | 500 內部服務器錯誤 |
501 未被使用 | 502 網關錯誤 | 503 不可用的服務 | 504 網關超時 | 505 HTTP版本未被支持 |