HTTP 首部
HTTP 協(xié)議的請求和響應(yīng)報文中必定包含 HTTP 首部。首部內(nèi)容為客
戶端和服務(wù)器分別處理請求和響應(yīng)提供所需要的信息。對于客戶端用戶來說，這些信息中的大部分內(nèi)容都無須親自查看
報文首部由幾個字段構(gòu)成
在請求中，HTTP 報文由方法、URI、HTTP 版本、HTTP 首部字段等
部分構(gòu)成。
下面的示例是訪問 http://hackr.jp 時，請求報文的首部信息。
GET / HTTP/1.1
Host: hackr.jp
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*; q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
If-Modified-Since: Fri, 31 Aug 2007 02:02:20 GMT
If-None-Match: "45bae1-16a-46d776ac"
Cache-Control: max-age=0
在響應(yīng)中，HTTP 報文由 HTTP 版本、狀態(tài)碼（數(shù)字和原因短語）、
HTTP 首部字段 3 部分構(gòu)成。
以下示例是之前請求訪問 http://hackr.jp/ 時，返回的響應(yīng)報文的首部
信息。
HTTP/1.1 304 Not Modified
Date: Thu, 07 Jun 2012 07:21:36 GMT
Server: Apache
Connection: close
Etag: "45bae1-16a-46d776ac"
在報文眾多的字段當(dāng)中，HTTP 首部字段包含的信息最為豐富。首部
字段同時存在于請求和響應(yīng)報文內(nèi)，并涵蓋 HTTP 報文相關(guān)的內(nèi)容信
息。
因 HTTP 版本或擴展規(guī)范的變化，首部字段可支持的字段內(nèi)容略有不
同。本書主要涉及 HTTP/1.1 及常用的首部字段。
HTTP 首部字段是構(gòu)成 HTTP 報文的要素之一。在客戶端與服務(wù)器之
間以 HTTP 協(xié)議進行通信的過程中，無論是請求還是響應(yīng)都會使用首
部字段，它能起到傳遞額外重要信息的作用。
使用首部字段是為了給瀏覽器和服務(wù)器提供報文主體大小、所使用的
語言、認(rèn)證信息等內(nèi)容。
HTTP 首部字段是由首部字段名和字段值構(gòu)成的，中間用冒號“:” 分
隔。
首部字段名: 字段值
例如，在 HTTP 首部中以 Content-Type 這個字段來表示報文主體的 對
象類型。
Content-Type: text/html
就以上述示例來看，首部字段名為 Content-Type，字符串 text/html 是
字段值。
另外，字段值對應(yīng)單個 HTTP 首部字段可以有多個值，如下所示。
Keep-Alive: timeout=15, max=100
若 HTTP 首部字段重復(fù)了會如何
當(dāng) HTTP 報文首部中出現(xiàn)了兩個或兩個以上具有相同首部字段名時
會怎么樣？這種情況在規(guī)范內(nèi)尚未明確，根據(jù)瀏覽器內(nèi)部處理邏輯
的不同，結(jié)果可能并不一致。有些瀏覽器會優(yōu)先處理第一次出現(xiàn)的
首部字段，而有些則會優(yōu)先處理最后出現(xiàn)的首部字段。
HTTP 首部字段根據(jù)實際用途被分為以下 4 種類型。
通用首部字段（General Header Fields）
請求報文和響應(yīng)報文兩方都會使用的首部。
請求首部字段（Request Header Fields）
從客戶端向服務(wù)器端發(fā)送請求報文時使用的首部。補充了請求的附加
內(nèi)容、客戶端信息、響應(yīng)內(nèi)容相關(guān)優(yōu)先級等信息。
響應(yīng)首部字段（Response Header Fields）
從服務(wù)器端向客戶端返回響應(yīng)報文時使用的首部。補充了響應(yīng)的附加
內(nèi)容，也會要求客戶端附加額外的內(nèi)容信息。
實體首部字段（Entity Header Fields）
針對請求報文和響應(yīng)報文的實體部分使用的首部。補充了資源內(nèi)容更
新時間等與實體有關(guān)的信息。
HTTP/1.1 規(guī)范定義了如下 47 種首部字段。
表 6-2：請求首部字段
在 HTTP 協(xié)議通信交互中使用到的首部字段，不限于 RFC2616 中定
義的 47 種首部字段。還有 Cookie、Set-Cookie 和 Content-Disposition
等在其他 RFC 中定義的首部字段，它們的使用頻率也很高。
這些非正式的首部字段統(tǒng)一歸納在 RFC4229 HTTP Header Field
Registrations 中。
HTTP 首部字段將定義成緩存代理和非緩存代理的行為，分成 2 種類
型。
端到端首部（End-to-end Header）
分在此類別中的首部會轉(zhuǎn)發(fā)給請求 / 響應(yīng)對應(yīng)的最終接收目標(biāo)，且必
須保存在由緩存生成的響應(yīng)中，另外規(guī)定它必須被轉(zhuǎn)發(fā)。
逐跳首部（Hop-by-hop Header）
分在此類別中的首部只對單次轉(zhuǎn)發(fā)有效，會因通過緩存或代理而不再轉(zhuǎn)發(fā)。HTTP/1.1 和之后版本中，如果要使用 hop-by-hop 首部，需提
供 Connection 首部字段。
下面列舉了 HTTP/1.1 中的逐跳首部字段。除這 8 個首部字段之外，
其他所有字段都屬于端到端首部。
Connection
Keep-Alive
Proxy-Authenticate
Proxy-Authorization
Trailer
TE
Transfer-Encoding
Upgrade
通用首部字段是指，請求報文和響應(yīng)報文雙方都會使用的首部
通過指定首部字段 Cache-Control 的指令，就能操作緩存的工作機
制。
指令的參數(shù)是可選的，多個指令之間通過“,”分隔。首部字段 Cache-
Control 的指令可用于請求及響應(yīng)時。
Cache-Control: private, max-age=0, no-cache
Cache-Control 指令一覽
表示是否能緩存的指令
public 指令
Cache-Control: public
當(dāng)指定使用 public 指令時，則明確表明其他用戶也可利用緩存。
private 指令
Cache-Control: private
當(dāng)指定 private 指令后，響應(yīng)只以特定的用戶作為對象，這與 public
指令的行為相反。
緩存服務(wù)器會對該特定用戶提供資源緩存的服務(wù)，對于其他用戶發(fā)送過來的請求，代理服務(wù)器則不會返回緩存。
no-cache 指令
Cache-Control: no-cache
使用 no-cache 指令的目的是為了防止從緩存中返回過期的資源。
客戶端發(fā)送的請求中如果包含 no-cache 指令，則表示客戶端將不會接
收緩存過的響應(yīng)。于是，“中間”的緩存服務(wù)器必須把客戶端請求轉(zhuǎn)發(fā)
給源服務(wù)器。
如果服務(wù)器返回的響應(yīng)中包含 no-cache 指令，那么緩存服務(wù)器不能對
資源進行緩存。源服務(wù)器以后也將不再對緩存服務(wù)器請求中提出的資
源有效性進行確認(rèn)，且禁止其對響應(yīng)資源進行緩存操作。
Cache-Control: no-cache=Location
由服務(wù)器返回的響應(yīng)中，若報文首部字段 Cache-Control 中對 no-cache
字段名具體指定參數(shù)值，那么客戶端在接收到這個被指定參數(shù)值的首
部字段對應(yīng)的響應(yīng)報文后，就不能使用緩存。換言之，無參數(shù)值的首
部字段可以使用緩存。只能在響應(yīng)指令中指定該參數(shù)。
控制可執(zhí)行緩存的對象的指令
no-store 指令
Cache-Control: no-store
當(dāng)使用 no-store 指令時，暗示請求（和對應(yīng)的響應(yīng)）或響應(yīng)中包含
機密信息。因此，該指令規(guī)定緩存不能在本地存儲請求或響應(yīng)的任一部分。
指定緩存期限和認(rèn)證的指令
s-maxage 指令
Cache-Control: s-maxage=604800（單位 ：秒）
s-maxage 指令的功能和 max-age 指令的相同，它們的不同點是 smaxage
指令只適用于供多位用戶使用的公共緩存服務(wù)器 。也就是
說，對于向同一用戶重復(fù)返回響應(yīng)的服務(wù)器來說，這個指令沒有任何
作用。
另外，當(dāng)使用 s-maxage 指令后，則直接忽略對 Expires 首部字段及
max-age 指令的處理。
max-age 指令
Cache-Control: max-age=604800（單位：秒）
當(dāng)客戶端發(fā)送的請求中包含 max-age 指令時，如果判定緩存資源的緩
存時間數(shù)值比指定時間的數(shù)值更小，那么客戶端就接收緩存的資源。
另外，當(dāng)指定 max-age 值為 0，那么緩存服務(wù)器通常需要將請求轉(zhuǎn)發(fā)
給源服務(wù)器。
當(dāng)服務(wù)器返回的響應(yīng)中包含 max-age 指令時，緩存服務(wù)器將不對資源
的有效性再作確認(rèn)，而 max-age 數(shù)值代表資源保存為緩存的最長時
間。
應(yīng)用 HTTP/1.1 版本的緩存服務(wù)器遇到同時存在 Expires 首部字段的情
況時，會優(yōu)先處理 max-age 指令，而忽略掉 Expires 首部字段。而
HTTP/1.0 版本的緩存服務(wù)器的情況卻相反，max-age 指令會被忽略掉
min-fresh 指令
Cache-Control: min-fresh=60（單位：秒）
min-fresh 指令要求緩存服務(wù)器返回至少還未過指定時間的緩存資源。
比如，當(dāng)指定 min-fresh 為 60 秒后，過了 60 秒的資源都無法作為響
應(yīng)返回了。
max-stale 指令
Cache-Control: max-stale=3600（單位：秒）
使用 max-stale 可指示緩存資源，即使過期也照常接收。
如果指令未指定參數(shù)值，那么無論經(jīng)過多久，客戶端都會接收響應(yīng)；
如果指令中指定了具體數(shù)值，那么即使過期，只要仍處于 max-stale
指定的時間內(nèi)，仍舊會被客戶端接收。
only-if-cached 指令
Cache-Control: only-if-cached
使用 only-if-cached 指令表示客戶端僅在緩存服務(wù)器本地緩存目標(biāo)資
源的情況下才會要求其返回。換言之，該指令要求緩存服務(wù)器不重新
加載響應(yīng)，也不會再次確認(rèn)資源有效性。若發(fā)生請求緩存服務(wù)器的本
地緩存無響應(yīng)，則返回狀態(tài)碼 504 Gateway Timeout。
must-revalidate 指令
Cache-Control: must-revalidate
使用 must-revalidate 指令，代理會向源服務(wù)器再次驗證即將返回的響
應(yīng)緩存目前是否仍然有效。
若代理無法連通源服務(wù)器再次獲取有效資源的話，緩存必須給客戶端
一條 504（Gateway Timeout）狀態(tài)碼。
另外，使用 must-revalidate 指令會忽略請求的 max-stale 指令（即使已
經(jīng)在首部使用了 max-stale，也不會再有效果）。
proxy-revalidate 指令
Cache-Control: proxy-revalidate
proxy-revalidate 指令要求所有的緩存服務(wù)器在接收到客戶端帶有該指
令的請求返回響應(yīng)之前，必須再次驗證緩存的有效性。
no-transform 指令
Cache-Control: no-transform
使用 no-transform 指令規(guī)定無論是在請求還是響應(yīng)中，緩存都不能改
變實體主體的媒體類型。這樣做可防止緩存或代理壓縮圖片等類似操作。
Cache-Control 擴展
cache-extension token
Cache-Control: private, community="UCI"
通過 cache-extension 標(biāo)記（token），可以擴展 Cache-Control 首部字
段內(nèi)的指令。
如上例，Cache-Control 首部字段本身沒有 community 這個指令。借助
extension tokens 實現(xiàn)了該指令的添加。如果緩存服務(wù)器不能理解
community 這個新指令，就會直接忽略。因此，extension tokens 僅對
能理解它的緩存服務(wù)器來說是有意義的。
Connection 首部字段具備如下兩個作用
控制不再轉(zhuǎn)發(fā)給代理的首部字段
Connection: 不再轉(zhuǎn)發(fā)的首部字段名
在客戶端發(fā)送請求和服務(wù)器返回響應(yīng)內(nèi)，使用 Connection 首部字
段，可控制不再轉(zhuǎn)發(fā)給代理的首部字段（即 Hop-by-hop 首
部）。
管理持久連接
Connection: close
? ? ? ?HTTP/1.1 版本的默認(rèn)連接都是持久連接。為此，客戶端會在持
久連接上連續(xù)發(fā)送請求。當(dāng)服務(wù)器端想明確斷開連接時，則指定
Connection 首部字段的值為 Close。
Connection: Keep-Alive
? ? ? ?HTTP/1.1 之前的 HTTP 版本的默認(rèn)連接都是非持久連接。為
此，如果想在舊版本的 HTTP 協(xié)議上維持持續(xù)連接，則需要指定
Connection 首部字段的值為 Keep-Alive。
如上圖①所示，客戶端發(fā)送請求給服務(wù)器時，服務(wù)器端會像上圖
②那樣加上首部字段 Keep-Alive 及首部字段 Connection 后返回
響應(yīng)。
首部字段 Date 表明創(chuàng)建 HTTP 報文的日期和時間。
HTTP/1.1 協(xié)議使用在 RFC1123 中規(guī)定的日期時間的格式，如下 示
例。
Date: Tue, 03 Jul 2012 04:40:59 GMT
之前的 HTTP 協(xié)議版本中使用在 RFC850 中定義的格式，如下所示。
Date: Tue, 03-Jul-12 04:40:59 GMT
除此之外，還有一種格式。它與 C 標(biāo)準(zhǔn)庫內(nèi)的 asctime() 函數(shù)的輸出
格式一致。
Date: Tue Jul 03 04:40:59 2012
Pragma 是 HTTP/1.1 之前版本的歷史遺留字段，僅作為與 HTTP/1.0
的向后兼容而定義。
規(guī)范定義的形式唯一，如下所示。
Pragma: no-cache
該首部字段屬于通用首部字段，但只用在客戶端發(fā)送的請求中?？蛻?/p>
端會要求所有的中間服務(wù)器不返回緩存的資源。
所有的中間服務(wù)器如果都能以 HTTP/1.1 為基準(zhǔn)，那直接采用 Cache-
Control: no-cache 指定緩存的處理方式是最為理想的。但要整體掌握
全部中間服務(wù)器使用的 HTTP 協(xié)議版本卻是不現(xiàn)實的。因此，發(fā)送的
請求會同時含有下面兩個首部字段。
Cache-Control: no-cache
Pragma: no-cache
首部字段 Trailer 會事先說明在報文主體后記錄了哪些首部字段。該
首部字段可應(yīng)用在 HTTP/1.1 版本分塊傳輸編碼時。
HTTP/1.1 200 OK
Date: Tue, 03 Jul 2012 04:40:56 GMT
Content-Type: text/html
...
Transfer-Encoding: chunked
Trailer: Expires
...(報文主體)...
0
Expires: Tue, 28 Sep 2004 23:59:59 GMT
以上用例中，指定首部字段 Trailer 的值為 Expires，在報文主體之后
（分塊長度 0 之后）出現(xiàn)了首部字段 Expires。
首部字段 Transfer-Encoding 規(guī)定了傳輸報文主體時采用的編碼方式。HTTP/1.1 的傳輸編碼方式僅對分塊傳輸編碼有效
HTTP/1.1 200 OK
Date: Tue, 03 Jul 2012 04:40:56 GMT
Cache-Control: public, max-age=604800
Content-Type: text/javascript; charset=utf-8
Expires: Tue, 10 Jul 2012 04:40:56 GMT
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Content-Encoding: gzip
Transfer-Encoding: chunked
Connection: keep-alive
cf0 ←16進制(10進制為3312)
...3312字節(jié)分塊數(shù)據(jù)...
392 ←16進制(10進制為914)
...914字節(jié)分塊數(shù)據(jù)...
0
以上用例中，正如在首部字段 Transfer-Encoding 中指定的那樣，有效
使用分塊傳輸編碼，且分別被分成 3312 字節(jié)和 914 字節(jié)大小的分塊
數(shù)據(jù)。
首部字段 Upgrade 用于檢測 HTTP 協(xié)議及其他協(xié)議是否可使用更高的
版本進行通信，其參數(shù)值可以用來指定一個完全不同的通信協(xié)議。
上圖用例中，首部字段 Upgrade 指定的值為 TLS/1.0。請注意此處兩
個字段首部字段的對應(yīng)關(guān)系，Connection 的值被指定為 Upgrade。
Upgrade 首部字段產(chǎn)生作用的 Upgrade 對象僅限于客戶端和鄰接服務(wù)
器之間。因此，使用首部字段 Upgrade 時，還需要額外指定
Connection:Upgrade。
對于附有首部字段 Upgrade 的請求，服務(wù)器可用 101 Switching
Protocols 狀態(tài)碼作為響應(yīng)返回。
使用首部字段 Via 是為了追蹤客戶端與服務(wù)器之間的請求和響應(yīng)報文
的傳輸路徑。
報文經(jīng)過代理或網(wǎng)關(guān)時，會先在首部字段 Via 中附加該服務(wù)器的信
息，然后再進行轉(zhuǎn)發(fā)。這個做法和 traceroute 及電子郵件的 Received
首部的工作機制很類似。
首部字段 Via 不僅用于追蹤報文的轉(zhuǎn)發(fā)，還可避免請求回環(huán)的發(fā)生。所以必須在經(jīng)過代理時附加該首部字段內(nèi)容。
上圖用例中，在經(jīng)過代理服務(wù)器 A 時，Via 首部附加了“1.0
gw.hackr.jp (Squid/3.1)”這樣的字符串值。行頭的 1.0 是指接收請求的服務(wù)器上應(yīng)用的 HTTP 協(xié)議版本。接下來經(jīng)過代理服務(wù)器 B 時亦是如
此，在 Via 首部附加服務(wù)器信息，也可增加 1 個新的 Via 首部寫入服
務(wù)器信息。
Via 首部是為了追蹤傳輸路徑，所以經(jīng)常會和 TRACE 方法一起使
用。比如，代理服務(wù)器接收到由 TRACE 方法發(fā)送過來的請求（其中
Max-Forwards: 0）時，代理服務(wù)器就不能再轉(zhuǎn)發(fā)該請求了。這種情況
下，代理服務(wù)器會將自身的信息附加到 Via 首部后，返回該請求的響
應(yīng)。
HTTP/1.1 的 Warning 首部是從 HTTP/1.0 的響應(yīng)首部（Retry-After）演
變過來的。該首部通常會告知用戶一些與緩存相關(guān)的問題的警告。
Warning: 113 gw.hackr.jp:8080 "Heuristic expiration" Tue, 03
Warning 首部的格式如下。最后的日期時間部分可省略。
Warning: [警告碼][警告的主機:端口號]“[警告內(nèi)容]”([日期時間])
HTTP/1.1 中定義了 7 種警告。警告碼對應(yīng)的警告內(nèi)容僅推薦參考。
另外，警告碼具備擴展性，今后有可能追加新的警告碼
請求首部字段是從客戶端往服務(wù)器端發(fā)送請求報文中所使用的字段，
用于補充請求的附加信息、客戶端信息、對響應(yīng)內(nèi)容相關(guān)的優(yōu)先級等
內(nèi)容。
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;
Accept 首部字段可通知服務(wù)器，用戶代理能夠處理的媒體類型及媒體
類型的相對優(yōu)先級?？墒褂?type/subtype 這種形式，一次指定多種媒
體類型。
下面我們試舉幾個媒體類型的例子
文本文件
text/html, text/plain, text/css ...
application/xhtml+xml, application/xml ...
圖片文件
image/jpeg, image/gif, image/png ...
視頻文件
video/mpeg, video/quicktime ...
應(yīng)用程序使用的二進制文件
application/octet-stream, application/zip ...
比如，如果瀏覽器不支持 PNG 圖片的顯示，那 Accept 就不指定
image/png，而指定可處理的 image/gif 和 image/jpeg 等圖片類型。
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
Accept-Charset 首部字段可用來通知服務(wù)器用戶代理支持的字符集及
字符集的相對優(yōu)先順序。另外，可一次性指定多種字符集。與首部字
段 Accept 相同的是可用權(quán)重 q 值來表示相對優(yōu)先級。
該首部字段應(yīng)用于內(nèi)容協(xié)商機制的服務(wù)器驅(qū)動協(xié)商。
Accept-Encoding: gzip, deflate
Accept-Encoding 首部字段用來告知服務(wù)器用戶代理支持的內(nèi)容編碼及
內(nèi)容編碼的優(yōu)先級順序。可一次性指定多種內(nèi)容編碼。
下面試舉出幾個內(nèi)容編碼的例子。
gzip
? ? ? ?由文件壓縮程序 gzip（GNU zip）生成的編碼格式
（RFC1952），采用 Lempel-Ziv 算法（LZ77）及 32 ? ? ? ? ? ? ?位循環(huán)冗余
校驗（Cyclic Redundancy Check，通稱 CRC）。
compress
由 UNIX 文件壓縮程序 compress 生成的編碼格式，采用 Lempel-
Ziv-Welch 算法（LZW）。
deflate
? ? ? ? ? 組合使用 zlib 格式（RFC1950）及由 deflate 壓縮算法
（RFC1951）生成的編碼格式。
identity
? 不執(zhí)行壓縮或不會變化的默認(rèn)編碼格式
采用權(quán)重 q 值來表示相對優(yōu)先級，這點與首部字段 Accept 相同。另
外，也可使用星號（*）作為通配符，指定任意的編碼格式。
Accept-Language: zh-cn,zh;q=0.7,en-us,en;q=0.3
首部字段 Accept-Language 用來告知服務(wù)器用戶代理能夠處理的自然
語言集（指中文或英文等），以及自然語言集的相對優(yōu)先級。可一次
指定多種自然語言集。
和 Accept 首部字段一樣，按權(quán)重值 q 來表示相對優(yōu)先級。在上述圖
例中，客戶端在服務(wù)器有中文版資源的情況下，會請求其返回中文版
對應(yīng)的響應(yīng)，沒有中文版時，則請求返回英文版響應(yīng)。
Authorization: Basic dWVub3NlbjpwYXNzd29yZA==
首部字段 Authorization 是用來告知服務(wù)器，用戶代理的認(rèn)證信息（證
書值）。通常，想要通過服務(wù)器認(rèn)證的用戶代理會在接收到返回的
401 狀態(tài)碼響應(yīng)后，把首部字段 Authorization 加入請求中。共用緩存
在接收到含有 Authorization 首部字段的請求時的操作處理會略有差
異。
Expect: 100-continue
客戶端使用首部字段 Expect 來告知服務(wù)器，期望出現(xiàn)的某種特定行
為。因服務(wù)器無法理解客戶端的期望作出回應(yīng)而發(fā)生錯誤時，會返回
狀態(tài)碼 417 Expectation Failed。
客戶端可以利用該首部字段，寫明所期望的擴展。雖然 HTTP/1.1 規(guī)
范只定義了 100-continue（狀態(tài)碼 100 Continue 之意）。
等待狀態(tài)碼 100 響應(yīng)的客戶端在發(fā)生請求時，需要指定 Expect:100-
continue。
首部字段 From 用來告知服務(wù)器使用用戶代理的用戶的電子郵件地
址。通常，其使用目的就是為了顯示搜索引擎等用戶代理的負(fù)責(zé)人的
電子郵件聯(lián)系方式。使用代理時，應(yīng)盡可能包含 From 首部字段（但
可能會因代理不同，將電子郵件地址記錄在 User-Agent 首部字段
內(nèi)）。
圖：虛擬主機運行在同一個 IP 上，因此使用首部字段 Host 加以
區(qū)分
Host: www.hackr.jp
首部字段 Host 會告知服務(wù)器，請求的資源所處的互聯(lián)網(wǎng)主機名和端
口號。Host 首部字段在 HTTP/1.1 規(guī)范內(nèi)是唯一一個必須被包含在請
求內(nèi)的首部字段。
首部字段 Host 和以單臺服務(wù)器分配多個域名的虛擬主機的工作機制
有很密切的關(guān)聯(lián)，這是首部字段 Host 必須存在的意義。
請求被發(fā)送至服務(wù)器時，請求中的主機名會用 IP 地址直接替換解
決。但如果這時，相同的 IP 地址下部署運行著多個域名，那么服務(wù)
器就會無法理解究竟是哪個域名對應(yīng)的請求。因此，就需要使用首部
字段 Host 來明確指出請求的主機名。若服務(wù)器未設(shè)定主機名，那直
接發(fā)送一個空值即可。
形如 If-xxx 這種樣式的請求首部字段，都可稱為條件請求。服務(wù)器接
收到附帶條件的請求后，只有判斷指定條件為真時，才會執(zhí)行請求。
