1. HTTP介紹
- HTTP是
Hyper Text Transfer Protocol
- 從圖3-1中可以清楚地看到用戶端與服務端使用HTTP通信的過程，接下來總結一下HTTP協定的特點,具體如下。
(1) 支援用戶端(浏覽器就是一種 Web用戶端)/伺服器模式。
(2) 簡單快速:用戶端向伺服器請求服務時,隻需傳送請求方式和路徑。常用的請求方式有GET、POST等,每種方式規定了用戶端與伺服器聯系的類型不同。由于 HTTP簡單,使得HTTP伺服器的程式規模小,因而通信速度很快。
(3) 靈活:HTTP 允許傳輸任意類型的資料,正在傳輸的資料類型由
Content-Type
加以标記。
(4) 無狀态:HTTP是無狀态協定。無狀态是指協定對于事務處理沒有記憶能力，如果後續處理需要前面的資訊,則它必須重傳,這樣可能導緻每次連接配接傳送的資料量增大。
2. HTTP 1.0 和 HTTP 1.1
- HTTP自誕生以來,先後經曆了很多版本,其中,最早的版本是 HTTP 0.9,它1990年被提出。後來,為了進一步完善HTTP,先後在1996年提出了版本1.0,在1997年提出了版本1.1。由于HTTP 0.9版本已經過時,這裡不作過多講解。接下來,隻針對HTTP 1.0和 HTTP 1.1進行詳細地講解。
2.1 HTTP 1.0
- 基于HTTP1.0協定的用戶端與伺服器在互動過程中需要經過建立連接配接、發送請求資訊、回送響應資訊、關閉連接配接4個步驟,具體互動過程如圖3-2所示。
- 從圖3-2中可以看出,用戶端與伺服器建立連接配接後,每次隻能處理一個 HTTP請求。對于内容豐富的網頁來說,這樣的通信方式明顯有缺陷。例如,下面的一段HTML代碼:
<html>
<body>
<img src="/image01.jpg">
<img src="/image02.jpg">
<img src="/image03.jpg">
</body>
</html> - 上面的 HTML文檔中包含三個
<img>
<img>
src
URL
2.2 HTTP 1.1
- 為了克服上述HTTP 1.0的缺陷,HTTP1.1版本應運而生,它支援持久連接配接，也就是說在一個 TCP 連接配接上可以傳送多個 HTTP 請求和響應,進而減少了建立和關閉連接配接的消耗和延時。基于 HTTP 1.1的用戶端和伺服器端的互動過程,如圖3-3所示。
- 從圖3-3中可以看出,當用戶端與伺服器端建立連接配接後,用戶端可以向伺服器端發送多個請求,并且在發送下個請求時,無須等待上次請求的傳回結果。但伺服器必須按照接受用戶端請求的先後順序依次傳回響應結果,以保證用戶端能夠區分出每次請求的響應内容。由此可見,HTTP 1.1不僅繼承了HTTP 1.0的優點,而且有效解決了HTTP 1.0的性能問題,顯著地減少了浏覽器與伺服器互動所需要的時間。
3. HTTP消息
- 當使用者在浏覽器中通路某個
URL
form
HTTP請求消息
HTTP 響應消息
- 在HTTP消息中,除了伺服器端的
響應實體内容(HTML 網頁、圖檔等)
(1) 在浏覽器的位址欄中輸入
www.baidu.com
通路百度首頁,在F12中可以看到請求的 URL位址,如圖所示。
(2) 單擊URL位址左邊的Name,在展開的預設頭資訊頁籤中可以看到格式化後的響應頭資訊和請求頭資訊。單擊請求頭資訊一欄左邊的“原始頭資訊”,可以看到原始的請求頭資訊,具體如下所示;
- 在上述請求消息中,第一行為請求行,請求行後面的為請求頭消息,空行代表請求頭的結束。
(3) 單擊響應頭資訊一欄左邊的“原始頭資訊”,可以看到原始的響應頭資訊,如下所示:
- 在上面的響應消息中,第一行為響應狀态行,響應狀态行後面的為響應消息頭,空行代表響應消息頭的結束。
4. HTTP請求消息
- 在 HTTP中，一個完整的請求消息是由請求行、請求頭和實體内容三部分組成,其中,每部分都有各自不同的作用。本節将圍繞HTTP請求消息的每個組成部分進行詳細的講解。
4.1 HTTP請求行
- HTTP請求行位于請求消息的第一行,它包括三個部分,分别是請求方式、資源路名以及所使用的HTTP版本,具體示例如下:
GET /index.html HTTP/1.1 - 上面的示例就是一個HTTP請求行,其中,
GET
index.html
HTTP/1.1
- 關于請求資源和協定版本,讀者都比較容易了解,而 HTTP請求方式對讀者來說比較陌生,接下來就針對HTTP的請求方式進行具體分析。
- 在 HTTP的請求消息中,請求方式有
GET,POST、 HEAD、OPTIONS、 DELETE,TRACE、PUT和 CONNECT
URI
- 表3-1中列舉了HTTP的8種請求方式,其中最常用的就是
GET
POST
1. GET 請求方式
- 當使用者在浏覽器位址欄中直接輸入某個
URL
GET
form
method
GET
method
GET
GET
- 如果浏覽器請求的
URL
URL
http://wwrw.xdr630.com/javaForm?username=xdr630&password=123456 - 在上述
URL
?
=
&
- 當浏覽器向伺服器發送請求消息時,上述
URL
URI
GET /javaForm?username=xdr630&password=123456 HTTP/1.1 - 需要注意的是,使用
GET
1KB
2. POST 請求方式
- 如果網頁上
form
method
POST
POST
URI
POST
Content-Type
“application/x-www-form-urlencoded
Content-Length
POST /javaForm HTTP/1.1
Host: www.xdr630.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 17
username=xdr630&password=123456 - 對于使用
POST
URI
- 需要注意的是，在實際開發中,通常都會使用
POST
-
POST
由于
GET
請求方式是通過請求參數傳遞資料的,是以最多可傳遞
1KB
的資料。而
POST
請求方式是通過實體内容傳遞資料的,是以可以傳遞資料的大小沒有限制
-
POST
GET
GET
請求方式的參數資訊都會在
URL
位址欄明文顯示,而
POST
請求方式傳遞的參數隐藏在實體内容中,使用者是看不到的,是以,
POST
GET
請求方式更安全。
5. 測試GET請求方式
(1) 建立一個HTML檔案，
GET.html
，如下所示：
GET.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Title</title>
</head>
<body>
<form action="" method="get">
使用者名：<input type="text" name="username" style="width: 150px"><br>
密碼： <input type="text" name="password" style="width: 150px"><br>
<input type="submit" value="送出">
</form>
</body>
</html> - 送出後：這時位址欄中的URL位址發生了變化，在原有的URL位址後面附加上了參數資訊
- 檢視顯示的請求頭資訊，發現在請求行的URL請求資源後附加了參數資訊，如圖
- 而在Query String Parameters
6. 測試POST請求方式
POST.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Title</title>
</head>
<body>
<form action="" method="post">
使用者名：<input type="text" name="username" style="width: 150px"><br>
密碼： <input type="text" name="password" style="width: 150px"><br>
<input type="submit" value="送出">
</form>
</body>
</html> - 送出後，URL位址欄沒有變化。F12檢視發現請求的參數被加密了
- F12檢視，發現在請求消息中多了兩個請求消息頭
- 新添加的兩個消息頭中，
Content-Type
Content-Length
- F12 中看到 Form Data 就是送出的表單資訊，也就是HTTP請求消息的實體内容，也就是說，在POST請求方式中，表單的内容将作為實體内容送出給伺服器。
7. HTTP請求消息頭
- 在HTTP請求消息中,請求行之後,便是若幹請求消息頭。請求消息頭主要用于向伺服器端傳遞附加消息,例如,用戶端可以接收的資料類型、壓縮方法、語言以及發送請求的超連結所屬頁面的URL位址等資訊,具體示例如下:
- 從上面的請求消息頭中可以看出,每個請求消息頭都是由一個頭字段名稱和一個值構成，頭字段名稱和值之間用冒号(
:
()
- 當浏覽器發送請求給伺服器時,根據功能需求的不同,發送的請求消息頭也不相同，接下來,針對一些常用的請求頭字段進行詳細講解。
1. Accept
- Accept頭字段用于指出用戶端程式(通常是浏覽器)能夠處理的
MIME(Multi-purpose Internet Mail Extensions,多用途網際網路郵件擴充)
務器同時支援
png
類型的圖檔,則浏覽器可以發送包含
image/png
的Accept頭字段,伺服器檢查到Accept頭中包含
image/png
這種
MIME
類型,可能在網頁中的
img
元素中使用
png
類型的檔案。
MIME
類型有很多種,例如,下面的這些 MIME類型都可以作為Accept頭字段的值。
2. Accept-Charset
- Accept-Charset 頭字段用于告知伺服器端用戶端所使用的字元集,具體示例如下:
Accept-Charset: ISO-8859-1 - 在上面的請求頭中,指出用戶端伺服器使用
ISO-8859-1
Accept-Charset
Accept-Charset: ISO-8859-1,unicode-1-1 - 需要注意的是,如果
Accept-Charset
- 如果Accept-Charset頭出現在請求消息裡,但是伺服器不能發送采用用戶端期望字元集編碼的文檔,那麼伺服器将發送一個
406
406
Accept-Charset
3. Accept-Encoding
- Accept-Encoding頭字段用于指定用戶端能夠進行解碼的資料編碼方式,這裡的編碼方式通常指的是某種壓縮方式。在 Accept-Encoding頭字段中,可以指定多個資料編碼方式,它們之間以逗号分隔,具體示例如下:
Accept-Encoding: gzip,compress - 在上面的頭字段中，
gzip
compress
Content-Encoding
- 需要注意的是,
Accept-Encoding
Accept
Accept
MIME
Accept-Encoding
4. Accept-Language
- Accept-Language頭字段用于指定用戶端期望伺服器傳回哪個國家語言的文檔,它的值可以指定多個國家的語言,語言之間用逗号分隔,具體示例如下:
Accept-Language: zh-CN,en-us - 在上述示例中,
zh-cn
en-us
- 需要注意的是,浏覽器會根據“語言首選項”對話框中語言清單的先後順序,生成相應的Accept-Language消息頭。
- 伺服器隻要檢查Accept-Language請求頭中的資訊,按照其中設定的國家語言的先後順序,首先選擇傳回位于前面的國家語言的網頁文檔,如果不能傳回,則依次傳回後面的國家語言的網頁文檔。
5. Authorization(授權)與Proxy-Authorization
- 當用戶端通路受密碼保護的網頁時, Web伺服器會發送401響應狀态碼和
WWW-Authenticate
Authorization
WWW-Authenticate
Authorization
WWW-Authenticate
BASIC
DIGEST
BASIC
Base64
- 例如,将使用者名為
Ann
666888
Ann:666888
Base64
Authorization
Authorization: Basic Qw5uOjY2Njg4OA== - 然而,使用
Base64
- 如果使用
DIGEST
MD5
-
Proxy-Authorization
Authorization
Proxy-Authorization
6. Host
- Host頭字段用于指定資源所在的主機名和端口号,格式與資源的完整URL中的主機名和端口号部分相同,具體示例如下所示:
Host: www.xdr630.top - 在上述示例中,由于浏覽器連接配接伺服器時預設使用的端口号為80,是以“www.xdr630.top”後面的端口号資訊“:80”可以省略。
- 需要注意的是,在HTTP 1.1中,浏覽器和其他用戶端發送的每個請求包含Host請求頭子段,以便通路Web站點時,會根據位址欄中的URL地端所要通路的虛拟Web站點。當浏覽器通路Web站點時,會根據位址欄中的URL位址自動生成相應的Host請求頭。
7. If-Match
- 浏覽器和代理伺服器都可以緩存伺服器回送的網頁文檔。當使用者再次通路已緩存的頁面時,隻有網頁内容已被更新,伺服器才需要把該頁面的内容重新回送到用戶端,否則會通知浏覽器通路本地緩存的頁面,以減少不必要的網絡傳輸流量。當伺服器為用戶端傳送網頁檔案的内容時,可以傳輸一些代表實體内容特征的頭字段,這些頭字段被稱為實體标簽。當客戶機再次向伺服器請求這個網頁檔案時,可以使用If-Match頭字段附帶以前緩存的實體标簽内容,這個請求被視為一個條件請求,例如:
If-Match: "repository" - 其中,"
repository
ETag: "repository" - 伺服器收到用戶端的請求後,會檢索If-Match頭中的實體标簽内容,并與伺服器端的代表目前網頁内容特征的實體标簽内容進行比較。如果兩者相同,則表示網頁内容沒有更改,Web伺服器不傳回網頁文檔,讓用戶端仍然使用以前緩存的網頁文檔。否則,伺服器傳回新的網頁檔案和新的實體标簽内容頭字段。
8. If-Modified-Since
- If-Modified-Since請求頭的作用和 If-Mach類似,隻不過它的值為GMT格式的時間。If-Modified-Since請求頭被視作一個請求條件,隻有伺服器中文檔的修改時間比IF-Modified-Since請求頭指定的時間新,伺服器才會傳回文檔内容。否則,伺服器将傳回一個304(Not Modified)狀态碼來表示浏覽器緩存的文檔是最新的,而不向浏覽器傳回文檔内容,這時,浏覽器仍然使用以前緩存的文檔。通過這種方式,可以在一定程度上減少浏覽器與伺服器之間的通信資料量,進而提高了通信效率。
9. Range和If-Range
- Range頭字段用于指定伺服器隻需傳回文檔中的部分内容及内容範圍,這對較大文檔的斷點續傳非常有用。如果用戶端在一次請求中隻接收到伺服器傳回的部分内容就中斷了,可以在第二次請求中,使用 Range頭字段要求伺服器隻傳回中斷位置以後的内容。Range頭有以下幾種使用格式。
(1)Range: bytes=1000-2000
(2) Range: bytes=1000-
(3) Range:bytes=-1000
- 在上面列舉的三種格式中,第一種格式請求伺服器傳回文檔中的第1000~2000個位元組之間的内容,包括第1000個和第2000個位元組的内容。第二種格式請求伺服器傳回文檔中的第1000個位元組以後的所有内容。第三種格式請求伺服器傳回文檔中的最後1000個位元組的内容。
- If-Range頭字段隻能伴随着Range頭字段一起使用,其設定值可以是實體标簽或GMT格式的時間。如果設定值為實體标簽,且該标簽内容與伺服器端代表目前網頁内容特征的實體标簽内容相同,則伺服器按Range頭的要求傳回網頁中的部分内容，否則，伺服器傳回目前網頁的所有内容。如果設定值為GMT格式的時間,并且自從這個時間以來,伺服器上儲存的該網頁檔案沒有發生修改,伺服器會按Range頭的要求傳回網頁中的部分内容,否則,伺服器傳回目前網頁的所有内容。
10. Max-Forward
- Max-Forward頭字段指定目前請求可以途經的代理伺服器數量,每經過一個代理伺服器,此數值就減1。當Max-Forward請求頭的值為0時,如果請求還沒有到達最終的Web伺服器,那麼代理伺服器将終止轉發這個請求,由它來完成對客戶機的最終響應。
11. Referer
- 浏覽器向伺服器發出的請求,可能是直接在浏覽器中輸入 URL位址而發出,也可能是單擊一個網頁上的超連結而發出。對于第一種直接在浏覽器位址欄中輸入 URL位址的情況,浏覽器不會發送 Referer請求頭,而對于第二種情況,浏覽器會使用Referer頭字段辨別送出請求的超連結所在網頁的URL。例如,本地Tomcat伺服器的 chapter03項目中有一個 HTML檔案 GET.html,GET.html中包含一個指向遠端伺服器的超連結，當單擊這個超連結向伺服器發送GET請求時,浏覽器會在發送的請求消息中包含Referer頭空段.如下所示.
Referer: http://localhost:8080/Test01/GET.html - Referer頭字段非常有用,常被網站管理人員用來追蹤網站的通路者是如何導航進入網站的。同時,Referer頭字段還可以用于網站的防盜鍊。有R提太機,版什麼是盜鍊呢?假設一個網站的首頁中想顯示一些圖檔資訊,而在該網站的伺服器中并沒有這些圖檔資源,它通過在 HTML 檔案中使用img标記連結到其他網站的圖檔資源,将其展示給浏覽者,這就是盜鍊。盜鍊的網站提高了自己網站的通路量,卻加重了被連結網站伺服器的負擔,損害了其合法利益。是以,一個網站為了保護自己的資源,可以通過Referer頭檢測出從哪裡連結到目前的網頁或資源，一旦檢測到不是通過本站的連結進行的通路,可以進行阻止通路或者跳轉到指定的頁面。
12. User-Agent
- User-Agent中文名為使用者代理;簡稱
UA
User-Agent
User-Agent: Mozilla/4.0(compatible;MSIE 8.0; Windows NT 5.1: Trident/4.0) - 在上面的請求頭中,User-Agent頭字段首先列出了Mozilla版本,然後列出了浏覽器的版本(MSIE 8.0表示 Microsoft IE 8.0)、作業系統的版本(Windows NT 5.1表示Windows XP)以及浏覽器的引擎名稱(Trident/4.0)。
8. HTTP 響應消息
- 當伺服器收到浏覽器的請求後,會回送響應消息給用戶端。一個完整的響應消息主要包括響應狀态行、響應消息頭和實體内容,其中,每個組成部分都代表了不同的含義，本節将圍繞HTTP響應消息的每個組成部分進行詳細的講解。
1. HTTP響應狀态行
- HTTP響應狀态行位于響應消息的第一行,它包括三個部分，分别是 HTTP版本一個表示成功或錯誤的整數代碼(狀态碼)和對狀态碼進行描述的文本資訊,具體示例如下:
HTTP/1.1 200 OK - 上面的示例就是一個 HTTP 響應消息的狀态行,其中 HTTP 1.1是通信使用的協定版本(200是狀态碼),OK是狀态描述,說明用戶端請求成功。需要注意的是,請求行中的每個部分需要用空格分隔,最後要以回車換行結束。
- 狀态代碼由三位數字組成,表示請求是否被了解或被滿足。HTTP響應狀态碼的第一個數字定義了響應的類别,後面兩位沒有具體的分類,第一個數字有5種可能的取值，具體介紹如下所示。
-
1xx
-
2xx
-
3xx
-
4xx
-
5xx
- 下面通過表3-2~表3-6對 HTTP 1.1協定版本下的5種類别的狀态碼、狀态資訊(每個狀态碼後面小括号中的内容就是狀态資訊)及其作用分别進行說明。
- 表3-2～表3-6列舉了HTTP的大多數狀态碼,這些狀态碼無須記憶。接下來列舉幾個Web開發中比較常見的狀态碼,具體如下。
(1)
200
:表示伺服器成功處理了用戶端的請求。
(2)
302
:表示請求的資源臨時從不同的URI響應請求,但請求者應繼續使用原有位置來進行以後的請求。例如,在請求重定向中,臨時 URI應該是響應的Location頭字段所指向的資源。
(3)
404
;表示伺服器找不到請求的資源。例如,通路伺服器不存在的網頁經常傳回此狀态碼。
(4)
500
:表示伺服器發生錯誤,無法處理用戶端的請求。
2. HTTP 響應消息頭
- 在HTTP響應消息中,第一行為響應狀态行,緊接着的是若幹響應消息頭,伺服器端通過響應消息頭向用戶端傳遞附加資訊,包括服務程式名、被請求資源需要的認證方式,用戶端請求資源的最後修改時間、重定向位址等資訊。HTTP響應消息頭的具體示例如下所示:
- 從上面的響應消息頭可以看出,它們的格式和 HTTP請求消息頭的格式相同。當伺服器向用戶端回送響應消息時,根據情況的不同,發送的響應消息頭也不相同。接下來,針對―些常用的響應消息頭字段進行詳細講解。
1. Accept-Range
- Accept-Range頭字段用于說明伺服器是否接收用戶端使用
Range
Accept-Range: none - 如果伺服器想告訴用戶端可以使用以
bytes
2. Age
- Age頭字段用于指出目前網頁文檔可以在用戶端或代理伺服器中緩存的有效時間，設定值為一個以秒為機關的時間數,具體示例如下所示:
Age: 1234567 - 用戶端再次通路已緩存的某個網頁文檔内容時,先用目前的時間值減去伺服器傳回該網頁時所設定的Date頭字段值,如果結果值小于伺服器上傳回該網頁時所設定的Age頭字段的時間值,用戶端直接使用緩存中的網頁内容。否則,用戶端将向伺服器發出針對該頁面的網頁請求。
3. Etag
- Etag頭字段用于向用戶端傳送代表實體内容特征的标記資訊,這些标記資訊稱為實體标簽,每個版本的資源的實體标簽是不同的,通過實體标簽可以判斷在不同時間獲得的同一資源路徑下的實體内容是否相同。例如,在一個文檔最後添加一個回車換行，Etag頭字段的值就能辨別出不同。Etag頭字段的格式如下所示:
Etag: abc1234 4. Location
- Location頭字段用于通知用戶端擷取請求文檔的新位址,其值為一個使用絕對路徑的URL位址,如下所示;
Location: http://www.xdr630.top - Location頭字段和大多數
3xx
Location
Content-Type
5. Retry-After
- Retry-After頭字段可以與503狀态碼配合使用,告訴用戶端在什麼時間可以重新發送請求。也可以與任何一個3xx狀态碼配合使用,告訴用戶端處理重定向的最小延時時間。Retry-After頭字段的值可以是GMT格式的時間,也可是一個以秒為機關的時間數,具體示例如下:
Retry-After: Sun, 21 Mar 2021 10:00:00
GMTRetry-After: 120 //120秒 6. Server
- Server頭字段用于指定伺服器軟體産品的名稱,具體示例如下:
Server: Apache- Coyote/1.1 7. Vary
- Vary用于指定影響了伺服器所生成的響應内容的那些請求頭字段名,具體示例如下:
Vary: Accept-Language - 上面的響應頭字段說明了伺服器響應的内容受到了用戶端發送的Accept-Language請求頭的影響,伺服器根據Accept-Language請求頭的值,傳回相應語言種類的網頁内容。當用戶端再次通路已經緩存的資源時,需要檢查Vary頭字段中指定的請求頭字段，檢查請求頭字段的這次設定與上次的設定是否相同,以此作為是否使用緩存的條件。-例如,上次的請求中Accept-Language頭字段的值為en-us,而這次的 Accept-Language頭字段的值為zh-cn,即使用戶端使用請求資源路徑的本地緩存的其他條件都成立,但用戶端也不能使用緩存,它仍需向伺服器發出通路請求。
8. WWW-Authenticate和Proxy-Authenticate
- 當用戶端通路受密碼保護的網頁檔案時,伺服器會在響應消息中回送401(Unauthrized)響應狀态碼和WWW-Authoricate響應頭,訓示用戶端應該在Author-ization請求頭中使用WWW-Authoricate響應頭指定的認證方式提供使用者名和密碼資訊。WWW-Authenticate響應頭中可以指定兩種認證方式:
BASIC
DIGEST
WWW-Authenticate: BASIC realm= "xdr630" - 其中, realm屬性用于指定目前資源所屬的域,域定義了同一個主機内的一個受保護區間(一組需要保護的資源)，它可以是任意字元串。同一台主機上可以有多個域,相同的域内所有的資源都共享相同的賬戶。如果某個賬戶具有通路某個資源的權限,那麼該賬戶就能通路同一個域中的其他資源。根據HTTP驗證的規範，與某一資源具有相同的目錄路徑或位于其目錄路徑的子目錄中的資源,與該資源使用相同的域。
- DIGEST認證方式細節比較複雜,想對其進行深入研究的讀者可以參閱 RFC2617文檔。
- Proxy-Authenticate頭字段是針對代理伺服器的使用者資訊驗證，其他的作用與用法與 WWW-Authenticate頭字段類似。
9. Refresh
- Refresh頭字段用于告訴浏覽器自動重新整理頁面的時間,它的值是一個以秒為機關的時間數,具體示例如下所示:
Refresh:3 - 上面所示的Refresh頭字段用于告訴浏覽器在3秒後自動重新整理此頁面。
- 需要注意的是,在 Refresh頭字段的時間值後面還可以增加一個URL參數,時間值與URL之間用分号(﹔)分隔,用于告訴浏覽器在指定的時間值後跳轉到其他網頁,例如告訴浏覽器經過3秒跳轉到www.xdr630.top網站,具體示例如下:
Refresh:3; url=http://www.xdr630.top 10. Content-Disposition
- 如果伺服器希望浏覽器不是直接處理響應的實體内容,而是讓使用者選擇将響應的實體内容儲存到一個檔案中,這需要使用Content-Disposition頭字段。Content-Disposition頭字段沒有在 HTTP的标準規範中定義,它是從 RFC 2183中借鑒過來的。在RFC 2183中,Content-Disposition指定了接收程式處理資料内容的方式,有inline和attachment兩種标準方式, inline表示直接處理,而attachment則要求使用者幹預并控制接收程式處理資料内容的方式。而在 HTTP應用中，隻有attachment是 Content-Disposition的标準方式。attachment後面還可以指定filename參數。filename參數值是伺服器建議浏覽器儲存實體内容的檔案名稱,浏覽器應該忽略filename參數值中的目錄部分,隻取參數中的最後部分作為檔案名。在設定Content-Disposition之前,一定要設定Content-Type頭字段,具體示例如下.
Content-Type: application/octet-stream
Content- Disposition: attachment; filename=lee.zip 3. HTTP其他頭字段
1. 通用頭字段
- 在 HTTP消息中,有些頭字段既适用于請求消息也适用于響應消息,這樣的字段被稱為通用頭字段。通用頭字段有如下幾種:Cache-Control、 Connection、Date, Pragma,Trailer、 Transfer-Encoding,Upgrade、 Via, Warning,關于這些通用頭字段的相關講解具體如下。
1. Cache-Control
- 如果Cache-Control用在請求消息中,它用于通知位于用戶端和伺服器端之間的理伺服器如何使用已緩存的頁面。在這種情況下,Cache-Control的值可以是:no-cache、no-store、max-age , max-stale、 min-fresh 、no-transform,only-if-cached等。
- 如果Cache-Control用在響應消息中,它用于通知用戶端和代理伺服器如何緩存頁面,在這種情況下，Cache-Control 的取值可以為public、 private , no-cache、no-store、no-transform,must-revalidate、proxy-revalidate 、 max-age,s-max-age等。
- 在一個Cache-Control頭字段中可以設定多個值,它們之間用過号分隔,具體示例如下:
Cache-Control: no- stroe,no-cache,must-revalidage - 在上面的Cache-Control頭字段中,設定的每個值都有特定的含義,接下來,通過表3-7對Cache-Control頭字段的一些常用值進行介紹說明。
2. Connection
- Connection頭字段用于指定處理完本次請求/響應後,用戶端和伺服器端是否還要繼續保持連接配接。Connection頭字段可以指定兩個值,如下所示:罐必監中來都鼓
Connection: Keep-Alive
Connection: close - 當Connection頭字段的值為Keep-Alive時,用戶端與伺服器在完成本次互動後繼續保持連接配接,當Connection頭字段的值為close 時,用戶端與伺服器在完成本次互動後關閉連接配接。對于HTTP1.1版本來說,預設采用持久連接配接,也就是說預設情況下，Connection頭字段的值為Keep- Alive.
3. Data
- Date頭字段用于表示 HTTP消息産生的目前時間,它的值為GMT格式,具體示例如下:
Mon, 22 Feb 2021 08:29:02 GMT - 一般情況下,伺服器傳回的所有響應中必須包括一個 Date頭字段.除了下而這此情況。
- 響應狀态代碼表示伺服器的錯誤，如500(内部伺服器錯誤)或503(服務不可用),那麼伺服器就不可能産生一個有效的日期。
- 伺服器沒有時鐘,不能提供目前時間,響應就不能設定Date頭,這種情況下,伺服器也不能設定如 Expire、Last-Modified等這樣的頭字段。
4. Pragma
- Pragma頭字段主要在HTTP 1.0中通知代理伺服器和用戶端如何使用緩存頁面，它的值隻能固定設定為no-cache,如下所示:
Pragma: no-cache - 當Pragma頭字段用于響應消息時,訓示用戶端不要緩存文檔;當用于請求消息時，訓示代理伺服器必須傳回一個最新的文檔,而不能傳回緩存的文檔。在HTTP 1.0中，一些浏覽器對Pragma頭字段的支援不是非常可靠,是以,人們常常通過設定Expires頭字段的值為0來實作同樣功能。
- 而在 HTTP 1.1中,
Cache-Control
Pragma
5. Transfer-Encoding
- 對于HTTP 1.0協定,伺服器端和用戶端不是持久化連接配接,當伺服器端關閉了TCP連接配接,用戶端就知道響應的資料已經發送完畢。而對于HTTP 1.1來說,由于伺服器端和用戶端保持持久連接配接,伺服器端必須在響應消息中通過Content-Length頭字段通知用戶端響應資料的長度,用戶端才能知道資料何時傳輸完畢。然而,在伺服器端,有些資料是動态生成的,伺服器必須等到所有的内容都生成後才能準确地計算出響應資料的長度,也就是說隻有當所有資料生成完畢後伺服器端才能響應用戶端的請求,這樣勢必會影響效率。為了解決這個問題，Transfer-Encoding頭字段被引人,這個頭字段指定響應消息的實體内容采用哪種傳輸編碼方式,目前标準設定值隻有chunked,具體示例如下:
Transfer-Encoding: chunked - 當響應消息中設定了Transfer-Encoding頭字段後,會把響應消息的整個實體内容分成一連串分段後再進行傳輸。每個分段的開始都是一個十六進制的數字,用來表示整個分段的大小。最後一個分段必須是0,用于表示整個 chunked編碼資料的結束,如下所示:
HTTP/1.1 200 OK
Content-Type: text/htm1Transfer-Encoding: chunked
7f
<html>
<head>
<title>trailer Example</title>
</head>
<body>
<p> Please wait while we complete your transaction ...</p>
2c
<p>Transaction complete!</p>
</body>
</html>
0 - 上面的響應消息中,7f和2c代表兩個分段内容的大小辨別資訊,是以這種情況下不必用 Content-Length頭字段來指定整個實體内容的大小。
6. Trailer
- 一些頭字段可以放置在整個 HTTP消息的尾部,也就是可以在實體内容部分之後放置頭字段資訊。對于放置在尾部的頭字段,需要在消息頭中使用Trailer字段說明,具體示例如下，
Trailer:Date - 需要注意的是，Trailer頭字段必須在 chunked傳輸編碼的方式下使用。
7. Upgrade
- Upgrade頭字段用在用戶端,用于指定用戶端想要從目前協定切換的新的通信協定。如果伺服器端認為切換的協定合适,會在響應消息中設定Upgrade頭字段指定切換的協定，Upgrade響應頭字段需要和101狀态碼配合使用,具體示例如下:
//請求消息
GET /HTTP/1.1
Host: 127.0.0.1
Upgrade: TLS/1.0
//響應消息
HTTP/1.1 101 Switching Protocols
Upgrade: TLS/1.0 8. Via
- Via頭字段用于指定HTTP 消息所途經的代理伺服器所使用的協定和主機名稱,這個頭字段由代理伺服器産生,每個代理伺服器必須把它的資訊追加到Via字段的最後，以反映 HTTP消息途經的多個代理伺服器的順序,具體示例如下:
Via: HTTP/1.1 Proxy1,HTTP/1.1 Proxy2 - 如果代理伺服器所使用的協定為HTTP,Via頭字段中的協定名稱可以省略,如下所示:
Via: 1.1 Proxy1,1.1 Proxy2 9. Warning
- Warning頭字段主要用于說明其他頭字段和狀态碼不能說明的一些附加警告資訊，例如提示代理伺服器斷開網絡,如下所示:
warning:112 Disconnected operation 2. 實體頭字段
- 請求消息和響應消息中都可以傳遞實體資訊,實體資訊包括實體頭字段和實體内容,實體頭字段是實體内容的元資訊,描述了實體内容的屬性,例如實體内容的類型、長度、壓縮方法、最後的修改時間、資料的有效期等。接下來,本節将針對實體頭字段進行詳細的講解。
1. Allow
- Allow頭字段指定了請求資源所支援的請求方式(如 GET,POST等),用于通知用戶端應該嚴格按照指定的方式請求資源,如下所示:
Al1ow: GET,HEAD,PUT - 需要注意的是,Allow頭字段必須和405響應狀态碼一起使用。
2. Content-Language
- Content-Language用于指定傳回網頁文檔的國家語言類型,其設定值是zh-cn,en-us,ja等國家語言的标準名稱。由于同一個字元在不同的國家語言中的樣式和意義上能有略微差別,如果一些用戶端軟體正好要對字元文本按不同的國家語言進行不同處理時, Content-Language頭字段就比較重要了。Content-Language的具體示例如下所示:
Content-Language: en-us 3. Content-Length
- Content-Length頭字段用于表示實體内容的長度(位元組數),首先來看一個帶有Content-Length頭字段的簡單的響應消息,具體如下所示:
HTTP/1.1 200 OK
Date: Mon, 22 Feb 2021 09:29:57 GMT
Content- Length:109
<html>
<head>
<title> content-Length Example</title>
</head>
<body>
Content-Length:109
</body>
</html> - 在上面的響應消息中,從
<html>
</hml>
- 在 HTTP 1.1中,浏覽器與伺服器之間保持持久連接配接,伺服器允許用戶端在一個TCP連接配接上發送多個請求,伺服器必須在每個響應中發送一個 Content-Length響應頭來辨別各個實體内容的長度,以便用戶端能厘清每個響應内容的結束位置,而不會将上一個響應和下一個響應混淆。
- 如果響應消息中包含 Transfer-Encoding響應頭,也就是說響應内容以chunked編碼方式傳回,那麼,Content-Length響應頭就不應該設定了。
4. Content-Location
- Content-Location頭字段用于指定響應消息中實體内容的實際位置路徑(不能簡單地認為響應消息中的實體内容所在的路徑就是請求資源的路徑)，當一個請求資源路徑對應有多種實體内容形式時,例如,同一請求資源可能有多個國家語言的版本,每個國家語言的版本都有自己的位置,在這種情況下,請求資源路徑與響應的實體内容所在的路徑可能是不同的,具體示例如下:
//請求消息
GET /docs/index.html HTTP/1.1
Host: httpd.apache.org
Accept- Language: en-us
//響應消息
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 - 在上面的示例中,請求消息中需要請求index. html文檔,而且要求是英文文檔,伺服器中發現有可用的英文文檔index_en_us.html,就會在響應消息中将Content-Location消息頭的值設定為index_en_us. html文檔的路徑,并把該文檔回送給用戶端。
- Content-Location的設定值可以是絕對路徑,也可以是相對路徑,如果是相對路徑，則是相對請求資源路徑而言的,對于上面的響應消息來說, index, html和 index_en_us.html在同一目錄下。
5. Content-Range
- Content-Range頭字段用于指定伺服器傳回的部分實體内容的位置資訊。隻有客戶機使用了Range請求頭要求伺服器傳回實體的部分内容時,伺服器的響應頭中才會包含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說明後面的資料以byte為機關,21010～47021說明傳回的内容從第21010個位元組開始到第47021個位元組結束,47022說明整個實體内容的大小為47022個位元組,從 Content-Length頭字段可以看出傳回的實體内容的長度為26012(47 021-21 010＋1)個位元組。
6. Content-MD5
- Content-MD5頭字段用于提供對實體内容的完整性檢查,它的值是對實體内容MD5 數字摘要後再進行 Base64編碼的結果。
- MD5 數字摘要算法是一種雜湊演算法,能夠通過對一段資訊進行運算,産生一個16個位元組的數字摘要。如果對輸人資訊做了任何形式的改變,對改變後的資訊再次進行MD5運算所産生的數字摘要和改變之前的數字摘要都不相同。由于通過MD5算法計算的16個位元組摘要資訊可能無法轉化成可列印的 ASCII字元顯示,是以需要對這16個位元組進行 Base64編碼,将其轉換為可列印的 ASCII字元。Content-MD5的頭字段如下所示:
Content-MD5: ZTFmZDA5MDYyYTMzZGQzMDMxMmixMjc4YThhNTMyM21= 7. Content-Type
- Content-Type用于指出實體内容的MIME類型。MIME(Multipurpose InternetMail Extensions,多用途網際網路郵件擴充類型)是一個網際網路标準,它設計之初是為了在發送電子郵件時附加多媒體資料,讓郵件客戶程式能根據其類型進行處理。由于通過HTTP傳輸的資料也有各種類型,是以,HTTP 也采用了MIME來辨別不同的資料類型。用戶端通過檢查響應頭字段 Content-Type中的 MIME類型,就能知道接收到的實體内容代表哪種格式的資料類型,進而進行正确的處理。
- 大多數伺服器會在配置檔案中設定檔案擴充名與MIME類型的映射關系,進而可以根據請求資源的擴充名自動确定 Content-Type的 MIME類型。在Tomcat的 web.xml檔案中有大量的元素,來實作檔案擴充名和 MIME類型的映射，下面是web. xml檔案的片段:
...
<mime-mapping>
<extension>pdf</extension>
<mime-type>application/pdf</mime-type>
</mime-mapping>
... - 其中
<mime-mapping >
<extension>
,<mime-type>
- MIME類型包含主類型和子類型,兩者之間用“/”分隔,上面的檔案片段中的 MIM類型“application/pdf”, application為主類型,pdf為子類型。MIME類型也可以使用“
*
*/ *
image/ *
x-