#HTTP的頭域包括通用頭、請求頭、響應頭和實體頭四個部分。每一個頭域由一個域名,冒號和域值三部分組成。 #通用頭部: 是客戶端和服務器均可以使用的頭部,能夠在客戶端、服務器和其餘應用程序之間提供一些很是有用的通用功能,如Date頭部。 #請求頭部: 是請求報文特有的,它們爲服務器提供了一些額外信息,好比客戶端但願接收什麼類型的數據,如Accept頭部。 #響應頭部: 便於客戶端提供信息,好比,客服端在與哪一種類型的服務器進行交互,如Server頭部。 #實體頭部: 指的是用於應對實體主體部分的頭部,好比,能夠用實體頭部來講明實體主體部分的數據類型,如Content-Type頭部。
#請求報文和響應報文兩方都會使用的首部
#請求頭用於說明是誰或什麼在發送請求、請求源於何處,或者客戶端的喜愛及能力。服務器能夠根據請求頭部給出的客戶端信息,試着爲客戶端提供更好的響應
#響應頭向客戶端提供一些額外信息,好比誰在發送響應、響應者的功能,甚至與響應相關的一些特殊指令。這些頭部有助於客戶端處理響應,並在未來發起更好的請求
#實體頭部提供了有關實體及其內容的大量信息,從有關對象類型的信息,到可以對資源使用的各類有效的請求方法。總之,實體頭部能夠告知接收者它在對什麼進行處理。請求消息和響應消息均可以包含實體信息,實體信息通常由實體頭域和實體組成
#經過指定首部字段Cache-Control的指令,就能操做緩存的工做機制。
#① public指令 Cache-Control:public #設置爲public時 當指定public指令時,則明確表示其餘用戶也可利用緩存 #② private指令 Cache-Control:private #設置爲private時 當指定private指令時,響應只以特定的用戶做爲對象,這與public指令的行爲相反。緩存服務器會對該用戶提供資源緩存的服務,對於其餘用戶發送過來的請求,代理服務器不會返回緩存。 #③ no-cache指令 Cache-Control:no-cache no-cache指令的目的是爲了防止從緩存中返回過時的資源,緩存會向源服務器進行有效期確認後處理資源。 客戶端發送的請求中若是包含no-cache指令,則表示客戶端不會接收緩存過的響應,緩存服務器必須把客戶端請求轉發給源服務器。從源服務器返回最新資源後,緩存服務器依然能夠將最新資源進行緩存,而後再返回給客戶端,除非服務器端也返回no-cache指令。 服務端返回的響應中若是包含no-cache指令,那麼緩存服務器不能對資源進行緩存,源服務器之後也不會再對緩存服務器請求中提出的資源有效性進行確認。 Cache-Control:no-cache=Location 只能在響應指令中指定該參數,經過服務器端返回的指令來肯定客戶端是否可使用緩存。 客戶端在接收到這個被指定參數值的報文首部後,就不能使用緩存。換句話說,無參數值的首部字段可使用緩存。 # ④ no-store指令 Cache-Control:no-store 暗示請求或響應中包含機密信息,該指令規定不進行任何緩存。
#① s-maxage指令 Cache-Control:s-maxage=3600 (單位:秒) 它與max-age的指令相同,不一樣點是s-maxage只適用於供多位用戶使用的公共緩存服務器。對於向同一用戶重複返回響應的服務器來講,這個指令沒有任何做用。 使用這個指令後,會直接忽略對Expires首部字段及max-age指令的處理。 #② max-age指令 Cache-Control:max-age=3600 (單位:秒) 當客戶端發送的請求中包含該指令時,若是斷定緩存資源的緩存時間比指定的時間數值更小,那麼客戶端就接收緩存的資源。若是max-age的值爲0,那麼緩存服務器須要將請求轉發給源服務器。 當服務器返回的響應中包含該指令時,緩存服務器將不會對資源的有效性進行確認,此時max-age表明資源保存爲緩存的最長時間。 HTTP/1.1版本的緩存服務器遇到同時存在Expires首部字段的狀況時,會優先處理max-age指令,而忽略掉Expires首部字段。可是HTTP/1.0版本的緩存服務器狀況卻相反,max-age指令會被忽略掉。 #③ min-fresh指令 Cache-Control:min-fresh=60 (單位:秒) 這個指令要求緩存服務器返回還未過指定時間的緩存資源。 #④ max-stale指令 Cache-Control:max-stale=3600 (單位:秒) 指示緩存資源,即便過時,但只要處於max-stale指定的時間內仍然會被客戶端照常接收。若是該指令未指定相應參數,那麼不管過了 多久,客戶端都會接收響應。 #⑤ only-if-cached指令 Cache-Control:only-if-cached 該指令要求緩存服務器不從新加載響應,也不會再次確認資源有效性,若是請求緩存服務器的本地緩存無響應,則返回狀態碼504。 #⑥ must-revalidate指令 Cache-Control:must-revalidate 使用該指令時,代理會向源服務器再次驗證即將返回的響應緩存目前是否仍然有效,若代理沒法鏈接源服務器獲取有效資源的話,緩存必須給客戶端一個504的狀態碼。另外,使用該指令將忽略請求的max-stale指令。 #⑦ proxy-revalidate指令 Cache-Control:proxy-revalidate 當客戶端的請求包含該指令時,緩存服務器在返回響應以前,必須再次驗證緩存的有效性。 #⑧ no-transform指令 Cache-Control:no-transform 該指令規定不管在請求仍是在響應中,緩存都不能改變主體的媒體類型,這樣能夠防止緩存或代理壓縮圖片等相似操做。 #⑨ cache-extension token Cache-Control:private,community="UCI" 經過cache-extension標記(token),能夠擴展Cache-Control首部字段內的指令。如上添加了community這個新指令,若是緩存服務器不可以理解community這個新指令,就會直接忽略。所以,extension tokens僅對能理解它的緩存服務器有效。
#它有兩個做用: #① 控制再也不轉發給代理的首部字段 Connection:Upgrade (再也不轉發的首部字段名) //操做方式是將首部字段Upgrade刪除後再轉發 #② 管理持久鏈接 HTTP/1.1版本的默認鏈接都是持久鏈接(長鏈接),而後客戶端會在持久鏈接上連續發送請求,當服務器想明確斷開鏈接時,則指定Connection首部字段爲Close。 Connection:Close #若是關閉以後下次鏈接還須要三次握手 HTTP/1.1以前的版本默認的都是非持久鏈接(短鏈接),若是想在舊版本的HTTP協議上維持持續鏈接,則須要指定Connection的值爲Keep-Alive。 Keep-Alive:timeout=10,max=500 Connection:Keep-Alive
HTTP/1.1協議使用RFC1123中規定的日期時間的格式,以下: Date:Tue,03 Jul 2012 04:40:59 GMT HTTP/1.1以前的協議使用RFC850中定義的格式,以下: Date:Tue,03-Jul-12 04:40:59 GMT
#此字段會事先說明在報文主體後記錄了哪些首部字段,可用於HTTP/1.1版本分塊傳輸編碼時。 下例中,指定首部字段Trailer的值爲Expires,在報文主體以後(分塊長度0以後)出現了首部字段Expires。
#此字段規定了傳輸報文主體時使用的編碼方式,HTTP/1.1的傳輸編碼方式僅對分塊傳輸編碼有效。
#此字段用於檢測HTTP協議及其餘協議是否可使用更高的版本進行通訊,其參數值能夠用來指定一個徹底不一樣的通訊協議。 下例中,Upgrade對象僅限於客戶端和鄰接服務器之間,所以,在使用了Upgrade時,還須要額外指定Connection:Upgrade,對於附有Upgrade字段的請求,服務端可以使用101狀態碼做爲響應返回。
#此字段是爲了追蹤客戶端與服務端之間的請求和響應報文的傳輸路徑。報文在通過代理或網關時,會先在首部字段Via中附加該服務器的信息,而後再進行轉發,使用它能夠避免迴環的發生,因此必須在通過代理時附加該首部字段內容,以下:
Via首部爲了追蹤傳輸路徑,常常會和TRACE方法一塊兒使用。好比,代理服務器接收到由TRACE方法發送過來的請求(Max-Forwards:0)時,代理服務器就不能轉發該請求了,這種狀況下,代理服務器會將自身的信息附加到Via首部後,返回該請求的響應。
#該首部字段一般會告知用戶一些與緩存相關的一些問題的警告。格式以下: Warning:[警告碼][警告的主機:端口號]"[警告內容]"
它用在客戶端發送的請求中,客戶端會要求全部的中間服務器不返回緩存的資源。 Pragma:no-cache 它是HTTP/1.1以前版本的歷史遺留字段,僅做爲HTTP/1.0的向後兼容。若是全部的中間服務器都使用HTTP/1.1版本協議的話,那麼直接使用Cache-Control:no-cache是最理想的,但全部的中間服務器使用的HTTP協議版本並不徹底一致。所以,發送的請求會同時含有下面兩個字段。 Cache-Control:no-cache Pragma:no-cache
# 請求首部字段是從客戶端往服務端發送請求報文中所使用的字段,用於補充請求的附加信息、客戶端信息、對響應內容的優先級等內容。
#該首部字段可通知服務器,用戶代理能處理的媒體類型以及媒體類型的相對優先級, 可以使用type/subtype這種形式,一次指定多種媒體類型。 若是想要給顯示的媒體類型增長優先級,就使用q=來額外表示權重值,用" ; "進行分隔。權重值q的範圍是0~1(可精確到小數點後三位),且1爲最大值。不指定權重值時,默認q=1.0。當服務器提供多種內容時,將會首先返回媒體值最高的類型。 #Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
#該首部字段可用來通知服務器用戶代理支持的字符集及字符集的相對優先級順序。一樣,可一次性指定多個字符集,用q=來表示字符集的相對優先級。 Accept-Charset:iso-8859-5,unicode-1-1;q=0.8
#該首部字段可用來通知服務器用戶代理支持的內容編碼及內容編碼的優先級順序。一樣,可一次性指定多種內容編碼,用q=來表示內容編碼的相對優先級。 Accept-Encoding:gzip,deflate
# 該首部字段告知服務器用戶代理可以處理的天然語言集以及天然語言集的相對優先級。一樣,可一次指定多種天然語言集,用q=來表示天然語言集的相對優先級。 Accept-Language:zh-cn,zh;q=0.7,en-us,en;q=0.3
# 該首部字段用來告知服務器用戶代理的認證信息。一般,想要經過服務器認證的用戶代理會在接收到返回的401狀態碼響應以後,把首部字段Authorization加入請求中。共用緩存在接收到含有Authorization首部字段的請求時的操做處理有所差別。 Authorization:Basic dWVub3N1bjpwYXNzd29yZA==
#該首部字段用來告知服務器使用代理的用戶的電子郵件地址。一般,使用目的就是爲了顯示搜索引擎等用戶代理的負責人的電子郵件聯繫方式。使用代理時,應儘量使用該字段,但有的代理可能會將電子郵件地址在User-Agent首部字段內。 From:info@qq.com
Host:www.adcd.com #該首部字段會告知服務器,請求的資源所處的互聯網主機名和端口號。它是HTTP/1.1規範中惟一一個必須包含在請求內的首部字段。 因爲相同的IP地址下可能會部署運行多個域名,服務器就會沒法理解到底是哪一個域名對應的請求,所以就須要使用此字段來明確的指出請求的主機名。若是服務器沒有設定主機名,那直接發送一個空值便可,以下: Host:
#If-Match 形如If-xxx這種形式的請求首部字段,均可稱爲條件請求,服務器接收到附帶條件的請求後,只有判斷指定條件爲真時,纔會執行請求。 If-Match:"123456" 該首部字段會告知服務器匹配資源所使用的實體標記(ETag)值,這時的服務器沒法使用弱ETag值。服務器會比對If-Match的字段值和資源的ETag值,僅當再者一致時,纔會執行請求。反之,則返回狀態碼412的響應。也可使用" * "來指定If-Match的字段值,這時服務器將會忽略ETag的值,只要資源存在就處理請求。 #If-None-Match If-None-Match:* 該首部字段與If-Match的做用相反。 #If-Modified-Since If-Modified-Since:Thu,15 Apr 2004 00:00:00 GMT 該首部字段用於確認代理或客戶端擁有的本地資源的有效性。它會告知服務器在些字段指定的時間後資源發生了更新就處理該請求,若是請求的資源沒有更新過,則返回狀態碼304的響應。 #If-Unmodified-Since If-Modified-Since:Thu,15 Apr 2004 00:00:00 GMT 該首部字段與If-Modified-Since的做用相反。 If-Range If-Range:"123456" Range:bytes=5001-10000 該首部字段屬於附帶條件之一,它告訴服務器若指定的If-Range值(ETag值或時間)和請求資源的ETag值或時間相同時,則做爲範圍請求處理。不然,返回全體資源。 若是不使用該首部字段,就須要兩次處理
#Max-Forwards:10 經過Trace或Options的方法發送包含該首部字段的請求時,該字段以十進制整數形式指定可通過的服務器最大數目。服務器在往下一下服務器轉發請求以前,會將該首部字段的值減1後從新賦值。當值爲0時,請求再也不進行轉發,而是直接返回響應。
# 客戶端接收到從代理服務器發送過來的認證質詢時,客戶端會發送包含該首部字段的請求,以告知服務器認證所須要的信息。 Proxy-Authorization: Basic dGlwOjkpNLAGfFY5
#客戶端發送帶有該首部字段的請求能夠指定服務器資源的範圍。接收到該首部字段的服務器,會在處理請求以後返回狀態碼爲206 Partial Content的響應,若是沒法處理該範圍請求,則會返回狀態碼爲200 OK的響應及所有資源。 Range:bytes=5001-10000
#該首部字段會告知服務器請求的原始資源的URI。
#該首部字段會告知服務器客戶端可以處理響應的傳輸編碼方式以及相對優先級,它和Accept-Encoding的功能很像,可是TE只是用於傳輸編碼。 TE: gzip, deflate;q=0.5 #首部字段TE除指定傳輸編碼以外,還能夠指定伴隨trailer字段的分塊傳輸編碼的方式。這時須要把trailers賦值給該字段值。以下所示: TE: trailers
# 該首部字段將會建立請求的瀏覽器和用戶代理名稱等信息傳達給服務器。
# 響應首部字段是由服務器端向客戶端返回響應報文中所使用的字段,用於補充響應的附加信息、服務器信息,以及對客戶端的附加要求等信息。
# 該首部字段是用於告知客戶端服務器是否能處理範圍請求,以指定獲取服務器端某個部分的資源。它能夠指定的字段值有兩種,可處理範圍請求時指定其爲bytes,反之則指定爲none。
#該首部字段能夠告知客戶端,源服務器在多久前建立了響應,字段值的單位爲秒。若建立該響應的服務器是緩存服務器,Age值是指緩存後的響應再次發起認證到認證完成的時間值。代理建立響應時必須加上首部字段Age。 Age:600
ETag: "82e22293907ce725faf67773957acd12" 首部字段 ETag 能告知客戶端實體標識。它是一種可將資源以字符串形式作惟一性標識的方式。服務器會爲每份資源分配對應的 ETag值。 ① 強ETag ETag: "usagi-1234" 強 ETag 值,不論實體發生多麼細微的變化都會改變其值。 ② 弱ETag ETag: W/"usagi-1234" Proxy-Authenticate: Basic realm="Usagidesign Auth" 弱 ETag 值只用於提示資源是否相同。只有資源發生了根本改變,產生差別時纔會改變 ETag 值。這時,會在字段值最開始處附加 W/。
#使用首部字段 Location 能夠將響應接收方引導至某個與請求 URI 位置不一樣的資源。基本上, #該字段會配合 3xx :提供重定向的URI。幾乎全部的瀏覽器在接收到包含首部字段 Location 的響應後,都會強制性地嘗試對已提示的重定向資源進行訪問。 Location: http://www.baidu.com
# 該首部字段會把由代理服務器所要求的認證信息發送給客戶端。它與客戶端和服務器之間的 HTTP 訪問認證的行爲類似,不一樣之處在於其認證行爲是在客戶端與代理之間進行的。而客戶端與服務器之間進行認證時,首部字段 WWW-Authorization 有着相同的做用。 Proxy-Authenticate: Basic realm="Usagidesign Auth"
#該首部字段告知客戶端應該在多久以後再次發送請求。主要配合狀態碼 503 Service Unavailable 響應,或 3xx Redirect 響應一塊兒使用。字段值能夠指定爲具體的日期時間(Wed, 04 Jul 2012 06:34:24GMT 等格式),也能夠是建立響應後的秒數。 Retry-After: 120
#該首部字段告知客戶端當前服務器上安裝的 HTTP 服務器應用程序的信息。不僅僅會標出服務器上的軟件應用名稱,還有可能包括版本號和安裝時啓用的可選項。 Server: Apache/2.2.17 (Unix)
# 當代理服務器接收到帶有 Vary 首部字段指定獲取資源的請求時,若是與使用的 Accept-Language 字段的值相同,那麼就直接從緩存返回響應。反之,則須要先從源服務器端獲取資源後才能做爲響應返回。 首部字段 Vary 可對緩存進行控制。源服務器會向代理服務器傳達關於本地緩存使用方法的命令。從代理服務器接收到源服務器返回包含 Vary 指定項的響應以後,若再要進行緩存,僅對請求中含有相同 Vary 指定首部字段的請求返回緩存。即便對相同資源發起請求,但因爲 Vary 指定的首部字段不相同,所以必需要從源服務器從新獲取資源。 Vary: Accept-Language
該首部字段用於 HTTP 訪問認證。它會告知客戶端適用於訪問請求 URI 所指定資源的認證方案(Basic 或是 Digest)和帶參數提示的質詢(challenge)。狀態碼 401 Unauthorized 響應中,確定帶有首部字段 WWW-Authenticate。 WWW-Authenticate: Basic realm="Usagidesign Auth"
#實體首部字段是包含在請求報文和響應報文中的實體部分所使用的首部,用於補充內容的更新時間等與實體相關的信息。
#一、Allow Allow: GET, HEAD 該首部字段用於通知客戶端可以支持 Request-URI 指定資源的全部 HTTP 方法。當服務器接收到不支持的 HTTP 方法時,會以狀態碼405 Method Not Allowed 做爲響應返回。與此同時,還會把全部能支持的 HTTP 方法寫入首部字段 Allow 後返回。 二、Content-Encoding Content-Encoding: gzip 該首部字段會告知客戶端服務器對實體的主體部分選用的內容編碼方式。內容編碼是指在不丟失實體信息的前提下所進行的壓縮。 主要採起4種方式的壓縮:gzip、compress、deflate、identity 三、Content-Language Content-Language: zh-CN 該首部字段會告知客戶端,實體主體使用的天然語言(指中文或英文等語言)。 四、Content-Length Content-Length: 15000 首部字段 Content-Length 代表了實體主體部分的大小(單位是字節)。對實體主體進行內容編碼傳輸時,不能再使用 Content-Length首部字段。 五、Content-Location Content-Location: http://www.hackr.jp/index-ja.html 該首部字段給出與報文主體部分相對應的 URI。和首部字段 Location 不一樣,Content-Location 表示的是報文主體返回資源對應的 URI。 六、Content-MD5 Content-MD5: OGFkZDUwNGVhNGY3N2MxMDIwZmQ4NTBmY2IyTY== 該首部字段是一串由 MD5 算法生成的值,其目的在於檢查報文主體在傳輸過程當中是否保持完整,以及確認傳輸到達。 對報文主體執行 MD5 算法得到的 128 位二進制數,再經過 Base64 編碼後將結果寫入 Content-MD5 字段值。因爲 HTTP 首部沒法記錄二進制值,因此要經過 Base64 編碼處理。爲確保報文的有效性,做爲接收方的客戶端會對報文主體再執行一次相同的 MD5 算法。計算出的125值與字段值做比較後,便可判斷出報文主體的準確性。 採用這種方法,對內容上的偶發性改變是無從查證的,也沒法檢測出惡意篡改。其中一個緣由在於,內容若是可以被篡改,那麼同時意味着 Content-MD5 也可從新計算而後被篡改。因此處在接收階段的客戶端是沒法意識到報文主體以及首部字段 Content-MD5 是已經被篡改過的。 七、Content-Range Content-Range: bytes 5001-10000/10000 針對範圍請求,返回響應時使用的首部字段 Content-Range,能告知客戶端做爲響應返回的實體的哪一個部分符合範圍請求。字段值以字節爲單位,表示當前發送部分及整個實體大小。 八、Content-Type Content-Type: text/html; charset=UTF-8 該首部字段說明了實體主體內對象的媒體類型。和首部字段 Accept 同樣,字段值用 type/subtype 形式賦值。參數 charset 使用 iso-8859-1 或 euc-jp 等字符集進行賦值。 9、Expires Expires: Wed, 04 Jul 2012 08:26:05 GMT 首部字段 Expires 會將資源失效的日期告知客戶端。緩存服務器在接收到含有首部字段 Expires 的響應後,會以緩存來應答請求,在Expires 字段值指定的時間以前,響應的副本會一直被保存。當超過指定的時間後,緩存服務器在請求發送過來時,會轉向源服務器請求資源。源服務器不但願緩存服務器對資源緩存時,最好在 Expires 字段內寫入與首部字段 Date 相同的時間值。可是,當首部字段 Cache-Control 有指定 max-age 指令時,比起首部字段 Expires,會優先處理 max-age 指令。 十、Last-Modified Last-Modified: Wed, 23 May 2012 09:59:55 GMT 該首部字段指明資源最終修改的時間。通常來講,這個值就是 Request-URI 指定資源被修改的時間。但相似使用 CGI 腳本進行動態數據處理時,該值有可能會變成數據最終修改時的時間。 ———————————————— 版權聲明:本文爲CSDN博主「_雲捲雲舒_」的原創文章,遵循 CC 4.0 BY-SA 版權協議,轉載請附上原文出處連接及本聲明。 原文連接:https://blog.csdn.net/alexshi5/article/details/80379086
#管理服務器與客戶端之間狀態的 Cookie,
Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31 GMT; pat #響應首部字段。當服務器準備開始管理客戶端的狀態時,會事先告知各類信息。下表是Set-Cookie字段的屬性。
Cookie: status=enable #請求首部字段。首部字段 Cookie 會告知服務器,當客戶端想得到 HTTP 狀態管理支持時,就會在請求中包含從服務器接收到的 Cookie。接收到多個Cookie 時,一樣能夠以多個 Cookie 形式發送。