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ù)器提供報文主體大小挪圾、所使用的
語言浅萧、認證信息等內(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ù)器請求中提出的資
源有效性進行確認馒索，且禁止其對響應(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)的任一部分器一。
指定緩存期限和認證的指令
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ù)器將不對資源
的有效性再作確認黍翎，而 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)，也不會再次確認資源有效性乡摹。若發(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 版本的默認連接都是持久連接。為此伐债，客戶端會在持
久連接上連續(xù)發(fā)送請求预侯。當(dāng)服務(wù)器端想明確斷開連接時，則指定
Connection 首部字段的值為 Close峰锁。
Connection: Keep-Alive
? ? ? ?HTTP/1.1 之前的 HTTP 版本的默認連接都是非持久連接萎馅。為
此，如果想在舊版本的 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)準庫內(nèi)的 asctime() 函數(shù)的輸出
格式一致盘榨。
Date: Tue Jul 03 04:40:59 2012
Pragma 是 HTTP/1.1 之前版本的歷史遺留字段喻粹，僅作為與 HTTP/1.0
的向后兼容而定義。
規(guī)范定義的形式唯一草巡，如下所示守呜。
Pragma: no-cache
該首部字段屬于通用首部字段，但只用在客戶端發(fā)送的請求中〔槠梗客戶
端會要求所有的中間服務(wù)器不返回緩存的資源弥喉。
所有的中間服務(wù)器如果都能以 HTTP/1.1 為基準，那直接采用 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í)行壓縮或不會變化的默認編碼格式
采用權(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ù)器瞬矩，用戶代理的認證信息（證
書值）。通常锋玲，想要通過服務(wù)器認證的用戶代理會在接收到返回的
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ù)器使用用戶代理的用戶的電子郵件地
址商架。通常堰怨，其使用目的就是為了顯示搜索引擎等用戶代理的負責(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í)行請求枯饿。
