超文本傳輸協(xié)議 -- HTTP/1.0
（Hyptertext Transfer Protocol – HTTP/1.0）
關(guān)于下段備忘（Status of This Memo）
本段文字為Internet團(tuán)體提供信息，并沒有以任何方式指定Internet標(biāo)準(zhǔn)。本段文字沒
有分發(fā)限制。
IESG提示（IESG Note）：
IESG已在關(guān)注此協(xié)議，并期待該文檔能盡快被標(biāo)準(zhǔn)跟蹤文檔所替代。
摘要（Abstract）
HTTP（Hypertext Transfer Protocol）是應(yīng)用級(jí)協(xié)議，它適應(yīng)了分布式超媒體協(xié)作系統(tǒng)對(duì)
靈活性及速度的要求。它是一個(gè)一般的、無狀態(tài)的、基于對(duì)象的協(xié)議，通過對(duì)其請(qǐng)求方法
（request methods）進(jìn)行擴(kuò)展，可以被用于多種用途，比如命名服務(wù)器（name server）及分
布式對(duì)象管理系統(tǒng)。HTTP的一個(gè)特性是其數(shù)據(jù)表現(xiàn)類型允許系統(tǒng)的構(gòu)建不再依賴于要傳輸
的數(shù)據(jù)。
HTTP自從1990年就在WWW上被廣泛使用。該規(guī)范反映了“HTTP/1.0”的普通用法。
目錄（Table of Contents）
1. 介紹（Introduction） 6
1.1 目的（Purpose） 6
1.2 術(shù)語（Terminology） 6
1.3 概述（Overall Operation） 8
1.4 HTTP and MIME 9
2. 標(biāo)志轉(zhuǎn)換及通用語法（Notational Conventions and Generic Grammar） 9
2.1 補(bǔ)充反饋方式（Augmented BNF） 9
2.2 基本規(guī)則（Basic Rules） 10
3. 協(xié)議參數(shù)（Protocol Parameters） 12
3.1 HTTP版本（HTTP Version） 12
3.2 統(tǒng)一資源標(biāo)識(shí)（Uniform Resource Identifiers） 13
3.2.1 一般語法（General Syntax） 13
3.2.2 http URL 14
3.3 Date/Time 格式（Date/Time Formats） 15
3.4 字符集（Character Sets） 16
3.5 內(nèi)容譯碼（Content Codings） 16
3.6 介質(zhì)類型（Media Types） 17
3.6.1標(biāo)準(zhǔn)及文本缺省（Canonicalization and Text Defaults） 18
3.6.2 多部分類型（Multipart Types） 18
3.7 產(chǎn)品標(biāo)識(shí)（Product Tokens） 19
4. HTTP 消息（HTTP Message） 19
4.1 消息類型（Message Types） 19
4.2 消息標(biāo)題（Message Headers） 20
4.3 普通標(biāo)題域（General Header Fields） 20
5. 請(qǐng)求（Request） 21
5.1 請(qǐng)求隊(duì)列（Request-Line） 21
5.1.1 方法（Method） 22
5.1.2 請(qǐng)求URI（Request-URI） 22
5.2 請(qǐng)求標(biāo)題域（Request Header Fields） 23
6. 回應(yīng)（Response） 23
6.1 狀態(tài)行（Status-Line） 24
6.1.1 狀態(tài)代碼和原因分析（Status Code and Reason Phrase） 24
6.2 回應(yīng)標(biāo)題域（Response Header Fields） 25
7. 實(shí)體（Entity） 26
7.1 實(shí)體標(biāo)題域（Entity Header Fields） 26
7.2 實(shí)體主體（Entity Body） 26
7.2.1 類型（Type） 27
7.2.2 長度（Length） 27
8. 方法定義（Method Definitions） 27
8.1 GET 28
8.2 HEAD 28
8.3 POST 28
9. 狀態(tài)代碼定義（Status Code Definitions） 29
9.1 消息1xx（Informational 1xx） 29
9.2 成功2xx（Successful 2xx） 29
9.3 重定向（Redirection 3xx） 30
9.4 客戶端錯(cuò)誤（Client Error ）4xx 31
9.5 服務(wù)器錯(cuò)誤（Server Error ）5xx 32
10. 標(biāo)題域定義（Header Field Definitions） 33
10.1 允許（Allow） 33
10.2 授權(quán)（Authorization） 34
10.3 內(nèi)容編碼（Content-Encoding） 34
10.4 內(nèi)容長度（Content-Length） 34
10.5 內(nèi)容類型（Content-Type） 35
10.6 日期（Date） 35
10.7 過期（Expires） 36
10.8 來自（From） 37
10.9 從何時(shí)更改（If-Modified-Since） 37
10.10 最近更改（Last-Modified） 38
10.11 位置（Location） 38
10.12 注解（Pragma） 39
10.13 提交方（Referer） 39
10.14 服務(wù)器（Server） 40
10.15 用戶代理（User-Agent） 40
10.16 WWW-授權(quán)（WWW-Authenticate） 40
11. 訪問鑒別（Access Authentication） 41
11.1 基本授權(quán)方案（Basic Authentication Scheme） 42
12. 安全考慮（Security Considerations） 43
12.1 客戶授權(quán)（Authentication of Clients） 43
12.2 安全方法（Safe Methods） 43
12.3 服務(wù)器日志信息的弊端（Abuse of Server Log Information） 43
12.4 敏感信息傳輸（Transfer of Sensitive Information） 44
12.5 基于文件及路徑名的攻擊（Attacks Based On File and Path Names） 44
13. 感謝（Acknowledgments） 45
14. 參考書目（References） 45
15. 作者地址（Authors' Addresses） 47
附錄（Appendices） 48
A. Internet介質(zhì)類型消息/http（Internet Media Type message/http） 48
B. 容錯(cuò)應(yīng)用（Tolerant Applications） 48
C. 與MIME的關(guān)系（Relationship to MIME） 49
C.1 轉(zhuǎn)換為規(guī)范形式（Conversion to Canonical Form） 49
C.2 日期格式轉(zhuǎn)換（Conversion of Date Formats） 49
C.3 內(nèi)容編碼介紹（Introduction of Content-Encoding） 50
C.4 無內(nèi)容傳輸編碼（No Content-Transfer-Encoding） 50
C.5 多個(gè)主體的HTTP標(biāo)題域（HTTP Header Fields in Multipart Body-Parts）
50
D. 附加特性（Additional Features） 50
D.1 附加請(qǐng)求方法（Additional Request Methods） 51
D.2 附加標(biāo)題域定義（Additional Header Field Definitions） 51
1. 介紹（Introduction）
1.1 目的（Purpose）
HTTP（Hypertext Transfer Protocol）是應(yīng)用級(jí)協(xié)議，它適應(yīng)了分布式超媒體協(xié)作系統(tǒng)對(duì)
靈活性及速度的要求。它是一個(gè)一般的、無狀態(tài)的、基于對(duì)象的協(xié)議，通過對(duì)其請(qǐng)求方法
（request methods）進(jìn)行擴(kuò)展，可以被用于多種用途，比如命名服務(wù)器（name server）及分
布式對(duì)象管理系統(tǒng)。HTTP的一個(gè)特性是其數(shù)據(jù)表現(xiàn)類型允許系統(tǒng)的構(gòu)建不再依賴于要傳輸
的數(shù)據(jù)。
HTTP自從1990年就在WWW上被廣泛使用。該規(guī)范反映了“HTTP/1.0”的普通用法。
該規(guī)范描述了在大多數(shù)HTTP/1.0客戶機(jī)及服務(wù)器上看起來已經(jīng)實(shí)現(xiàn)的特性。規(guī)范將被
分成兩個(gè)部分：HTTP特性的實(shí)現(xiàn)是本文檔的主要內(nèi)容，而其它不太通行的實(shí)現(xiàn)將被列在附
錄D中。
實(shí)用的信息系統(tǒng)需要更多的功能，而不僅僅是數(shù)據(jù)的獲取，包括搜索、前端更新及注解。
HTTP允許使用開放的命令集來表示請(qǐng)求的目的，它使用基于URI[2]（Uniform Resource
Identifier），即統(tǒng)一資源標(biāo)識(shí)的規(guī)則來定位（URL[4]）或命名（URN[16]）方法所用到的資
源。HTTP使用與郵件（Internet Mail [7]）和MIME（Multipurpose Internet Mail Extensions [5]）
相似的格式來傳遞消息。
HTTP也作為用戶代理、代理服務(wù)器/網(wǎng)關(guān)與其它Internet協(xié)議進(jìn)行通訊的一般協(xié)議，這
些協(xié)議是，SMTP [12], NNTP [11], FTP [14], Gopher [1], and WAIS [8]等。HTTP允許不同的
應(yīng)用可以進(jìn)行基本的超媒體資源訪問，并簡(jiǎn)化用戶代理的實(shí)現(xiàn)。
1.2 術(shù)語（Terminology）
本規(guī)范用了許多與參與方、對(duì)象及HTTP通訊相關(guān)的術(shù)語，如下：
連接（connection）
兩個(gè)應(yīng)用程序以通訊為目的在傳輸層建立虛擬電路。
消息（message）
HTTP通訊的基本單元，在連接中傳輸?shù)慕Y(jié)構(gòu)化的、有順序的字節(jié)（其含義在第四
節(jié)中定義）。
請(qǐng)求（request）
HTTP的請(qǐng)求消息（在第五節(jié)定義）
回應(yīng)（response）
HTTP的回應(yīng)消息（在第六節(jié)定義）
資源（resource）
網(wǎng)絡(luò)上可以用URI來標(biāo)識(shí)的數(shù)據(jù)對(duì)象或服務(wù)（見3.2節(jié)）
實(shí)體（entity）
可被附在請(qǐng)求或回應(yīng)消息中的特殊的表示法、數(shù)據(jù)資源的表示、服務(wù)資源的回應(yīng)等，
由實(shí)體標(biāo)題（entity header）或?qū)嶓w主體（entity body）內(nèi)容形式存在的元信息組成。
客戶端（client）
指以發(fā)出請(qǐng)求為目的而建立連接的應(yīng)用程序。
用戶代理（user agent）
指初始化請(qǐng)求的客戶端，如瀏覽器、編輯器、蜘蛛（web爬行機(jī)器人）或其它終端
用戶工具。
服務(wù)器（server）
指接受連接，并通過發(fā)送回應(yīng)來響應(yīng)服務(wù)請(qǐng)求的應(yīng)用程序。
原始服務(wù)器（origin server）
存放資源或產(chǎn)生資源的服務(wù)器。
代理（proxy）
同時(shí)扮演服務(wù)器及客戶端角色的中間程序，用來為其它客戶產(chǎn)生請(qǐng)求。請(qǐng)求經(jīng)過變
換，被傳遞到最終的目的服務(wù)器，在代理程序內(nèi)部，請(qǐng)求或被處理，或被傳遞。代
理必須在消息轉(zhuǎn)發(fā)前對(duì)消息進(jìn)行解釋，而且如有必要還得重寫消息。代理通常被用
作經(jīng)過防火墻的客戶端出口，用以輔助處理用戶代理所沒實(shí)現(xiàn)的請(qǐng)求。
網(wǎng)關(guān)（gateway）
服務(wù)器之間的服務(wù)器。與代理不同，網(wǎng)關(guān)接受請(qǐng)求就好象它就是被請(qǐng)求資源所在的
原始服務(wù)器，發(fā)出請(qǐng)求的客戶端可能并沒有意識(shí)到它在與網(wǎng)關(guān)進(jìn)行通訊。網(wǎng)關(guān)是網(wǎng)
絡(luò)防火墻服務(wù)器端的門戶。對(duì)非HTTP系統(tǒng)資源進(jìn)行訪問時(shí)，網(wǎng)關(guān)做為中間的協(xié)議
翻譯者。
隧道（tunnel）
隧道就好象連接兩端看不見的中繼器。處于激活狀態(tài)時(shí)，它雖然是由HTTP請(qǐng)求來
初始化的，但它并不參與HTTP通訊。當(dāng)需要中繼連接的兩端關(guān)閉后，隧道也自然
終止。在入口有需求及中間程序無法或不該解釋要中繼的通訊時(shí)，通常要用到隧道
技術(shù)。
緩存（cache）
指程序本地存儲(chǔ)的回應(yīng)消息和用來控制消息存儲(chǔ)、重獲、刪除的子系統(tǒng)。
緩存回應(yīng)的目的是為減少請(qǐng)求回應(yīng)時(shí)間，以及未來一段時(shí)間對(duì)網(wǎng)絡(luò)帶寬的消耗。任
何客戶端及服務(wù)端都可以包含緩存。服務(wù)器在以隧道方式工作時(shí)不能使用緩存。
任何指定的程序都有能力同時(shí)做為客戶端和服務(wù)器。我們?cè)谑褂眠@個(gè)概念時(shí)，不是看程
序功能上是否能實(shí)現(xiàn)客戶及服務(wù)器，而是看程序在特定連接時(shí)段上扮演何種角色（客戶或服
務(wù)器）。同樣，任何服務(wù)器可以扮演原始服務(wù)器、代理、網(wǎng)關(guān)、隧道等角色，行為的切換取
決于每次請(qǐng)求的內(nèi)容。
1.3 概述（Overall Operation）
HTTP協(xié)議是基于請(qǐng)求/回應(yīng)機(jī)制的。客戶端與服務(wù)器端建立連接后，以請(qǐng)求方法、URI、
協(xié)議版本等方式向服務(wù)器端發(fā)出請(qǐng)求，該請(qǐng)求可跟隨包含請(qǐng)求修飾符、客戶信息、及可能的
請(qǐng)求體（body）內(nèi)容的MIME類型消息。
服務(wù)器端通過狀態(tài)隊(duì)列（status line）來回應(yīng)，內(nèi)容包括消息的協(xié)議版本、成功或錯(cuò)誤代
碼，也跟隨著包含服務(wù)器信息、實(shí)體元信息及實(shí)體內(nèi)容的MIME類型消息。
絕大多數(shù)HTTP通訊由用戶代理進(jìn)行初始化，并通過它來組裝請(qǐng)求以獲取存儲(chǔ)在一些原
始服務(wù)器上的資源。在最簡(jiǎn)單的情況下，通過用戶代理（UA）與原始服務(wù)器（O）之間一
個(gè)簡(jiǎn)單的連接（v）就可以完成。
request chain ------------------------>
UA -------------------v------------------- O
<----------------------- response chain
更復(fù)雜的情況是當(dāng)請(qǐng)求/回應(yīng)鏈之間存在一個(gè)或更多中間環(huán)節(jié)。總體看來，有三種中間
環(huán)節(jié)：代理（proxy）、網(wǎng)關(guān)（gateway）、隧道（tunnel）。
代理（proxy）是向前推送的代理人（agent），它以絕對(duì)形式接收URI請(qǐng)求，重寫全部
或部分消息，并將經(jīng)過改寫的請(qǐng)求繼續(xù)向URI中指定的服務(wù)器處推送。
網(wǎng)關(guān)是接收代理，它處于服務(wù)器層之上，在必要時(shí)候，它用服務(wù)器可識(shí)別的協(xié)議來傳遞
請(qǐng)求。
隧道不改變消息，它只是連接兩端的中繼點(diǎn)。在有中間層（如防火墻）或中間層無法解
析消息內(nèi)容的情況下，需要靠隧道技術(shù)來幫助通訊穿越中間層。
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- response chain
上面的圖形表示在用戶代理和原始服務(wù)器之間有三個(gè)中間層（A，B和C）。由圖可見，
請(qǐng)求或回應(yīng)消息在整個(gè)信息鏈上運(yùn)行需要通過四個(gè)單獨(dú)的連接，它與在此之前介紹的簡(jiǎn)單情
況是有區(qū)別的，而且此區(qū)別是十分重要的。因?yàn)镠TTP通訊選項(xiàng)可以設(shè)置成幾種情況，如只
與最近的非隧道鄰居連接、只與信息鏈末端連接、或者可與鏈中全部環(huán)節(jié)連接等等。雖然上
面的圖是線性的，而實(shí)際上每個(gè)參與環(huán)節(jié)都在同時(shí)與多方進(jìn)行通訊活動(dòng)。例如，B在接受除
A之外其它客戶端請(qǐng)求的同時(shí)，向除C之外的其它服務(wù)器推送請(qǐng)求，在這個(gè)時(shí)刻，它可能
接受到A的請(qǐng)求，并給予處理。
參與通訊的任何一方如果沒有以隧道方式進(jìn)行工作，必須要借助內(nèi)部緩存機(jī)制來處理請(qǐng)
求，如果鏈上某個(gè)參與方碰巧緩存了某個(gè)請(qǐng)求的回應(yīng)，那就相應(yīng)于縮短了請(qǐng)求/回應(yīng)鏈。下
面的圖例演示了當(dāng)B緩存了從O經(jīng)由C過來的回應(yīng)信息，而UA和A沒緩存的情況：
request chain ---------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
<--------- response chain
并非所有的回應(yīng)都可以被緩存，某些請(qǐng)求所包含的修飾符中可能對(duì)緩存行為進(jìn)行了特別
指明。一些基于HTTP/1.0的應(yīng)用使用了啟發(fā)式的方法來描述哪些回應(yīng)可被緩存，而哪些則
不可以，但遺憾的是，這些規(guī)則并沒有形成標(biāo)準(zhǔn)。
在Internet上，HTTP通訊往往基于TCP/IP的連接方式。缺省的端口是TCP 80[15]口，
但也可以使用其它端口。并不排除基于Ineternet上的其它協(xié)議或網(wǎng)絡(luò)協(xié)議的HTTP實(shí)現(xiàn)方
式，HTTP只是假定傳輸是可靠的，因而任何能提供這種保證的協(xié)議都可以被使用。至于
HTTP/1.0請(qǐng)求和回應(yīng)在數(shù)據(jù)傳輸過程中的數(shù)據(jù)結(jié)構(gòu)問題，不在本文討論范圍之內(nèi)。
實(shí)驗(yàn)室應(yīng)用除外，當(dāng)前的做法是客戶端在每次請(qǐng)求之前建立連接，而服務(wù)器端在發(fā)送回
應(yīng)后關(guān)閉此連接。不管客戶端還是服務(wù)器端都應(yīng)注意處理突發(fā)的連接中斷，因?yàn)殡p方都有可
能因?yàn)橛脩舨僮鳌⒆詣?dòng)超時(shí)、程序失敗等原因關(guān)閉與對(duì)方的連接。在這種情況下，不管請(qǐng)求
處于什么樣的狀態(tài)，如單方或雙方同時(shí)關(guān)閉連接，都會(huì)導(dǎo)致當(dāng)前的請(qǐng)求被終止。
1.4 HTTP and MIME
HTTP/1.0使用了多種結(jié)構(gòu)來定義MIME，詳見RFC1521[5]。附錄C描述了Internet承
認(rèn)的Internet介質(zhì)類型與mail介質(zhì)類型的不同工作方式，并給出二者區(qū)別的基本解釋。
2. 標(biāo)志轉(zhuǎn)換及通用語法（Notational Conventions and
Generic Grammar）
2.1 補(bǔ)充反饋方式（Augmented BNF）
與RFC822[7]很類似，本文對(duì)所有機(jī)制的說明都是以散文和補(bǔ)充反饋的方式來描述的。
對(duì)于實(shí)現(xiàn)者來說，要想理解這些約定，必須對(duì)這些符號(hào)很熟悉。補(bǔ)充反饋方式（augmented
BNF）包括下面的結(jié)構(gòu)：
要解釋的名詞＝名詞解釋（name = definition）
規(guī)則的名字（name）就是它本身（不帶任何尖括號(hào)，“<”，“>”），后面跟個(gè)等號(hào)＝，
然后就是該規(guī)則的定義。如果規(guī)則需要用多個(gè)行來描述，利用空格進(jìn)行縮進(jìn)格式排
版。某些基本的規(guī)則使用大寫，如SP, LWS, HT, CRLF, DIGIT, ALPHA,等等。定義
中還可以使用尖括號(hào)來幫助理解規(guī)則名的使用。
字面意思（"literal"）
文字的字面意思放在引號(hào)中間，除非特別指定，該段文字是大小寫敏感的。
規(guī)則1｜規(guī)則2（rule1 | rule2）
“｜”表示其分隔的元素是可選的，比如，“是｜否”要選擇‘是’或‘否’。
（規(guī)則1 規(guī)則2）（(rule1 rule2)）
在圓括號(hào)中的元素表明必選其一。如（元素1（元素2｜元素3）元素4）可表明兩
種意思，即“元素1 元素2 元素4”和“元素1 元素3 元素4”
*規(guī)則（*rule）
在元素前加星號(hào)“*”表示循環(huán)，其完整形式是“<n>*<m>元素”，表明元素最少產(chǎn)
生<n>次，最多<m>次。缺省值是0到無限，例如，“1*元素”意思是至少有一個(gè)，
而“1*2元素”表明允許有1個(gè)或2個(gè)。
［規(guī)則］（[rule]）
方括號(hào)內(nèi)是可選元素。如“［元素1 元素2］”與“*1（元素1 元素2）”是一回
事。
N 規(guī)則（N rule）
表明循環(huán)的次數(shù)：“<n>（元素）”就是“<n>*<n>（元素）”，也就是精確指出<n>
取值。因而，2DIGIT 就是2位數(shù)字, 3ALPHA 就是由三個(gè)字母組成字符串。
＃規(guī)則（#rule）
“#”與“*”類似，用于定義元素列表。
完整形式是“<n>#<m>元素”表示至少有<n>個(gè)至多有<m>個(gè)元素，中間用“,”或
任意數(shù)量的空格（LWS-linear whitespace）來分隔，這將使列表非常方便，如“（*LWS
元素 *（ *LWS "," *LWS 元素 ））”就等同于“1#元素”。
空元素在結(jié)構(gòu)中可被任意使用，但不參與元素個(gè)數(shù)的計(jì)數(shù)。也就是說，“（元素1），，
（元素2）”僅表示2個(gè)元素。但在結(jié)構(gòu)中，應(yīng)至少有一個(gè)非空的元素存在。缺省
值是0到無限，即“#（元素）”表示可取任何數(shù)值，包括0；而“1#元素”表示至
少有1個(gè)；而“1#2元素”表示有1個(gè)或2個(gè)。
；注釋（; comment）
分號(hào)后面是注釋，僅在單行使用。
隱含*LWS（implied *LWS）
本文的語法描述是基于單詞的。除非另有指定，線性空格（LWS）可以兩個(gè)鄰近符
號(hào)或分隔符（tspecials）之間任意使用，而不會(huì)對(duì)整句的意思造成影響。在兩個(gè)符號(hào)之
間必須有至少一個(gè)分隔符，因?yàn)樗鼈円惨鰹閱为?dú)的符號(hào)來解釋。實(shí)際上，應(yīng)用程序在
產(chǎn)生HTTP結(jié)構(gòu)時(shí)，應(yīng)當(dāng)試圖遵照“通常方式”，因?yàn)楝F(xiàn)在的確有些實(shí)現(xiàn)方式在通常方
式下無法正常工作。
2.2 基本規(guī)則（Basic Rules）
下面的規(guī)則將用于本文后面對(duì)結(jié)構(gòu)基本解析。
US-ASCII 編碼字符集定義[17]。
OCTET = <8-bit的順序數(shù)據(jù)，即bytes>
CHAR = < US-ASCII字符（取值為0 – 127的OCTET）>
UPALPHA = < US-ASCII 大寫字符"A"到"Z">
LOALPHA = <US-ASCII 小寫字符"a"到"z">
ALPHA = UPALPHA | LOALPHA
DIGIT = < US-ASCII 數(shù)字"0"到"9">
CTL = < US-ASCII 控制字符（取值0到31的octet ）和DEL （127）>
CR = <US-ASCII CR, 回車符carriage return（13）>
LF = <US-ASCII LF, 換行符linefeed （10）>
SP = <US-ASCII SP, 空格space （32）>
HT = <US-ASCII HT, 水平制表符horizontal-tab（9）>
<"> = <US-ASCII 雙引號(hào)標(biāo)記double-quote mark （34）>
HTTP/1.0規(guī)定，除實(shí)體主體（Entity-Body，見附錄B容錯(cuò)應(yīng)用）外，所有協(xié)議元
素的行結(jié)束標(biāo)志都是CRLF（按字節(jié)順序）。在實(shí)體主體內(nèi)部的行結(jié)束標(biāo)志定義及
其對(duì)應(yīng)的介質(zhì)類型定義，見3.6節(jié)的描述。
CRLF = CR LF
HTTP/1.0的頭可以折成許多行，只要每個(gè)后續(xù)行以空格或水平制表符開頭。所有
的線性空格（LWS），同空格（SP）有相同的語義。
LWS = [CRLF] 1*( SP | HT )
實(shí)際上，有些應(yīng)用并沒有考慮處理這樣多行的頭，所以從兼容性上考慮，HTTP/1.0
應(yīng)用最好不要產(chǎn)生折成多行的頭。
TEXT規(guī)則只是用于描述消息解釋器不關(guān)心的域的內(nèi)容及其取值。文本內(nèi)容可包含
不同于US-ASCII的字符。
TEXT = <除了控制字符（CTLs）之外的任何OCTET，包括LWS >
在標(biāo)題域中的收件人域如包含US-ASCII字符集以外的字符，這些字符將按照
ISO-8859-1標(biāo)準(zhǔn)來解釋。
十六進(jìn)制數(shù)字型字符在幾個(gè)協(xié)議元素中到。
HEX = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
許多HTTP/1.0頭域的內(nèi)容由被LWS分隔的單詞或特殊字符組成，這些特殊字符
必須置于引號(hào)中間的字符串內(nèi)，作為參數(shù)值使用。
Word = 符號(hào)（token）| 被引號(hào)引起來的字符串
token = 1*<除控制字符（CTLs）或tspecials之外的任意字符>
tspecials = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
在HTTP頭域中可用括號(hào)表示注釋文字。注釋只允許寫在包含注釋的域，做為域值
定義的一部分。在除此之外其它域中，括號(hào)將被視為域值。
comment = "(" *( ctext | comment ) ")"
ctext = <除圓括號(hào)外的任何TEXT>
被雙引號(hào)圈中的文本字符串將被視為一個(gè)單詞。
quoted-string = ( <"> *(qdtext) <"> )
qdtext = <除了雙引號(hào)及控制字符之外的任何字符，包括LWS >
在HTTP/1.0中不允許使用后斜線“\”來引用單字符。
3. 協(xié)議參數(shù)（Protocol Parameters）
3.1 HTTP版本（HTTP Version）
HTTP采用主從（<major>.<minor>）數(shù)字形式來表示版本。協(xié)議的版本政策傾向于讓發(fā)
送方表明其消息的格式及功能，而不僅僅為了獲得通訊的特性，這樣做的目的是為了與更高
版本的HTTP實(shí)現(xiàn)通訊。只增加擴(kuò)展域的值或增加了不影響通訊行為的消息組件都不會(huì)導(dǎo)致
版本數(shù)據(jù)的變化。當(dāng)協(xié)議消息的主要解析算法沒變，而消息語法及發(fā)送方的隱含功能增加了，
將會(huì)導(dǎo)致從版本號(hào)（<minor>）增加；當(dāng)協(xié)議中消息的格式變化了，主版本號(hào)（<major>）也
將發(fā)生改變。
HTTP消息的版本由消息第一行中的HTTP版本域來表示。如果消息中的協(xié)議版本沒有
指定，接收方必須假定它是符合HTTP/0.9的簡(jiǎn)單標(biāo)準(zhǔn)。
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
注意，主從版本應(yīng)當(dāng)被看作單獨(dú)的整數(shù)，因?yàn)樗鼈兌加锌赡茉黾樱瑥亩^一位整
數(shù)。因而，HTTP/2.4比HTTP/2.13版本低，而HTTP/2.13又比HTTP/12.3版本低。
版本號(hào)前面的0將被接收方忽略，而在發(fā)送方處也不應(yīng)產(chǎn)生。
本文檔定義了HTTP協(xié)議的0.9及1.0版本。發(fā)送完整請(qǐng)求（Full-Request）及完整
回應(yīng)（Full-Response）消息的應(yīng)用必須指明HTTP的版本為“HTTP/1.0”。
HTTP/1.0服務(wù)器必須：
o識(shí)別HTTP/0.9及HTTP/1.0請(qǐng)求命令中的請(qǐng)求隊(duì)列（Request-Line）的格式。
o理解任何HTTP/0.9及HTTP/1.0中的合法請(qǐng)求格式。
o 使用與客戶端相同版本的協(xié)議進(jìn)行消息回應(yīng)。
HTTP/1.0 客戶端必須：
o 識(shí)別HTTP/1.0回應(yīng)中狀態(tài)隊(duì)列（Status-Line）的格式。
o 理解HTTP/0.9及HTTP/1.0中合法回應(yīng)的格式。
當(dāng)代理及網(wǎng)關(guān)收到與其自身版本不同的HTTP請(qǐng)求時(shí)，必須小心處理請(qǐng)求的推送，因?yàn)?br>協(xié)議版本表明發(fā)送方的能力，代理或網(wǎng)關(guān)不應(yīng)發(fā)出高于自身版本的消息。如果收到高版本的
請(qǐng)求，代理或網(wǎng)關(guān)必須降低該請(qǐng)求的版本，并回應(yīng)一個(gè)錯(cuò)誤。而低版本的請(qǐng)求也應(yīng)在被推送
前升級(jí)。
代理或網(wǎng)關(guān)回應(yīng)請(qǐng)求時(shí)必須遵照前面列出的規(guī)定。
3.2 統(tǒng)一資源標(biāo)識(shí)（Uniform Resource Identifiers）
URI有許多名字，如WWW地址、通用文件標(biāo)識(shí)（Universal Document Identifiers）、通
用資源標(biāo)識(shí)（Universal Resource Identifiers [2]），以及最終的統(tǒng)一資源定位符（Uniform
Resource Locators (URL) [4]）和統(tǒng)一資源名（URN）。在涉及HTTP以前，URI用簡(jiǎn)單格式
的字符串描述－名字、位置、或其它特性，如網(wǎng)絡(luò)資源。
3.2.1 一般語法（General Syntax）
在HTTP中URI可以用絕對(duì)形式表示，也可用相對(duì)于某一基本URI[9]的形式表示，具
體取決于它們的使用方式。這兩種形式的不同在于絕對(duì)URI總是以方法名稱后跟“：”開頭。
URI = ( absoluteURI | relativeURI ) [ "#" fragment ]
absoluteURI = scheme ":" *( uchar | reserved )
relativeURI = net_path | abs_path | rel_path
net_path = "http://" net_loc [ abs_path ]
abs_path = "/" rel_path
rel_path = [ path ] [ ";" params ] [ "?" query ]
path = fsegment *( "/" segment )
fsegment = 1*pchar
segment = *pchar
params = param *( ";" param )
param = *( pchar | "/" )
scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )
net_loc = *( pchar | ";" | "?" )
query = *( uchar | reserved )
fragment = *( uchar | reserved )
pchar = uchar | ":" | "@" | "&" | "=" | "+"
uchar = unreserved | escape
unreserved = ALPHA | DIGIT | safe | extra | national
escape = "%" HEX HEX
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
extra = "!" | "*" | "'" | "(" | ")" | ","
safe = "$" | "-" | "_" | "."
unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">"
national = <any OCTET excluding ALPHA, DIGIT,
reserved, extra, safe, and unsafe>
權(quán)威的URL語法及語義信息請(qǐng)參見RFC1738[4]和RFC1808[9]。上面所提到的BNF中
包括了合法URL中不允許出現(xiàn)的符號(hào)（RFC1738），因?yàn)镠TTP服務(wù)器并沒有限制為只能用
非保留字符集中的字符來表示地址路徑，而且HTTP代理也可能接收到RFC1738沒有定義
的URI請(qǐng)求。
3.2.2 http URL
“http”表示要通過HTTP協(xié)議來定位網(wǎng)絡(luò)資源。本節(jié)定義了HTTP URL的語法和語義。
http_URL = "http:" "http://" host [ ":" port ] [ abs_path ]
host = <合法的Internet主機(jī)域名或IP地址（用十進(jìn)制數(shù)及點(diǎn)組成）
，見RFC1123，2.1節(jié)定義>
port = *DIGIT
如是端口為空或沒指定，則缺省為80端口。對(duì)于絕對(duì)路徑的URI來說，擁有被請(qǐng)求的
資源的服務(wù)器主機(jī)通過偵聽該端口的TCP連接來接收該URI請(qǐng)求。如果URL中沒有給出
絕對(duì)路徑，要作為請(qǐng)求URI（參見5.1.2節(jié)）使用，必須以“/”形式給出。
注意：雖然HTTP協(xié)議獨(dú)立于傳輸層協(xié)議，http URL只是標(biāo)識(shí)資源的TCP位置，而對(duì)
于非TCP資源來說，必須用其它的URI形式來標(biāo)識(shí)。
規(guī)范的HTTP URL形式可通過將主機(jī)中的大寫字符轉(zhuǎn)換成小寫（主機(jī)名是大小寫敏感
的）來獲得。如果端口是80，去掉冒號(hào)及端口號(hào)，并將空路徑替換成“/”。
3.3 Date/Time 格式（Date/Time Formats）
出于歷史原因，HTTP/1.0應(yīng)用允許三種格式來表示時(shí)間戳：
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
第一種格式是首選的Internet標(biāo)準(zhǔn)格式，表示方法長度固定（RFC1123[6]）。第二種格
式在普通情況下使用，但是它是基于已經(jīng)廢棄的RFC850[10]中的日期格式，而且年不是用
四位數(shù)字表示的。HTTP/1.0 客戶端及服務(wù)器端在解析日期時(shí)可識(shí)別全部三種格式，但是它
們不可以產(chǎn)生第三種時(shí)間格式(asctime) 。
注意：對(duì)于接收到由非HTTP應(yīng)用產(chǎn)生的日期數(shù)據(jù)時(shí)，提倡對(duì)接收到的日期值進(jìn)行填充。
這樣做是因?yàn)椋谀承r(shí)候，代理或網(wǎng)關(guān)可能通過SMTP或NNTP來獲取或發(fā)送消息。
所有的HTTP/1.0 date/timp時(shí)間戳必須用世界時(shí)間（Universal Time，UT），即格林威治
時(shí)間來表示（Greenwich Mean Time，GMT），沒有任何修改的余地。前面的兩種格式用了
“GMT”表示時(shí)區(qū)，在讀ASC表示的時(shí)間時(shí)，也應(yīng)假定是這個(gè)時(shí)區(qū)。
HTTP-date = rfc1123-date | rfc850-date | asctime-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date = weekday "," SP date2 SP time SP "GMT"
asctime-date = wkday SP date3 SP time SP 4DIGIT
date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2DIGIT
; day-month-year (e.g., 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; month day (e.g., Jun 2)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59
wkday = "Mon" | "Tue" | "Wed"
| "Thu" | "Fri" | "Sat" | "Sun"
weekday = "Monday" | "Tuesday" | "Wednesday"
| "Thursday" | "Friday" | "Saturday" | "Sunday"
month = "Jan" | "Feb" | "Mar" | "Apr"
| "May" | "Jun" | "Jul" | "Aug"
| "Sep" | "Oct" | "Nov" | "Dec"
注意：HTTP要求只能在協(xié)議流中使用data/time時(shí)間戳格式，不要求客戶端及服務(wù)
器端在用戶描述、請(qǐng)求登錄等情況下使用這類格式。
3.4 字符集（Character Sets）
HTTP所使用的字符集定義和描述MIME時(shí)用的相同：
本文檔用字符集（character set）來指明利用一個(gè)或多個(gè)表將順序字節(jié)轉(zhuǎn)換成順序字
符的方法。注意，不需要其它方向的無條件轉(zhuǎn)換，因?yàn)椴皇撬械淖址伎梢杂媒o
定字符集來表示，同時(shí)，一個(gè)字符集也可能提供一種以上的字節(jié)順序來表示一種特
殊的字符。這種定義傾向于允許不同類型的字符編碼通過簡(jiǎn)單的單表映射來實(shí)現(xiàn)，
如，從表US-ASCII切換到復(fù)雜表如ISO2202。實(shí)際上，與MIME字符集名相關(guān)的
定義必須完整指定從字節(jié)到字符的映射，特別是不允許通過利用外部配置信息來確
定精確的映射。
注意：術(shù)語字符集（character set）歸于字符編碼（character encoding）。事實(shí)上，
由于HTTP與MIME共同使用同樣的注冊(cè)，所以其術(shù)語也應(yīng)一致。
HTTP字符集由大小寫敏感的符號(hào)組成。全部的符號(hào)定義參見IANA字符集注冊(cè)
[15]。因?yàn)樽?cè)處不會(huì)為每個(gè)字符集單獨(dú)定義一套符號(hào)，所以我們?cè)谶@看到的字符
集名大多是與HTTP實(shí)體使用相關(guān)的。這些在RFC 1521 [5] 中注冊(cè)的字符集，即
US-ASCII [17] 及ISO-8859 [18]字符集，還有一些其它字符集被強(qiáng)烈建議在MIME
字符集參數(shù)內(nèi)部使用。
charset = "US-ASCII"
| "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"
| "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"
| "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"
| "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR"
| "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8"
| token
雖然HTTP允許使用專用符號(hào)做為字符集值，但是任何在IANA字符集注冊(cè)表[15]
中有預(yù)定義值的符號(hào)都必須表明其所屬的字符集。應(yīng)用應(yīng)當(dāng)將其對(duì)字符集的使用限
制在IANA注冊(cè)表規(guī)定的范圍之內(nèi)。
實(shí)體主體的字符集如果屬于US-ASCII 或ISO-8859-1字符集，則勿需標(biāo)記，否則，
應(yīng)當(dāng)用主體字符編碼方式中的最基本命名來標(biāo)記。
3.5 內(nèi)容譯碼（Content Codings）
內(nèi)容譯碼值用于指示對(duì)資源進(jìn)行的編碼轉(zhuǎn)換。內(nèi)容譯碼主要用于將經(jīng)過壓縮、加密等操
作的文件進(jìn)行還原，使其保持其原來的介質(zhì)類型。典型情況下，經(jīng)過編碼保存的資源只能經(jīng)
過解碼或類似的操作才能還原。
content-coding = "x-gzip" | "x-compress" | token
注意：出于對(duì)未來兼容性的考慮，HTTP/1.0應(yīng)用應(yīng)將"gzip" 和"compress" 分別與
"x-gzip"和"x-compress"對(duì)應(yīng)起來。
所有的內(nèi)容譯碼值都是大小寫敏感的。HTTP/1.0在內(nèi)容編碼（10.3節(jié)）頭域中使用內(nèi)
容譯碼值。雖然該值描述的是內(nèi)容譯碼，但更為重要的是，它指明了應(yīng)當(dāng)用什么機(jī)制來進(jìn)行
解碼。注意，單獨(dú)的程序可能有能力實(shí)現(xiàn)對(duì)多種格式編碼的解碼。
在這段文字中，提到了兩個(gè)值：
x-gzip
文件壓縮程序"gzip" (GNU zip，由Jean-loup Gailly開發(fā))的編碼格式。該格式屬于
典型的帶有32位CRC 校驗(yàn)的Lempel-Ziv譯碼 (LZ77)。
x-compress
文件壓縮程序"compress"的編碼格式，該格式適用于LZW（Lempel-Ziv-Welch）譯
碼。
注意：用程序名來標(biāo)識(shí)編碼格式的做法不是很理想，在將來可能不會(huì)繼續(xù)這樣做。現(xiàn)在
之所以這樣做是出于歷史的原因，并非良好的設(shè)計(jì)。
3.6 介質(zhì)類型（Media Types）
HTTP在Content-Type header域（10.5節(jié)）中使用Internet介質(zhì)類型[13]，用以提供開放
的可擴(kuò)展的數(shù)據(jù)類型。
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
參數(shù)可參照屬性/值對(duì)的方式，用類型/子類型的格式來寫。
Parameter = attribute "=" value
Attribute = token
Value = token | quoted-string
其中，類型、子類型、參數(shù)屬性名是大小寫敏感的。而參數(shù)值不一定是大小寫敏感的，
這得看參數(shù)名的語法而定。在類型和子類型、屬性名和屬性值之間不能有LWS（空格）。當(dāng)
接收到不能識(shí)別的介質(zhì)類型的參數(shù)時(shí)，用戶代理應(yīng)當(dāng)忽略它們。
一些老的HTTP應(yīng)用不能識(shí)別介質(zhì)類型參數(shù)，所以HTTP/1.0的應(yīng)用程序只能在定義消
息內(nèi)容時(shí)使用介質(zhì)參數(shù)。
介質(zhì)參數(shù)（Media-type）值用Internet授權(quán)分配數(shù)字（Internet Assigned Number
Authority ，IANA [15]）注冊(cè)。介質(zhì)類型注冊(cè)過程請(qǐng)參見RFC1590[13]。不鼓勵(lì)使用未注冊(cè)
的介質(zhì)類型。
3.6.1標(biāo)準(zhǔn)及文本缺省（Canonicalization and Text Defaults）
Internet介質(zhì)類型是用規(guī)范形式注冊(cè)的。一般來說，在通過HTTP協(xié)議傳輸實(shí)體主體
（Entity-Body）之前，必須先將其表示成適當(dāng)?shù)囊?guī)范格式。如果主體用使用了一種
Content-Encoding進(jìn)行編碼，下面的數(shù)據(jù)在編碼前必須轉(zhuǎn)換成規(guī)范形式：
"text"類型的介質(zhì)子類型在規(guī)范形式中使用CRLF做為文本行中斷。實(shí)際上，為和實(shí)體
主體（Entity body）內(nèi)的使用方式保持一致，HTTP允許傳輸純以CR或LF單獨(dú)表示行中斷
的文本介質(zhì)。HTTP應(yīng)用程序必須將其通過HTTP方式接收到的文本介質(zhì)中的CRLF、CR、
LF看做是行中斷符。
另外，如果文本介質(zhì)的字符集沒有使用字節(jié)13和10做為CR和LF，象一些多字節(jié)字
符集，HTTP允許使用該字符集指定的任何順序的字節(jié)替代CR和LF做為行中斷，這種行
中斷的靈活運(yùn)用方式僅可于實(shí)體主體（Entity-Body）中。一個(gè)純CR或LF不應(yīng)在任何HTTP
控制結(jié)構(gòu)（如標(biāo)題域-header field和多塊分界線-multipart boundaries）中替代CRLF。
參數(shù)"charset"在定義數(shù)據(jù)的字符集（3.4節(jié)）時(shí)，與一些介質(zhì)類型一起使用。當(dāng)發(fā)送方
沒有顯式給出字符參數(shù)時(shí)，HTTP在接收時(shí)將"text"的介質(zhì)子類型定義為缺省
值"ISO-8859-1"。"ISO-8859-1"字符集或其子集以外的數(shù)據(jù)必須要標(biāo)記其相應(yīng)的字符集值，
這樣可以保證接收方能正確地對(duì)其進(jìn)行解析。
注意：許多當(dāng)前HTTP服務(wù)器提供的數(shù)據(jù)使用"ISO-8859-1"以外的其它字符集，而且也
沒有正確的進(jìn)行標(biāo)記，這種工作方式限制了互操作性，建議不要采用。做為一種補(bǔ)救方法，
一些HTTP用戶代理提供了配置選項(xiàng)，使用戶可以在字符集參數(shù)沒指定的情況下，自行更改
缺省的介質(zhì)類型解釋方式。
3.6.2 多部分類型（Multipart Types）
MIME提供了多部分（"multipart"）類型的數(shù)字――在一個(gè)單獨(dú)的消息實(shí)體主體
（Entity-Body）內(nèi)可以封裝幾個(gè)實(shí)體（entities）。雖然用戶代理可能需要了解每種類型，從
而可以正確解釋每部分主體的意圖，但是在IANA[15]的多部分類型（multipart types）注冊(cè)
中卻找不到專為HTTP/1.0所指定的內(nèi)容。HTTP用戶代理只得自己來做接收多部分類型的
工作，其過程和行為與MIME用戶代理是相同或相似的。HTTP服務(wù)器不應(yīng)假定HTTP客戶
端都有能力處理多部分類型。
所有的多部分類型都使用通用的語法，而且必須在介質(zhì)類型值部分包括邊界參數(shù)
（boundary parameter）。消息的主體是其自身，做為協(xié)議元素，它必須只使用CRLF做為段
間（body-parts）的行中斷符。多段主體（Multipart body-parts）中可能包括對(duì)各段有重要意
義的HTTP標(biāo)題域。
3.7 產(chǎn)品標(biāo)識(shí)（Product Tokens）
是通訊應(yīng)用程序用來標(biāo)識(shí)其自身的一個(gè)簡(jiǎn)單符號(hào)，常和任意字母及版本描述一起使用。
大多數(shù)產(chǎn)品標(biāo)識(shí)也將其產(chǎn)品的重要組成部分的版本號(hào)一起列出，中間用空格分隔。
按慣例，在標(biāo)識(shí)應(yīng)用程序時(shí)，組件以其重要性順序排列。
Product = token ["/" product-version]
product-version = token
例如：
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
產(chǎn)品標(biāo)識(shí)應(yīng)當(dāng)短小，因而禁止利用該域填寫廣告或其它無關(guān)信息。雖然任何符號(hào)字符都
可能出現(xiàn)在產(chǎn)品版本中，該符號(hào)應(yīng)當(dāng)只用于做版本定義，也就是說，同一個(gè)產(chǎn)品的連續(xù)版本
之間只能通過產(chǎn)品版本值進(jìn)行區(qū)分。
4. HTTP 消息（HTTP Message）
4.1 消息類型（Message Types）
HTTP消息由客戶端到服務(wù)器的請(qǐng)求和由服務(wù)器到客戶端的回應(yīng)組成。
HTTP-message = Simple-Request ; HTTP/0.9 messages
| Simple-Response
| Full-Request ; HTTP/1.0 messages
| Full-Response
完整的請(qǐng)求（Full-Request）和完整的回應(yīng)（Full-Response）都使用RFC822[7]中實(shí)體傳
輸部分規(guī)定的消息格式。兩者的消息都可能包括標(biāo)題域（headers，可選）、實(shí)體主體（entity
body）。實(shí)體主體與標(biāo)題間通過空行來分隔（即CRLF前沒有內(nèi)容的行）。
Full-Request = Request-Line ; Section 5.1
*( General-Header ; Section 4.3
| Request-Header ; Section 5.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
Full-Response = Status-Line ; Section 6.1
*( General-Header ; Section 4.3
| Response-Header ; Section 6.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
簡(jiǎn)單請(qǐng)求（Simple_Request）與簡(jiǎn)單回應(yīng)（Simple-Response）不允許使用任何標(biāo)題信息，
并限制只能使用唯一的請(qǐng)求方法（GET）
Simple-Request = "GET" SP Request-URI CRLF
Simple-Response = [ Entity-Body ]
不提倡使用簡(jiǎn)單方式請(qǐng)求格式，因?yàn)樗乐沽朔?wù)器在接到簡(jiǎn)單請(qǐng)求時(shí)對(duì)返回實(shí)體的介
質(zhì)類型進(jìn)行驗(yàn)證。
4.2 消息標(biāo)題（Message Headers）
HTTP標(biāo)題域，包括主標(biāo)題（General-Header,4.3節(jié)）、請(qǐng)求標(biāo)題（Request-Header ,5.2節(jié)）、
回應(yīng)標(biāo)題（Response-Header ,6.2節(jié)）及實(shí)體標(biāo)題（Entity-Header,7.1節(jié)），都遵照RFC822-3.1
節(jié)[7]給出的通用格式定義。每個(gè)標(biāo)題域由后緊跟冒號(hào)的名字，單空格（SP），字符及域值組
成。域名是大小寫敏感的。雖然不提倡，標(biāo)題域還是可以擴(kuò)展成多行使用，只要這些行以一
個(gè)以上的SP或HT開頭就行。
HTTP-header = field-name ":" [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, tspecials, and quoted-string>
標(biāo)題域接收的順序并不重要，但良好的習(xí)慣是，先發(fā)送主標(biāo)題，然后是請(qǐng)求標(biāo)題或回應(yīng)
標(biāo)題，最后是實(shí)體標(biāo)題。
當(dāng)且僅當(dāng)標(biāo)題域的全部域值都用逗號(hào)分隔的列表示時(shí)（即，#（值）），多個(gè)有相同域名
的HTTP標(biāo)題域才可以表示在一個(gè)消息里。而且必須能在不改變消息語法的前提下，將并發(fā)
的域值加到第一個(gè)值后面，之間用逗號(hào)分隔，最終能將多個(gè)標(biāo)題域結(jié)合成“域名：域值”對(duì)。
4.3 普通標(biāo)題域（General Header Fields）
有幾種標(biāo)題域是請(qǐng)求與回應(yīng)都要使用的，但并不用于被傳輸?shù)膶?shí)體。這些標(biāo)題只用于被
傳輸?shù)南ⅰ?
General-Header = Date ; Section 10.6
| Pragma ; Section 10.12
普通標(biāo)題域名稱只有在與協(xié)議版本的變化結(jié)合起來后，才能進(jìn)行可靠的擴(kuò)展。實(shí)際上，
新的或?qū)嶒?yàn)中的標(biāo)題域只要能被通訊各方識(shí)別，其語法就可使用，而無法識(shí)別的標(biāo)題域都將
被視為實(shí)體域。
5. 請(qǐng)求（Request）
從客戶端到服務(wù)器端的請(qǐng)求消息包括，消息首行中，對(duì)資源的請(qǐng)求方法、資源的標(biāo)識(shí)符
及使用的協(xié)議。考慮到局限性更大的HTTP/0.9的向后兼容問題，有兩種合法的HTTP請(qǐng)求
格式：
Request = Simple-Request | Full-Request
Simple-Request = "GET" SP Request-URI CRLF
Full-Request = Request-Line ; Section 5.1
*( General-Header ; Section 4.3
| Request-Header ; Section 5.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
如果HTTP/1.0服務(wù)器收到簡(jiǎn)單請(qǐng)求，它必須回應(yīng)一個(gè)HTTP/0.9格式的簡(jiǎn)單回應(yīng)。
HTTP/1.0的客戶端有能力接收完整回應(yīng)，但不能產(chǎn)生簡(jiǎn)單請(qǐng)求。
5.1 請(qǐng)求隊(duì)列（Request-Line）
請(qǐng)求隊(duì)列以一個(gè)方法符號(hào)開頭，跟在請(qǐng)求URI及協(xié)議版本的后面，以CRLF為結(jié)尾。
該元素用空格SP分隔。除了最后的CRLF，不允許出現(xiàn)單獨(dú)的CR或LF符。
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
注意，簡(jiǎn)單請(qǐng)求與完整請(qǐng)求的請(qǐng)求隊(duì)列之間的區(qū)別在于是否有HTTP版本域和是否可以
使用除GET以外的其它方法。
5.1.1 方法（Method）
方法代號(hào)指明了將要以何種方式來訪問由請(qǐng)求URI指定的資源。方法是大小寫敏感的。
Method = "GET" ; Section 8.1
|"HEAD" ; Section 8.2
| "POST" ; Section 8.3
| extension-method
extension-method = token
可以訪問指定資源的方法列表是可以動(dòng)態(tài)變化的；如果用某種方法訪問資源被拒絕，客
戶端可從回應(yīng)中的返回碼得到通知。服務(wù)器端在方法無法識(shí)別或沒有實(shí)現(xiàn)時(shí)，返回狀態(tài)代碼
501（尚未沒實(shí)現(xiàn)）。
這些方法被HTTP/1.0的應(yīng)用程序普遍使用，完整定義請(qǐng)參見第8節(jié)。
5.1.2 請(qǐng)求URI（Request-URI）
請(qǐng)求URI就是統(tǒng)一資源標(biāo)識(shí)符（3.2節(jié)），用來標(biāo)識(shí)要請(qǐng)求的資源。
Request-URI = absoluteURI | abs_path
上面兩種請(qǐng)求URI方式可根據(jù)實(shí)際的請(qǐng)求方式選擇使用。
絕對(duì)URI（absoluteURI）格式只在代理（proxy）在產(chǎn)生請(qǐng)求時(shí)使用。代理的責(zé)任是將
請(qǐng)求向前推送，并將回應(yīng)返回。如果請(qǐng)求是GET或HEAD方式，而且之前的回應(yīng)被緩存，
如果代理忽略標(biāo)題域的過期信息限制，它可能使用緩存中的消息。注意，代理可能將請(qǐng)求推
送至另外一個(gè)代理，也可將請(qǐng)求直接送至絕對(duì)URI中所指定的目的服務(wù)器。為了避免請(qǐng)求
循環(huán)，代理必須能夠識(shí)別它的所有服務(wù)器名，包括別名、本地變量及數(shù)字形式的IP地址。
下面是一個(gè)請(qǐng)求隊(duì)列的例子：
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0
最普通的請(qǐng)求URI形式就是原始服務(wù)器或網(wǎng)關(guān)用來標(biāo)識(shí)資源的方式。在這種方式下，
只有給出絕對(duì)路徑的URI才能被傳輸（見3.2.1節(jié)）。例如，如客戶端希望直接從原始服務(wù)
器上接收資源，它們將產(chǎn)生一個(gè)與主機(jī)"www.w3.org"80端口的TCP連接，并在完整請(qǐng)求之
后發(fā)送下面的命令：
GET /pub/WWW/TheProject.html HTTP/1.0
注意絕對(duì)路徑不可以為空，如果URI中沒有內(nèi)容，也必須加上一個(gè)"/"（server root）。
請(qǐng)求URI以編碼字符串方式傳輸，有些字符可能在傳輸過程中被轉(zhuǎn)義（escape），如變
成“%HEXHEX”形式。具體這方面內(nèi)容請(qǐng)參見RFC1738[4]。原始服務(wù)器在正確解釋請(qǐng)求
之前必須對(duì)請(qǐng)求URI進(jìn)行解碼。
5.2 請(qǐng)求標(biāo)題域（Request Header Fields）
請(qǐng)求標(biāo)題域允許客戶端向服務(wù)器端傳遞該請(qǐng)求的附加信息及客戶端信息。該域做為請(qǐng)求
的修飾部分，遵照編程語言程序調(diào)用參數(shù)的語法形式。
Request-Header = Authorization ; Section 10.2
| From ; Section 10.8
| If-Modified-Since ; Section 10.9
| Referer ; Section 10.13
| User-Agent ; Section 10.15
請(qǐng)求標(biāo)題域名只有在與協(xié)議版本的變化結(jié)合起來后，才能進(jìn)行可靠的擴(kuò)展。實(shí)際上，新
的或?qū)嶒?yàn)中的標(biāo)題域只要能被通訊各方識(shí)別，其語法就可使用，而無法識(shí)別的標(biāo)題域都將被
視為實(shí)體域。
6. 回應(yīng)（Response）
在接收、解釋請(qǐng)求消息后，服務(wù)器端返回HTTP回應(yīng)消息。
Response = Simple-Response | Full-Response
Simple-Response = [ Entity-Body ]
Full-Response = Status-Line ; Section 6.1
*( General-Header ; Section 4.3
| Response-Header ; Section 6.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
當(dāng)請(qǐng)求是HTTP/0.9的或者服務(wù)器端只支持HTTP/0.9時(shí)，只能以Simple-Response方式
回應(yīng)。如果客戶端發(fā)送HTTP/1.0完整請(qǐng)求后，接收到的回應(yīng)不是以狀態(tài)行（Status-Line）
開頭的，客戶端將其視為簡(jiǎn)單回應(yīng)，并相應(yīng)對(duì)其進(jìn)行分析。注意，簡(jiǎn)單請(qǐng)求只包括實(shí)體主體，
它在服務(wù)器端關(guān)閉連接時(shí)終止。
6.1 狀態(tài)行（Status-Line）
完整回應(yīng)消息的第一行就是狀態(tài)行，它依次由協(xié)議版本、數(shù)字形式的狀態(tài)代碼、及相應(yīng)
的詞語文本組成，各元素間以空格（SP）分隔，除了結(jié)尾的CRLF外，不允許出現(xiàn)單獨(dú)的
CR或LF符。
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
狀態(tài)行總是以協(xié)議版本及狀態(tài)代碼開頭，如：
"HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP
（如，"HTTP/1.0 200"）。
這種表示方式并不足以區(qū)分完整請(qǐng)求和簡(jiǎn)單請(qǐng)求。簡(jiǎn)單回應(yīng)可能允許這種表達(dá)式出現(xiàn)在
實(shí)體主體的開始部分，但會(huì)引起消息的誤解。因?yàn)榇蠖鄶?shù)HTTP/0.9的服務(wù)器都只能回
應(yīng)"text/html"類型，在這種情況下，不可能產(chǎn)生完整的回應(yīng)。
6.1.1 狀態(tài)代碼和原因分析（Status Code and Reason
Phrase）
狀態(tài)代碼（Status-Code）由3位數(shù)字組成，表示請(qǐng)求是否被理解或被滿足。原因分析是
用簡(jiǎn)短的文字來描述狀態(tài)代碼產(chǎn)生的原因。狀態(tài)代碼用來支持自動(dòng)操作，原因分析是為人類
用戶準(zhǔn)備的。客戶端不需要檢查或顯示原因分析。
狀態(tài)代碼的第一位數(shù)字定義了回應(yīng)的類別，后面兩位數(shù)字沒有具體分類。首位數(shù)字有5
種取值可能：
o 1xx:：保留，將來使用。
o 2xx：成功 － 操作被接收、理解、接受（received, understood, accepted）。
o 3xx：重定向（Redirection）－ 要完成請(qǐng)求必須進(jìn)行進(jìn)一步操作。
o 4xx：客戶端出錯(cuò) － 請(qǐng)求有語法錯(cuò)誤或無法實(shí)現(xiàn)。
o 5xx：服務(wù)器端出錯(cuò) － 服務(wù)器無法實(shí)現(xiàn)合法的請(qǐng)求。
HTTP/1.0的狀態(tài)代碼、原因解釋在下面給出。下面的原因解釋只是建議采用，可任意
更改，而不會(huì)對(duì)協(xié)議造成影響。完整的代碼定義在第9節(jié)。
Status-Code = "200" ; OK
| "201" ; Created
| "202" ; Accepted
| "204" ; No Content
| "301" ; Moved Permanently
| "302" ; Moved Temporarily
| "304" ; Not Modified
| "400" ; Bad Request
| "401" ; Unauthorized
| "403" ; Forbidden
| "404" ; Not Found
| "500" ; Internal Server Error
| "501" ; Not Implemented
| "502" ; Bad Gateway
| "503" ; Service Unavailable
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
HTTP狀態(tài)代碼是可擴(kuò)展的，而只有上述代碼才可以被當(dāng)前全部的應(yīng)用所識(shí)別。HTTP
應(yīng)用不要求了解全部注冊(cè)的狀態(tài)代碼，當(dāng)然，如果了解了更好。實(shí)際上，應(yīng)用程序必須理解
任何一種狀態(tài)代碼，如果碰到不識(shí)別的情況，可根據(jù)其首位數(shù)字來判斷其類型并處理。另外，
不要緩存無法識(shí)別的回應(yīng)。
例如，如果客戶端收到一個(gè)無法識(shí)別的狀態(tài)碼431，可以安全地假定是請(qǐng)求出了問題，
可認(rèn)為回應(yīng)的狀態(tài)碼就是400。在這種情況下，用戶代理應(yīng)當(dāng)在回應(yīng)消息的實(shí)體中通知用戶，
因?yàn)閷?shí)體中可以包括一些人類可以識(shí)別的非正常狀態(tài)的描述信息。
6.2 回應(yīng)標(biāo)題域（Response Header Fields）
回應(yīng)標(biāo)題域中包括不能放在狀態(tài)行中的附加回應(yīng)信息。該域還可以存放與服務(wù)器相關(guān)的
信息，以及在對(duì)請(qǐng)求URI所指定資源進(jìn)行訪問的下一步信息。
Response-Header = Location ; Section 10.11
| Server ; Section 10.14
| WWW-Authenticate ; Section 10.16
回應(yīng)標(biāo)題域名只有在與協(xié)議版本的變化結(jié)合起來后，才能進(jìn)行可靠的擴(kuò)展。實(shí)際上，新
的或?qū)嶒?yàn)中的標(biāo)題域只要能被通訊各方識(shí)別，其語法就可使用，而無法識(shí)別的標(biāo)題域都將被
視為實(shí)體域。
7. 實(shí)體（Entity）
完整請(qǐng)求和完整回應(yīng)消息可能會(huì)傳輸請(qǐng)求或回應(yīng)中的實(shí)體。實(shí)體由實(shí)體標(biāo)題
（Entity-Header）域、（通常還有）實(shí)體主體（Entity-Body）組成。從這種角度看，客戶端
與服務(wù)器都將扮演發(fā)送方及接收方的角色。某一時(shí)刻的角色定位則取決于在這個(gè)時(shí)刻誰在發(fā)
送實(shí)體，而誰又在接收實(shí)體。
7.1 實(shí)體標(biāo)題域（Entity Header Fields）
實(shí)體標(biāo)題域中定義了一些可選的元信息，如有無實(shí)體、請(qǐng)求資源。
Entity-Header = Allow ; Section 10.1
| Content-Encoding ; Section 10.3
| Content-Length ; Section 10.4
| Content-Type ; Section 10.5
| Expires ; Section 10.7
| Last-Modified ; Section 10.10
| extension-header
extension-header = HTTP-header
擴(kuò)展標(biāo)題（extension-header）機(jī)制允許在不改變協(xié)議的前提下定義附加的實(shí)體標(biāo)題域，
但是不能假定接收方可以識(shí)別這些域。對(duì)于不可識(shí)別的標(biāo)題域，接收方一般是忽略不管，而
代理則繼續(xù)將其向前推送。
7.2 實(shí)體主體（Entity Body）
與HTTP請(qǐng)求或回應(yīng)一起發(fā)送的實(shí)體主體的格式和編碼信息都在實(shí)體標(biāo)題域
（Entity-Header）中定義。
Entity-Body = *OCTET
實(shí)體主體只在請(qǐng)求方法有要求時(shí)才會(huì)被放在請(qǐng)求消息中。請(qǐng)求消息標(biāo)題域處的內(nèi)容長度
標(biāo)題域（Content-Length header field）的標(biāo)志將指明請(qǐng)求中的實(shí)體主體是否存在。包含實(shí)體
主體的HTTP/1.0請(qǐng)求必須包含合法的內(nèi)容長度標(biāo)題域。
對(duì)回應(yīng)消息來說，消息中是否包含實(shí)體主體取決于請(qǐng)求方法和回應(yīng)代碼。所有的HEAD
請(qǐng)求方法的回應(yīng)都不應(yīng)包括主體，即便是實(shí)體標(biāo)題域中指明有主體也一樣。在主體中不應(yīng)包
括這些回應(yīng)信息，全部1xx（信息）、204（無內(nèi)容）和304（未修改）。而其它的回應(yīng)必須包
括實(shí)體主體或其內(nèi)容長度標(biāo)題（Content-Length header）域的定義值為0。
7.2.1 類型（Type）
當(dāng)消息中包括實(shí)體主體，主體的數(shù)據(jù)類型由標(biāo)題域中的內(nèi)容類型（Content-Type）和內(nèi)
容編碼（Content-Encoding）決定。定義了二層順序編碼模式：
entity-body := Content-Encoding( Content-Type( data ) )
內(nèi)容類型（Content-Type）指定了下列數(shù)據(jù)的介質(zhì)類型（media type）。內(nèi)容編碼
（Content-Encoding）可用于指示附加內(nèi)容解碼方式，通常用于有數(shù)據(jù)壓縮屬性的被請(qǐng)求資
源。內(nèi)容編碼的缺省值是none。
任何包括實(shí)體主體的消息必須含有內(nèi)容類型（Content-Type）標(biāo)題域，以定義主體的類
型。只有當(dāng)內(nèi)容類型標(biāo)題域中沒有給出介質(zhì)類型時(shí)，如簡(jiǎn)單回應(yīng)消息，接收方可能對(duì)該URL
所指定的資源進(jìn)行判斷，如其內(nèi)容及擴(kuò)展名等等，從而猜測(cè)出該主體的介質(zhì)類型。如果還無
法確定介質(zhì)類型，接收方應(yīng)當(dāng)將其視為" application/octet-stream"型。
7.2.2 長度（Length）
當(dāng)實(shí)體主體被包括在消息中，主體長度可以有兩種方式確定。如果內(nèi)容長度
（Content-Length）標(biāo)題域存在，其字節(jié)值就是實(shí)體主體長度；否則，其主體長度由服務(wù)端
關(guān)閉連接時(shí)確定。
由于服務(wù)端無法在連接關(guān)閉時(shí)發(fā)送回應(yīng)信息，所以不能用關(guān)閉連接來指示請(qǐng)求主體的結(jié)
束。因而，HTTP/1.0請(qǐng)求如果包含主體，就必須在內(nèi)容長度（Content-Length）標(biāo)題域中給
出合法的值。如果請(qǐng)求包括實(shí)體主體，且內(nèi)容長度沒指定，服務(wù)端將無法識(shí)別或無法從其它
域中計(jì)算出其主體長度，在這種情況下，服務(wù)端將會(huì)返回400（非法請(qǐng)求）回應(yīng)。
注意：一些老的服務(wù)器在發(fā)送包含由服務(wù)器端動(dòng)態(tài)插入的數(shù)據(jù)流文件時(shí)，支持非法的內(nèi)
容長度使用。要強(qiáng)調(diào)的是，未來版本的HTTP協(xié)議將會(huì)很快改變這種情況。除非客戶端自己
知道正在從一個(gè)支持它的服務(wù)器端得到回應(yīng)，否則不應(yīng)依賴于內(nèi)容長度域的正確性。
8. 方法定義（Method Definitions）
通用的HTTP/1.0的方法集將在下面定義，雖然該方法集可以擴(kuò)展，但并不保證附加的
方法能夠被擴(kuò)展的客戶端和服務(wù)器端所支持。
8.1 GET
GET方法就是以實(shí)體方式得到由請(qǐng)求URI所指定資源的信息。如果請(qǐng)求URI只是一個(gè)
數(shù)據(jù)產(chǎn)生過程，那么最終要在回應(yīng)實(shí)體中返回的是由該處理過程的結(jié)果所指向的資源，而不
是返回該處理過程的描述文字，除非那段文字恰好是處理的輸出。
如果請(qǐng)求消息包含If-Modified-Since標(biāo)題域，GET方法的語法就變成“條件GET”，即
“（conditional GET）”。 條件GET方法可以對(duì)指定資源進(jìn)行判斷，如果它在If-Modified-Since
標(biāo)題域（見10.9節(jié)）中的指定日期后發(fā)生了更新，才啟動(dòng)傳輸，否則不傳輸。這種條件GET
允許被緩存的實(shí)體在不必經(jīng)過多次請(qǐng)求或不必要的數(shù)據(jù)傳輸就能進(jìn)行刷新，從而有助于降低
網(wǎng)絡(luò)負(fù)載。
8.2 HEAD
HEAD方法與GET幾乎一樣，區(qū)別在于，HEAD方法不讓服務(wù)器在回應(yīng)中返回任何實(shí)
體。對(duì)HEAD請(qǐng)求的回應(yīng)部分來說，它的HTTP標(biāo)題中包含的元信息與通過GET請(qǐng)求所得
到的是相同的。通過使用這種方法，不必傳輸整個(gè)實(shí)體主體，就可以得到請(qǐng)求URI所指定
資源的元信息。該方法通常用來測(cè)試超鏈接的合法性、可訪問性及最近更新。
與條件GET不同，不存在所謂的“條件HEAD”，即"conditional HEAD"。即使在HEAD
請(qǐng)求中指定If-Modified-Since標(biāo)題域，它也會(huì)被忽略。
8.3 POST
POST方法用來向目的服務(wù)器發(fā)出請(qǐng)求，要求它接受被附在請(qǐng)求后的實(shí)體，并把它當(dāng)作
請(qǐng)求隊(duì)列（Request-Line）中請(qǐng)求URI所指定資源的附加新子項(xiàng)。POST被設(shè)計(jì)成用統(tǒng)一的
方法實(shí)現(xiàn)下列功能：
o 對(duì)現(xiàn)有資源的注釋（Annotation of existing resources）；
o 向電子公告欄、新聞組，郵件列表或類似討論組發(fā)送消息；
o 提交數(shù)據(jù)塊，如將表格（form [3]）的結(jié)果提交給數(shù)據(jù)處理過程；
o 通過附加操作來擴(kuò)展數(shù)據(jù)庫。
POST方法的實(shí)際功能由服務(wù)器來決定，而且通常依賴于請(qǐng)求URI。在POST過程中，
實(shí)體是URI的從屬部分，就好象文件從屬于包含它的目錄、新聞組文件從屬于發(fā)出該文件
的新聞組、記錄從屬于其所在的數(shù)據(jù)庫一樣。
成功的POST不需要在原始服務(wù)器創(chuàng)建實(shí)體，并將其做為資源；也不需要為未來的訪問
提供條件。也就是說，POST方法不一定會(huì)指向URI指定的資源。在這種情況下，200（成
功）或204（無內(nèi)容）都是適當(dāng)?shù)幕貞?yīng)狀態(tài)，取決于實(shí)際回應(yīng)實(shí)體中對(duì)結(jié)果的描述。
如果在原始服務(wù)器上創(chuàng)建了資源，回應(yīng)應(yīng)是201（已創(chuàng)建），并包含一個(gè)實(shí)體
（對(duì)"text/html"類型最為適合），該實(shí)體中記錄著對(duì)新資源請(qǐng)求的狀態(tài)描述。
在所有的HTTP/1.0的POST請(qǐng)求中，必須指定合法的內(nèi)容長度（Content-Length）。如
果HTTP/1.0服務(wù)器在接收到請(qǐng)求消息內(nèi)容時(shí)無法確定其長度，就會(huì)返回400（非法請(qǐng)求）
代碼。
應(yīng)用程序不能緩存對(duì)POST請(qǐng)求的回應(yīng)，因?yàn)樽鰹閼?yīng)用程序來說，它們沒有辦法知道服
務(wù)器在未來的請(qǐng)求中將如何回應(yīng)。
9. 狀態(tài)代碼定義（Status Code Definitions）
每個(gè)狀態(tài)代碼都將在下面描述，包括它們將對(duì)應(yīng)哪個(gè)方法、以及回應(yīng)中需要的全部元信
息。
9.1 消息1xx（Informational 1xx）
該類狀態(tài)代碼用于表示臨時(shí)回應(yīng)。臨時(shí)回應(yīng)由狀態(tài)行（Status-Line）及可選標(biāo)題組成，
由空行終止。HTTP/1.0中沒有定義任何1xx的狀態(tài)代碼，所以它們不是對(duì)HTTP/1.0請(qǐng)求的
合法回應(yīng)。實(shí)際上，它們主要用于實(shí)驗(yàn)用途，這已經(jīng)超出本文檔的范圍。
9.2 成功2xx（Successful 2xx）
表示客戶端請(qǐng)求被成功接收、理解、接受。
200 OK
請(qǐng)求成功。回應(yīng)的信息依賴于請(qǐng)求所使用的方法，如下：
GET 要請(qǐng)求的資源已經(jīng)放在回應(yīng)的實(shí)體中了。
HEAD 沒有實(shí)體主體，回應(yīng)中只包括標(biāo)題信息。
POST 實(shí)體（描述或包含操作的結(jié)果）。
201 Created
請(qǐng)求完成，結(jié)果是創(chuàng)建了新資源。新創(chuàng)建資源的URI可在回應(yīng)的實(shí)體中得到。原
始服務(wù)器應(yīng)在發(fā)出該狀態(tài)代碼前創(chuàng)建該資源。如果該操作不能立即完成，服務(wù)器必
須在該資源可用時(shí)在回應(yīng)主體中給出提示，否則，服務(wù)器端應(yīng)回應(yīng)202（可被接受）。
在本文定義的方法，只有POST可以創(chuàng)建資源。
202 Accepted
請(qǐng)求被接受，但處理尚未完成。請(qǐng)求可能不一定會(huì)最終完成，有可能被處理過程隨
時(shí)中斷，在這種情況下，沒有辦法在異步操作中重新發(fā)送狀態(tài)代碼。
202回應(yīng)是沒有義務(wù)的，這樣做的目的是允許服務(wù)器不必等到用戶代理和服務(wù)器間
的連接結(jié)束，就可以響應(yīng)其它過程的請(qǐng)求（象每天運(yùn)行一次的，基于批處理的過程）。
在某些回應(yīng)中返回的實(shí)體中包括當(dāng)前請(qǐng)求的狀態(tài)指示、狀態(tài)監(jiān)視器指針或用戶對(duì)請(qǐng)
求能否實(shí)現(xiàn)的評(píng)估信息。
204 No Content
服務(wù)器端已經(jīng)實(shí)現(xiàn)了請(qǐng)求，但是沒有返回新的信息。如果客戶是用戶代理，則勿需
為此更新自身的文檔視圖。該回應(yīng)主要是為了在不影響用戶代理激活文檔視圖的前
提下，進(jìn)行script語句的輸入及其它操作。該回應(yīng)還可能包括新的、以實(shí)體標(biāo)題形
式表示的元信息，它可被當(dāng)前用戶代理激活視圖中的文檔所使用。
9.3 重定向（Redirection 3xx）
該類狀態(tài)碼表示用戶代理要想完成請(qǐng)求，還需要發(fā)出進(jìn)一步的操作。這些操作只有
當(dāng)后跟的請(qǐng)求是GET或HEAD時(shí)，才可由用戶代理來實(shí)現(xiàn)，而不用與用戶進(jìn)行交
互。用戶代理永遠(yuǎn)也不要對(duì)請(qǐng)求進(jìn)行5次以上的重定向操作，這樣可能導(dǎo)致無限循
環(huán)。
300 Multiple Choices
該狀態(tài)碼不被HTTP/1.0的應(yīng)用程序直接使用，只是做為3xx類型回應(yīng)的缺省解釋。
存在多個(gè)可用的被請(qǐng)求資源。
除非是HEAD請(qǐng)求，否則回應(yīng)的實(shí)體中必須包括這些資源的字符列表及位置信息，
由用戶或用戶代理來決定哪個(gè)是最適合的。
如果服務(wù)器有首選，它應(yīng)將對(duì)應(yīng)的URL信息存放在位置域（Location field）處，
用戶代理會(huì)根據(jù)此域的值來實(shí)現(xiàn)自動(dòng)的重定向。
301 Moved Permanently
請(qǐng)求到的資源都會(huì)分配一個(gè)永久的URL，這樣就可以在將來通過該URL來訪問此
資源。有編輯鏈接功能的客戶端會(huì)盡可能地根據(jù)服務(wù)器端傳回的新鏈接而自動(dòng)更新
請(qǐng)求URI。
新的URL必須由回應(yīng)中的位置域指定。除非是HEAD請(qǐng)求，否則回應(yīng)的實(shí)體主體
（Entity-Body）必須包括對(duì)新URL超鏈接的簡(jiǎn)要描述。
如果用POST方法發(fā)出請(qǐng)求，而接收到301回應(yīng)狀態(tài)碼。在這種情況下，除非用戶
確認(rèn)，否則用戶代理不必自動(dòng)重定向請(qǐng)求，因?yàn)檫@將導(dǎo)致改變已發(fā)出請(qǐng)求的環(huán)境。
注意：當(dāng)在接收到301狀態(tài)碼后而自動(dòng)重定向POST請(qǐng)求時(shí)，一些現(xiàn)存的用戶代理
會(huì)錯(cuò)誤地將其改為GET請(qǐng)求。
302 Moved Temporarily
請(qǐng)求到的資源在一個(gè)不同的URL處臨時(shí)保存。因?yàn)橹囟ㄏ蛴袝r(shí)會(huì)被更改，客戶端
應(yīng)繼續(xù)用請(qǐng)求URI來發(fā)出以后的請(qǐng)求。
新的URL必須由回應(yīng)中的位置域指定。除非是HEAD請(qǐng)求，否則回應(yīng)的實(shí)體主體
（Entity-Body）必須包括對(duì)新URL超鏈接的簡(jiǎn)要描述。
如果用POST方法發(fā)出請(qǐng)求，而接收到302回應(yīng)狀態(tài)碼。在這種情況下，除非用戶
確認(rèn)，否則用戶代理不必自動(dòng)重定向請(qǐng)求，因?yàn)檫@將導(dǎo)致改變已發(fā)出請(qǐng)求的環(huán)境。
注意：當(dāng)在接收到302狀態(tài)碼后而自動(dòng)重定向POST請(qǐng)求時(shí)，一些現(xiàn)存的用戶代理
會(huì)錯(cuò)誤地將其改為GET請(qǐng)求。
304 Not Modified
如果客戶端成功執(zhí)行了條件GET請(qǐng)求，而對(duì)應(yīng)文件自If-Modified-Since域所指定
的日期以來就沒有更新過，服務(wù)器應(yīng)當(dāng)回應(yīng)此狀態(tài)碼，而不是將實(shí)體主體發(fā)送給客
戶端。回應(yīng)標(biāo)題域中只應(yīng)包括一些相關(guān)信息，比如緩存管理器、與實(shí)體最近更新
（entity's Last-Modified）日期無關(guān)的修改。相關(guān)標(biāo)題域的例子有：日期、服務(wù)器、
過期時(shí)間。每當(dāng)304回應(yīng)中給出的域值發(fā)生變化，緩存都應(yīng)當(dāng)對(duì)緩存的實(shí)體進(jìn)行更
新。
9.4 客戶端錯(cuò)誤（Client Error ）4xx
4xx類的狀態(tài)碼表示客戶端發(fā)生錯(cuò)誤。如果客戶端在收到4xx代碼時(shí)請(qǐng)求還沒有完成，
它應(yīng)當(dāng)立即終止向服務(wù)器發(fā)送數(shù)據(jù)。除了回應(yīng)HEAD請(qǐng)求外，不論錯(cuò)誤是臨時(shí)的還是永久
的，服務(wù)器端都必須在回應(yīng)的實(shí)體中包含錯(cuò)誤狀態(tài)的解釋。這些狀態(tài)碼適用于任何請(qǐng)求方法。
注意：如果客戶端正在發(fā)送數(shù)據(jù)，服務(wù)器端的TCP實(shí)現(xiàn)應(yīng)當(dāng)小心，以確保客戶端在關(guān)
閉輸入連接之前收到回應(yīng)包。如果客戶端在關(guān)閉后仍舊向服務(wù)器發(fā)送數(shù)據(jù)，服務(wù)器會(huì)給客戶
端發(fā)送一個(gè)復(fù)位包，清空客戶端尚未處理的輸入緩沖區(qū)，以終止HTTP應(yīng)用程序的讀取、解
釋活動(dòng)。
400 非法請(qǐng)求（Bad Request）
如果請(qǐng)求的語法不對(duì)，服務(wù)器將無法理解。客戶端在對(duì)該請(qǐng)求做出更改之前，不應(yīng)
再次向服務(wù)器重復(fù)發(fā)送該請(qǐng)求。
401 未授權(quán)（Unauthorized）
請(qǐng)求需要用戶授權(quán)。回應(yīng)中的WWW-Authenticate標(biāo)題域（10.16節(jié)）應(yīng)提示用戶
以授權(quán)方式請(qǐng)求資源。客戶端應(yīng)使用合適的授權(quán)標(biāo)題域（10.2節(jié)）來重復(fù)該請(qǐng)求。如果
請(qǐng)求中已經(jīng)包括了授權(quán)信任信息，那回應(yīng)的401表示此授權(quán)被拒絕。如果用戶代理在多
次嘗試之后，回應(yīng)一樣還是返回401狀態(tài)代碼，用戶應(yīng)當(dāng)察看一下回應(yīng)的實(shí)體，因?yàn)樵?br>實(shí)體中會(huì)包括一些相關(guān)的動(dòng)態(tài)信息。HTTP訪問授權(quán)會(huì)在11節(jié)中解釋。
403 禁止（Forbidden）
服務(wù)器理解請(qǐng)求，但是拒絕實(shí)現(xiàn)該請(qǐng)求。授權(quán)對(duì)此沒有幫助，客戶端應(yīng)當(dāng)停止重復(fù)
發(fā)送此請(qǐng)求。如果不是用HEAD請(qǐng)求方法，而且服務(wù)器端愿意公布請(qǐng)求未被實(shí)現(xiàn)原因
的前提下，服務(wù)器會(huì)將拒絕原因?qū)懺诨貞?yīng)實(shí)體中。該狀態(tài)碼一般用于服務(wù)器端不想公布
請(qǐng)求被拒絕的細(xì)節(jié)或沒有其它的回應(yīng)可用。
404 沒有找到（Not Found）
服務(wù)器沒有找到與請(qǐng)求URI相符的資源。404狀態(tài)碼并不指明狀況是臨時(shí)性的還是
永久性的。如果服務(wù)器不希望為客戶端提供這方面的信息，還回應(yīng)403（禁止）狀態(tài)碼。
9.5 服務(wù)器錯(cuò)誤（Server Error ）5xx
回應(yīng)代碼以‘5’開頭的狀態(tài)碼表示服務(wù)器端發(fā)現(xiàn)自己出現(xiàn)錯(cuò)誤，不能繼續(xù)執(zhí)行請(qǐng)
求。如果客戶端在收到5xx狀態(tài)碼時(shí)，請(qǐng)求尚未完成，它應(yīng)當(dāng)立即停止向服務(wù)器發(fā)送數(shù)
據(jù)。除了回應(yīng)HEAD請(qǐng)求外，服務(wù)器應(yīng)當(dāng)在其回應(yīng)實(shí)體中包括對(duì)錯(cuò)誤情況的解釋、并
指明是臨時(shí)性的還永久性的。
這類回應(yīng)代碼沒有標(biāo)題域，可適用于任何請(qǐng)求方法。
500 服務(wù)器內(nèi)部錯(cuò)誤（Internal Server Error）
服務(wù)器碰到了意外情況，使其無法繼續(xù)回應(yīng)請(qǐng)求。
501 未實(shí)現(xiàn)（Not Implemented）
服務(wù)器無法提供對(duì)請(qǐng)求中所要求功能的支持。如果服務(wù)器無法識(shí)別請(qǐng)求方法就會(huì)回
應(yīng)此狀態(tài)代碼，這意味著不能回應(yīng)請(qǐng)求所要求的任何資源。
502 非法網(wǎng)關(guān)（Bad Gateway）
充當(dāng)網(wǎng)關(guān)或代理的服務(wù)器從要發(fā)送請(qǐng)求的上游（upstream）服務(wù)器收到非法的回應(yīng)。
503 服務(wù)不可用（Service Unavailable）
服務(wù)器當(dāng)前無法處理請(qǐng)求。這一般是由于服務(wù)器臨時(shí)性超載或維護(hù)引起的。該狀態(tài)
碼暗示情況是暫時(shí)性的，要產(chǎn)生一些延遲。
注意：503狀態(tài)碼并沒有暗示服務(wù)器在超載時(shí)一定要返回此狀態(tài)碼。一些服務(wù)器可
能希望在超載時(shí)采用簡(jiǎn)單處理，即斷掉連接。
10. 標(biāo)題域定義（Header Field Definitions）
本節(jié)定義了HTTP/1.0標(biāo)題域常用的語法及語義。無論是發(fā)送方還是接收方，都有
可能做為客戶端或服務(wù)器端，具體角色取決于在此時(shí)刻究竟是誰在接收、誰在發(fā)送。
10.1 允許（Allow）
表示由請(qǐng)求URI所指定的資源支持在Allow實(shí)體標(biāo)題域中列出的方法，目的是讓接收
方更清楚地知道請(qǐng)求此資源的合法方式。Allow標(biāo)題域不允許在POST方法中使用，如果非
要這么做，將被忽略。
Allow = "Allow" ":" 1#method
Example of use:
Allow: GET, HEAD
該域不能防止客戶端嘗試其它方法。但實(shí)際上由Allow標(biāo)題域中的值所表示的指示
信息是有用的，應(yīng)當(dāng)被遵守。實(shí)際的Allow方法集在每次向原始服務(wù)器上發(fā)出請(qǐng)求時(shí)定
義。
由于用戶代理（user agent）可能出于其它目的與原始服務(wù)器通訊，做為代理（proxy）
來說，即使無法識(shí)別請(qǐng)求所指定的所有方法，也不能修改該請(qǐng)求的Allow標(biāo)題域。
Allow標(biāo)題域并不表示服務(wù)器實(shí)現(xiàn)了哪些方法。
10.2 授權(quán)（Authorization）
通常，用戶代理在收到401（未授權(quán)）回應(yīng)時(shí)，可能（也可能不會(huì)）希望服務(wù)器對(duì)其授
權(quán)。如果希望授權(quán)，用戶代理將在請(qǐng)求中加入授權(quán)請(qǐng)求標(biāo)題（Authorization request-header）
域。授權(quán)域值由信任證書組成，其中有對(duì)用戶代理所請(qǐng)求資源領(lǐng)域的授權(quán)信息。
Authorization = "Authorization" ":" credentials
HTTP訪問授權(quán)在11節(jié)中描述。如果請(qǐng)求中的授權(quán)指定了一個(gè)范圍，那在此范圍的其
它請(qǐng)求也都具有相同的信任關(guān)系。
對(duì)包含授權(quán)信息域的請(qǐng)求來說，其回應(yīng)是不能被緩存的。
10.3 內(nèi)容編碼（Content-Encoding）
內(nèi)容編碼的實(shí)體標(biāo)題域（entity-header）用作介質(zhì)類型（media-type）的修飾符。它指明
要對(duì)資源采用的附加內(nèi)容譯碼方式，因而要獲得內(nèi)容類型（Content-Type）標(biāo)題域中提及的
介質(zhì)類型，必須采用與譯碼方式一致的解碼機(jī)制。內(nèi)容編碼主要用來記錄文件的壓縮方法。
各種壓縮方法將在后面列出。
Content-Encoding = "Content-Encoding" ":" content-coding
內(nèi)容譯碼（Content codings）在3.5節(jié)中定義，例如：
Content-Encoding: x-gzip
內(nèi)容編碼是請(qǐng)求URI指定資源的一個(gè)特性，一般來說，資源用編碼方式存儲(chǔ)，只有在
通過解碼變換以后才能使用。
10.4 內(nèi)容長度（Content-Length）
內(nèi)容長度（Content-Length）實(shí)體標(biāo)題域指明了發(fā)送到接收方的實(shí)體主體（Entity-Body）
長度，用字節(jié)方式存儲(chǔ)的十進(jìn)制數(shù)字表示。對(duì)于HEAD方法，其尺寸已經(jīng)在前一次GET請(qǐng)
求中發(fā)出了。
Content-Length = "Content-Length" ":" 1*DIGIT
例如：
Content-Length: 3495
不論實(shí)體是何種介質(zhì)類型，應(yīng)用程序都將通過該域來判定將要傳輸?shù)膶?shí)體主體尺寸。所
有包括實(shí)體主體的HTTP/1.0的請(qǐng)求消息都必須包括合法的內(nèi)容長度值。
任何0以上（包括0）的值都是合法的內(nèi)容長度值。在7.2.2節(jié)描述了當(dāng)內(nèi)容長度值沒
有給出時(shí)，如何決定回應(yīng)實(shí)體主體長度的方法。
注意：該域的含義與在MIME中定義的有重要區(qū)別。在MIME中，它是可選域，只
在"message/external-body"內(nèi)容類型中使用；而在HTTP中，在實(shí)體被傳輸前，該域就決定
了實(shí)體的長度。
10.5 內(nèi)容類型（Content-Type）
內(nèi)容類型實(shí)體標(biāo)題域指明了發(fā)送給接收方的實(shí)體主體長度。對(duì)于HEAD方法，介質(zhì)類
型已經(jīng)在前一次GET請(qǐng)求中發(fā)出了。
Content-Type = "Content-Type" ":" media-type
介質(zhì)類型在3.6節(jié)中定義，如下例：
Content-Type: text/html
更多關(guān)于介質(zhì)類型的討論在7.2.1節(jié)。
10.6 日期（Date）
日期普通標(biāo)題（Date general-header）域表示消息產(chǎn)生的時(shí)間，其語法與RFC822中定義
的orig-date是一樣的。該域值是HTTP型日期，在3.3節(jié)中描述。
Date = "Date" ":" HTTP-date
例如：
Date: Tue, 15 Nov 1994 08:12:31 GMT
如果直接通過用戶代理（如請(qǐng)求）或原始服務(wù)器（如回應(yīng)）的連接接收到消息，日期可
以認(rèn)為是接收端的當(dāng)前時(shí)間。然而，對(duì)于原始服務(wù)器來說，時(shí)間對(duì)其回應(yīng)緩存的處理非常重
要，所以，原始服務(wù)器的回應(yīng)總是包括日期標(biāo)題。客戶端只有在發(fā)送帶實(shí)體的消息時(shí)，才可
向服務(wù)器發(fā)送日期標(biāo)題域，比如POST請(qǐng)求。如果接收到的消息被接收方或網(wǎng)關(guān)通過有日期
要求的協(xié)議緩存起來時(shí)，該消息即使沒有日期標(biāo)題域，接收方也會(huì)為其分配一個(gè)。
理論上，日期應(yīng)當(dāng)在實(shí)體產(chǎn)生時(shí)生成，而實(shí)際上，日期可能在消息產(chǎn)生過程的任意時(shí)間
生成，而不會(huì)造成任何不利的影響。
注意：早期版本錯(cuò)誤地將此域值定義為實(shí)體主體封裝時(shí)的日期。這已經(jīng)被實(shí)際應(yīng)用所更
正。
10.7 過期（Expires）
過期實(shí)體標(biāo)題域中的日期/時(shí)間值指定了實(shí)體過期的時(shí)間。這為信息提供方提供了使信
息失效的手段。當(dāng)超過此期限時(shí)，應(yīng)用程序不應(yīng)再對(duì)此實(shí)體進(jìn)行緩存了。過期并不意味著原
始資源會(huì)在此期限后發(fā)生改變或停止存在。在實(shí)際應(yīng)用中，信息提供者通過檢查過期標(biāo)題域
中所指定的時(shí)間，從而獲知或預(yù)測(cè)資源將會(huì)發(fā)生改變的確切日期。該格式用的是絕對(duì)日期時(shí)
間（3.2節(jié)）。
Expires = "Expires" ":" HTTP-date
例如：
Expires: Thu, 01 Dec 1994 16:00:00 GMT
如果給定日期比日期標(biāo)題中的要早（或相同），接收方不應(yīng)緩存附加的實(shí)體。如果資源
是動(dòng)態(tài)自然生成的，象有些大量數(shù)據(jù)的處理，資源的實(shí)體應(yīng)當(dāng)被加上一個(gè)適當(dāng)?shù)倪^期時(shí)間值。
過期域并不能強(qiáng)制用戶代理對(duì)其進(jìn)行刷新或重新載入資源，它只用于緩存機(jī)制。當(dāng)對(duì)已
初始化過的資源發(fā)出新請(qǐng)求時(shí)，該機(jī)制才檢查該資源的過期狀態(tài)。
用戶代理通常都有歷史記錄機(jī)制，如“后退”按鈕和歷史記錄列表。該種機(jī)制可以用來
重新顯示某次對(duì)話（session）之前已經(jīng)獲取的實(shí)體信息。在缺省狀態(tài)下，過期域不對(duì)歷史機(jī)
制使用。除非用戶在配置用戶代理時(shí)指定了對(duì)歷史文件進(jìn)行過期刷新，否則，只要實(shí)體還保
存著，歷史機(jī)制就能顯示它，不論該實(shí)體是否已經(jīng)過期。
注意：應(yīng)用程序應(yīng)兼容對(duì)過期標(biāo)題非法或錯(cuò)誤的實(shí)現(xiàn)，如碰到0值或非法的日期格式，
應(yīng)用程序應(yīng)將其視為“立即過期（expires immediately）”。雖然這些值不符合HTTP/1.0，對(duì)
于一個(gè)健壯的應(yīng)用來說，還是必要的。
10.8 來自（From）
From請(qǐng)求標(biāo)題域，如果給出來，則應(yīng)包括一個(gè)使用此用戶代理的人類用戶的Internet
e-mail地址。該地址應(yīng)當(dāng)能被系統(tǒng)識(shí)別，就象RFC822[7]（已經(jīng)更新為RFC1123[6]）中的郵
箱定義一樣。
From = "From" ":" mailbox
例如：
From: webmaster@w3.org
該標(biāo)題域可能用來做為登錄目的使用，以確定對(duì)某資源的請(qǐng)求是否合法。它不應(yīng)用于不
安全的訪問保護(hù)。該域的解釋是，請(qǐng)求已按請(qǐng)求人指定的行為方式完成，而該請(qǐng)求人將為此
種方式負(fù)責(zé)。特殊情況下，機(jī)器人（robot）代理也應(yīng)包括此標(biāo)題域，域中注明是誰運(yùn)行它
的，這樣，當(dāng)接收端發(fā)生任何問題時(shí)，都可以同這個(gè)人取得聯(lián)系。
該域中的Internet e-mail地址可以與處理該請(qǐng)求的Internet主機(jī)分離。例如，當(dāng)請(qǐng)求通過
代理（proxy）時(shí)，應(yīng)使用原始的傳輸?shù)刂贰?br>注意：客戶端在沒有得到用戶批準(zhǔn)時(shí)，不應(yīng)發(fā)送From標(biāo)題域，因?yàn)檫@樣做可能會(huì)產(chǎn)生
用戶隱私及網(wǎng)站安全方面的問題。強(qiáng)烈建議在請(qǐng)求之前提供手段以禁止（disable）、允許
（enable）、修改（modify）該域的值。
10.9 從何時(shí)更改（If-Modified-Since）
If-Modified-Since請(qǐng)求標(biāo)題域和GET方法一起使用，用于處理下面情況：當(dāng)在該域指定
的日期以來，請(qǐng)求資源沒有發(fā)生任何變更。這時(shí)，服務(wù)器將不會(huì)下傳該資源的拷貝，即，回
應(yīng)不帶任何實(shí)體主體，只是304狀態(tài)碼（未修改）。
If-Modified-Since = "If-Modified-Since" ":" HTTP-date
例如：
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
條件GET方法可以請(qǐng)求服務(wù)端將在If-Modified-Since標(biāo)題域中的指定日期后發(fā)生變更
的指定資源下傳，也就是說，如果資源沒發(fā)生變化，就不下傳了。其算法如下：
a) 如果請(qǐng)求的回應(yīng)狀態(tài)不是200（成功）碼或它傳過來的If-Modified-Since中的
日期不合法，此時(shí)按照普通GET來回應(yīng)。如果日期比服務(wù)器的當(dāng)前時(shí)間還要
晚，則是非法時(shí)間。
b) 如果資源在If-Modified-Since日期以后有變化，回應(yīng)也和普通GET一樣
c) 如果資源在If-Modified-Since日期以后沒變化，服務(wù)器端將回應(yīng)304（未修改）。
注：該日期應(yīng)是合法的。
這樣做的目的是為了以最小的代價(jià)，對(duì)被緩存信息進(jìn)行有效更新。
10.10 最近更改（Last-Modified）
Last-Modified實(shí)體標(biāo)題域表示由發(fā)送方設(shè)定的資源最近修改日期及時(shí)間。該域的精確定
義在于接收方如何去解釋它：如果接收方已有此資源的拷貝，但此拷貝比Last-Modified域
所指定的要舊，該拷貝就是過期的。
Last-Modified = "Last-Modified" ":" HTTP-date
例如：
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
該標(biāo)題域的精確含義取決于發(fā)送方的執(zhí)行方式及原始資源的自然狀態(tài)。對(duì)于文件來說，
可能是它在文件系統(tǒng)的last-modified時(shí)間。對(duì)于包含多個(gè)組成部分的實(shí)體來說，可能是組成
部分中最新的last-modify時(shí)間。對(duì)數(shù)據(jù)庫網(wǎng)關(guān)來說，可能是記錄的last-update時(shí)間戳。對(duì)于
虛（virtual）對(duì)象來說，可能是內(nèi)部狀態(tài)的最近改變時(shí)間。
原始服務(wù)器不應(yīng)發(fā)送比服務(wù)器消息產(chǎn)生時(shí)間更晚的Last-Modified日期，因?yàn)樵撓?huì)
導(dǎo)致服務(wù)器在未來的某個(gè)時(shí)間內(nèi)，用消息原始的日期對(duì)該域值進(jìn)行再次更新。
10.11 位置（Location）
Location回應(yīng)標(biāo)題域定義了由請(qǐng)求URI指定的資源的位置。對(duì)于3xx（重定向）回應(yīng)，
位置域必須能幫助服務(wù)器找到相應(yīng)的URL，以實(shí)現(xiàn)對(duì)資源的重定向。只允許用絕對(duì)URL。
Location = "Location" ":" absoluteURI
例如：
Location: http://www.w3.org/hypertext/WWW/NewLocation.html
10.12 注解（Pragma）
Prama普通標(biāo)題域包括一些可能對(duì)請(qǐng)求/回應(yīng)鏈中的任一接收方有用的特殊指示信息。
從協(xié)議角度看，所有的注解指示了一些特定的可選行為，事實(shí)上，一些系統(tǒng)可能會(huì)要求行為
與指示一致。
Pragma = "Pragma" ":" 1#pragma-directive
pragma-directive = "no-cache" | extension-pragma
extension-pragma = token [ "=" word ]
當(dāng)"no-cache"出現(xiàn)在請(qǐng)求消息中時(shí)，應(yīng)用程序應(yīng)當(dāng)向原始服務(wù)器推送此請(qǐng)求，即使它已
經(jīng)在上次請(qǐng)求時(shí)已經(jīng)緩存了一份拷貝。這樣將保證客戶端能接收到最權(quán)威的回應(yīng)。它也用來
在客戶端發(fā)現(xiàn)其緩存中拷貝不可用或過期時(shí)，對(duì)拷貝進(jìn)行強(qiáng)制刷新。
不管注解（Pragma）指示信息對(duì)代理（proxy）及網(wǎng)關(guān)（gateway）應(yīng)用程序如何重要，
它必須能穿越這些應(yīng)用，因?yàn)樵撔畔⒖赡軐?duì)請(qǐng)求/回應(yīng)鏈上的其它接收方有用。實(shí)際上，如
果注解與某個(gè)接收方無關(guān)，它應(yīng)當(dāng)被該接收方忽略。
10.13 提交方（Referer）
提交方請(qǐng)求標(biāo)題域是出于服務(wù)器端利益方面的考慮，允許客戶端指明該鏈接的出處，即
該指向資源地址的請(qǐng)求URI是從哪里獲得的。這樣，服務(wù)器將產(chǎn)生一個(gè)備份鏈接（back-links）
列表，用于維護(hù)受歡迎的資源、登錄、緩存優(yōu)化等活動(dòng)。
Referer = "Referer" ":" ( absoluteURI | relativeURI )
例子：
Referer: http://www.w3.org/hypertext/DataSources/Overview.html
如果只給了部分URI，應(yīng)當(dāng)參照請(qǐng)求URI來解釋它。URI不能包括段（fragment）。
注意：因?yàn)殒溄拥脑a可能暴露一些隱私信息，因此強(qiáng)烈建議由用戶來決定是否發(fā)送
提交人域。例如，瀏覽器客戶端有個(gè)選項(xiàng)可以用來進(jìn)行離線瀏覽，可以使能或禁止提交人或
表單信息的發(fā)送。
10.14 服務(wù)器（Server）
服務(wù)器回應(yīng)標(biāo)題域包含由原始服務(wù)器用來處理請(qǐng)求的軟件信息。該域可包含多個(gè)產(chǎn)品標(biāo)
識(shí)（3.7節(jié)）及注釋以標(biāo)識(shí)服務(wù)器及重要的子產(chǎn)品。按照習(xí)慣，產(chǎn)品標(biāo)識(shí)將按其應(yīng)用的重要
順序排列。
Server = "Server" ":" 1*( product | comment )
例如：
Server: CERN/3.0 libwww/2.17
如果回應(yīng)要通過代理來推送，代理應(yīng)用程序不應(yīng)將它自己的數(shù)據(jù)加入產(chǎn)品列表。
注意：一些指定服務(wù)器軟件的版本有啟示作用，因?yàn)檫@些版本的軟件存在一些安全漏洞，
將使服務(wù)器更易受到攻擊。提倡服務(wù)器軟件在實(shí)現(xiàn)時(shí)，將此域變成可以進(jìn)行配置的選項(xiàng)。
注意：有些服務(wù)器不遵守服務(wù)器域產(chǎn)品標(biāo)識(shí)的語法約束。
10.15 用戶代理（User-Agent）
用戶代理請(qǐng)求標(biāo)題域包含用戶原始請(qǐng)求的信息，這可用于統(tǒng)計(jì)方面的用途。通過跟蹤協(xié)
議沖突、自動(dòng)識(shí)別用戶代理以避免特殊用戶代理的局限性，從而做到更好的回應(yīng)。雖然沒有
規(guī)定，用戶代理應(yīng)當(dāng)在請(qǐng)求中包括此域。該域可包含多個(gè)產(chǎn)品標(biāo)識(shí)（3.7節(jié)）及注釋以標(biāo)識(shí)
該代理及其重要的子產(chǎn)品。按照習(xí)慣，產(chǎn)品標(biāo)識(shí)將按子產(chǎn)品對(duì)應(yīng)用的重要性順序排列。
User-Agent = "User-Agent" ":" 1*( product | comment )
例如：
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
注意：現(xiàn)存有些代理應(yīng)用將它們的產(chǎn)品信息回到了用戶代理域中，這種方法不值得提倡，
因?yàn)檫@樣做會(huì)使機(jī)器在解釋這些信息時(shí)產(chǎn)生混淆。
注意：現(xiàn)在有些客戶端不遵守用戶代理域中產(chǎn)品標(biāo)識(shí)的語法約束。
10.16 WWW-授權(quán)（WWW-Authenticate）
WWW-授權(quán)回應(yīng)標(biāo)題域必須被包括在401（未授權(quán)）回應(yīng)消息中。該域值由一個(gè)以上的
challenge組成，這些challenge可用于指出請(qǐng)求URI的授權(quán)方案及參數(shù)。
WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
HTTP訪問授權(quán)處理在11節(jié)中描述。用戶代理在解析WWW-授權(quán)域值時(shí)要特別注意看
看它是否包含一個(gè)以上的待解決問題（challenge）或是否提供了一個(gè)以上的WWW-授權(quán)標(biāo)
題域，因?yàn)榇鉀Q問題（challenge）的內(nèi)容中可能包含用逗號(hào)分隔的授權(quán)參數(shù)列表。
11. 訪問鑒別（Access Authentication）
HTTP提供了一個(gè)簡(jiǎn)單的質(zhì)詢回應(yīng)（challenge-response）鑒別機(jī)制，可用于服務(wù)器通過
客戶端提供的授權(quán)信息來對(duì)其進(jìn)行身份鑒別。授權(quán)方案用可擴(kuò)展的、大小寫敏感的符號(hào)來標(biāo)
識(shí)，后跟獲取證明所需要的以逗號(hào)分隔的‘屬性－值’對(duì)。
auth-scheme = token
auth-param = token "=" quoted-string
原始服務(wù)器用401（未授權(quán)）回應(yīng)消息來質(zhì)詢用戶代理的授權(quán)。該回應(yīng)必須包括WWW-
授權(quán)標(biāo)題域，而該WWW-授權(quán)標(biāo)題域包括一個(gè)以上用于請(qǐng)求資源認(rèn)證的參數(shù)（challenge）。
challenge = auth-scheme 1*SP realm *( "," auth-param )
realm = "realm" "=" realm-value
realm-value = quoted-string
凡涉及到參數(shù)（challenge）處理的授權(quán)方案都有realm屬性（大小寫敏感）。與標(biāo)準(zhǔn)URL
（相對(duì)于被訪問服務(wù)器root）聯(lián)合使用的realm值（也是大小寫敏感）用來定義保護(hù)區(qū)域。
Realm使得服務(wù)器上的被保護(hù)資源被放在特殊的保護(hù)分區(qū)內(nèi)，這些區(qū)域都有各自的授權(quán)方案
和（或）授權(quán)數(shù)據(jù)庫。Relm值是個(gè)字符串，通常由原始服務(wù)器來分配，對(duì)于授權(quán)方案來說，
可能存在些附加的語法處理問題。
通常，用戶代理在收到401（未授權(quán)）回應(yīng)時(shí)，可能（也可能不會(huì)）希望服務(wù)器對(duì)其授
權(quán)。如果希望授權(quán)，用戶代理將在請(qǐng)求中加入授權(quán)請(qǐng)求標(biāo)題（Authorization request-header）
域。授權(quán)域值由信任證書組成，其中有對(duì)用戶代理所請(qǐng)求資源領(lǐng)域的授權(quán)信息。
credentials = basic-credentials
| ( auth-scheme #auth-param )
可由用戶代理通過信任方式來訪問的區(qū)域由保護(hù)區(qū)域決定。如果早先的請(qǐng)求已經(jīng)通過認(rèn)
證，在由授權(quán)方案，參數(shù)和（或）用戶選擇等所指定的時(shí)間間隔內(nèi)，其它的請(qǐng)求可通過相同
的信任來訪問該保護(hù)區(qū)域。
除非由授權(quán)另行指定，否則單個(gè)保護(hù)區(qū)域的范圍不能擴(kuò)展到服務(wù)器之外。
如果服務(wù)器不希望通過請(qǐng)求來接受信任，它應(yīng)當(dāng)返回403（禁止）回應(yīng)。
HTTP協(xié)議的訪問授權(quán)不限于這種簡(jiǎn)單的質(zhì)詢回應(yīng)（challenge-response）機(jī)制，還可以
使用其它的方法，比如傳輸級(jí)加密或消息封裝及通過附加標(biāo)題域來指定授權(quán)信息等等。但是，
這些方法不在本文檔的討論范圍。
代理必須完全透明地處理用戶授權(quán)，也就是說，它們必須在不做任何改動(dòng)的前提下將
WWW-授權(quán)及授權(quán)標(biāo)題向前推送，也不可以對(duì)包含授權(quán)的回應(yīng)進(jìn)行緩存。HTTP/1.0不為客
戶端提供通過代理方式授權(quán)的方法。
11.1 基本授權(quán)方案（Basic Authentication Scheme）
用戶代理必須對(duì)于每個(gè)領(lǐng)域（realm）通過用戶標(biāo)識(shí)（user-ID）及口令來對(duì)自身進(jìn)行授
權(quán)，這是基本授權(quán)方案的工作模式。Realm值應(yīng)當(dāng)被看作不透明的字符串，該值將用于同服
務(wù)器端其它的realm值相比較。只有用戶標(biāo)識(shí)及口令通過受保護(hù)資源的認(rèn)證，服務(wù)器才會(huì)給
請(qǐng)求授權(quán)。授權(quán)參數(shù)沒有可選項(xiàng)。
在接收到對(duì)受保護(hù)區(qū)域的未經(jīng)認(rèn)證的資源請(qǐng)求時(shí)，服務(wù)器應(yīng)當(dāng)回應(yīng)一個(gè)質(zhì)詢
（challenge），如下：
WWW-Authenticate: Basic realm="WallyWorld"
"WallyWorld"是由服務(wù)器分配的字符串，用于對(duì)請(qǐng)求URI所指定的受保護(hù)資源進(jìn)行標(biāo)
識(shí)。
為了接收授權(quán)，客戶端需要在基于64位（base64 [5]）的證書中發(fā)送用戶標(biāo)識(shí)及口令，
中間用冒號(hào)':'分隔。
basic-credentials = "Basic" SP basic-cookie
basic-cookie = <base64 [5] encoding of userid-password,
except not limited to 76 char/line>
userid-password = [ token ] ":" *TEXT
如果用戶代理希望發(fā)送用戶標(biāo)識(shí)"Aladdin"和口令“open sesame”，應(yīng)當(dāng)遵循下面的標(biāo)題
域形式：
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Basic授權(quán)方案是對(duì)HTTP服務(wù)器資源的非授權(quán)訪問進(jìn)行過濾的非安全方法。它基于假
定客戶端與服務(wù)器端的連接是安全的，為什么說是假定呢，因?yàn)樵趯?shí)際的開放性網(wǎng)絡(luò)中，使
用basic授權(quán)方案往往存在許多不安全的地方。盡管如此，客戶端仍然需要實(shí)現(xiàn)此方案，以
與采用此種方案的服務(wù)器進(jìn)行通訊。
12. 安全考慮（Security Considerations）
本節(jié)的描述對(duì)下面各角色有關(guān)：信息應(yīng)用開發(fā)者、信息提供者、HTTP/1.0中受安全性
限制的用戶。本節(jié)僅是討論安全問題，并對(duì)減少隱患提出了建議，但是并不提供對(duì)問題的最
終解決辦法。
12.1 客戶授權(quán)（Authentication of Clients）
正如11.1節(jié)中所述，基本授權(quán)（Basic authentication）方案不是安全的用戶授權(quán)方案，
也不能用它來防止實(shí)體主體源碼以文本方式在物理網(wǎng)絡(luò)中傳輸。HTTP/1.0并不反對(duì)在目前
日益突出的安全問題面前采用其它的授權(quán)方式及加密機(jī)制。
12.2 安全方法（Safe Methods）
客戶端軟件開發(fā)者應(yīng)當(dāng)注意，客戶端軟件代表用戶在Internet上與其它方面交互，并應(yīng)
注意避免讓用戶知道其間發(fā)生的具體動(dòng)作，這些動(dòng)作可能會(huì)暴露對(duì)交互各方有重要意義的信
息。
特別情況下，按協(xié)定來看，GET和HEAD方法應(yīng)被視作是安全的，同重新獲得數(shù)據(jù)應(yīng)
當(dāng)沒有什么不同。這就允許用戶代理采用其它方法，如POST，在某種情況下，可能存在這
樣一種情況，即請(qǐng)求中包含不安全的行為。
通常，服務(wù)器端在執(zhí)行過GET請(qǐng)求之后，其結(jié)果之類的副產(chǎn)品還殘留在服務(wù)器上；實(shí)
際上，一些動(dòng)態(tài)資源需要這種特性來實(shí)現(xiàn)。這里的重要區(qū)別在于用戶沒有請(qǐng)求這些副產(chǎn)品，
因而也不應(yīng)當(dāng)對(duì)這類請(qǐng)求進(jìn)行解釋。
12.3 服務(wù)器日志信息的弊端（Abuse of Server Log
Information）
服務(wù)器為保存與用戶請(qǐng)求相關(guān)的個(gè)人數(shù)據(jù)，如閱讀方式或感興趣的主題等提供了空間。
這些存儲(chǔ)信息顯然是受某些國家法律保護(hù)的，所以對(duì)此類數(shù)據(jù)的處理應(yīng)當(dāng)小心。用HTTP
協(xié)議提供數(shù)據(jù)的一方應(yīng)當(dāng)負(fù)責(zé)保證這些信息在未得各方許可之前不會(huì)散布出去。
12.4 敏感信息傳輸（Transfer of Sensitive Information）
與其它協(xié)議一樣，HTTP協(xié)議不能調(diào)整傳輸數(shù)據(jù)的內(nèi)容，也不存在未卜先知的方法，通
過給定請(qǐng)求的上下文信息片段就能推測(cè)出信息的敏感程度。因而，應(yīng)用程序應(yīng)當(dāng)盡可能像信
息提供方一樣，為該信息提供更多的控制。在此，有三個(gè)標(biāo)題域值得一提：服務(wù)端（Server）、
提交方（Referer）和來自（From）。
一些指定服務(wù)器軟件的版本有啟示作用，因?yàn)檫@些版本的軟件存在一些安全漏洞，將使
服務(wù)器更易受到攻擊。提倡服務(wù)器軟件在實(shí)現(xiàn)時(shí)，將Server標(biāo)題域變成可以進(jìn)行配置的選
項(xiàng)。
提交方（Referer）標(biāo)題域允許閱讀方式（reading patterns）被暴露，并可導(dǎo)出反向鏈接。
雖然該域很有用，但是如果包含在此域的用戶信息如果沒有被分開，則它的作用很可能被濫
用。另外，即使此域中用戶信息被清除，從該域的其它信息仍可推測(cè)出其私有文件的URI，
這可能是該信息發(fā)布者所不想看到的。
來自（From）標(biāo)題域可能包括一些與用戶私人隱私及站點(diǎn)安全相關(guān)的信息，因而，在
發(fā)送數(shù)據(jù)前，應(yīng)當(dāng)允許用戶使用一些設(shè)定手段，如禁止（disable）、允許（enable）、及修改
（modify），對(duì)此域信息進(jìn)行配置。用戶應(yīng)當(dāng)能夠根據(jù)他們的選擇或使用應(yīng)用程序提供的缺
省配置來設(shè)定此域的內(nèi)容。
我們建議，但不做要求：為用戶提供方便的界面來允許（enable）或禁止（disable）發(fā)
送From域或Referer域的信息。
12.5 基于文件及路徑名的攻擊（Attacks Based On File and
Path Names）
HTTP原始服務(wù)器的實(shí)現(xiàn)應(yīng)當(dāng)注意，要對(duì)以服務(wù)器管理員名義發(fā)出的，對(duì)某個(gè)文件的
HTTP請(qǐng)求進(jìn)行限制。如果HTTP服務(wù)器直接將HTTP URI發(fā)送給系統(tǒng)調(diào)用，服務(wù)器要特別
注意，當(dāng)某個(gè)請(qǐng)求文件不是發(fā)往HTTP客戶端時(shí)，要予以拒絕服務(wù)。例如，在Unix、Microsoft
Windows以及其它的操作系統(tǒng)使用".."做為上級(jí)目錄名。在這樣的系統(tǒng)下，HTTP服務(wù)器端
必須禁止通過使用這種結(jié)構(gòu)的請(qǐng)求URI來訪問HTTP服務(wù)器其它范圍的資源。同樣，服務(wù)
器端內(nèi)部使用的一些文件，包括訪問控制文件，配置文件、script代碼等，也要受到特別保
護(hù)，以避免被非法請(qǐng)求獲取，導(dǎo)致系統(tǒng)敏感信息暴露。實(shí)驗(yàn)證明，哪怕是最小的bug，也可
能導(dǎo)致嚴(yán)重的安全問題。
13. 感謝（Acknowledgments）
本文檔著重論述補(bǔ)充反饋方式（augmented BNF）及由David H. Crocker在RFC822[7]
中定義的一般結(jié)構(gòu)。同樣，它使用了許多由Nathaniel Borenstein和Ned Freed為MIME [5]
做的許多定義。我們希望通過它們來減少對(duì)HTTP/1.0及mail消息格式之間關(guān)系的混淆。
HTTP協(xié)議在過去四年中發(fā)展很快，它得益于龐大而活躍的開發(fā)團(tuán)體――是他們，這些
參與WWW討論郵件列表的人們，造就了HTTP在全球范圍內(nèi)的成功。Marc Andreessen，
Robert Cailliau， Daniel W. Connolly，Bob Denny，Jean-Francois Groff， Phillip M.
Hallam-Baker， Hakon W. Lie， Ari Luotonen，Rob McCool， Lou Montulli， Dave Raggett，
Tony Sanders，和Marc VanHeyningen，他們?yōu)楸疚臋n早期版本投入了巨大精力。Paul Hoffman
提供了關(guān)于信息狀態(tài)方面的信息，以及附錄C、D的內(nèi)容。
該文檔從HTTP-WG成員的評(píng)注中得益非淺。以下是對(duì)本規(guī)范做出貢獻(xiàn)的人們：
Gary Adams Harald Tveit Alvestrand
Keith Ball Brian Behlendorf
Paul Burchard Maurizio Codogno
Mike Cowlishaw Roman Czyborra
Michael A. Dolan John Franks
Jim Gettys Marc Hedlund
Koen Holtman Alex Hopmann
Bob Jernigan Shel Kaphan
Martijn Koster Dave Kristol
Daniel LaLiberte Paul Leach
Albert Lunde John C. Mallery
Larry Masinter Mitra
Jeffrey Mogul Gavin Nicol
Bill Perry Jeffrey Perry
Owen Rees Luigi Rizzo
David Robinson Marc Salomon
Rich Salz Jim Seidman
Chuck Shotton Eric W. Sink
Simon E. Spero Robert S. Thau
Francois Yergeau Mary Ellen Zurko
Jean-Philippe Martin-Flatin
14. 參考書目（References）
[1] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
Torrey, D., and B. Alberti, "The Internet Gopher Protocol: A
Distributed Document Search and Retrieval Protocol", RFC 1436,
University of Minnesota, March 1993.
[2] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
Unifying Syntax for the Expression of Names and Addresses of
Objects on the Network as used in the World-Wide Web",
RFC 1630, CERN, June 1994.
[3] Berners-Lee, T., and D. Connolly, "Hypertext Markup Language -
2.0", RFC 1866, MIT/W3C, November 1995.
[4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, CERN, Xerox PARC,
University of Minnesota, December 1994.
[5] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", RFC 1521, Bellcore,
Innosoft, September 1993.
[6] Braden, R., "Requirements for Internet hosts - Application and
Support", STD 3, RFC 1123, IETF, October 1989.
[7] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, August 1982.
[8] F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang,
J. Sui, and M. Grinbaum. "WAIS Interface Protocol Prototype
Functional Specification." (v1.5), Thinking Machines
Corporation, April 1990.
[9] Fielding, R., "Relative Uniform Resource Locators", RFC 1808,
UC Irvine, June 1995.
[10] Horton, M., and R. Adams, "Standard for interchange of USENET
Messages", RFC 1036 (Obsoletes RFC 850), AT&T Bell
Laboratories, Center for Seismic Studies, December 1987.
[11] Kantor, B., and P. Lapsley, "Network News Transfer Protocol:
A Proposed Standard for the Stream-Based Transmission of News",
RFC 977, UC San Diego, UC Berkeley, February 1986.
[12] Postel, J., "Simple Mail Transfer Protocol." STD 10, RFC 821,
USC/ISI, August 1982.
[13] Postel, J., "Media Type Registration Procedure." RFC 1590,
USC/ISI, March 1994.
[14] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
STD 9, RFC 959, USC/ISI, October 1985.
[15] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, USC/ISI, October 1994.
[16] Sollins, K., and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation,
December 1994.
[17] US-ASCII. Coded Character Set - 7-Bit American Standard Code
for Information Interchange. Standard ANSI X3.4-1986, ANSI,
1986.
[18] ISO-8859. International Standard -- Information Processing --
8-bit Single-Byte Coded Graphic Character Sets --
Part 1: Latin alphabet No. 1, ISO 8859-1:1987.
Part 2: Latin alphabet No. 2, ISO 8859-2, 1987.
Part 3: Latin alphabet No. 3, ISO 8859-3, 1988.
Part 4: Latin alphabet No. 4, ISO 8859-4, 1988.
Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988.
Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987.
Part 7: Latin/Greek alphabet, ISO 8859-7, 1987.
Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.
Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.
15. 作者地址（Authors' Addresses）
Tim Berners-Lee
Director, W3 Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.
Fax: +1 (617) 258 8682
EMail: timbl@w3.org
Roy T. Fielding
Department of Information and Computer Science
University of California
Irvine, CA 92717-3425, U.S.A.
Fax: +1 (714) 824-4056
EMail: fielding@ics.uci.edu
Henrik Frystyk Nielsen
W3 Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.
Fax: +1 (617) 258 8682
EMail: frystyk@w3.org
附錄（Appendices）
這些信息出現(xiàn)在附錄中僅有一個(gè)理由，即他們沒有成為HTTP/1.0規(guī)范的組成部分。
A. Internet介質(zhì)類型消息/http（Internet Media Type
message/http）
做為HTTP/1.0協(xié)議的補(bǔ)充，該文檔做為Internet介質(zhì)類型"message/http"的規(guī)范。下面
內(nèi)容被登記在IANA[13]中。
介質(zhì)類型名（Media Type name）： message
介質(zhì)子類型名（Media subtype name）： http
請(qǐng)求參數(shù)（Required parameters）： none
可選參數(shù)項(xiàng)（Optional parameters）： version, msgtype
版本（version）：附加消息的HTTP版本號(hào)，比如“1.0”。如果沒有給出，版
本可以從其主體的第一行中得到。
消息類型（msgtype）：消息類型――請(qǐng)求（request）或回應(yīng)（response）。如果
沒有給出，版本可以從其主體的第一行中得到。
編碼考慮（Encoding considerations）：只允許用"7bit", "8bit",或"binary" 。
安全考慮（Security considerations）： none
B. 容錯(cuò)應(yīng)用（Tolerant Applications）
雖然此文檔指明了產(chǎn)生HTTP/1.0消息的必要條件，并非所有的應(yīng)用程序都校正他們的
實(shí)現(xiàn)。因此，我們建議應(yīng)用程序增強(qiáng)其容錯(cuò)能力，以便在岐義仍可被明確解釋時(shí)，還能保證
正常運(yùn)行。
客戶端解析狀態(tài)行（Status-Line）及服務(wù)器解析請(qǐng)求行（Request-Line）時(shí)，應(yīng)當(dāng)做到容
錯(cuò)。特別是，即使只需要一個(gè)SP分隔的情況下，它們也可接受以任何數(shù)量的SP或HT字
符分隔的域。
HTTP標(biāo)題域的行終止符是順序字符CRLF。而我們建議應(yīng)用程序在解析這類標(biāo)題時(shí)，
也應(yīng)識(shí)別單個(gè)LF（沒有前面的CR）做為終止符情況。
C. 與MIME的關(guān)系（Relationship to MIME）
HTTP/1.0使用了許多為Internet Mail（RFC822[7]）及多用途Internet郵件擴(kuò)展
（Multipurpose Internet Mail Extensions）MIME[5]定義的結(jié)構(gòu)，以允許實(shí)體通過一種開放的
可擴(kuò)展的機(jī)制進(jìn)行傳輸。實(shí)際上，HTTP中有些特性與RFC1521中討論的郵件不同，這些
區(qū)別被用來優(yōu)化二進(jìn)制傳輸?shù)男阅埽o介質(zhì)類型的使用提供了更大的自由度，使日期比較變
得更加容易，當(dāng)然，這也是為了兼容早期的一些HTTP服務(wù)器及客戶端的應(yīng)用。
在寫作本文時(shí)，據(jù)說RFC1521將被修訂。修訂版本將會(huì)包括一些出現(xiàn)在HTTP/1.0中的
已有的應(yīng)用，但這些應(yīng)用在目前的RFC1521中尚未包括。
該附錄描述了HTTP與RFC1521中的不同之處。代理和網(wǎng)關(guān)在限制MIME環(huán)境時(shí)，應(yīng)
當(dāng)注意到這些區(qū)別，并在必須時(shí)提供相應(yīng)的轉(zhuǎn)換支持。從MIME到HTTP環(huán)境的代理和網(wǎng)
關(guān)也要注意這些區(qū)別，因?yàn)橐恍┺D(zhuǎn)換可能是必須的。
C.1 轉(zhuǎn)換為規(guī)范形式（Conversion to Canonical Form）
RFC1521要求Internet郵件實(shí)體在被傳輸前轉(zhuǎn)換成規(guī)范形式，正如RFC1521[5]附錄C
中所描述的那樣。本文檔中3.6.1節(jié)中描述了HTTP在傳輸時(shí)允許的“text”介質(zhì)類型的子類
型的具體形式。
RFC1521要求"text"的內(nèi)容類型（Content-Type）必須用CRLF作為行中斷符，禁止單獨(dú)
使用CR或LF。HTTP允許在HTTP傳輸時(shí)使用CRLF、單獨(dú)的CR或LF做為行中斷符。
只要有可能，HTTP環(huán)境或RFC1521環(huán)境下的代理或網(wǎng)關(guān)應(yīng)當(dāng)將本文檔3.6.1節(jié)中描述
的文本介質(zhì)類型中的所有行中斷符都轉(zhuǎn)換成CRLF。注意，由于存在著內(nèi)容編碼
（Content-Encoding）問題，以及HTTP允許使用多字符集，而其中的某些字符集不用字節(jié)
13和10做為CR和LF，這樣就使實(shí)際的處理更加復(fù)雜。
C.2 日期格式轉(zhuǎn)換（Conversion of Date Formats）
HTTP/1.0使用受限制的日期格式集（3.3節(jié)）以簡(jiǎn)化日期比較的處理。其它協(xié)議的代理
和網(wǎng)關(guān)應(yīng)當(dāng)保證消息中的任何日期標(biāo)題域與HTTP/1.0格式一致，否則，要對(duì)其進(jìn)行改寫。
C.3 內(nèi)容編碼介紹（Introduction of Content-Encoding）
RFC1521不包括殊如HTTP/1.0中內(nèi)容編碼標(biāo)題域之類的概念。由于內(nèi)容類型域是介質(zhì)
類型的修飾，因而從HTTP到MIME兼容協(xié)議中的代理和網(wǎng)關(guān)必須在將消息向前推送之前，
更改內(nèi)容類型標(biāo)題域（Content-Type）的值或者對(duì)實(shí)體主體（Entity-Body）進(jìn)行解碼（有些
Internet mail內(nèi)容類型的實(shí)驗(yàn)性應(yīng)用采用介質(zhì)類型參數(shù)為";conversions=<content-coding>"來
替代內(nèi)容解碼，而事實(shí)上，該參數(shù)并非RFC1521的組成部分）。
C.4 無內(nèi)容傳輸編碼（No Content-Transfer-Encoding）
HTTP不使用RFC1521的CTE（Content-Transfer-Encoding）域。與MIME協(xié)議兼容的
代理和網(wǎng)關(guān)在向HTTP客戶端傳遞回應(yīng)消息前都必須清除任何無標(biāo)識(shí)的CTE編碼
（"quoted-printable"或"base64"）。
從HTTP到MIME兼容協(xié)議的代理和網(wǎng)關(guān)要負(fù)責(zé)保證協(xié)議上消息格式正確及編碼傳輸
安全，所謂安全傳輸是指滿足對(duì)應(yīng)協(xié)議所規(guī)定的限制或約束標(biāo)準(zhǔn)。代理或網(wǎng)關(guān)應(yīng)當(dāng)用適當(dāng)?shù)?br>內(nèi)容傳輸編碼（Content-Transfer-Encoding）來標(biāo)識(shí)數(shù)據(jù)，以提高在目的協(xié)議上實(shí)現(xiàn)安全傳輸
的可能性。
C.5 多個(gè)主體的HTTP標(biāo)題域（HTTP Header Fields in
Multipart Body-Parts）
在RFC1521中，大多數(shù)多個(gè)主體組成的標(biāo)題域通常會(huì)被忽略，除非其域名以"Content-"開
頭。在HTTP/1.0中，多個(gè)主體部分（multipart body-parts）所包含的任何HTTP標(biāo)題域，只
對(duì)對(duì)應(yīng)的部分有意義。
D. 附加特性（Additional Features）
該附錄中包括的一些協(xié)議元素存在于一些HTTP實(shí)現(xiàn)中，但并非對(duì)所有的HTTP/1.0的
應(yīng)用都適用。開發(fā)者應(yīng)注意這些特性，但不能依賴它們來與其它的HTTP/1.0應(yīng)用程序進(jìn)行
交互。
D.1 附加請(qǐng)求方法（Additional Request Methods）
D.1.1 PUT
PUT方法請(qǐng)求服務(wù)器將附件的實(shí)體儲(chǔ)存在提供的請(qǐng)求URI處。如果該請(qǐng)求URI指向的
資源已經(jīng)存在，則附件實(shí)體應(yīng)被看做是當(dāng)前原始服務(wù)器上資源的修改版本。如果請(qǐng)求URI
沒有指向現(xiàn)存的資源，該URI將被該請(qǐng)求的用戶代理定義成為一個(gè)新的資源，原始服務(wù)器
將用該URI產(chǎn)生這個(gè)資源。
POST與PUT兩種請(qǐng)求的基本區(qū)別在于對(duì)請(qǐng)求URI的理解不同。在POST請(qǐng)求方法中
的URI所標(biāo)識(shí)的資源將做為附件實(shí)體被服務(wù)器處理，該資源可能是數(shù)據(jù)接收處理過程、某
些其它協(xié)議的網(wǎng)關(guān)、或可被注釋的單獨(dú)實(shí)體。與此相反，用戶代理很清楚它發(fā)出的PUT請(qǐng)
求中附帶URI所標(biāo)識(shí)的實(shí)體指向何處，而服務(wù)器處不應(yīng)將該請(qǐng)求用到其它資源頭上。
D.1.2 DELETE
DELETE方法請(qǐng)求原始服務(wù)器刪除由請(qǐng)求URI所指定的資源。
D.1.3 LINK
LINK方法建立與請(qǐng)求URI所指定資源或其它已存在資源之間的一個(gè)或多個(gè)連接關(guān)系。
D.1.4 UNLINK
UNLINK方法刪除與請(qǐng)求URI所指定資源之間的一個(gè)或多個(gè)連接關(guān)系。
D.2 附加標(biāo)題域定義（Additional Header Field Definitions）
D.2.1 Accept
Accept請(qǐng)求標(biāo)題域用于指示可被接受的請(qǐng)求回應(yīng)的介質(zhì)范圍列表。星號(hào)"*"用于按范圍
將介質(zhì)類型分組，用"*/*"指示可接受全部介質(zhì)類型；用"type/*"指示可接受type類型的所有
子類型。對(duì)于給定請(qǐng)求的上下文，客戶端應(yīng)當(dāng)表示出哪些類型是它可以接受的。
D.2.2 可接受的字體集（Accept-Charset）
Accept-Charset請(qǐng)求標(biāo)題域用來指示除了US-ASCII和ISO-8859-1外，首選的字符集。
該域?qū)⑹箍蛻舳擞心芰斫飧鼜V泛的或有特殊用途的字符集，從而在服務(wù)器上可以存放采用
此類字符集的文檔。
D.2.3 可接受編碼（Accept-Encoding）
Accept-Encoding請(qǐng)求標(biāo)題域與Accept相似，但是限制了回應(yīng)中可接受的內(nèi)容編碼
（content-coding）值。
D.2.4 可接受語言（Accept-Language）
Accept-Language請(qǐng)求標(biāo)題域與Accept相似，但限制了請(qǐng)求回應(yīng)中首選的自然語言集。
D.2.5 內(nèi)容語言（Content-Language）
Content-Language實(shí)體標(biāo)題域描述了附加實(shí)體中為聽眾指定的自然語言。注意，這可能
與在實(shí)體內(nèi)部使用的各種語言不是一碼事。
D.2.6 連接（Link）
Link實(shí)體標(biāo)題域描述了實(shí)體和某些其它資源之間的關(guān)系。一個(gè)實(shí)體可能包括多個(gè)連接
值。處于元信息級(jí)的Link指明了分層結(jié)構(gòu)和導(dǎo)航路徑之間的關(guān)系。
D.2.7 MIME版本（MIME-Version）
HTTP消息可能包括一個(gè)單獨(dú)的MIME版本的普通標(biāo)題（general-header）域，用以指示
用來構(gòu)造消息的MIME協(xié)議的版本。MIME版本標(biāo)題域的使用，正如RFC1521[5]中定義的
那樣，應(yīng)當(dāng)用來指示消息是否符合MIME規(guī)范。然而不幸的是，一些老的HTTP/1.0服務(wù)器
不加選擇地發(fā)送此域，導(dǎo)致此域已經(jīng)被廢棄。
D.2.8 在….后重試（Retry-After）
Retry-After回應(yīng)標(biāo)題域可與503（服務(wù)不可用）回應(yīng)一起使用，用于指示服務(wù)器停止響
應(yīng)客戶請(qǐng)求的時(shí)間長短。該域的值可用HTTP格式的日期表示，也可以用整數(shù)來表示回應(yīng)時(shí)
間后的秒數(shù)。
D.2.9 標(biāo)題（Title）
Title實(shí)體標(biāo)題域用于指示實(shí)體的標(biāo)題。
D.2.10 URI
URI實(shí)體標(biāo)題域可能包含一些或全部統(tǒng)一資源標(biāo)識(shí)（Uniform Resource Identifiers），見
3.2節(jié)，通過這些標(biāo)識(shí)來表示請(qǐng)求URI所指定的資源。并不擔(dān)保根據(jù)URI一定能夠找到指定
的資源。
RFC1945——Hyptertext Transfer Protocol – HTTP/1.0 超文本傳輸協(xié)議1.0
1