HTTP協(xié)議詳解

1. HTTP介紹

2. HTTP 1.0 和 HTTP 1.1

2.1 HTTP 1.0

2.2 HTTP 1.1

1. HTTP介紹

2. HTTP 1.0 和 HTTP 1.1

2.1 HTTP 1.0

2.2 HTTP 1.1

3. HTTP消息

4. HTTP請(qǐng)求消息

4.1 HTTP請(qǐng)求行

1. GET 請(qǐng)求方式

2. POST 請(qǐng)求方式

5. 測(cè)試GET請(qǐng)求方式

6. 測(cè)試POST請(qǐng)求方式

7. HTTP請(qǐng)求消息頭

1. Accept

2. Accept-Charset

3. Accept-Encoding

4. Accept-Language

5. Authorization(授權(quán))與Proxy-Authorization

6. Host

7. If-Match

8. If-Modified-Since

9. Range和If-Range

10. Max-Forward

11. Referer

12. User-Agent

8. HTTP 響應(yīng)消息

1. HTTP響應(yīng)狀態(tài)行

2. HTTP 響應(yīng)消息頭

1. Accept-Range

2. Age

3. Etag

4. Location

5. Retry-After

6. Server

7. Vary

8. WWW-Authenticate和Proxy-Authenticate

9. Refresh

10. Content-Disposition

3. HTTP其他頭字段

1. 通用頭字段

1. Cache-Control

2. Connection

3. Data

4. Pragma

5. Transfer-Encoding

6. Trailer

7. Upgrade

8. Via

9. Warning

2. 實(shí)體頭字段

1. Allow

2. Content-Language

3. Content-Length

4. Content-Location

5. Content-Range

6. Content-MD5

7. Content-Type

1. HTTP介紹

HTTP是 Hyper Text Transfer Protocol的縮寫,即超文本傳輸協(xié)議。它是一種請(qǐng)求/響應(yīng)式的協(xié)議,客戶端在與服務(wù)器端建立連接后,就可以向服務(wù)器端發(fā)送請(qǐng)求,這種請(qǐng)求被稱作HTTP請(qǐng)求,服務(wù)器端接收到請(qǐng)求后會(huì)做出響應(yīng),稱為HTTP響應(yīng),客戶端與服務(wù)器端在HTTP 下的交互過(guò)程如圖3-1所示。

從圖3-1中可以清楚地看到客戶端與服務(wù)端使用HTTP通信的過(guò)程，接下來(lái)總結(jié)一下HTTP協(xié)議的特點(diǎn),具體如下。

(1) 支持客戶端(瀏覽器就是一種 Web客戶端)/服務(wù)器模式。

(2) 簡(jiǎn)單快速:客戶端向服務(wù)器請(qǐng)求服務(wù)時(shí),只需傳送請(qǐng)求方式和路徑。常用的請(qǐng)求方式有GET、POST等,每種方式規(guī)定了客戶端與服務(wù)器聯(lián)系的類型不同。由于 HTTP簡(jiǎn)單,使得HTTP服務(wù)器的程序規(guī)模小,因而通信速度很快。

(3) 靈活:HTTP 允許傳輸任意類型的數(shù)據(jù),正在傳輸?shù)臄?shù)據(jù)類型由 Content-Type 加以標(biāo)記。

(4) 無(wú)狀態(tài):HTTP是無(wú)狀態(tài)協(xié)議。無(wú)狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒(méi)有記憶能力，如果后續(xù)處理需要前面的信息,則它必須重傳,這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。

2. HTTP 1.0 和 HTTP 1.1

HTTP自誕生以來(lái),先后經(jīng)歷了很多版本,其中,最早的版本是 HTTP 0.9,它1990年被提出。后來(lái),為了進(jìn)一步完善HTTP,先后在1996年提出了版本1.0,在1997年提出了版本1.1。由于HTTP 0.9版本已經(jīng)過(guò)時(shí),這里不作過(guò)多講解。接下來(lái),只針對(duì)HTTP 1.0和 HTTP 1.1進(jìn)行詳細(xì)地講解。

2.1 HTTP 1.0

基于HTTP1.0協(xié)議的客戶端與服務(wù)器在交互過(guò)程中需要經(jīng)過(guò)建立連接、發(fā)送請(qǐng)求信息、回送響應(yīng)信息、關(guān)閉連接4個(gè)步驟,具體交互過(guò)程如圖3-2所示。

從圖3-2中可以看出,客戶端與服務(wù)器建立連接后,每次只能處理一個(gè) HTTP請(qǐng)求。對(duì)于內(nèi)容豐富的網(wǎng)頁(yè)來(lái)說(shuō),這樣的通信方式明顯有缺陷。例如,下面的一段HTML代碼:

上面的 HTML文檔中包含三個(gè)標(biāo)記,由于標(biāo)記的src屬性指明的是圖片的 URL 地址,因此,當(dāng)客戶端訪問(wèn)這些圖片時(shí),還需要發(fā)送三次請(qǐng)求,并且每次請(qǐng)求都需要與服務(wù)器重新建立連接。如此一來(lái),必然導(dǎo)致客戶端與服務(wù)器端交互耗時(shí),影響網(wǎng)頁(yè)的訪問(wèn)速度。

2.2 HTTP 1.1

為了克服上述HTTP 1.0的缺陷,HTTP1.1版本應(yīng)運(yùn)而生,它支持持久連接，也就是說(shuō)在一個(gè) TCP 連接上可以傳送多個(gè) HTTP 請(qǐng)求和響應(yīng),從而減少了建立和關(guān)閉連接的消耗和延時(shí)。基于 HTTP 1.1的客戶端和服務(wù)器端的交互過(guò)程,如圖3-3所示。

從圖3-3中可以看出,當(dāng)客戶端與服務(wù)器端建立連接后,客戶端可以向服務(wù)器端發(fā)送多個(gè)請(qǐng)求,并且在發(fā)送下個(gè)請(qǐng)求時(shí),無(wú)須等待上次請(qǐng)求的返回結(jié)果。但服務(wù)器必須按照接受客戶端請(qǐng)求的先后順序依次返回響應(yīng)結(jié)果,以保證客戶端能夠區(qū)分出每次請(qǐng)求的響應(yīng)內(nèi)容。由此可見,HTTP 1.1不僅繼承了HTTP 1.0的優(yōu)點(diǎn),而且有效解決了HTTP 1.0的性能問(wèn)題,顯著地減少了瀏覽器與服務(wù)器交互所需要的時(shí)間。

3. HTTP消息

當(dāng)用戶在瀏覽器中訪問(wèn)某個(gè) URL地址,單擊網(wǎng)頁(yè)的某個(gè)超鏈接或者提交網(wǎng)頁(yè)上的form表單時(shí),瀏覽器都會(huì)向服務(wù)器發(fā)送請(qǐng)求數(shù)據(jù),即 HTTP請(qǐng)求消息。服務(wù)器接收到請(qǐng)求數(shù)據(jù)后,會(huì)將處理后的數(shù)據(jù)回送給客戶端,即 HTTP 響應(yīng)消息。HTTP請(qǐng)求消息和HTTP響應(yīng)消息統(tǒng)稱為HTTP消息。

在HTTP消息中,除了服務(wù)器端的響應(yīng)實(shí)體內(nèi)容(HTML 網(wǎng)頁(yè)、圖片等)以外,其他信息對(duì)用戶都是不可見的,要想觀察這些“隱藏”的信息，需要借助一些網(wǎng)絡(luò)查看工具，如：F12等。

(1) 在瀏覽器的地址欄中輸入 www.baidu.com 訪問(wèn)百度首頁(yè),在F12中可以看到請(qǐng)求的 URL地址,如圖所示。

(2) 單擊URL地址左邊的Name,在展開的默認(rèn)頭信息選項(xiàng)卡中可以看到格式化后的響應(yīng)頭信息和請(qǐng)求頭信息。單擊請(qǐng)求頭信息一欄左邊的“原始頭信息”,可以看到原始的請(qǐng)求頭信息,具體如下所示;

在上述請(qǐng)求消息中,第一行為請(qǐng)求行,請(qǐng)求行后面的為請(qǐng)求頭消息,空行代表請(qǐng)求頭的結(jié)束。

(3) 單擊響應(yīng)頭信息一欄左邊的“原始頭信息”,可以看到原始的響應(yīng)頭信息,如下所示:

在上面的響應(yīng)消息中,第一行為響應(yīng)狀態(tài)行,響應(yīng)狀態(tài)行后面的為響應(yīng)消息頭,空行代表響應(yīng)消息頭的結(jié)束。

4. HTTP請(qǐng)求消息

在 HTTP中，一個(gè)完整的請(qǐng)求消息是由請(qǐng)求行、請(qǐng)求頭和實(shí)體內(nèi)容三部分組成,其中,每部分都有各自不同的作用。本節(jié)將圍繞HTTP請(qǐng)求消息的每個(gè)組成部分進(jìn)行詳細(xì)的講解。

4.1 HTTP請(qǐng)求行

HTTP請(qǐng)求行位于請(qǐng)求消息的第一行,它包括三個(gè)部分,分別是請(qǐng)求方式、資源路名以及所使用的HTTP版本,具體示例如下:

GET /index.html HTTP/1.1

上面的示例就是一個(gè)HTTP請(qǐng)求行,其中,GET是請(qǐng)求方式, index.html是請(qǐng)求源路徑,HTTP/1.1是通信使用的協(xié)議版本。需要注意的是,請(qǐng)求行中的每個(gè)部分需要用空格分隔,最后要以回車換行結(jié)束。

關(guān)于請(qǐng)求資源和協(xié)議版本,讀者都比較容易理解,而 HTTP請(qǐng)求方式對(duì)讀者來(lái)說(shuō)比較陌生,接下來(lái)就針對(duì)HTTP的請(qǐng)求方式進(jìn)行具體分析。

在 HTTP的請(qǐng)求消息中,請(qǐng)求方式有GET,POST、 HEAD、OPTIONS、 DELETE,TRACE、PUT和 CONNECT共8種,每種方式都指明了操作服務(wù)器中指定URI資源的方式,它們表示的含義如表3-1所示。

表3-1中列舉了HTTP的8種請(qǐng)求方式,其中最常用的就是GET和POST 方式,接下來(lái),針對(duì)這兩種請(qǐng)求方式進(jìn)行詳細(xì)講解,具體如下所示。

1. GET 請(qǐng)求方式

當(dāng)用戶在瀏覽器地址欄中直接輸入某個(gè)URL地址或者單擊網(wǎng)頁(yè)上的一個(gè)超鏈接時(shí),瀏覽器將使用GET 方式發(fā)送請(qǐng)求。如果將網(wǎng)頁(yè)上的form表單的method屬性設(shè)置為“GET”或者不設(shè)置method屬性(默認(rèn)值是GET),當(dāng)用戶提交表單時(shí),瀏覽器也將使用GET方式發(fā)送請(qǐng)求。

如果瀏覽器請(qǐng)求的URL中有參數(shù)部分,在瀏覽器生成的請(qǐng)求消息中,參數(shù)部分將附加在請(qǐng)求行中的資源路徑后面。先來(lái)看一個(gè)URL地址,具體如下，

http://wwrw.xdr630.com/javaForm?username=xdr630&password=123456

在上述URL中，“?”后面的內(nèi)容為參數(shù)信息。參數(shù)是由參數(shù)名和參數(shù)值組成的,并且中間使用等號(hào)(=)進(jìn)行連接。需要注意的是,如果URL地址中有多個(gè)參數(shù),參數(shù)之間需要用“&”分隔。

當(dāng)瀏覽器向服務(wù)器發(fā)送請(qǐng)求消息時(shí),上述 URL中的參數(shù)部分會(huì)附加在要訪問(wèn)的URI咨源后面.具體加下所示，

GET /javaForm?username=xdr630&password=123456 HTTP/1.1

需要注意的是,使用GET方式傳送的數(shù)據(jù)量有限,最多不能超過(guò)1KB.

2. POST 請(qǐng)求方式

如果網(wǎng)頁(yè)上form表單的method 屬性設(shè)置為“POST”,當(dāng)用戶提交表單時(shí),瀏覽器將使用POST方式提交表單內(nèi)容,并把各個(gè)表單元素及數(shù)據(jù)作為HTTP消息的實(shí)體內(nèi)容發(fā)送給服務(wù)器,而不是作為URI地址的參數(shù)傳遞。另外,在使用POST方式向服務(wù)器傳遞數(shù)據(jù)時(shí)， Content-Type消息頭會(huì)自動(dòng)設(shè)為“application/x-www-form-urlencoded”,Content-Length消息頭會(huì)自動(dòng)設(shè)置為實(shí)體內(nèi)容的長(zhǎng)度,具體示例如下:

POST /javaForm HTTP/1.1 Host: www.xdr630.com Content-Type: application/x-www-form-urlencoded Content-Length: 17 username=xdr630&password=123456

對(duì)于使用POST方式傳遞的請(qǐng)求信息,服務(wù)器端程序會(huì)采用與獲取URI后面參數(shù)相同的方式來(lái)獲取表單各個(gè)字段的數(shù)據(jù)。

需要注意的是，在實(shí)際開發(fā)中,通常都會(huì)使用POST方式發(fā)送請(qǐng)求,其原因主要有兩個(gè),具體如下。

POST 傳輸數(shù)據(jù)大小無(wú)限制

由于GET請(qǐng)求方式是通過(guò)請(qǐng)求參數(shù)傳遞數(shù)據(jù)的,因此最多可傳遞1KB的數(shù)據(jù)。而POST請(qǐng)求方式是通過(guò)實(shí)體內(nèi)容傳遞數(shù)據(jù)的,因此可以傳遞數(shù)據(jù)的大小沒(méi)有限制

POST比 GET請(qǐng)求方式更安全

由于 GET請(qǐng)求方式的參數(shù)信息都會(huì)在URL地址欄明文顯示,而POST請(qǐng)求方式傳遞的參數(shù)隱藏在實(shí)體內(nèi)容中,用戶是看不到的,因此,POST 比 GET 請(qǐng)求方式更安全。

5. 測(cè)試GET請(qǐng)求方式

(1) 創(chuàng)建一個(gè)HTML文件，GET.html，如下所示：

GET.html

提交后：這時(shí)地址欄中的URL地址發(fā)生了變化，在原有的URL地址后面附加上了參數(shù)信息

查看顯示的請(qǐng)求頭信息，發(fā)現(xiàn)在請(qǐng)求行的URL請(qǐng)求資源后附加了參數(shù)信息，如圖

而在Query String Parameters

6. 測(cè)試POST請(qǐng)求方式

POST.html

提交后，URL地址欄沒(méi)有變化。F12查看發(fā)現(xiàn)請(qǐng)求的參數(shù)被加密了

F12查看，發(fā)現(xiàn)在請(qǐng)求消息中多了兩個(gè)請(qǐng)求消息頭

新添加的兩個(gè)消息頭中，Content-Type表示實(shí)體內(nèi)容的數(shù)據(jù)格式，Content-Length表示實(shí)體的內(nèi)容長(zhǎng)度。

F12 中看到 Form Data 就是提交的表單信息，也就是HTTP請(qǐng)求消息的實(shí)體內(nèi)容，也就是說(shuō)，在POST請(qǐng)求方式中，表單的內(nèi)容將作為實(shí)體內(nèi)容提交給服務(wù)器。

7. HTTP請(qǐng)求消息頭

在HTTP請(qǐng)求消息中,請(qǐng)求行之后,便是若干請(qǐng)求消息頭。請(qǐng)求消息頭主要用于向服務(wù)器端傳遞附加消息,例如,客戶端可以接收的數(shù)據(jù)類型、壓縮方法、語(yǔ)言以及發(fā)送請(qǐng)求的超鏈接所屬頁(yè)面的URL地址等信息,具體示例如下:

從上面的請(qǐng)求消息頭中可以看出,每個(gè)請(qǐng)求消息頭都是由一個(gè)頭字段名稱和一個(gè)值構(gòu)成，頭字段名稱和值之間用冒號(hào)(:)和空格()分隔,每個(gè)請(qǐng)求消息頭之后使用一個(gè)回車換行符標(biāo)志結(jié)束。需要注意的是,頭字段名稱不區(qū)分大小寫,但習(xí)慣上將單詞的第一個(gè)字母大寫。

當(dāng)瀏覽器發(fā)送請(qǐng)求給服務(wù)器時(shí),根據(jù)功能需求的不同,發(fā)送的請(qǐng)求消息頭也不相同，接下來(lái),針對(duì)一些常用的請(qǐng)求頭字段進(jìn)行詳細(xì)講解。

1. Accept

Accept頭字段用于指出客戶端程序(通常是瀏覽器)能夠處理的 MIME(Multi-purpose Internet Mail Extensions,多用途互聯(lián)網(wǎng)郵件擴(kuò)展)類型。例如如果瀏覽器和服

務(wù)器同時(shí)支持 png類型的圖片,則瀏覽器可以發(fā)送包含 image/png的Accept頭字段,服務(wù)器檢查到Accept頭中包含image/png這種 MIME類型,可能在網(wǎng)頁(yè)中的img元素中使用png類型的文件。MIME類型有很多種,例如,下面的這些 MIME類型都可以作為Accept頭字段的值。

2. Accept-Charset

Accept-Charset 頭字段用于告知服務(wù)器端客戶端所使用的字符集,具體示例如下:

Accept-Charset: ISO-8859-1

在上面的請(qǐng)求頭中,指出客戶端服務(wù)器使用ISO-8859-1字符集。如果想指定多種字符集,則可以在 Accept-Charset頭字段中將指定的多個(gè)字符集以逗號(hào)分隔，具體示例如下:

Accept-Charset: ISO-8859-1,unicode-1-1

需要注意的是,如果Accept-Charset頭字段沒(méi)有在請(qǐng)求頭中出現(xiàn),則說(shuō)明客戶端能接受使用任何字符集的數(shù)據(jù)。

如果Accept-Charset頭出現(xiàn)在請(qǐng)求消息里,但是服務(wù)器不能發(fā)送采用客戶端期望字符集編碼的文檔,那么服務(wù)器將發(fā)送一個(gè)406錯(cuò)誤狀態(tài)響應(yīng),406是一個(gè)響應(yīng)狀態(tài)碼,表示服務(wù)器返回內(nèi)容使用的字符集與Accept-Charset頭字段指定的值不兼容,關(guān)于狀態(tài)碼的相關(guān)知識(shí),將在后面的章節(jié)進(jìn)行詳細(xì)講解。

3. Accept-Encoding

Accept-Encoding頭字段用于指定客戶端能夠進(jìn)行解碼的數(shù)據(jù)編碼方式,這里的編碼方式通常指的是某種壓縮方式。在 Accept-Encoding頭字段中,可以指定多個(gè)數(shù)據(jù)編碼方式,它們之間以逗號(hào)分隔,具體示例如下:

Accept-Encoding: gzip,compress

在上面的頭字段中，gzip和 compress這兩種格式是最常見的數(shù)據(jù)編碼方式。在傳輸較大的實(shí)體內(nèi)容之前,對(duì)其進(jìn)行壓縮編碼,可以節(jié)省網(wǎng)絡(luò)帶寬和傳輸時(shí)間。服務(wù)器接收到這個(gè)請(qǐng)求頭,它使用其中指定的一種格式對(duì)原始文檔內(nèi)容進(jìn)行壓縮編碼，然后再將其作為響應(yīng)消息的實(shí)體內(nèi)容發(fā)送給客戶端,并且在 Content-Encoding響應(yīng)頭中指出實(shí)體內(nèi)容所使用的壓縮編碼格式。瀏覽器在接收到這樣的實(shí)體內(nèi)容之后,需要對(duì)其進(jìn)行反向解壓縮。

需要注意的是,Accept-Encoding 和Accept消息頭不同，Accept請(qǐng)求頭指定的MIME類型是指解壓后的實(shí)體內(nèi)容類型,Accept-Encoding消息頭指定的是實(shí)體內(nèi)容壓縮的方式。

4. Accept-Language

Accept-Language頭字段用于指定客戶端期望服務(wù)器返回哪個(gè)國(guó)家語(yǔ)言的文檔,它的值可以指定多個(gè)國(guó)家的語(yǔ)言,語(yǔ)言之間用逗號(hào)分隔,具體示例如下:

Accept-Language: zh-CN,en-us

在上述示例中, zh-cn代表中文(中國(guó)),en-us代表英語(yǔ)(美國(guó))，這些值不需要記憶。

需要注意的是,瀏覽器會(huì)根據(jù)“語(yǔ)言首選項(xiàng)”對(duì)話框中語(yǔ)言列表的先后順序,生成相應(yīng)的Accept-Language消息頭。

服務(wù)器只要檢查Accept-Language請(qǐng)求頭中的信息,按照其中設(shè)置的國(guó)家語(yǔ)言的先后順序,首先選擇返回位于前面的國(guó)家語(yǔ)言的網(wǎng)頁(yè)文檔,如果不能返回,則依次返回后面的國(guó)家語(yǔ)言的網(wǎng)頁(yè)文檔。

5. Authorization(授權(quán))與Proxy-Authorization

當(dāng)客戶端訪問(wèn)受口令保護(hù)的網(wǎng)頁(yè)時(shí), Web服務(wù)器會(huì)發(fā)送401響應(yīng)狀態(tài)碼和WWW-Authenticate響應(yīng)頭，要求客戶端使用Authorization請(qǐng)求頭來(lái)應(yīng)答。根據(jù) WWW-Authenticate響應(yīng)頭指定的認(rèn)證方式不同,Authorization請(qǐng)求頭中的內(nèi)容格式也不一樣。WWW-Authenticate響應(yīng)頭指定的認(rèn)證方式有兩種:BASIC 和 DIGEST。對(duì)于BASIC認(rèn)證方式,客戶端需要把用戶名和密碼用“:”分隔,然后經(jīng)過(guò) Base64編碼之后傳送給Web服務(wù)器。

例如,將用戶名為Ann、密碼為666888的用戶信息“Ann:666888”進(jìn)行 Base64編碼，形成的 Authorization請(qǐng)求頭字段內(nèi)容如下所示:

Authorization: Basic Qw5uOjY2Njg4OA==

然而,使用Base64編碼的數(shù)據(jù)很容易被解碼,這實(shí)際上相當(dāng)于是一種未加密的明文傳送方式,裝備了網(wǎng)絡(luò)監(jiān)視工具的計(jì)算機(jī)截獲到該信息后,很容易破解出用戶名和密碼。

如果使用DIGEST認(rèn)證方式,服務(wù)器首先向?yàn)g覽器發(fā)送一些用于驗(yàn)證過(guò)程的信息及附加信息,瀏覽器將這些信息與用戶名和密碼以及某些其他信息進(jìn)行混合后,再執(zhí)行MD5加密算法,將得到的結(jié)果和附加信息一起以明文文本通過(guò)網(wǎng)絡(luò)發(fā)送給服務(wù)器。服務(wù)器也使用與客戶端一樣的信息和附加信息,將它們和所保存的客戶端密碼執(zhí)行散列算法,然后將計(jì)算結(jié)果和客戶端的結(jié)果進(jìn)行比較,只有這兩個(gè)數(shù)字完全相同才允許訪問(wèn)。

Proxy-Authorization頭字段的作用和用法與Authorization頭字段基本相同,只不過(guò)Proxy-Authorization請(qǐng)求頭是服務(wù)器端向代理服務(wù)器發(fā)送的驗(yàn)證信息。

6. Host

Host頭字段用于指定資源所在的主機(jī)名和端口號(hào),格式與資源的完整URL中的主機(jī)名和端口號(hào)部分相同,具體示例如下所示:

Host: www.xdr630.top

在上述示例中,由于瀏覽器連接服務(wù)器時(shí)默認(rèn)使用的端口號(hào)為80,所以“www.xdr630.top”后面的端口號(hào)信息“:80”可以省略。

需要注意的是,在HTTP 1.1中,瀏覽器和其他客戶端發(fā)送的每個(gè)請(qǐng)求包含Host請(qǐng)求頭子段,以便訪問(wèn)Web站點(diǎn)時(shí),會(huì)根據(jù)地址欄中的URL地端所要訪問(wèn)的虛擬Web站點(diǎn)。當(dāng)瀏覽器訪問(wèn)Web站點(diǎn)時(shí),會(huì)根據(jù)地址欄中的URL地址自動(dòng)生成相應(yīng)的Host請(qǐng)求頭。

7. If-Match

瀏覽器和代理服務(wù)器都可以緩存服務(wù)器回送的網(wǎng)頁(yè)文檔。當(dāng)用戶再次訪問(wèn)已緩存的頁(yè)面時(shí),只有網(wǎng)頁(yè)內(nèi)容已被更新,服務(wù)器才需要把該頁(yè)面的內(nèi)容重新回送到客戶端,否則會(huì)通知瀏覽器訪問(wèn)本地緩存的頁(yè)面,以減少不必要的網(wǎng)絡(luò)傳輸流量。當(dāng)服務(wù)器為客戶端傳送網(wǎng)頁(yè)文件的內(nèi)容時(shí),可以傳輸一些代表實(shí)體內(nèi)容特征的頭字段,這些頭字段被稱為實(shí)體標(biāo)簽。當(dāng)客戶機(jī)再次向服務(wù)器請(qǐng)求這個(gè)網(wǎng)頁(yè)文件時(shí),可以使用If-Match頭字段附帶以前緩存的實(shí)體標(biāo)簽內(nèi)容,這個(gè)請(qǐng)求被視為一個(gè)條件請(qǐng)求,例如:

If-Match: "repository"

其中,"repository"是客戶端上次訪問(wèn)Web服務(wù)器中的該頁(yè)面時(shí),服務(wù)器使用ETag實(shí)體標(biāo)簽傳送的內(nèi)容,具體示例如下所示:

ETag: "repository"

服務(wù)器收到客戶端的請(qǐng)求后,會(huì)檢索If-Match頭中的實(shí)體標(biāo)簽內(nèi)容,并與服務(wù)器端的代表當(dāng)前網(wǎng)頁(yè)內(nèi)容特征的實(shí)體標(biāo)簽內(nèi)容進(jìn)行比較。如果兩者相同,則表示網(wǎng)頁(yè)內(nèi)容沒(méi)有更改,Web服務(wù)器不返回網(wǎng)頁(yè)文檔,讓客戶端仍然使用以前緩存的網(wǎng)頁(yè)文檔。否則,服務(wù)器返回新的網(wǎng)頁(yè)文件和新的實(shí)體標(biāo)簽內(nèi)容頭字段。

8. If-Modified-Since

If-Modified-Since請(qǐng)求頭的作用和 If-Mach類似,只不過(guò)它的值為GMT格式的時(shí)間。If-Modified-Since請(qǐng)求頭被視作一個(gè)請(qǐng)求條件,只有服務(wù)器中文檔的修改時(shí)間比IF-Modified-Since請(qǐng)求頭指定的時(shí)間新,服務(wù)器才會(huì)返回文檔內(nèi)容。否則,服務(wù)器將返回一個(gè)304(Not Modified)狀態(tài)碼來(lái)表示瀏覽器緩存的文檔是最新的,而不向?yàn)g覽器返回文檔內(nèi)容,這時(shí),瀏覽器仍然使用以前緩存的文檔。通過(guò)這種方式,可以在一定程度上減少瀏覽器與服務(wù)器之間的通信數(shù)據(jù)量,從而提高了通信效率。

9. Range和If-Range

Range頭字段用于指定服務(wù)器只需返回文檔中的部分內(nèi)容及內(nèi)容范圍,這對(duì)較大文檔的斷點(diǎn)續(xù)傳非常有用。如果客戶端在一次請(qǐng)求中只接收到服務(wù)器返回的部分內(nèi)容就中斷了,可以在第二次請(qǐng)求中,使用 Range頭字段要求服務(wù)器只返回中斷位置以后的內(nèi)容。Range頭有以下幾種使用格式。

(1)Range: bytes=1000-2000

(2) Range: bytes=1000-

(3) Range:bytes=-1000

在上面列舉的三種格式中,第一種格式請(qǐng)求服務(wù)器返回文檔中的第1000~2000個(gè)字節(jié)之間的內(nèi)容,包括第1000個(gè)和第2000個(gè)字節(jié)的內(nèi)容。第二種格式請(qǐng)求服務(wù)器返回文檔中的第1000個(gè)字節(jié)以后的所有內(nèi)容。第三種格式請(qǐng)求服務(wù)器返回文檔中的最后1000個(gè)字節(jié)的內(nèi)容。

If-Range頭字段只能伴隨著Range頭字段一起使用,其設(shè)置值可以是實(shí)體標(biāo)簽或GMT格式的時(shí)間。如果設(shè)置值為實(shí)體標(biāo)簽,且該標(biāo)簽內(nèi)容與服務(wù)器端代表當(dāng)前網(wǎng)頁(yè)內(nèi)容特征的實(shí)體標(biāo)簽內(nèi)容相同,則服務(wù)器按Range頭的要求返回網(wǎng)頁(yè)中的部分內(nèi)容，否則，服務(wù)器返回當(dāng)前網(wǎng)頁(yè)的所有內(nèi)容。如果設(shè)置值為GMT格式的時(shí)間,并且自從這個(gè)時(shí)間以來(lái),服務(wù)器上保存的該網(wǎng)頁(yè)文件沒(méi)有發(fā)生修改,服務(wù)器會(huì)按Range頭的要求返回網(wǎng)頁(yè)中的部分內(nèi)容,否則,服務(wù)器返回當(dāng)前網(wǎng)頁(yè)的所有內(nèi)容。

10. Max-Forward

Max-Forward頭字段指定當(dāng)前請(qǐng)求可以途經(jīng)的代理服務(wù)器數(shù)量,每經(jīng)過(guò)一個(gè)代理服務(wù)器,此數(shù)值就減1。當(dāng)Max-Forward請(qǐng)求頭的值為0時(shí),如果請(qǐng)求還沒(méi)有到達(dá)最終的Web服務(wù)器,那么代理服務(wù)器將終止轉(zhuǎn)發(fā)這個(gè)請(qǐng)求,由它來(lái)完成對(duì)客戶機(jī)的最終響應(yīng)。

11. Referer

瀏覽器向服務(wù)器發(fā)出的請(qǐng)求,可能是直接在瀏覽器中輸入 URL地址而發(fā)出,也可能是單擊一個(gè)網(wǎng)頁(yè)上的超鏈接而發(fā)出。對(duì)于第一種直接在瀏覽器地址欄中輸入 URL地址的情況,瀏覽器不會(huì)發(fā)送 Referer請(qǐng)求頭,而對(duì)于第二種情況,瀏覽器會(huì)使用Referer頭字段標(biāo)識(shí)發(fā)出請(qǐng)求的超鏈接所在網(wǎng)頁(yè)的URL。例如,本地Tomcat服務(wù)器的 chapter03項(xiàng)目中有一個(gè) HTML文件 GET.html,GET.html中包含一個(gè)指向遠(yuǎn)程服務(wù)器的超鏈接，當(dāng)單擊這個(gè)超鏈接向服務(wù)器發(fā)送GET請(qǐng)求時(shí),瀏覽器會(huì)在發(fā)送的請(qǐng)求消息中包含Referer頭空段.如下所示.

Referer: http://localhost:8080/Test01/GET.html

Referer頭字段非常有用,常被網(wǎng)站管理人員用來(lái)追蹤網(wǎng)站的訪問(wèn)者是如何導(dǎo)航進(jìn)入網(wǎng)站的。同時(shí),Referer頭字段還可以用于網(wǎng)站的防盜鏈。有R提太機(jī),版什么是盜鏈呢?假設(shè)一個(gè)網(wǎng)站的首頁(yè)中想顯示一些圖片信息,而在該網(wǎng)站的服務(wù)器中并沒(méi)有這些圖片資源,它通過(guò)在 HTML 文件中使用img標(biāo)記鏈接到其他網(wǎng)站的圖片資源,將其展示給瀏覽者,這就是盜鏈。盜鏈的網(wǎng)站提高了自己網(wǎng)站的訪問(wèn)量,卻加重了被鏈接網(wǎng)站服務(wù)器的負(fù)擔(dān),損害了其合法利益。所以,一個(gè)網(wǎng)站為了保護(hù)自己的資源,可以通過(guò)Referer頭檢測(cè)出從哪里鏈接到當(dāng)前的網(wǎng)頁(yè)或資源，一旦檢測(cè)到不是通過(guò)本站的鏈接進(jìn)行的訪問(wèn),可以進(jìn)行阻止訪問(wèn)或者跳轉(zhuǎn)到指定的頁(yè)面。

12. User-Agent

User-Agent中文名為用戶代理;簡(jiǎn)稱UA,它用于指定瀏覽器或者其他客戶端程序使用的操作系統(tǒng)及版本、瀏覽器及版本、瀏覽器渲染引擎、瀏覽器語(yǔ)言等,以便服務(wù)器針對(duì)不同類型的瀏覽器而返回不同的內(nèi)容。例如,服務(wù)器可以通過(guò)檢查User-Agent頭,如果發(fā)現(xiàn)客戶端是一個(gè)無(wú)線手持終端,就返回一個(gè)WML文檔;如果客戶端是一個(gè)普通的瀏覽器,則返回通常HTML文檔。例如,IE瀏覽器生成的User-Agent請(qǐng)求信息如下:

User-Agent: Mozilla/4.0(compatible;MSIE 8.0; Windows NT 5.1: Trident/4.0)

在上面的請(qǐng)求頭中,User-Agent頭字段首先列出了Mozilla版本,然后列出了瀏覽器的版本(MSIE 8.0表示 Microsoft IE 8.0)、操作系統(tǒng)的版本(Windows NT 5.1表示W(wǎng)indows XP)以及瀏覽器的引擎名稱(Trident/4.0)。

8. HTTP 響應(yīng)消息

當(dāng)服務(wù)器收到瀏覽器的請(qǐng)求后,會(huì)回送響應(yīng)消息給客戶端。一個(gè)完整的響應(yīng)消息主要包括響應(yīng)狀態(tài)行、響應(yīng)消息頭和實(shí)體內(nèi)容,其中,每個(gè)組成部分都代表了不同的含義，本節(jié)將圍繞HTTP響應(yīng)消息的每個(gè)組成部分進(jìn)行詳細(xì)的講解。

1. HTTP響應(yīng)狀態(tài)行

HTTP響應(yīng)狀態(tài)行位于響應(yīng)消息的第一行,它包括三個(gè)部分，分別是 HTTP版本一個(gè)表示成功或錯(cuò)誤的整數(shù)代碼(狀態(tài)碼)和對(duì)狀態(tài)碼進(jìn)行描述的文本信息,具體示例如下:

HTTP/1.1 200 OK

上面的示例就是一個(gè) HTTP 響應(yīng)消息的狀態(tài)行,其中 HTTP 1.1是通信使用的協(xié)議版本(200是狀態(tài)碼),OK是狀態(tài)描述,說(shuō)明客戶端請(qǐng)求成功。需要注意的是,請(qǐng)求行中的每個(gè)部分需要用空格分隔,最后要以回車換行結(jié)束。

狀態(tài)代碼由三位數(shù)字組成,表示請(qǐng)求是否被理解或被滿足。HTTP響應(yīng)狀態(tài)碼的第一個(gè)數(shù)字定義了響應(yīng)的類別,后面兩位沒(méi)有具體的分類,第一個(gè)數(shù)字有5種可能的取值，具體介紹如下所示。

1xx:表示請(qǐng)求已接收,需要繼續(xù)處理。監(jiān)嘩斯分認(rèn)工源店,價(jià)出戰(zhàn)條細(xì)出網(wǎng)此額海

2xx:表示請(qǐng)求已成功被服務(wù)器接收、理解并接受。

3xx:為完成請(qǐng)求,客戶端需進(jìn)一步細(xì)化請(qǐng)求。

4xx:客戶端的請(qǐng)求有錯(cuò)誤。

5xx:服務(wù)器端出現(xiàn)錯(cuò)誤。

下面通過(guò)表3-2~表3-6對(duì) HTTP 1.1協(xié)議版本下的5種類別的狀態(tài)碼、狀態(tài)信息(每個(gè)狀態(tài)碼后面小括號(hào)中的內(nèi)容就是狀態(tài)信息)及其作用分別進(jìn)行說(shuō)明。

表3-2～表3-6列舉了HTTP的大多數(shù)狀態(tài)碼,這些狀態(tài)碼無(wú)須記憶。接下來(lái)列舉幾個(gè)Web開發(fā)中比較常見的狀態(tài)碼,具體如下。

(1) 200:表示服務(wù)器成功處理了客戶端的請(qǐng)求。

(2) 302:表示請(qǐng)求的資源臨時(shí)從不同的URI響應(yīng)請(qǐng)求,但請(qǐng)求者應(yīng)繼續(xù)使用原有位置來(lái)進(jìn)行以后的請(qǐng)求。例如,在請(qǐng)求重定向中,臨時(shí) URI應(yīng)該是響應(yīng)的Location頭字段所指向的資源。

(3) 404;表示服務(wù)器找不到請(qǐng)求的資源。例如,訪問(wèn)服務(wù)器不存在的網(wǎng)頁(yè)經(jīng)常返回此狀態(tài)碼。

(4) 500:表示服務(wù)器發(fā)生錯(cuò)誤,無(wú)法處理客戶端的請(qǐng)求。

2. HTTP 響應(yīng)消息頭

在HTTP響應(yīng)消息中,第一行為響應(yīng)狀態(tài)行,緊接著的是若干響應(yīng)消息頭,服務(wù)器端通過(guò)響應(yīng)消息頭向客戶端傳遞附加信息,包括服務(wù)程序名、被請(qǐng)求資源需要的認(rèn)證方式,客戶端請(qǐng)求資源的最后修改時(shí)間、重定向地址等信息。HTTP響應(yīng)消息頭的具體示例如下所示:

從上面的響應(yīng)消息頭可以看出,它們的格式和 HTTP請(qǐng)求消息頭的格式相同。當(dāng)服務(wù)器向客戶端回送響應(yīng)消息時(shí),根據(jù)情況的不同,發(fā)送的響應(yīng)消息頭也不相同。接下來(lái),針對(duì)―些常用的響應(yīng)消息頭字段進(jìn)行詳細(xì)講解。

1. Accept-Range

Accept-Range頭字段用于說(shuō)明服務(wù)器是否接收客戶端使用Range請(qǐng)求頭字段請(qǐng)求資源。如果服務(wù)器想告訴客戶機(jī)不要使用Range頭字段,則使用下面的頭信息

Accept-Range: none

如果服務(wù)器想告訴客戶端可以使用以bytes為單位的Range請(qǐng)求,則應(yīng)該使用下面的頭信息:

2. Age

Age頭字段用于指出當(dāng)前網(wǎng)頁(yè)文檔可以在客戶端或代理服務(wù)器中緩存的有效時(shí)間，設(shè)置值為一個(gè)以秒為單位的時(shí)間數(shù),具體示例如下所示:

Age: 1234567

客戶端再次訪問(wèn)已緩存的某個(gè)網(wǎng)頁(yè)文檔內(nèi)容時(shí),先用當(dāng)前的時(shí)間值減去服務(wù)器返回該網(wǎng)頁(yè)時(shí)所設(shè)置的Date頭字段值,如果結(jié)果值小于服務(wù)器上返回該網(wǎng)頁(yè)時(shí)所設(shè)置的Age頭字段的時(shí)間值,客戶端直接使用緩存中的網(wǎng)頁(yè)內(nèi)容。否則,客戶端將向服務(wù)器發(fā)出針對(duì)該頁(yè)面的網(wǎng)頁(yè)請(qǐng)求。

3. Etag

Etag頭字段用于向客戶端傳送代表實(shí)體內(nèi)容特征的標(biāo)記信息,這些標(biāo)記信息稱為實(shí)體標(biāo)簽,每個(gè)版本的資源的實(shí)體標(biāo)簽是不同的,通過(guò)實(shí)體標(biāo)簽可以判斷在不同時(shí)間獲得的同一資源路徑下的實(shí)體內(nèi)容是否相同。例如,在一個(gè)文檔最后添加一個(gè)回車換行，Etag頭字段的值就能標(biāo)識(shí)出不同。Etag頭字段的格式如下所示:

Etag: abc1234

4. Location

Location頭字段用于通知客戶端獲取請(qǐng)求文檔的新地址,其值為一個(gè)使用絕對(duì)路徑的URL地址,如下所示;

Location: http://www.xdr630.top

Location頭字段和大多數(shù)3xx狀態(tài)碼配合使用,以便通知客戶端自動(dòng)重新連接到新的地址請(qǐng)求文檔。由于當(dāng)前響應(yīng)并沒(méi)有直接返回內(nèi)容給客戶端,所以使用 Location頭的HTTP消息不應(yīng)該有實(shí)體內(nèi)容,由此可見,在HTTP消息頭中不能同時(shí)出現(xiàn) Location和Content-Type這兩個(gè)頭空段

5. Retry-After

Retry-After頭字段可以與503狀態(tài)碼配合使用,告訴客戶端在什么時(shí)間可以重新發(fā)送請(qǐng)求。也可以與任何一個(gè)3xx狀態(tài)碼配合使用,告訴客戶端處理重定向的最小延時(shí)時(shí)間。Retry-After頭字段的值可以是GMT格式的時(shí)間,也可是一個(gè)以秒為單位的時(shí)間數(shù),具體示例如下:

Retry-After: Sun, 21 Mar 2021 10:00:00 GMTRetry-After: 120 //120秒

6. Server

Server頭字段用于指定服務(wù)器軟件產(chǎn)品的名稱,具體示例如下:

Server: Apache- Coyote/1.1

7. Vary

Vary用于指定影響了服務(wù)器所生成的響應(yīng)內(nèi)容的那些請(qǐng)求頭字段名,具體示例如下:

Vary: Accept-Language

上面的響應(yīng)頭字段說(shuō)明了服務(wù)器響應(yīng)的內(nèi)容受到了客戶端發(fā)送的Accept-Language請(qǐng)求頭的影響,服務(wù)器根據(jù)Accept-Language請(qǐng)求頭的值,返回相應(yīng)語(yǔ)言種類的網(wǎng)頁(yè)內(nèi)容。當(dāng)客戶端再次訪問(wèn)已經(jīng)緩存的資源時(shí),需要檢查Vary頭字段中指定的請(qǐng)求頭字段，檢查請(qǐng)求頭字段的這次設(shè)置與上次的設(shè)置是否相同,以此作為是否使用緩存的條件。-例如,上次的請(qǐng)求中Accept-Language頭字段的值為en-us,而這次的 Accept-Language頭字段的值為zh-cn,即使客戶端使用請(qǐng)求資源路徑的本地緩存的其他條件都成立,但客戶端也不能使用緩存,它仍需向服務(wù)器發(fā)出訪問(wèn)請(qǐng)求。

8. WWW-Authenticate和Proxy-Authenticate

當(dāng)客戶端訪問(wèn)受口令保護(hù)的網(wǎng)頁(yè)文件時(shí),服務(wù)器會(huì)在響應(yīng)消息中回送401(Unauthrized)響應(yīng)狀態(tài)碼和WWW-Authoricate響應(yīng)頭,指示客戶端應(yīng)該在Author-ization請(qǐng)求頭中使用WWW-Authoricate響應(yīng)頭指定的認(rèn)證方式提供用戶名和密碼信息。WWW-Authenticate響應(yīng)頭中可以指定兩種認(rèn)證方式:BASIC 和 DIGEST。如果要求客戶端采用 BASIC方式傳送認(rèn)證信息,語(yǔ)法格式如下:

WWW-Authenticate: BASIC realm= "xdr630"

其中, realm屬性用于指定當(dāng)前資源所屬的域,域定義了同一個(gè)主機(jī)內(nèi)的一個(gè)受保護(hù)區(qū)間(一組需要保護(hù)的資源)，它可以是任意字符串。同一臺(tái)主機(jī)上可以有多個(gè)域,相同的域內(nèi)所有的資源都共享相同的賬戶。如果某個(gè)賬戶具有訪問(wèn)某個(gè)資源的權(quán)限,那么該賬戶就能訪問(wèn)同一個(gè)域中的其他資源。根據(jù)HTTP驗(yàn)證的規(guī)范，與某一資源具有相同的目錄路徑或位于其目錄路徑的子目錄中的資源,與該資源使用相同的域。

DIGEST認(rèn)證方式細(xì)節(jié)比較復(fù)雜,想對(duì)其進(jìn)行深入研究的讀者可以參閱 RFC2617文檔。

Proxy-Authenticate頭字段是針對(duì)代理服務(wù)器的用戶信息驗(yàn)證，其他的作用與用法與 WWW-Authenticate頭字段類似。

9. Refresh

Refresh頭字段用于告訴瀏覽器自動(dòng)刷新頁(yè)面的時(shí)間,它的值是一個(gè)以秒為單位的時(shí)間數(shù),具體示例如下所示:

Refresh:3

上面所示的Refresh頭字段用于告訴瀏覽器在3秒后自動(dòng)刷新此頁(yè)面。

需要注意的是,在 Refresh頭字段的時(shí)間值后面還可以增加一個(gè)URL參數(shù),時(shí)間值與URL之間用分號(hào)(﹔)分隔,用于告訴瀏覽器在指定的時(shí)間值后跳轉(zhuǎn)到其他網(wǎng)頁(yè),例如告訴瀏覽器經(jīng)過(guò)3秒跳轉(zhuǎn)到www.xdr630.top網(wǎng)站,具體示例如下:

Refresh:3; url=http://www.xdr630.top

10. Content-Disposition

如果服務(wù)器希望瀏覽器不是直接處理響應(yīng)的實(shí)體內(nèi)容,而是讓用戶選擇將響應(yīng)的實(shí)體內(nèi)容保存到一個(gè)文件中,這需要使用Content-Disposition頭字段。Content-Disposition頭字段沒(méi)有在 HTTP的標(biāo)準(zhǔn)規(guī)范中定義,它是從 RFC 2183中借鑒過(guò)來(lái)的。在RFC 2183中,Content-Disposition指定了接收程序處理數(shù)據(jù)內(nèi)容的方式,有inline和attachment兩種標(biāo)準(zhǔn)方式, inline表示直接處理,而attachment則要求用戶干預(yù)并控制接收程序處理數(shù)據(jù)內(nèi)容的方式。而在 HTTP應(yīng)用中，只有attachment是 Content-Disposition的標(biāo)準(zhǔn)方式。attachment后面還可以指定filename參數(shù)。filename參數(shù)值是服務(wù)器建議瀏覽器保存實(shí)體內(nèi)容的文件名稱,瀏覽器應(yīng)該忽略filename參數(shù)值中的目錄部分,只取參數(shù)中的最后部分作為文件名。在設(shè)置Content-Disposition之前,一定要設(shè)置Content-Type頭字段,具體示例如下.

Content-Type: application/octet-stream Content- Disposition: attachment; filename=lee.zip

3. HTTP其他頭字段

1. 通用頭字段

在 HTTP消息中,有些頭字段既適用于請(qǐng)求消息也適用于響應(yīng)消息,這樣的字段被稱為通用頭字段。通用頭字段有如下幾種:Cache-Control、 Connection、Date, Pragma,Trailer、 Transfer-Encoding,Upgrade、 Via, Warning,關(guān)于這些通用頭字段的相關(guān)講解具體如下。

如果Cache-Control用在請(qǐng)求消息中,它用于通知位于客戶端和服務(wù)器端之間的理服務(wù)器如何使用已緩存的頁(yè)面。在這種情況下,Cache-Control的值可以是:no-cache、no-store、max-age , max-stale、 min-fresh 、no-transform,only-if-cached等。

如果Cache-Control用在響應(yīng)消息中,它用于通知客戶端和代理服務(wù)器如何緩存頁(yè)面,在這種情況下，Cache-Control 的取值可以為public、 private , no-cache、no-store、no-transform,must-revalidate、proxy-revalidate 、 max-age,s-max-age等。

在一個(gè)Cache-Control頭字段中可以設(shè)置多個(gè)值,它們之間用過(guò)號(hào)分隔,具體示例如下:

Cache-Control: no- stroe,no-cache,must-revalidage

在上面的Cache-Control頭字段中,設(shè)置的每個(gè)值都有特定的含義,接下來(lái),通過(guò)表3-7對(duì)Cache-Control頭字段的一些常用值進(jìn)行介紹說(shuō)明。

Connection頭字段用于指定處理完本次請(qǐng)求/響應(yīng)后,客戶端和服務(wù)器端是否還要繼續(xù)保持連接。Connection頭字段可以指定兩個(gè)值,如下所示:罐必監(jiān)中來(lái)都鼓

Connection: Keep-Alive Connection: close

當(dāng)Connection頭字段的值為Keep-Alive時(shí),客戶端與服務(wù)器在完成本次交互后繼續(xù)保持連接,當(dāng)Connection頭字段的值為close 時(shí),客戶端與服務(wù)器在完成本次交互后關(guān)閉連接。對(duì)于HTTP1.1版本來(lái)說(shuō),默認(rèn)采用持久連接,也就是說(shuō)默認(rèn)情況下，Connection頭字段的值為Keep- Alive.

Date頭字段用于表示 HTTP消息產(chǎn)生的當(dāng)前時(shí)間,它的值為GMT格式,具體示例如下:

Mon, 22 Feb 2021 08:29:02 GMT

一般情況下,服務(wù)器返回的所有響應(yīng)中必須包括一個(gè) Date頭字段.除了下而這此情況。

響應(yīng)狀態(tài)代碼表示服務(wù)器的錯(cuò)誤，如500(內(nèi)部服務(wù)器錯(cuò)誤)或503(服務(wù)不可用),那么服務(wù)器就不可能產(chǎn)生一個(gè)有效的日期。

服務(wù)器沒(méi)有時(shí)鐘,不能提供當(dāng)前時(shí)間,響應(yīng)就不能設(shè)置Date頭,這種情況下,服務(wù)器也不能設(shè)置如 Expire、Last-Modified等這樣的頭字段。

Pragma頭字段主要在HTTP 1.0中通知代理服務(wù)器和客戶端如何使用緩存頁(yè)面，它的值只能固定設(shè)置為no-cache,如下所示:

Pragma: no-cache

當(dāng)Pragma頭字段用于響應(yīng)消息時(shí),指示客戶端不要緩存文檔;當(dāng)用于請(qǐng)求消息時(shí)，指示代理服務(wù)器必須返回一個(gè)最新的文檔,而不能返回緩存的文檔。在HTTP 1.0中，一些瀏覽器對(duì)Pragma頭字段的支持不是非常可靠,因此,人們常常通過(guò)設(shè)置Expires頭字段的值為0來(lái)實(shí)現(xiàn)同樣功能。

而在 HTTP 1.1中,Cache-Control頭字段也基本替代了Pragma頭字段的使用。

對(duì)于HTTP 1.0協(xié)議,服務(wù)器端和客戶端不是持久化連接,當(dāng)服務(wù)器端關(guān)閉了TCP連接,客戶端就知道響應(yīng)的數(shù)據(jù)已經(jīng)發(fā)送完畢。而對(duì)于HTTP 1.1來(lái)說(shuō),由于服務(wù)器端和客戶端保持持久連接,服務(wù)器端必須在響應(yīng)消息中通過(guò)Content-Length頭字段通知客戶端響應(yīng)數(shù)據(jù)的長(zhǎng)度,客戶端才能知道數(shù)據(jù)何時(shí)傳輸完畢。然而,在服務(wù)器端,有些數(shù)據(jù)是動(dòng)態(tài)生成的,服務(wù)器必須等到所有的內(nèi)容都生成后才能準(zhǔn)確地計(jì)算出響應(yīng)數(shù)據(jù)的長(zhǎng)度,也就是說(shuō)只有當(dāng)所有數(shù)據(jù)生成完畢后服務(wù)器端才能響應(yīng)客戶端的請(qǐng)求,這樣勢(shì)必會(huì)影響效率。為了解決這個(gè)問(wèn)題，Transfer-Encoding頭字段被引人,這個(gè)頭字段指定響應(yīng)消息的實(shí)體內(nèi)容采用哪種傳輸編碼方式,目前標(biāo)準(zhǔn)設(shè)置值只有chunked,具體示例如下:

Transfer-Encoding: chunked

當(dāng)響應(yīng)消息中設(shè)置了Transfer-Encoding頭字段后,會(huì)把響應(yīng)消息的整個(gè)實(shí)體內(nèi)容分成一連串分段后再進(jìn)行傳輸。每個(gè)分段的開始都是一個(gè)十六進(jìn)制的數(shù)字,用來(lái)表示整個(gè)分段的大小。最后一個(gè)分段必須是0,用于表示整個(gè) chunked編碼數(shù)據(jù)的結(jié)束,如下所示:

HTTP/1.1 200 OK Content-Type: text/htm1Transfer-Encoding: chunked 7f

Please wait while we complete your transaction ...

Transaction complete!

上面的響應(yīng)消息中,7f和2c代表兩個(gè)分段內(nèi)容的大小標(biāo)識(shí)信息,所以這種情況下不必用 Content-Length頭字段來(lái)指定整個(gè)實(shí)體內(nèi)容的大小。

一些頭字段可以放置在整個(gè) HTTP消息的尾部,也就是可以在實(shí)體內(nèi)容部分之后放置頭字段信息。對(duì)于放置在尾部的頭字段,需要在消息頭中使用Trailer字段說(shuō)明,具體示例如下，

Trailer:Date

需要注意的是，Trailer頭字段必須在 chunked傳輸編碼的方式下使用。

Upgrade頭字段用在客戶端,用于指定客戶端想要從當(dāng)前協(xié)議切換的新的通信協(xié)議。如果服務(wù)器端認(rèn)為切換的協(xié)議合適,會(huì)在響應(yīng)消息中設(shè)置Upgrade頭字段指定切換的協(xié)議，Upgrade響應(yīng)頭字段需要和101狀態(tài)碼配合使用,具體示例如下:

//請(qǐng)求消息 GET /HTTP/1.1 Host: 127.0.0.1 Upgrade: TLS/1.0 //響應(yīng)消息 HTTP/1.1 101 Switching Protocols Upgrade: TLS/1.0

Via頭字段用于指定HTTP 消息所途經(jīng)的代理服務(wù)器所使用的協(xié)議和主機(jī)名稱,這個(gè)頭字段由代理服務(wù)器產(chǎn)生,每個(gè)代理服務(wù)器必須把它的信息追加到Via字段的最后，以反映 HTTP消息途經(jīng)的多個(gè)代理服務(wù)器的順序,具體示例如下:

Via: HTTP/1.1 Proxy1,HTTP/1.1 Proxy2

如果代理服務(wù)器所使用的協(xié)議為HTTP,Via頭字段中的協(xié)議名稱可以省略,如下所示:

Via: 1.1 Proxy1,1.1 Proxy2

Warning頭字段主要用于說(shuō)明其他頭字段和狀態(tài)碼不能說(shuō)明的一些附加警告信息，例如提示代理服務(wù)器斷開網(wǎng)絡(luò),如下所示:

warning:112 Disconnected operation

2. 實(shí)體頭字段

請(qǐng)求消息和響應(yīng)消息中都可以傳遞實(shí)體信息,實(shí)體信息包括實(shí)體頭字段和實(shí)體內(nèi)容,實(shí)體頭字段是實(shí)體內(nèi)容的元信息,描述了實(shí)體內(nèi)容的屬性,例如實(shí)體內(nèi)容的類型、長(zhǎng)度、壓縮方法、最后的修改時(shí)間、數(shù)據(jù)的有效期等。接下來(lái),本節(jié)將針對(duì)實(shí)體頭字段進(jìn)行詳細(xì)的講解。

Allow頭字段指定了請(qǐng)求資源所支持的請(qǐng)求方式(如 GET,POST等),用于通知客戶端應(yīng)該嚴(yán)格按照指定的方式請(qǐng)求資源,如下所示:

Al1ow: GET,HEAD,PUT

需要注意的是,Allow頭字段必須和405響應(yīng)狀態(tài)碼一起使用。

Content-Language用于指定返回網(wǎng)頁(yè)文檔的國(guó)家語(yǔ)言類型,其設(shè)置值是zh-cn,en-us,ja等國(guó)家語(yǔ)言的標(biāo)準(zhǔn)名稱。由于同一個(gè)字符在不同的國(guó)家語(yǔ)言中的樣式和意義上能有略微區(qū)別,如果一些客戶端軟件正好要對(duì)字符文本按不同的國(guó)家語(yǔ)言進(jìn)行不同處理時(shí), Content-Language頭字段就比較重要了。Content-Language的具體示例如下所示:

Content-Language: en-us

Content-Length頭字段用于表示實(shí)體內(nèi)容的長(zhǎng)度(字節(jié)數(shù)),首先來(lái)看一個(gè)帶有Content-Length頭字段的簡(jiǎn)單的響應(yīng)消息,具體如下所示:

HTTP/1.1 200 OK Date: Mon, 22 Feb 2021 09:29:57 GMT Content- Length:109 Content-Length:109

在上面的響應(yīng)消息中,從中的第一個(gè)字符“<”到中的最后一個(gè)字符“>”,內(nèi)容的長(zhǎng)度為109。

在 HTTP 1.1中,瀏覽器與服務(wù)器之間保持持久連接,服務(wù)器允許客戶端在一個(gè)TCP連接上發(fā)送多個(gè)請(qǐng)求,服務(wù)器必須在每個(gè)響應(yīng)中發(fā)送一個(gè) Content-Length響應(yīng)頭來(lái)標(biāo)識(shí)各個(gè)實(shí)體內(nèi)容的長(zhǎng)度,以便客戶端能分清每個(gè)響應(yīng)內(nèi)容的結(jié)束位置,而不會(huì)將上一個(gè)響應(yīng)和下一個(gè)響應(yīng)混淆。

如果響應(yīng)消息中包含 Transfer-Encoding響應(yīng)頭,也就是說(shuō)響應(yīng)內(nèi)容以chunked編碼方式返回,那么,Content-Length響應(yīng)頭就不應(yīng)該設(shè)置了。

Content-Location頭字段用于指定響應(yīng)消息中實(shí)體內(nèi)容的實(shí)際位置路徑(不能簡(jiǎn)單地認(rèn)為響應(yīng)消息中的實(shí)體內(nèi)容所在的路徑就是請(qǐng)求資源的路徑)，當(dāng)一個(gè)請(qǐng)求資源路徑對(duì)應(yīng)有多種實(shí)體內(nèi)容形式時(shí),例如,同一請(qǐng)求資源可能有多個(gè)國(guó)家語(yǔ)言的版本,每個(gè)國(guó)家語(yǔ)言的版本都有自己的位置,在這種情況下,請(qǐng)求資源路徑與響應(yīng)的實(shí)體內(nèi)容所在的路徑可能是不同的,具體示例如下:

//請(qǐng)求消息 GET /docs/index.html HTTP/1.1 Host: httpd.apache.org Accept- Language: en-us //響應(yīng)消息 HTTP/1.1 200 OK Date: Mon, 22 Feb 2021 09:29:57 GMT Server: Apache(UNIX) Content-Location: index_en_us.html Content-Type: text/html Content-Language: en-us

在上面的示例中,請(qǐng)求消息中需要請(qǐng)求index. html文檔,而且要求是英文文檔,服務(wù)器中發(fā)現(xiàn)有可用的英文文檔index_en_us.html,就會(huì)在響應(yīng)消息中將Content-Location消息頭的值設(shè)置為index_en_us. html文檔的路徑,并把該文檔回送給客戶端。

Content-Location的設(shè)置值可以是絕對(duì)路徑,也可以是相對(duì)路徑,如果是相對(duì)路徑，則是相對(duì)請(qǐng)求資源路徑而言的,對(duì)于上面的響應(yīng)消息來(lái)說(shuō), index, html和 index_en_us.html在同一目錄下。

Content-Range頭字段用于指定服務(wù)器返回的部分實(shí)體內(nèi)容的位置信息。只有客戶機(jī)使用了Range請(qǐng)求頭要求服務(wù)器返回實(shí)體的部分內(nèi)容時(shí),服務(wù)器的響應(yīng)頭中才會(huì)包含Content-Range頭,具體示例如下所示:

HTTP/1.1 206 Partial content Date: wed,15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-Range: bytes 21010-47021/47022 Content- Length:26012 Content-Type: image/gif

在Content-Range頭字段中, bytes說(shuō)明后面的數(shù)據(jù)以byte為單位,21010～47021說(shuō)明返回的內(nèi)容從第21010個(gè)字節(jié)開始到第47021個(gè)字節(jié)結(jié)束,47022說(shuō)明整個(gè)實(shí)體內(nèi)容的大小為47022個(gè)字節(jié),從 Content-Length頭字段可以看出返回的實(shí)體內(nèi)容的長(zhǎng)度為26012(47 021-21 010＋1)個(gè)字節(jié)。

Content-MD5頭字段用于提供對(duì)實(shí)體內(nèi)容的完整性檢查,它的值是對(duì)實(shí)體內(nèi)容MD5 數(shù)字摘要后再進(jìn)行 Base64編碼的結(jié)果。

MD5 數(shù)字摘要算法是一種散列算法,能夠通過(guò)對(duì)一段信息進(jìn)行運(yùn)算,產(chǎn)生一個(gè)16個(gè)字節(jié)的數(shù)字摘要。如果對(duì)輸人信息做了任何形式的改變,對(duì)改變后的信息再次進(jìn)行MD5運(yùn)算所產(chǎn)生的數(shù)字摘要和改變之前的數(shù)字摘要都不相同。由于通過(guò)MD5算法計(jì)算的16個(gè)字節(jié)摘要信息可能無(wú)法轉(zhuǎn)化成可打印的 ASCII字符顯示,因此需要對(duì)這16個(gè)字節(jié)進(jìn)行 Base64編碼,將其轉(zhuǎn)換為可打印的 ASCII字符。Content-MD5的頭字段如下所示:

Content-MD5: ZTFmZDA5MDYyYTMzZGQzMDMxMmixMjc4YThhNTMyM21=

Content-Type用于指出實(shí)體內(nèi)容的MIME類型。MIME(Multipurpose InternetMail Extensions,多用途互聯(lián)網(wǎng)郵件擴(kuò)展類型)是一個(gè)互聯(lián)網(wǎng)標(biāo)準(zhǔn),它設(shè)計(jì)之初是為了在發(fā)送電子郵件時(shí)附加多媒體數(shù)據(jù),讓郵件客戶程序能根據(jù)其類型進(jìn)行處理。由于通過(guò)HTTP傳輸?shù)臄?shù)據(jù)也有各種類型,因此,HTTP 也采用了MIME來(lái)標(biāo)識(shí)不同的數(shù)據(jù)類型。客戶端通過(guò)檢查響應(yīng)頭字段 Content-Type中的 MIME類型,就能知道接收到的實(shí)體內(nèi)容代表哪種格式的數(shù)據(jù)類型,從而進(jìn)行正確的處理。

大多數(shù)服務(wù)器會(huì)在配置文件中設(shè)置文件擴(kuò)展名與MIME類型的映射關(guān)系,從而可以根據(jù)請(qǐng)求資源的擴(kuò)展名自動(dòng)確定 Content-Type的 MIME類型。在Tomcat的 web.xml文件中有大量的元素,來(lái)實(shí)現(xiàn)文件擴(kuò)展名和 MIME類型的映射，下面是web. xml文件的片段:

... pdf application/pdf ...

其中元素的子元素用于指定文件的擴(kuò)展名,子元素用于指定該文件擴(kuò)展名映射的 MIME類型。

MIME類型包含主類型和子類型,兩者之間用“/”分隔,上面的文件片段中的 MIM類型“application/pdf”, application為主類型,pdf為子類型。MIME類型也可以使用“*”號(hào)通配符,“*/ *”代表所有的MIME類型,"image/ *”代表所有image的子類型如果子類型以“x-”開頭,則表示該類型目前還處于實(shí)驗(yàn)性的階段。Content-Type頭字段中的 MIME類型后面還可以指定響應(yīng)內(nèi)容所使用的字符碼表,兩者之間用分號(hào)(;)和空格隔開,如 Content-Type: text/html; charset=GB2312。如果Content-Type頭字段中沒(méi)有指定字符碼表,默認(rèn)使用的是ISO-8859-1字符碼表。

HTTP TCP/IP

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。