組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[email protected]
譯者：黃曉東（黃曉東 [email protected]）
譯文發佈時間：2001-7-14
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用於非商業用途自由轉載，但必須
保留本文檔的翻譯及版權信息。
Network Working Group T. Berners-Lee
Request for Comments: 1945 MIT/LCS
Category: Informational R. Fielding
UC Irvine
H. Frystyk
MIT/LCS
May 1996
超文本傳輸協議 -- HTTP/1.0
（Hyptertext Transfer Protocol – HTTP/1.0）
關於下段備忘（Status of This Memo）
本段文字爲Internet團體提供信息，並沒有以任何方式指定Internet標準。本段文字沒
有分發限制。
IESG提示（IESG Note）：
IESG已在關注此協議，並期待該文檔能儘快被標準跟蹤文檔所替代。
摘要（Abstract）
HTTP（Hypertext Transfer Protocol）是應用級協議，它適應了分佈式超媒體協作系統對
靈活性及速度的要求。它是一個一般的、無狀態的、基於對象的協議，通過對其請求方法
（request methods）進行擴展，可以被用於多種用途，比如命名服務器（name server）及分
布式對象管理系統。HTTP的一個特性是其數據表現類型允許系統的構建不再依賴於要傳輸
的數據。
HTTP自從1990年就在WWW上被廣泛使用。該規範反映了“HTTP/1.0”的普通用法。
目錄（Table of Contents）
1. 介紹（Introduction） 6
1.1 目的（Purpose） 6
1.2 術語（Terminology） 6
1.3 概述（Overall Operation） 8
1.4 HTTP and MIME 9
2. 標誌轉換及通用語法（Notational Conventions and Generic Grammar） 9
2.1 補充反饋方式（Augmented BNF） 9
2.2 基本規則（Basic Rules） 10
3. 協議參數（Protocol Parameters） 12
3.1 HTTP版本（HTTP Version） 12
3.2 統一資源標識（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 內容譯碼（Content Codings） 16
3.6 介質類型（Media Types） 17
3.6.1標準及文本缺省（Canonicalization and Text Defaults） 18
3.6.2 多部分類型（Multipart Types） 18
3.7 產品標識（Product Tokens） 19
4. HTTP 消息（HTTP Message） 19
4.1 消息類型（Message Types） 19
4.2 消息標題（Message Headers） 20
4.3 普通標題域（General Header Fields） 20
5. 請求（Request） 21
5.1 請求隊列（Request-Line） 21
5.1.1 方法（Method） 22
5.1.2 請求URI（Request-URI） 22
5.2 請求標題域（Request Header Fields） 23
6. 迴應（Response） 23
6.1 狀態行（Status-Line） 24
6.1.1 狀態代碼和原因分析（Status Code and Reason Phrase） 24
6.2 迴應標題域（Response Header Fields） 25
7. 實體（Entity） 26
7.1 實體標題域（Entity Header Fields） 26
7.2 實體主體（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. 狀態代碼定義（Status Code Definitions） 29
9.1 消息1xx（Informational 1xx） 29
9.2 成功2xx（Successful 2xx） 29
9.3 重定向（Redirection 3xx） 30
9.4 客戶端錯誤（Client Error ）4xx 31
9.5 服務器錯誤（Server Error ）5xx 32
10. 標題域定義（Header Field Definitions） 33
10.1 允許（Allow） 33
10.2 授權（Authorization） 34
10.3 內容編碼（Content-Encoding） 34
10.4 內容長度（Content-Length） 34
10.5 內容類型（Content-Type） 35
10.6 日期（Date） 35
10.7 過期（Expires） 36
10.8 來自（From） 37
10.9 從何時更改（If-Modified-Since） 37
10.10 最近更改（Last-Modified） 38
10.11 位置（Location） 38
10.12 註解（Pragma） 39
10.13 提交方（Referer） 39
10.14 服務器（Server） 40
10.15 用戶代理（User-Agent） 40
10.16 WWW-授權（WWW-Authenticate） 40
11. 訪問鑑別（Access Authentication） 41
11.1 基本授權方案（Basic Authentication Scheme） 42
12. 安全考慮（Security Considerations） 43
12.1 客戶授權（Authentication of Clients） 43
12.2 安全方法（Safe Methods） 43
12.3 服務器日誌信息的弊端（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介質類型消息/http（Internet Media Type message/http） 48
B. 容錯應用（Tolerant Applications） 48
C. 與MIME的關係（Relationship to MIME） 49
C.1 轉換爲規範形式（Conversion to Canonical Form） 49
C.2 日期格式轉換（Conversion of Date Formats） 49
C.3 內容編碼介紹（Introduction of Content-Encoding） 50
C.4 無內容傳輸編碼（No Content-Transfer-Encoding） 50
C.5 多個主體的HTTP標題域（HTTP Header Fields in Multipart Body-Parts）
50
D. 附加特性（Additional Features） 50
D.1 附加請求方法（Additional Request Methods） 51
D.2 附加標題域定義（Additional Header Field Definitions） 51
1. 介紹（Introduction）
1.1 目的（Purpose）
HTTP（Hypertext Transfer Protocol）是應用級協議，它適應了分佈式超媒體協作系統對
靈活性及速度的要求。它是一個一般的、無狀態的、基於對象的協議，通過對其請求方法
（request methods）進行擴展，可以被用於多種用途，比如命名服務器（name server）及分
布式對象管理系統。HTTP的一個特性是其數據表現類型允許系統的構建不再依賴於要傳輸
的數據。
HTTP自從1990年就在WWW上被廣泛使用。該規範反映了“HTTP/1.0”的普通用法。
該規範描述了在大多數HTTP/1.0客戶機及服務器上看起來已經實現的特性。規範將被
分成兩個部分：HTTP特性的實現是本文檔的主要內容，而其它不太通行的實現將被列在附
錄D中。
實用的信息系統需要更多的功能，而不僅僅是數據的獲取，包括搜索、前端更新及註解。
HTTP允許使用開放的命令集來表示請求的目的，它使用基於URI[2]（Uniform Resource
Identifier），即統一資源標識的規則來定位（URL[4]）或命名（URN[16]）方法所用到的資
源。HTTP使用與郵件（Internet Mail [7]）和MIME（Multipurpose Internet Mail Extensions [5]）
相似的格式來傳遞消息。
HTTP也作爲用戶代理、代理服務器/網關與其它Internet協議進行通訊的一般協議，這
些協議是，SMTP [12], NNTP [11], FTP [14], Gopher [1], and WAIS [8]等。HTTP允許不同的
應用可以進行基本的超媒體資源訪問，並簡化用戶代理的實現。
1.2 術語（Terminology）
本規範用了許多與參與方、對象及HTTP通訊相關的術語，如下：
連接（connection）
兩個應用程序以通訊爲目的在傳輸層建立虛擬電路。
消息（message）
HTTP通訊的基本單元，在連接中傳輸的結構化的、有順序的字節（其含義在第四
節中定義）。
請求（request）
HTTP的請求消息（在第五節定義）
迴應（response）
HTTP的迴應消息（在第六節定義）
資源（resource）
網絡上可以用URI來標識的數據對象或服務（見3.2節）
實體（entity）
可被附在請求或迴應消息中的特殊的表示法、數據資源的表示、服務資源的迴應等，
由實體標題（entity header）或實體主體（entity body）內容形式存在的元信息組成。
客戶端（client）
指以發出請求爲目的而建立連接的應用程序。
用戶代理（user agent）
指初始化請求的客戶端，如瀏覽器、編輯器、蜘蛛（web爬行機器人）或其它終端
用戶工具。
服務器（server）
指接受連接，並通過發送迴應來響應服務請求的應用程序。
原始服務器（origin server）
存放資源或產生資源的服務器。
代理（proxy）
同時扮演服務器及客戶端角色的中間程序，用來爲其它客戶產生請求。請求經過變
換，被傳遞到最終的目的服務器，在代理程序內部，請求或被處理，或被傳遞。代
理必須在消息轉發前對消息進行解釋，而且如有必要還得重寫消息。代理通常被用
作經過防火牆的客戶端出口，用以輔助處理用戶代理所沒實現的請求。
網關（gateway）
服務器之間的服務器。與代理不同，網關接受請求就好象它就是被請求資源所在的
原始服務器，發出請求的客戶端可能並沒有意識到它在與網關進行通訊。網關是網
絡防火牆服務器端的門戶。對非HTTP系統資源進行訪問時，網關做爲中間的協議
翻譯者。
隧道（tunnel）
隧道就好象連接兩端看不見的中繼器。處於激活狀態時，它雖然是由HTTP請求來
初始化的，但它並不參與HTTP通訊。當需要中繼連接的兩端關閉後，隧道也自然
終止。在入口有需求及中間程序無法或不該解釋要中繼的通訊時，通常要用到隧道
技術。
緩存（cache）
指程序本地存儲的迴應消息和用來控制消息存儲、重獲、刪除的子系統。
緩存迴應的目的是爲減少請求迴應時間，以及未來一段時間對網絡帶寬的消耗。任
何客戶端及服務端都可以包含緩存。服務器在以隧道方式工作時不能使用緩存。
任何指定的程序都有能力同時做爲客戶端和服務器。我們在使用這個概念時，不是看程
序功能上是否能實現客戶及服務器，而是看程序在特定連接時段上扮演何種角色（客戶或服
務器）。同樣，任何服務器可以扮演原始服務器、代理、網關、隧道等角色，行爲的切換取
決於每次請求的內容。
1.3 概述（Overall Operation）
HTTP協議是基於請求/迴應機制的。客戶端與服務器端建立連接後，以請求方法、URI、
協議版本等方式向服務器端發出請求，該請求可跟隨包含請求修飾符、客戶信息、及可能的
請求體（body）內容的MIME類型消息。
服務器端通過狀態隊列（status line）來回應，內容包括消息的協議版本、成功或錯誤代
碼，也跟隨着包含服務器信息、實體元信息及實體內容的MIME類型消息。
絕大多數HTTP通訊由用戶代理進行初始化，並通過它來組裝請求以獲取存儲在一些原
始服務器上的資源。在最簡單的情況下，通過用戶代理（UA）與原始服務器（O）之間一
個簡單的連接（v）就可以完成。
request chain ------------------------>
UA -------------------v------------------- O
<----------------------- response chain
更復雜的情況是當請求/迴應鏈之間存在一個或更多中間環節。總體看來，有三種中間
環節：代理（proxy）、網關（gateway）、隧道（tunnel）。
代理（proxy）是向前推送的代理人（agent），它以絕對形式接收URI請求，重寫全部
或部分消息，並將經過改寫的請求繼續向URI中指定的服務器處推送。
網關是接收代理，它處於服務器層之上，在必要時候，它用服務器可識別的協議來傳遞
請求。
隧道不改變消息，它只是連接兩端的中繼點。在有中間層（如防火牆）或中間層無法解
析消息內容的情況下，需要靠隧道技術來幫助通訊穿越中間層。
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- response chain
上面的圖形表示在用戶代理和原始服務器之間有三個中間層（A，B和C）。由圖可見，
請求或迴應消息在整個信息鏈上運行需要通過四個單獨的連接，它與在此之前介紹的簡單情
況是有區別的，而且此區別是十分重要的。因爲HTTP通訊選項可以設置成幾種情況，如只
與最近的非隧道鄰居連接、只與信息鏈末端連接、或者可與鏈中全部環節連接等等。雖然上
面的圖是線性的，而實際上每個參與環節都在同時與多方進行通訊活動。例如，B在接受除
A之外其它客戶端請求的同時，向除C之外的其它服務器推送請求，在這個時刻，它可能
接受到A的請求，並給予處理。
參與通訊的任何一方如果沒有以隧道方式進行工作，必須要藉助內部緩存機制來處理請
求，如果鏈上某個參與方碰巧緩存了某個請求的迴應，那就相應於縮短了請求/迴應鏈。下
面的圖例演示了當B緩存了從O經由C過來的迴應信息，而UA和A沒緩存的情況：
request chain ---------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
<--------- response chain
並非所有的迴應都可以被緩存，某些請求所包含的修飾符中可能對緩存行爲進行了特別
指明。一些基於HTTP/1.0的應用使用了啓發式的方法來描述哪些迴應可被緩存，而哪些則
不可以，但遺憾的是，這些規則並沒有形成標準。
在Internet上，HTTP通訊往往基於TCP/IP的連接方式。缺省的端口是TCP 80[15]口，
但也可以使用其它端口。並不排除基於Ineternet上的其它協議或網絡協議的HTTP實現方
式，HTTP只是假定傳輸是可靠的，因而任何能提供這種保證的協議都可以被使用。至於
HTTP/1.0請求和迴應在數據傳輸過程中的數據結構問題，不在本文討論範圍之內。
實驗室應用除外，當前的做法是客戶端在每次請求之前建立連接，而服務器端在發送回
應後關閉此連接。不管客戶端還是服務器端都應注意處理突發的連接中斷，因爲雙方都有可
能因爲用戶操作、自動超時、程序失敗等原因關閉與對方的連接。在這種情況下，不管請求
處於什麼樣的狀緄シ交蛩酵憊乇樟櫻薊岬賈碌鼻暗那肭蟊恢罩埂?
1.4 HTTP and MIME
HTTP/1.0使用了多種結構來定義MIME，詳見RFC1521[5]。附錄C描述了Internet承
認的Internet介質類型與mail介質類型的不同工作方式，並給出二者區別的基本解釋。
2. 標誌轉換及通用語法（Notational Conventions and
Generic Grammar）
2.1 補充反饋方式（Augmented BNF）
與RFC822[7]很類似，本文對所有機制的說明都是以散文和補充反饋的方式來描述的。
對於實現者來說，要想理解這些約定，必須對這些符號很熟悉。補充反饋方式（augmented
BNF）包括下面的結構：
要解釋的名詞＝名詞解釋（name = definition）
規則的名字（name）就是它本身（不帶任何尖括號，“<”，“>”），後面跟個等號＝，
然後就是該規則的定義。如果規則需要用多個行來描述，利用空格進行縮進格式排
版。某些基本的規則使用大寫，如SP, LWS, HT, CRLF, DIGIT, ALPHA,等等。定義
中還可以使用尖括號來幫助理解規則名的使用。
字面意思（"literal"）
文字的字面意思放在引號中間，除非特別指定，該段文字是大小寫敏感的。
規則1｜規則2（rule1 | rule2）
“｜”表示其分隔的元素是可選的，比如，“是｜否”要選擇‘是’或‘否’。
（規則1 規則2）（(rule1 rule2)）
在圓括號中的元素表明必選其一。如（元素1（元素2｜元素3）元素4）可表明兩
種意思，即“元素1 元素2 元素4”和“元素1 元素3 元素4”
*規則（*rule）
在元素前加星號“*”表示循環，其完整形式是“<n>*<m>元素”，表明元素最少產
生<n>次，最多<m>次。缺省值是0到無限，例如，“1*元素”意思是至少有一個，
而“1*2元素”表明允許有1個或2個。
［規則］（[rule]）
方括號內是可選元素。如“［元素1 元素2］”與“*1（元素1 元素2）”是一回
事。
N 規則（N rule）
表明循環的次數：“<n>（元素）”就是“<n>*<n>（元素）”，也就是精確指出<n>
取值。因而，2DIGIT 就是2位數字, 3ALPHA 就是由三個字母組成字符串。
＃規則（#rule）
“#”與“*”類似，用於定義元素列表。
完整形式是“<n>#<m>元素”表示至少有<n>個至多有<m>個元素，中間用“,”或
任意數量的空格（LWS-linear whitespace）來分隔，這將使列表非常方便，如“（*LWS
元素 *（ *LWS "," *LWS 元素 ））”就等同於“1#元素”。
空元素在結構中可被任意使用，但不參與元素個數的計數。也就是說，“（元素1），，
（元素2）”僅表示2個元素。但在結構中，應至少有一個非空的元素存在。缺省
值是0到無限，即“#（元素）”表示可取任何數值，包括0；而“1#元素”表示至
少有1個；而“1#2元素”表示有1個或2個。
；註釋（; comment）
分號後面是註釋，僅在單行使用。
隱含*LWS（implied *LWS）
本文的語法描述是基於單詞的。除非另有指定，線性空格（LWS）可以兩個鄰近符
號或分隔符（tspecials）之間任意使用，而不會對整句的意思造成影響。在兩個符號之
間必須有至少一個分隔符，因爲它們也要做爲單獨的符號來解釋。實際上，應用程序在
產生HTTP結構時，應當試圖遵照“通常方式”，因爲現在的確有些實現方式在通常方
式下無法正常工作。
2.2 基本規則（Basic Rules）
下面的規則將用於本文後面對結構基本解析。
US-ASCII 編碼字符集定義[17]。
OCTET = <8-bit的順序數據，即bytes>
CHAR = < US-ASCII字符（取值爲0 – 127的OCTET）>
UPALPHA = < US-ASCII 大寫字符"A"到"Z">
LOALPHA = <US-ASCII 小寫字符"a"到"z">
ALPHA = UPALPHA | LOALPHA
DIGIT = < US-ASCII 數字"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 雙引號標記double-quote mark （34）>
HTTP/1.0規定，除實體主體（Entity-Body，見附錄B容錯應用）外，所有協議元
素的行結束標誌都是CRLF（按字節順序）。在實體主體內部的行結束標誌定義及
其對應的介質類型定義，見3.6節的描述。
CRLF = CR LF
HTTP/1.0的頭可以折成許多行，只要每個後續行以空格或水平製表符開頭。所有
的線性空格（LWS），同空格（SP）有相同的語義。
LWS = [CRLF] 1*( SP | HT )
實際上，有些應用並沒有考慮處理這樣多行的頭，所以從兼容性上考慮，HTTP/1.0
應用最好不要產生折成多行的頭。
TEXT規則只是用於描述消息解釋器不關心的域的內容及其取值。文本內容可包含
不同於US-ASCII的字符。
TEXT = <除了控制字符（CTLs）之外的任何OCTET，包括LWS >
在標題域中的收件人域如包含US-ASCII字符集以外的字符，這些字符將按照
ISO-8859-1標準來解釋。
十六進制數字型字符在幾個協議元素中到。
HEX = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
許多HTTP/1.0頭域的內容由被LWS分隔的單詞或特殊字符組成，這些特殊字符
必須置於引號中間的字符串內，作爲參數值使用。
Word = 符號（token）| 被引號引起來的字符串
token = 1*<除控制字符（CTLs）或tspecials之外的任意字符>
tspecials = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "/" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
在HTTP頭域中可用括號表示註釋文字。註釋只允許寫在包含註釋的域，做爲域值
定義的一部分。在除此之外其它域中，括號將被視爲域值。
comment = "(" *( ctext | comment ) ")"
ctext = <除圓括號外的任何TEXT>
被雙引號圈中的文本字符串將被視爲一個單詞。
quoted-string = ( <"> *(qdtext) <"> )
qdtext = <除了雙引號及控制字符之外的任何字符，包括LWS >
在HTTP/1.0中不允許使用後斜線“/”來引用單字符。
3. 協議參數（Protocol Parameters）
3.1 HTTP版本（HTTP Version）
HTTP採用主從（<major>.<minor>）數字形式來表示版本。協議的版本政策傾向於讓發
送方表明其消息的格式及功能，而不僅僅爲了獲得通訊的特性，這樣做的目的是爲了與更高
版本的HTTP實現通訊。只增加擴展域的值或增加了不影響通訊行爲的消息組件都不會導致
版本數據的變化。當協議消息的主要解析算法沒變，而消息語法及發送方的隱含功能增加了，
將會導致從版本號（<minor>）增加；當協議中消息的格式變化了，主版本號（<major>）也
將發生改變。
HTTP消息的版本由消息第一行中的HTTP版本域來表示。如果消息中的協議版本沒有
指定，接收方必須假定它是符合HTTP/0.9的簡單標準。
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
注意，主從版本應當被看作單獨的整數，因爲它們都有可能增加，從而超過一位整
數。因而，HTTP/2.4比HTTP/2.13版本低，而HTTP/2.13又比HTTP/12.3版本低。
版本號前面的0將被接收方忽略，而在發送方處也不應產生。
本文檔定義了HTTP協議的0.9及1.0版本。發送完整請求（Full-Request）及完整
迴應（Full-Response）消息的應用必須指明HTTP的版本爲“HTTP/1.0”。
HTTP/1.0服務器必須：
o識別HTTP/0.9及HTTP/1.0請求命令中的請求隊列（Request-Line）的格式。
o理解任何HTTP/0.9及HTTP/1.0中的合法請求格式。
o 使用與客戶端相同版本的協議進行消息迴應。
HTTP/1.0 客戶端必須：
o 識別HTTP/1.0迴應中狀態隊列（Status-Line）的格式。
o 理解HTTP/0.9及HTTP/1.0中合法迴應的格式。
當代理及網關收到與其自身版本不同的HTTP請求時，必須小心處理請求的推送，因爲
協議版本表明發送方的能力，代理或網關不應發出高於自身版本的消息。如果收到高版本的
請求，代理或網關必須降低該請求的版本，並回應一個錯誤。而低版本的請求也應在被推送
前升級。
代理或網關回應請求時必須遵照前面列出的規定。
3.2 統一資源標識（Uniform Resource Identifiers）
URI有許多名字，如WWW地址、通用文件標識（Universal Document Identifiers）、通
用資源標識（Universal Resource Identifiers [2]），以及最終的統一資源定位符（Uniform
Resource Locators (URL) [4]）和統一資源名（URN）。在涉及HTTP以前，URI用簡單格式
的字符串描述－名字、位置、或其它特性，如網絡資源。
3.2.1 一般語法（General Syntax）
在HTTP中URI可以用絕對形式表示，也可用相對於某一基本URI[9]的形式表示，具
體取決於它們的使用方式。這兩種形式的不同在於絕對URI總是以方法名稱後跟“：”開頭。
URI = ( absoluteURI | relativeURI ) [ "#" fragment ]
absoluteURI = scheme ":" *( uchar | reserved )
relativeURI = net_path | abs_path | rel_path
net_path = "//" 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>
權威的URL語法及語義信息請參見RFC1738[4]和RFC1808[9]。上面所提到的BNF中
包括了合法URL中不允許出現的符號（RFC1738），因爲HTTP服務器並沒有限制爲只能用
非保留字符集中的字符來表示地址路徑，而且HTTP代理也可能接收到RFC1738沒有定義
的URI請求。
3.2.2 http URL
“http”表示要通過HTTP協議來定位網絡資源。本節定義了HTTP URL的語法和語義。
http_URL = "http:" "//" host [ ":" port ] [ abs_path ]
host = <合法的Internet主機域名或IP地址（用十進制數及點組成）
，見RFC1123，2.1節定義>
port = *DIGIT
如是端口爲空或沒指定，則缺省爲80端口。對於絕對路徑的URI來說，擁有被請求的
資源的服務器主機通過偵聽該端口的TCP連接來接收該URI請求。如果URL中沒有給出
絕對路徑，要作爲請求URI（參見5.1.2節）使用，必須以“/”形式給出。
注意：雖然HTTP協議獨立於傳輸層協議，http URL只是標識資源的TCP位置，而對
於非TCP資源來說，必須用其它的URI形式來標識。
規範的HTTP URL形式可通過將主機中的大寫字符轉換成小寫（主機名是大小寫敏感
的）來獲得。如果端口是80，去掉冒號及端口號，並將空路徑替換成“/”。
3.3 Date/Time 格式（Date/Time Formats）
出於歷史原因，HTTP/1.0應用允許三種格式來表示時間戳：
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標準格式，表示方法長度固定（RFC1123[6]）。第二種格
式在普通情況下使用，但是它是基於已經廢棄的RFC850[10]中的日期格式，而且年不是用
四位數字表示的。HTTP/1.0 客戶端及服務器端在解析日期時可識別全部三種格式，但是它
們不可以產生第三種時間格式(asctime) 。
注意：對於接收到由非HTTP應用產生的日期數據時，提倡對接收到的日期值進行填充。
這樣做是因爲，在某些時候，代理或網關可能通過SMTP或NNTP來獲取或發送消息。
所有的HTTP/1.0 date/timp時間戳必須用世界時間（Universal Time，UT），即格林威治
時間來表示（Greenwich Mean Time，GMT），沒有任何修改的餘地。前面的兩種格式用了
“GMT”表示時區，在讀ASC表示的時間時，也應假定是這個時區。
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要求只能在協議流中使用data/time時間戳格式，不要求客戶端及服務
器端在用戶描述、請求登錄等情況下使用這類格式。
3.4 字符集（Character Sets）
HTTP所使用的字符集定義和描述MIME時用的相同：
本文檔用字符集（character set）來指明利用一個或多個表將順序字節轉換成順序字
符的方法。注意，不需要其它方向的無條件轉換，因爲不是所有的字符都可以用給
定字符集來表示，同時，一個字符集也可能提供一種以上的字節順序來表示一種特
殊的字符。這種定義傾向於允許不同類型的字符編碼通過簡單的單表映射來實現，
如，從表US-ASCII切換到複雜表如ISO2202。實際上，與MIME字符集名相關的
定義必須完整指定從字節到字符的映射，特別是不允許通過利用外部配置信息來確
定精確的映射。
注意：術語字符集（character set）歸於字符編碼（character encoding）。事實上，
由於HTTP與MIME共同使用同樣的註冊，所以其術語也應一致。
HTTP字符集由大小寫敏感的符號組成。全部的符號定義參見IANA字符集註冊
[15]。因爲註冊處不會爲每個字符集單獨定義一套符號，所以我們在這看到的字符
集名大多是與HTTP實體使用相關的。這些在RFC 1521 [5] 中註冊的字符集，即
US-ASCII [17] 及ISO-8859 [18]字符集，還有一些其它字符集被強烈建議在MIME
字符集參數內部使用。
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允許使用專用符號做爲字符集值，但是任何在IANA字符集註冊表[15]
中有預定義值的符號都必須表明其所屬的字符集。應用應當將其對字符集的使用限
制在IANA註冊表規定的範圍之內。
實體主體的字符集如果屬於US-ASCII 或ISO-8859-1字符集，則勿需標記，否則，
應當用主體字符編碼方式中的最基本命名來標記。
3.5 內容譯碼（Content Codings）
內容譯碼值用於指示對資源進行的編碼轉換。內容譯碼主要用於將經過壓縮、加密等操
作的文件進行還原，使其保持其原來的介質類型。典型情況下，經過編碼保存的資源只能經
過解碼或類似的操作才能還原。
content-coding = "x-gzip" | "x-compress" | token
注意：出於對未來兼容性的考慮，HTTP/1.0應用應將"gzip" 和"compress" 分別與
"x-gzip"和"x-compress"對應起來。
所有的內容譯碼值都是大小寫敏感的。HTTP/1.0在內容編碼（10.3節）頭域中使用內
容譯碼值。雖然該值描述的是內容譯碼，但更爲重要的是，它指明瞭應當用什麼機制來進行
解碼。注意，單獨的程序可能有能力實現對多種格式編碼的解碼。
在這段文字中，提到了兩個值：
x-gzip
文件壓縮程序"gzip" (GNU zip，由Jean-loup Gailly開發)的編碼格式。該格式屬於
典型的帶有32位CRC 校驗的Lempel-Ziv譯碼 (LZ77)。
x-compress
文件壓縮程序"compress"的編碼格式，該格式適用於LZW（Lempel-Ziv-Welch）譯
碼。
注意：用程序名來標識編碼格式的做法不是很理想，在將來可能不會繼續這樣做。現在
之所以這樣做是出於歷史的原因，並非良好的設計。
3.6 介質類型（Media Types）
HTTP在Content-Type header域（10.5節）中使用Internet介質類型[13]，用以提供開放
的可擴展的數據類型。
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
參數可參照屬性/值對的方式，用類型/子類型的格式來寫。
Parameter = attribute "=" value
Attribute = token
Value = token | quoted-string
其中，類型、子類型、參數屬性名是大小寫敏感的。而參數值不一定是大小寫敏感的，
這得看參數名的語法而定。在類型和子類型、屬性名和屬性值之間不能有LWS（空格）。當
接收到不能識別的介質類型的參數時，用戶代理應當忽略它們。
一些老的HTTP應用不能識別介質類型參數，所以HTTP/1.0的應用程序只能在定義消
息內容時使用介質參數。
介質參數（Media-type）值用Internet授權分配數字（Internet Assigned Number
Authority ，IANA [15]）註冊。介質類型註冊過程請參見RFC1590[13]。不鼓勵使用未註冊
的介質類型。
3.6.1標準及文本缺省（Canonicalization and Text Defaults）
Internet介質類型是用規範形式註冊的。一般來說，在通過HTTP協議傳輸實體主體
（Entity-Body）之前，必須先將其表示成適當的規範格式。如果主體用使用了一種
Content-Encoding進行編碼，下面的數據在編碼前必須轉換成規範形式：
"text"類型的介質子類型在規範形式中使用CRLF做爲文本行中斷。實際上，爲和實體
主體（Entity body）內的使用方式保持一致，HTTP允許傳輸純以CR或LF單獨表示行中斷
的文本介質。HTTP應用程序必須將其通過HTTP方式接收到的文本介質中的CRLF、CR、
LF看做是行中斷符。
另外，如果文本介質的字符集沒有使用字節13和10做爲CR和LF，象一些多字節字
符集，HTTP允許使用該字符集指定的任何順序的字節替代CR和LF做爲行中斷，這種行
中斷的靈活運用方式僅可於實體主體（Entity-Body）中。一個純CR或LF不應在任何HTTP
控制結構（如標題域-header field和多塊分界線-multipart boundaries）中替代CRLF。
參數"charset"在定義數據的字符集（3.4節）時，與一些介質類型一起使用。當發送方
沒有顯式給出字符參數時，HTTP在接收時將"text"的介質子類型定義爲缺省
值"ISO-8859-1"。"ISO-8859-1"字符集或其子集以外的數據必須要標記其相應的字符集值，
這樣可以保證接收方能正確地對其進行解析。
注意：許多當前HTTP服務器提供的數據使用"ISO-8859-1"以外的其它字符集，而且也
沒有正確的進行標記，這種工作方式限制了互操作性，建議不要採用。做爲一種補救方法，
一些HTTP用戶代理提供了配置選項，使用戶可以在字符集參數沒指定的情況下，自行更改
缺省的介質類型解釋方式。
3.6.2 多部分類型（Multipart Types）
MIME提供了多部分（"multipart"）類型的數字――在一個單獨的消息實體主體
（Entity-Body）內可以封裝幾個實體（entities）。雖然用戶代理可能需要了解每種類型，從
而可以正確解釋每部分主體的意圖，但是在IANA[15]的多部分類型（multipart types）註冊
中卻找不到專爲HTTP/1.0所指定的內容。HTTP用戶代理只得自己來做接收多部分類型的
工作，其過程和行爲與MIME用戶代理是相同或相似的。HTTP服務器不應假定HTTP客戶
端都有能力處理多部分類型。
所有的多部分類型都使用通用的語法，而且必須在介質類型值部分包括邊界參數
（boundary parameter）。消息的主體是其自身，做爲協議元素，它必須只使用CRLF做爲段
間（body-parts）的行中斷符。多段主體（Multipart body-parts）中可能包括對各段有重要意
義的HTTP標題域。
3.7 產品標識（Product Tokens）
是通訊應用程序用來標識其自身的一個簡單符號，常和任意字母及版本描述一起使用。
大多數產品標識也將其產品的重要組成部分的版本號一起列出，中間用空格分隔。
按慣例，在標識應用程序時，組件以其重要性順序排列。
Product = token ["/" product-version]
product-version = token
例如：
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
產品標識應當短小，因而禁止利用該域填寫廣告或其它無關信息。雖然任何符號字符都
可能出現在產品版本中，該符號應當只用於做版本定義，也就是說，同一個產品的連續版本
之間只能通過產品版本值進行區分。
4. HTTP 消息（HTTP Message）
4.1 消息類型（Message Types）
HTTP消息由客戶端到服務器的請求和由服務器到客戶端的迴應組成。
HTTP-message = Simple-Request ; HTTP/0.9 messages
| Simple-Response
| Full-Request ; HTTP/1.0 messages
| Full-Response
完整的請求（Full-Request）和完整的迴應（Full-Response）都使用RFC822[7]中實體傳
輸部分規定的消息格式。兩者的消息都可能包括標題域（headers，可選）、實體主體（entity
body）。實體主體與標題間通過空行來分隔（即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
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
簡單請求（Simple_Request）與簡單迴應（Simple-Response）不允許使用任何標題信息，
並限制只能使用唯一的請求方法（GET）
Simple-Request = "GET" SP Request-URI CRLF
Simple-Response = [ Entity-Body ]
不提倡使用簡單方式請求格式，因爲它防止了服務器在接到簡單請求時對返回實體的介
質類型進行驗證。
4.2 消息標題（Message Headers）
HTTP標題域，包括主標題（General-Header,4.3節）、請求標題（Request-Header ,5.2節）、
迴應標題（Response-Header ,6.2節）及實體標題（Entity-Header,7.1節），都遵照RFC822-3.1
節[7]給出的通用格式定義。每個標題域由後緊跟冒號的名字，單空格（SP），字符及域值組
成。域名是大小寫敏感的。雖然不提倡，標題域還是可以擴展成多行使用，只要這些行以一
個以上的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>
標題域接收的順序並不重要，但良好的習慣是，先發送主標題，然後是請求標題或迴應
標題，最後是實體標題。
當且僅當標題域的全部域值都用逗號分隔的列表示時（即，#（值）），多個有相同域名
的HTTP標題域纔可以表示在一個消息裏。而且必須能在不改變消息語法的前提下，將併發
的域值加到第一個值後面，之間用逗號分隔，最終能將多個標題域結合成“域名：域值”對。
4.3 普通標題域（General Header Fields）
有幾種標題域是請求與迴應都要使用的，但並不用於被傳輸的實體。這些標題只用於被
傳輸的消息。
General-Header = Date ; Section 10.6
| Pragma ; Section 10.12
普通標題域名稱只有在與協議版本的變化結合起來後，才能進行可靠的擴展。實際上，
新的或實驗中的標題域只要能被通訊各方識別，其語法就可使用，而無法識別的標題域都將
被視爲實體域。
5. 請求（Request）
從客戶端到服務器端的請求消息包括，消息首行中，對資源的請求方法、資源的標識符
及使用的協議。考慮到侷限性更大的HTTP/0.9的向後兼容問題，有兩種合法的HTTP請求
格式：
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服務器收到簡單請求，它必須迴應一個HTTP/0.9格式的簡單迴應。
HTTP/1.0的客戶端有能力接收完整迴應，但不能產生簡單請求。
5.1 請求隊列（Request-Line）
請求隊列以一個方法符號開頭，跟在請求URI及協議版本的後面，以CRLF爲結尾。
該元素用空格SP分隔。除了最後的CRLF，不允許出現單獨的CR或LF符。
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
注意，簡單請求與完整請求的請求隊列之間的區別在於是否有HTTP版本域和是否可以
使用除GET以外的其它方法。
5.1.1 方法（Method）
方法代號指明瞭將要以何種方式來訪問由請求URI指定的資源。方法是大小寫敏感的。
Method = "GET" ; Section 8.1
|"HEAD" ; Section 8.2
| "POST" ; Section 8.3
| extension-method
extension-method = token
可以訪問指定資源的方法列表是可以動態變化的；如果用某種方法訪問資源被拒絕，客
戶端可從迴應中的返回碼得到通知。服務器端在方法無法識別或沒有實現時，返回狀態代碼
501（尚未沒實現）。
這些方法被HTTP/1.0的應用程序普遍使用，完整定義請參見第8節。
5.1.2 請求URI（Request-URI）
請求URI就是統一資源標識符（3.2節），用來標識要請求的資源。
Request-URI = absoluteURI | abs_path
上面兩種請求URI方式可根據實際的請求方式選擇使用。
絕對URI（absoluteURI）格式只在代理（proxy）在產生請求時使用。代理的責任是將
請求向前推送，並將迴應返回。如果請求是GET或HEAD方式，而且之前的迴應被緩存，
如果代理忽略標題域的過期信息限制，它可能使用緩存中的消息。注意，代理可能將請求推
送至另外一個代理，也可將請求直接送至絕對URI中所指定的目的服務器。爲了避免請求
循環，代理必須能夠識別它的所有服務器名，包括別名、本地變量及數字形式的IP地址。
下面是一個請求隊列的例子：
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0
最普通的請求URI形式就是原始服務器或網關用來標識資源的方式。在這種方式下，
只有給出絕對路徑的URI才能被傳輸（見3.2.1節）。例如，如客戶端希望直接從原始服務
器上接收資源，它們將產生一個與主機"www.w3.org"80端口的TCP連接，並在完整請求之
後發送下面的命令：
GET /pub/WWW/TheProject.html HTTP/1.0
注意絕對路徑不可以爲空，如果URI中沒有內容，也必須加上一個"/"（server root）。
請求URI以編碼字符串方式傳輸，有些字符可能在傳輸過程中被轉義（escape），如變
成“%HEXHEX”形式。具體這方面內容請參見RFC1738[4]。原始服務器在正確解釋請求
之前必須對請求URI進行解碼。
5.2 請求標題域（Request Header Fields）
請求標題域允許客戶端向服務器端傳遞該請求的附加信息及客戶端信息。該域做爲請求
的修飾部分，遵照編程語言程序調用參數的語法形式。
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
請求標題域名只有在與協議版本的變化結合起來後，才能進行可靠的擴展。實際上，新
的或實驗中的標題域只要能被通訊各方識別，其語法就可使用，而無法識別的標題域都將被
視爲實體域。
6. 迴應（Response）
在接收、解釋請求消息後，服務器端返回HTTP迴應消息。
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
當請求是HTTP/0.9的或者服務器端只支持HTTP/0.9時，只能以Simple-Response方式
迴應。如果客戶端發送HTTP/1.0完整請求後，接收到的迴應不是以狀態行（Status-Line）
開頭的，客戶端將其視爲簡單迴應，並相應對其進行分析。注意，簡單請求只包括實體主體，
它在服務器端關閉連接時終止。
6.1 狀態行（Status-Line）
完整迴應消息的第一行就是狀態行，它依次由協議版本、數字形式的狀態代碼、及相應
的詞語文本組成，各元素間以空格（SP）分隔，除了結尾的CRLF外，不允許出現單獨的
CR或LF符。
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
狀態行總是以協議版本及狀態代碼開頭，如：
"HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP
（如，"HTTP/1.0 200"）。
這種表示方式並不足以區分完整請求和簡單請求。簡單迴應可能允許這種表達式出現在
實體主體的開始部分，但會引起消息的誤解。因爲大多數HTTP/0.9的服務器都只能回
應"text/html"類型，在這種情況下，不可能產生完整的迴應。
6.1.1 狀態代碼和原因分析（Status Code and Reason
Phrase）
狀態代碼（Status-Code）由3位數字組成，表示請求是否被理解或被滿足。原因分析是
用簡短的文字來描述狀態代碼產生的原因。狀態代碼用來支持自動操作，原因分析是爲人類
用戶準備的。客戶端不需要檢查或顯示原因分析。
狀態代碼的第一位數字定義了迴應的類別，後面兩位數字沒有具體分類。首位數字有5
種取值可能：
o 1xx:：保留，將來使用。
o 2xx：成功 － 操作被接收、理解、接受（received, understood, accepted）。
o 3xx：重定向（Redirection）－ 要完成請求必須進行進一步操作。
o 4xx：客戶端出錯 － 請求有語法錯誤或無法實現。
o 5xx：服務器端出錯 － 服務器無法實現合法的請求。
HTTP/1.0的狀態代碼、原因解釋在下面給出。下面的原因解釋只是建議採用，可任意
更改，而不會對協議造成影響。完整的代碼定義在第9節。
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狀態代碼是可擴展的，而只有上述代碼纔可以被當前全部的應用所識別。HTTP
應用不要求瞭解全部註冊的狀態代碼，當然，如果瞭解了更好。實際上，應用程序必須理解
任何一種狀態代碼，如果碰到不識別的情況，可根據其首位數字來判斷其類型並處理。另外，
不要緩存無法識別的迴應。
例如，如果客戶端收到一個無法識別的狀態碼431，可以安全地假定是請求出了問題，
可認爲迴應的狀態碼就是400。在這種情況下，用戶代理應當在迴應消息的實體中通知用戶，
因爲實體中可以包括一些人類可以識別的非正常狀態的描述信息。
6.2 迴應標題域（Response Header Fields）
迴應標題域中包括不能放在狀態行中的附加回應信息。該域還可以存放與服務器相關的
信息，以及在對請求URI所指定資源進行訪問的下一步信息。
Response-Header = Location ; Section 10.11
| Server ; Section 10.14
| WWW-Authenticate ; Section 10.16
迴應標題域名只有在與協議版本的變化結合起來後，才能進行可靠的擴展。實際上，新
的或實驗中的標題域只要能被通訊各方識別，其語法就可使用，而無法識別的標題域都將被
視爲實體域。
7. 實體（Entity）
完整請求和完整迴應消息可能會傳輸請求或迴應中的實體。實體由實體標題
（Entity-Header）域、（通常還有）實體主體（Entity-Body）組成。從這種角度看，客戶端
與服務器都將扮演發送方及接收方的角色。某一時刻的角色定位則取決於在這個時刻誰在發
送實體，而誰又在接收實體。
7.1 實體標題域（Entity Header Fields）
實體標題域中定義了一些可選的元信息，如有無實體、請求資源。
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
擴展標題（extension-header）機制允許在不改變協議的前提下定義附加的實體標題域，
但是不能假定接收方可以識別這些域。對於不可識別的標題域，接收方一般是忽略不管，而
代理則繼續將其向前推送。
7.2 實體主體（Entity Body）
與HTTP請求或迴應一起發送的實體主體的格式和編碼信息都在實體標題域
（Entity-Header）中定義。
Entity-Body = *OCTET
實體主體只在請求方法有要求時纔會被放在請求消息中。請求消息標題域處的內容長度
標題域（Content-Length header field）的標誌將指明請求中的實體主體是否存在。包含實體
主體的HTTP/1.0請求必須包含合法的內容長度標題域。
對迴應消息來說，消息中是否包含實體主體取決於請求方法和迴應代碼。所有的HEAD
請求方法的迴應都不應包括主體，即便是實體標題域中指明有主體也一樣。在主體中不應包
括這些迴應信息，全部1xx（信息）、204（無內容）和304（未修改）。而其它的迴應必須包
括實體主體或其內容長度標題（Content-Length header）域的定義值爲0。
7.2.1 類型（Type）
當消息中包括實體主體，主體的數據類型由標題域中的內容類型（Content-Type）和內
容編碼（Content-Encoding）決定。定義了二層順序編碼模式：
entity-body := Content-Encoding( Content-Type( data ) )
內容類型（Content-Type）指定了下列數據的介質類型（media type）。內容編碼
（Content-Encoding）可用於指示附加內容解碼方式，通常用於有數據壓縮屬性的被請求資
源。內容編碼的缺省值是none。
任何包括實體主體的消息必須含有內容類型（Content-Type）標題域，以定義主體的類
型。只有當內容類型標題域中沒有給出介質類型時，如簡單迴應消息，接收方可能對該URL
所指定的資源進行判斷，如其內容及擴展名等等，從而猜測出該主體的介質類型。如果還無
法確定介質類型，接收方應當將其視爲" application/octet-stream"型。
7.2.2 長度（Length）
當實體主體被包括在消息中，主體長度可以有兩種方式確定。如果內容長度
（Content-Length）標題域存在，其字節值就是實體主體長度；否則，其主體長度由服務端
關閉連接時確定。
由於服務端無法在連接關閉時發送迴應信息，所以不能用關閉連接來指示請求主體的結
束。因而，HTTP/1.0請求如果包含主體，就必須在內容長度（Content-Length）標題域中給
出合法的值。如果請求包括實體主體，且內容長度沒指定，服務端將無法識別或無法從其它
域中計算出其主體長度，在這種情況下，服務端將會返回400（非法請求）迴應。
注意：一些老的服務器在發送包含由服務器端動態插入的數據流文件時，支持非法的內
容長度使用。要強調的是，未來版本的HTTP協議將會很快改變這種情況。除非客戶端自己
知道正在從一個支持它的服務器端得到迴應，否則不應依賴於內容長度域的正確性。
8. 方法定義（Method Definitions）
通用的HTTP/1.0的方法集將在下面定義，雖然該方法集可以擴展，但並不保證附加的
方法能夠被擴展的客戶端和服務器端所支持。
8.1 GET
GET方法就是以實體方式得到由請求URI所指定資源的信息。如果請求URI只是一個
數據產生過程，那麼最終要在迴應實體中返回的是由該處理過程的結果所指向的資源，而不
是返回該處理過程的描述文字，除非那段文字恰好是處理的輸出。
如果請求消息包含If-Modified-Since標題域，GET方法的語法就變成“條件GET”，即
“（conditional GET）”。 條件GET方法可以對指定資源進行判斷，如果它在If-Modified-Since
標題域（見10.9節）中的指定日期後發生了更新，才啓動傳輸，否則不傳輸。這種條件GET
允許被緩存的實體在不必經過多次請求或不必要的數據傳輸就能進行刷新，從而有助於降低
網絡負載。
8.2 HEAD
HEAD方法與GET幾乎一樣，區別在於，HEAD方法不讓服務器在迴應中返回任何實
體。對HEAD請求的迴應部分來說，它的HTTP標題中包含的元信息與通過GET請求所得
到的是相同的。通過使用這種方法，不必傳輸整個實體主體，就可以得到請求URI所指定
資源的元信息。該方法通常用來測試超鏈接的合法性、可訪問性及最近更新。
與條件GET不同，不存在所謂的“條件HEAD”，即"conditional HEAD"。即使在HEAD
請求中指定If-Modified-Since標題域，它也會被忽略。
8.3 POST
POST方法用來向目的服務器發出請求，要求它接受被附在請求後的實體，並把它當作
請求隊列（Request-Line）中請求URI所指定資源的附加新子項。POST被設計成用統一的
方法實現下列功能：
o 對現有資源的註釋（Annotation of existing resources）；
o 向電子公告欄、新聞組，郵件列表或類似討論組發送消息；
o 提交數據塊，如將表格（form [3]）的結果提交給數據處理過程；
o 通過附加操作來擴展數據庫。
POST方法的實際功能由服務器來決定，而且通常依賴於請求URI。在POST過程中，
實體是URI的從屬部分，就好象文件從屬於包含它的目錄、新聞組文件從屬於發出該文件
的新聞組、記錄從屬於其所在的數據庫一樣。
成功的POST不需要在原始服務器創建實體，並將其做爲資源；也不需要爲未來的訪問
提供條件。也就是說，POST方法不一定會指向URI指定的資源。在這種情況下，200（成
功）或204（無內容）都是適當的迴應狀態，取決於實際迴應實體中對結果的描述。
如果在原始服務器上創建了資源，迴應應是201（已創建），幷包含一個實體
（對"text/html"類型最爲適合），該實體中記錄着對新資源請求的狀態描述。
在所有的HTTP/1.0的POST請求中，必須指定合法的內容長度（Content-Length）。如
果HTTP/1.0服務器在接收到請求消息內容時無法確定其長度，就會返回400（非法請求）
代碼。
應用程序不能緩存對POST請求的迴應，因爲做爲應用程序來說，它們沒有辦法知道服
務器在未來的請求中將如何迴應。
9. 狀態代碼定義（Status Code Definitions）
每個狀態代碼都將在下面描述，包括它們將對應哪個方法、以及迴應中需要的全部元信
息。
9.1 消息1xx（Informational 1xx）
該類狀態代碼用於表示臨時迴應。臨時迴應由狀態行（Status-Line）及可選標題組成，
由空行終止。HTTP/1.0中沒有定義任何1xx的狀態代碼，所以它們不是對HTTP/1.0請求的
合法迴應。實際上，它們主要用於實驗用途，這已經超出本文檔的範圍。
9.2 成功2xx（Successful 2xx）
表示客戶端請求被成功接收、理解、接受。
200 OK
請求成功。迴應的信息依賴於請求所使用的方法，如下：
GET 要請求的資源已經放在迴應的實體中了。
HEAD 沒有實體主體，迴應中只包括標題信息。
POST 實體（描述或包含操作的結果）。
201 Created
請求完成，結果是創建了新資源。新創建資源的URI可在迴應的實體中得到。原
始服務器應在發出該狀態代碼前創建該資源。如果該操作不能立即完成，服務器必
須在該資源可用時在迴應主體中給出提示，否則，服務器端應迴應202（可被接受）。
在本文定義的方法，只有POST可以創建資源。
202 Accepted
請求被接受，但處理尚未完成。請求可能不一定會最終完成，有可能被處理過程隨
時中斷，在這種情況下，沒有辦法在異步操作中重新發送狀態代碼。
202迴應是沒有義務的，這樣做的目的是允許服務器不必等到用戶代理和服務器間
的連接結束，就可以響應其它過程的請求（象每天運行一次的，基於批處理的過程）。
在某些迴應中返回的實體中包括當前請求的狀態指示、狀態監視器指針或用戶對請
求能否實現的評估信息。
204 No Content
服務器端已經實現了請求，但是沒有返回新的信息。如果客戶是用戶代理，則勿需
爲此更新自身的文檔視圖。該回應主要是爲了在不影響用戶代理激活文檔視圖的前
提下，進行script語句的輸入及其它操作。該回應還可能包括新的、以實體標題形
式表示的元信息，它可被當前用戶代理激活視圖中的文檔所使用。
9.3 重定向（Redirection 3xx）
該類狀態碼錶示用戶代理要想完成請求，還需要發出進一步的操作。這些操作只有
當後跟的請求是GET或HEAD時，纔可由用戶代理來實現，而不用與用戶進行交
互。用戶代理永遠也不要對請求進行5次以上的重定向操作，這樣可能導致無限循
環。
300 Multiple Choices
該狀態碼不被HTTP/1.0的應用程序直接使用，只是做爲3xx類型迴應的缺省解釋。
存在多個可用的被請求資源。
除非是HEAD請求，否則迴應的實體中必須包括這些資源的字符列表及位置信息，
由用戶或用戶代理來決定哪個是最適合的。
如果服務器有首選，它應將對應的URL信息存放在位置域（Location field）處，
用戶代理會根據此域的值來實現自動的重定向。
301 Moved Permanently
請求到的資源都會分配一個永久的URL，這樣就可以在將來通過該URL來訪問此
資源。有編輯鏈接功能的客戶端會儘可能地根據服務器端傳回的新鏈接而自動更新
請求URI。
新的URL必須由迴應中的位置域指定。除非是HEAD請求，否則迴應的實體主體
（Entity-Body）必須包括對新URL超鏈接的簡要描述。
如果用POST方法發出請求，而接收到301迴應狀態碼。在這種情況下，除非用戶
確認，否則用戶代理不必自動重定向請求，因爲這將導致改變已發出請求的環境。
注意：當在接收到301狀態碼後而自動重定向POST請求時，一些現存的用戶代理
會錯誤地將其改爲GET請求。
302 Moved Temporarily
請求到的資源在一個不同的URL處臨時保存。因爲重定向有時會被更改，客戶端
應繼續用請求URI來發出以後的請求。
新的URL必須由迴應中的位置域指定。除非是HEAD請求，否則迴應的實體主體
（Entity-Body）必須包括對新URL超鏈接的簡要描述。
如果用POST方法發出請求，而接收到302迴應狀態碼。在這種情況下，除非用戶
確認，否則用戶代理不必自動重定向請求，因爲這將導致改變已發出請求的環境。
注意：當在接收到302狀態碼後而自動重定向POST請求時，一些現存的用戶代理
會錯誤地將其改爲GET請求。
304 Not Modified
如果客戶端成功執行了條件GET請求，而對應文件自If-Modified-Since域所指定
的日期以來就沒有更新過，服務器應當迴應此狀態碼，而不是將實體主體發送給客
戶端。迴應標題域中只應包括一些相關信息，比如緩存管理器、與實體最近更新
（entity's Last-Modified）日期無關的修改。相關標題域的例子有：日期、服務器、
過期時間。每當304迴應中給出的域值發生變化，緩存都應當對緩存的實體進行更
新。
9.4 客戶端錯誤（Client Error ）4xx
4xx類的狀態碼錶示客戶端發生錯誤。如果客戶端在收到4xx代碼時請求還沒有完成，
它應當立即終止向服務器發送數據。除了迴應HEAD請求外，不論錯誤是臨時的還是永久
的，服務器端都必須在迴應的實體中包含錯誤狀態的解釋。這些狀態碼適用於任何請求方法。
注意：如果客戶端正在發送數據，服務器端的TCP實現應當小心，以確保客戶端在關
閉輸入連接之前收到迴應包。如果客戶端在關閉後仍舊向服務器發送數據，服務器會給客戶
端發送一個復位包，清空客戶端尚未處理的輸入緩衝區，以終止HTTP應用程序的讀取、解
釋活動。
400 非法請求（Bad Request）
如果請求的語法不對，服務器將無法理解。客戶端在對該請求做出更改之前，不應
再次向服務器重複發送該請求。
401 未授權（Unauthorized）
請求需要用戶授權。迴應中的WWW-Authenticate標題域（10.16節）應提示用戶
以授權方式請求資源。客戶端應使用合適的授權標題域（10.2節）來重複該請求。如果
請求中已經包括了授權信任信息，那回應的401表示此授權被拒絕。如果用戶代理在多
次嘗試之後，迴應一樣還是返回401狀態代碼，用戶應當察看一下回應的實體，因爲在
實體中會包括一些相關的動態信息。HTTP訪問授權會在11節中解釋。
403 禁止（Forbidden）
服務器理解請求，但是拒絕實現該請求。授權對此沒有幫助，客戶端應當停止重複
發送此請求。如果不是用HEAD請求方法，而且服務器端願意公佈請求未被實現原因
的前提下，服務器會將拒絕原因寫在迴應實體中。該狀態碼一般用於服務器端不想公佈
請求被拒絕的細節或沒有其它的迴應可用。
404 沒有找到（Not Found）
服務器沒有找到與請求URI相符的資源。404狀態碼並不指明狀況是臨時性的還是
永久性的。如果服務器不希望爲客戶端提供這方面的信息，還回應403（禁止）狀態碼。
9.5 服務器錯誤（Server Error ）5xx
迴應代碼以‘5’開頭的狀態碼錶示服務器端發現自己出現錯誤，不能繼續執行請
求。如果客戶端在收到5xx狀態碼時，請求尚未完成，它應當立即停止向服務器發送數
據。除了迴應HEAD請求外，服務器應當在其迴應實體中包括對錯誤情況的解釋、並
指明是臨時性的還永久性的。
這類迴應代碼沒有標題域，可適用於任何請求方法。
500 服務器內部錯誤（Internal Server Error）
服務器碰到了意外情況，使其無法繼續迴應請求。
501 未實現（Not Implemented）
服務器無法提供對請求中所要求功能的支持。如果服務器無法識別請求方法就會回
應此狀態代碼，這意味着不能迴應請求所要求的任何資源。
502 非法網關（Bad Gateway）
充當網關或代理的服務器從要發送請求的上游（upstream）服務器收到非法的迴應。
503 服務不可用（Service Unavailable）
服務器當前無法處理請求。這一般是由於服務器臨時性超載或維護引起的。該狀態
碼暗示情況是暫時性的，要產生一些延遲。
注意：503狀態碼並沒有暗示服務器在超載時一定要返回此狀態碼。一些服務器可
能希望在超載時採用簡單處理，即斷掉連接。
10. 標題域定義（Header Field Definitions）
本節定義了HTTP/1.0標題域常用的語法及語義。無論是發送方還是接收方，都有
可能做爲客戶端或服務器端，具體角色取決於在此時刻究竟是誰在接收、誰在發送。
10.1 允許（Allow）
表示由請求URI所指定的資源支持在Allow實體標題域中列出的方法，目的是讓接收
方更清楚地知道請求此資源的合法方式。Allow標題域不允許在POST方法中使用，如果非
要這麼做，將被忽略。
Allow = "Allow" ":" 1#method
Example of use:
Allow: GET, HEAD
該域不能防止客戶端嘗試其它方法。但實際上由Allow標題域中的值所表示的指示
信息是有用的，應當被遵守。實際的Allow方法集在每次向原始服務器上發出請求時定
義。
由於用戶代理（user agent）可能出於其它目的與原始服務器通訊，做爲代理（proxy）
來說，即使無法識別請求所指定的所有方法，也不能修改該請求的Allow標題域。
Allow標題域並不表示服務器實現了哪些方法。
10.2 授權（Authorization）
通常，用戶代理在收到401（未授權）迴應時，可能（也可能不會）希望服務器對其授
權。如果希望授權，用戶代理將在請求中加入授權請求標題（Authorization request-header）
域。授權域值由信任證書組成，其中有對用戶代理所請求資源領域的授權信息。
Authorization = "Authorization" ":" credentials
HTTP訪問授權在11節中描述。如果請求中的授權指定了一個範圍，那在此範圍的其
它請求也都具有相同的信任關係。
對包含授權信息域的請求來說，其迴應是不能被緩存的。
10.3 內容編碼（Content-Encoding）
內容編碼的實體標題域（entity-header）用作介質類型（media-type）的修飾符。它指明
要對資源採用的附加內容譯碼方式，因而要獲得內容類型（Content-Type）標題域中提及的
介質類型，必須採用與譯碼方式一致的解碼機制。內容編碼主要用來記錄文件的壓縮方法。
各種壓縮方法將在後面列出。
Content-Encoding = "Content-Encoding" ":" content-coding
內容譯碼（Content codings）在3.5節中定義，例如：
Content-Encoding: x-gzip
內容編碼是請求URI指定資源的一個特性，一般來說，資源用編碼方式存儲，只有在
通過解碼變換以後才能使用。
10.4 內容長度（Content-Length）
內容長度（Content-Length）實體標題域指明瞭發送到接收方的實體主體（Entity-Body）
長度，用字節方式存儲的十進制數字表示。對於HEAD方法，其尺寸已經在前一次GET請
求中發出了。
Content-Length = "Content-Length" ":" 1*DIGIT
例如：
Content-Length: 3495
不論實體是何種介質類型，應用程序都將通過該域來判定將要傳輸的實體主體尺寸。所
有包括實體主體的HTTP/1.0的請求消息都必須包括合法的內容長度值。
任何0以上（包括0）的值都是合法的內容長度值。在7.2.2節描述了當內容長度值沒
有給出時，如何決定迴應實體主體長度的方法。
注意：該域的含義與在MIME中定義的有重要區別。在MIME中，它是可選域，只
在"message/external-body"內容類型中使用；而在HTTP中，在實體被傳輸前，該域就決定
了實體的長度。
10.5 內容類型（Content-Type）
內容類型實體標題域指明瞭發送給接收方的實體主體長度。對於HEAD方法，介質類
型已經在前一次GET請求中發出了。
Content-Type = "Content-Type" ":" media-type
介質類型在3.6節中定義，如下例：
Content-Type: text/html
更多關於介質類型的討論在7.2.1節。
10.6 日期（Date）
日期普通標題（Date general-header）域表示消息產生的時間，其語法與RFC822中定義
的orig-date是一樣的。該域值是HTTP型日期，在3.3節中描述。
Date = "Date" ":" HTTP-date
例如：
Date: Tue, 15 Nov 1994 08:12:31 GMT
如果直接通過用戶代理（如請求）或原始服務器（如迴應）的連接接收到消息，日期可
以認爲是接收端的當前時間。然而，對於原始服務器來說，時間對其迴應緩存的處理非常重
要，所以，原始服務器的迴應總是包括日期標題。客戶端只有在發送帶實體的消息時，纔可
向服務器發送日期標題域，比如POST請求。如果接收到的消息被接收方或網關通過有日期
要求的協議緩存起來時，該消息即使沒有日期標題域，接收方也會爲其分配一個。
理論上，日期應當在實體產生時生成，而實際上，日期可能在消息產生過程的任意時間
生成，而不會造成任何不利的影響。
注意：早期版本錯誤地將此域值定義爲實體主體封裝時的日期。這已經被實際應用所更
正。
10.7 過期（Expires）
過期實體標題域中的日期/時間值指定了實體過期的時間。這爲信息提供方提供了使信
息失效的手段。當超過此期限時，應用程序不應再對此實體進行緩存了。過期並不意味着原
始資源會在此期限後發生改變或停止存在。在實際應用中，信息提供者通過檢查過期標題域
中所指定的時間，從而獲知或預測資源將會發生改變的確切日期。該格式用的是絕對日期時
間（3.2節）。
Expires = "Expires" ":" HTTP-date
例如：
Expires: Thu, 01 Dec 1994 16:00:00 GMT
如果給定日期比日期標題中的要早（或相同），接收方不應緩存附加的實體。如果資源
是動態自然生成的，象有些大量數據的處理，資源的實體應當被加上一個適當的過期時間值。
過期域並不能強制用戶代理對其進行刷新或重新載入資源，它只用於緩存機制。當對已
初始化過的資源發出新請求時，該機制才檢查該資源的過期狀態。
用戶代理通常都有歷史記錄機制，如“後退”按鈕和歷史記錄列表。該種機制可以用來
重新顯示某次對話（session）之前已經獲取的實體信息。在缺省狀態下，過期域不對歷史機
制使用。除非用戶在配置用戶代理時指定了對歷史文件進行過期刷新，否則，只要實體還保
存着，歷史機制就能顯示它，不論該實體是否已經過期。
注意：應用程序應兼容對過期標題非法或錯誤的實現，如碰到0值或非法的日期格式，
應用程序應將其視爲“立即過期（expires immediately）”。雖然這些值不符合HTTP/1.0，對
於一個健壯的應用來說，還是必要的。
10.8 來自（From）
From請求標題域，如果給出來，則應包括一個使用此用戶代理的人類用戶的Internet
e-mail地址。該地址應當能被系統識別，就象RFC822[7]（已經更新爲RFC1123[6]）中的郵
箱定義一樣。
From = "From" ":" mailbox
例如：
From: [email protected]
該標題域可能用來做爲登錄目的使用，以確定對某資源的請求是否合法。它不應用於不
安全的訪問保護。該域的解釋是，請求已按請求人指定的行爲方式完成，而該請求人將爲此
種方式負責。特殊情況下，機器人（robot）代理也應包括此標題域，域中註明是誰運行它
的，這樣，當接收端發生任何問題時，都可以同這個人取得聯繫。
該域中的Internet e-mail地址可以與處理該請求的Internet主機分離。例如，當請求通過
代理（proxy）時，應使用原始的傳輸地址。
注意：客戶端在沒有得到用戶批准時，不應發送From標題域，因爲這樣做可能會產生
用戶隱私及網站安全方面的問題。強烈建議在請求之前提供手段以禁止（disable）、允許
（enable）、修改（modify）該域的值。
10.9 從何時更改（If-Modified-Since）
If-Modified-Since請求標題域和GET方法一起使用，用於處理下面情況：當在該域指定
的日期以來，請求資源沒有發生任何變更。這時，服務器將不會下傳該資源的拷貝，即，回
應不帶任何實體主體，只是304狀態碼（未修改）。
If-Modified-Since = "If-Modified-Since" ":" HTTP-date
例如：
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
條件GET方法可以請求服務端將在If-Modified-Since標題域中的指定日期後發生變更
的指定資源下傳，也就是說，如果資源沒發生變化，就不下傳了。其算法如下：
a) 如果請求的迴應狀態不是200（成功）碼或它傳過來的If-Modified-Since中的
日期不合法，此時按照普通GET來回應。如果日期比服務器的當前時間還要
晚，則是非法時間。
b) 如果資源在If-Modified-Since日期以後有變化，迴應也和普通GET一樣
c) 如果資源在If-Modified-Since日期以後沒變化，服務器端將回應304（未修改）。
注：該日期應是合法的。
這樣做的目的是爲了以最小的代價，對被緩存信息進行有效更新。
10.10 最近更改（Last-Modified）
Last-Modified實體標題域表示由發送方設定的資源最近修改日期及時間。該域的精確定
義在於接收方如何去解釋它：如果接收方已有此資源的拷貝，但此拷貝比Last-Modified域
所指定的要舊，該拷貝就是過期的。
Last-Modified = "Last-Modified" ":" HTTP-date
例如：
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
該標題域的精確含義取決於發送方的執行方式及原始資源的自然狀態。對於文件來說，
可能是它在文件系統的last-modified時間。對於包含多個組成部分的實體來說，可能是組成
部分中最新的last-modify時間。對數據庫網關來說，可能是記錄的last-update時間戳。對於
虛（virtual）對象來說，可能是內部狀態的最近改變時間。
原始服務器不應發送比服務器消息產生時間更晚的Last-Modified日期，因爲該消息會
導致服務器在未來的某個時間內，用消息原始的日期對該域值進行再次更新。
10.11 位置（Location）
Location迴應標題域定義了由請求URI指定的資源的位置。對於3xx（重定向）迴應，
位置域必須能幫助服務器找到相應的URL，以實現對資源的重定向。只允許用絕對URL。
Location = "Location" ":" absoluteURI
例如：
Location: http://www.w3.org/hypertext/WWW/NewLocation.html
10.12 註解（Pragma）
Prama普通標題域包括一些可能對請求/迴應鏈中的任一接收方有用的特殊指示信息。
從協議角度看，所有的註解指示了一些特定的可選行爲，事實上，一些系統可能會要求行爲
與指示一致。
Pragma = "Pragma" ":" 1#pragma-directive
pragma-directive = "no-cache" | extension-pragma
extension-pragma = token [ "=" word ]
當"no-cache"出現在請求消息中時，應用程序應當向原始服務器推送此請求，即使它已
經在上次請求時已經緩存了一份拷貝。這樣將保證客戶端能接收到最權威的迴應。它也用來
在客戶端發現其緩存中拷貝不可用或過期時，對拷貝進行強制刷新。
不管註解（Pragma）指示信息對代理（proxy）及網關（gateway）應用程序如何重要，
它必須能穿越這些應用，因爲該信息可能對請求/迴應鏈上的其它接收方有用。實際上，如
果註解與某個接收方無關，它應當被該接收方忽略。
10.13 提交方（Referer）
提交方請求標題域是出於服務器端利益方面的考慮，允許客戶端指明該鏈接的出處，即
該指向資源地址的請求URI是從哪裏獲得的。這樣，服務器將產生一個備份鏈接（back-links）
列表，用於維護受歡迎的資源、登錄、緩存優化等活動。
Referer = "Referer" ":" ( absoluteURI | relativeURI )
例子：
Referer: http://www.w3.org/hypertext/DataSources/Overview.html
如果只給了部分URI，應當參照請求URI來解釋它。URI不能包括段（fragment）。
注意：因爲鏈接的原代碼可能暴露一些隱私信息，因此強烈建議由用戶來決定是否發送
提交人域。例如，瀏覽器客戶端有個選項可以用來進行離線瀏覽，可以使能或禁止提交人或
表單信息的發送。
10.14 服務器（Server）
服務器迴應標題域包含由原始服務器用來處理請求的軟件信息。該域可包含多個產品標
識（3.7節）及註釋以標識服務器及重要的子產品。按照習慣，產品標識將按其應用的重要
順序排列。
Server = "Server" ":" 1*( product | comment )
例如：
Server: CERN/3.0 libwww/2.17
如果迴應要通過代理來推送，代理應用程序不應將它自己的數據加入產品列表。
注意：一些指定服務器軟件的版本有啓示作用，因爲這些版本的軟件存在一些安全漏洞，
將使服務器更易受到攻擊。提倡服務器軟件在實現時，將此域變成可以進行配置的選項。
注意：有些服務器不遵守服務器域產品標識的語法約束。
10.15 用戶代理（User-Agent）
用戶代理請求標題域包含用戶原始請求的信息，這可用於統計方面的用途。通過跟蹤協
議衝突、自動識別用戶代理以避免特殊用戶代理的侷限性，從而做到更好的迴應。雖然沒有
規定，用戶代理應當在請求中包括此域。該域可包含多個產品標識（3.7節）及註釋以標識
該代理及其重要的子產品。按照習慣，產品標識將按子產品對應用的重要性順序排列。
User-Agent = "User-Agent" ":" 1*( product | comment )
例如：
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
注意：現存有些代理應用將它們的產品信息回到了用戶代理域中，這種方法不值得提倡，
因爲這樣做會使機器在解釋這些信息時產生混淆。
注意：現在有些客戶端不遵守用戶代理域中產品標識的語法約束。
10.16 WWW-授權（WWW-Authenticate）
WWW-授權迴應標題域必須被包括在401（未授權）迴應消息中。該域值由一個以上的
challenge組成，這些challenge可用於指出請求URI的授權方案及參數。
WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
HTTP訪問授權處理在11節中描述。用戶代理在解析WWW-授權域值時要特別注意看
看它是否包含一個以上的待解決問題（challenge）或是否提供了一個以上的WWW-授權標
題域，因爲待解決問題（challenge）的內容中可能包含用逗號分隔的授權參數列表。
11. 訪問鑑別（Access Authentication）
HTTP提供了一個簡單的質詢迴應（challenge-response）鑑別機制，可用於服務器通過
客戶端提供的授權信息來對其進行身份鑑別。授權方案用可擴展的、大小寫敏感的符號來標
識，後跟獲取證明所需要的以逗號分隔的‘屬性－值’對。
auth-scheme = token
auth-param = token "=" quoted-string
原始服務器用401（未授權）迴應消息來質詢用戶代理的授權。該回應必須包括WWW-
授權標題域，而該WWW-授權標題域包括一個以上用於請求資源認證的參數（challenge）。
challenge = auth-scheme 1*SP realm *( "," auth-param )
realm = "realm" "=" realm-value
realm-value = quoted-string
凡涉及到參數（challenge）處理的授權方案都有realm屬性（大小寫敏感）。與標準URL
（相對於被訪問服務器root）聯合使用的realm值（也是大小寫敏感）用來定義保護區域。
Realm使得服務器上的被保護資源被放在特殊的保護分區內，這些區域都有各自的授權方案
和（或）授權數據庫。Relm值是個字符串，通常由原始服務器來分配，對於授權方案來說，
可能存在些附加的語法處理問題。
通常，用戶代理在收到401（未授權）迴應時，可能（也可能不會）希望服務器對其授
權。如果希望授權，用戶代理將在請求中加入授權請求標題（Authorization request-header）
域。授權域值由信任證書組成，其中有對用戶代理所請求資源領域的授權信息。
credentials = basic-credentials
| ( auth-scheme #auth-param )
可由用戶代理通過信任方式來訪問的區域由保護區域決定。如果早先的請求已經通過認
證，在由授權方案，參數和（或）用戶選擇等所指定的時間間隔內，其它的請求可通過相同
的信任來訪問該保護區域。
除非由授權另行指定，否則單個保護區域的範圍不能擴展到服務器之外。
如果服務器不希望通過請求來接受信任，它應當返回403（禁止）迴應。
HTTP協議的訪問授權不限於這種簡單的質詢迴應（challenge-response）機制，還可以
使用其它的方法，比如傳輸級加密或消息封裝及通過附加標題域來指定授權信息等等。但是，
這些方法不在本文檔的討論範圍。
代理必須完全透明地處理用戶授權，也就是說，它們必須在不做任何改動的前提下將
WWW-授權及授權標題向前推送，也不可以對包含授權的迴應進行緩存。HTTP/1.0不爲客
戶端提供通過代理方式授權的方法。
11.1 基本授權方案（Basic Authentication Scheme）
用戶代理必須對於每個領域（realm）通過用戶標識（user-ID）及口令來對自身進行授
權，這是基本授權方案的工作模式。Realm值應當被看作不透明的字符串，該值將用於同服
務器端其它的realm值相比較。只有用戶標識及口令通過受保護資源的認證，服務器纔會給
請求授權。授權參數沒有可選項。
在接收到對受保護區域的未經認證的資源請求時，服務器應當迴應一個質詢
（challenge），如下：
WWW-Authenticate: Basic realm="WallyWorld"
"WallyWorld"是由服務器分配的字符串，用於對請求URI所指定的受保護資源進行標
識。
爲了接收授權，客戶端需要在基於64位（base64 [5]）的證書中發送用戶標識及口令，
中間用冒號':'分隔。
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
如果用戶代理希望發送用戶標識"Aladdin"和口令“open sesame”，應當遵循下面的標題
域形式：
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Basic授權方案是對HTTP服務器資源的非授權訪問進行過濾的非安全方法。它基於假
定客戶端與服務器端的連接是安全的，爲什麼說是假定呢，因爲在實際的開放性網絡中，使
用basic授權方案往往存在許多不安全的地方。儘管如此，客戶端仍然需要實現此方案，以
與採用此種方案的服務器進行通訊。
12. 安全考慮（Security Considerations）
本節的描述對下面各角色有關：信息應用開發者、信息提供者、HTTP/1.0中受安全性
限制的用戶。本節僅是討論安全問題，並對減少隱患提出了建議，但是並不提供對問題的最
終解決辦法。
12.1 客戶授權（Authentication of Clients）
正如11.1節中所述，基本授權（Basic authentication）方案不是安全的用戶授權方案，
也不能用它來防止實體主體源碼以文本方式在物理網絡中傳輸。HTTP/1.0並不反對在目前
日益突出的安全問題面前採用其它的授權方式及加密機制。
12.2 安全方法（Safe Methods）
客戶端軟件開發者應當注意，客戶端軟件代表用戶在Internet上與其它方面交互，並應
注意避免讓用戶知道其間發生的具體動作，這些動作可能會暴露對交互各方有重要意義的信
息。
特別情況下，按協定來看，GET和HEAD方法應被視作是安全的，同重新獲得數據應
當沒有什麼不同。這就允許用戶代理採用其它方法，如POST，在某種情況下，可能存在這
樣一種情況，即請求中包含不安全的行爲。
通常，服務器端在執行過GET請求之後，其結果之類的副產品還殘留在服務器上；實
際上，一些動態資源需要這種特性來實現。這裏的重要區別在於用戶沒有請求這些副產品，
因而也不應當對這類請求進行解釋。
12.3 服務器日誌信息的弊端（Abuse of Server Log
Information）
服務器爲保存與用戶請求相關的個人數據，如閱讀方式或感興趣的主題等提供了空間。
這些存儲信息顯然是受某些國家法律保護的，所以對此類數據的處理應當小心。用HTTP
協議提供數據的一方應當負責保證這些信息在未得各方許可之前不會散佈出去。
12.4 敏感信息傳輸（Transfer of Sensitive Information）
與其它協議一樣，HTTP協議不能調整傳輸數據的內容，也不存在未卜先知的方法，通
過給定請求的上下文信息片段就能推測出信息的敏感程度。因而，應用程序應當儘可能像信
息提供方一樣，爲該信息提供更多的控制。在此，有三個標題域值得一提：服務端（Server）、
提交方（Referer）和來自（From）。
一些指定服務器軟件的版本有啓示作用，因爲這些版本的軟件存在一些安全漏洞，將使
服務器更易受到攻擊。提倡服務器軟件在實現時，將Server標題域變成可以進行配置的選
項。
提交方（Referer）標題域允許閱讀方式（reading patterns）被暴露，並可導出反向鏈接。
雖然該域很有用，但是如果包含在此域的用戶信息如果沒有被分開，則它的作用很可能被濫
用。另外，即使此域中用戶信息被清除，從該域的其它信息仍可推測出其私有文件的URI，
這可能是該信息發佈者所不想看到的。
來自（From）標題域可能包括一些與用戶私人隱私及站點安全相關的信息，因而，在
發送數據前，應當允許用戶使用一些設定手段，如禁止（disable）、允許（enable）、及修改
（modify），對此域信息進行配置。用戶應當能夠根據他們的選擇或使用應用程序提供的缺
省配置來設定此域的內容。
我們建議，但不做要求：爲用戶提供方便的界面來允許（enable）或禁止（disable）發
送From域或Referer域的信息。
12.5 基於文件及路徑名的攻擊（Attacks Based On File and
Path Names）
HTTP原始服務器的實現應當注意，要對以服務器管理員名義發出的，對某個文件的
HTTP請求進行限制。如果HTTP服務器直接將HTTP URI發送給系統調用，服務器要特別
注意，當某個請求文件不是發往HTTP客戶端時，要予以拒絕服務。例如，在Unix、Microsoft
Windows以及其它的操作系統使用".."做爲上級目錄名。在這樣的系統下，HTTP服務器端
必須禁止通過使用這種結構的請求URI來訪問HTTP服務器其它範圍的資源。同樣，服務
器端內部使用的一些文件，包括訪問控制文件，配置文件、script代碼等，也要受到特別保
護，以避免被非法請求獲取，導致系統敏感信息暴露。實驗證明，哪怕是最小的bug，也可
能導致嚴重的安全問題。
13. 感謝（Acknowledgments）
本文檔着重論述補充反饋方式（augmented BNF）及由David H. Crocker在RFC822[7]
中定義的一般結構。同樣，它使用了許多由Nathaniel Borenstein和Ned Freed爲MIME [5]
做的許多定義。我們希望通過它們來減少對HTTP/1.0及mail消息格式之間關係的混淆。
HTTP協議在過去四年中發展很快，它得益於龐大而活躍的開發團體――是他們，這些
參與WWW討論郵件列表的人們，造就了HTTP在全球範圍內的成功。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，他們爲本文檔早期版本投入了巨大精力。Paul Hoffman
提供了關於信息狀態方面的信息，以及附錄C、D的內容。
該文檔從HTTP-WG成員的評註中得益非淺。以下是對本規範做出貢獻的人們：
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: [email protected]
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: [email protected]
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: [email protected]
附錄（Appendices）
這些信息出現在附錄中僅有一個理由，即他們沒有成爲HTTP/1.0規範的組成部分。
A. Internet介質類型消息/http（Internet Media Type
message/http）
做爲HTTP/1.0協議的補充，該文檔做爲Internet介質類型"message/http"的規範。下面
內容被登記在IANA[13]中。
介質類型名（Media Type name）： message
介質子類型名（Media subtype name）： http
請求參數（Required parameters）： none
可選參數項（Optional parameters）： version, msgtype
版本（version）：附加消息的HTTP版本號，比如“1.0”。如果沒有給出，版
本可以從其主體的第一行中得到。
消息類型（msgtype）：消息類型――請求（request）或迴應（response）。如果
沒有給出，版本可以從其主體的第一行中得到。
編碼考慮（Encoding considerations）：只允許用"7bit", "8bit",或"binary" 。
安全考慮（Security considerations）： none
B. 容錯應用（Tolerant Applications）
雖然此文檔指明瞭產生HTTP/1.0消息的必要條件，並非所有的應用程序都校正他們的
實現。因此，我們建議應用程序增強其容錯能力，以便在岐義仍可被明確解釋時，還能保證
正常運行。
客戶端解析狀態行（Status-Line）及服務器解析請求行（Request-Line）時，應當做到容
錯。特別是，即使只需要一個SP分隔的情況下，它們也可接受以任何數量的SP或HT字
符分隔的域。
HTTP標題域的行終止符是順序字符CRLF。而我們建議應用程序在解析這類標題時，
也應識別單個LF（沒有前面的CR）做爲終止符情況。
C. 與MIME的關係（Relationship to MIME）
HTTP/1.0使用了許多爲Internet Mail（RFC822[7]）及多用途Internet郵件擴展
（Multipurpose Internet Mail Extensions）MIME[5]定義的結構，以允許實體通過一種開放的
可擴展的機制進行傳輸。實際上，HTTP中有些特性與RFC1521中討論的郵件不同，這些
區別被用來優化二進制傳輸的性能，給介質類型的使用提供了更大的自由度，使日期比較變
得更加容易，當然，這也是爲了兼容早期的一些HTTP服務器及客戶端的應用。
在寫作本文時，據說RFC1521將被修訂。修訂版本將會包括一些出現在HTTP/1.0中的
已有的應用，但這些應用在目前的RFC1521中尚未包括。
該附錄描述了HTTP與RFC1521中的不同之處。代理和網關在限制MIME環境時，應
當注意到這些區別，並在必須時提供相應的轉換支持。從MIME到HTTP環境的代理和網
關也要注意這些區別，因爲一些轉換可能是必須的。
C.1 轉換爲規範形式（Conversion to Canonical Form）
RFC1521要求Internet郵件實體在被傳輸前轉換成規範形式，正如RFC1521[5]附錄C
中所描述的那樣。本文檔中3.6.1節中描述了HTTP在傳輸時允許的“text”介質類型的子類
型的具體形式。
RFC1521要求"text"的內容類型（Content-Type）必須用CRLF作爲行中斷符，禁止單獨
使用CR或LF。HTTP允許在HTTP傳輸時使用CRLF、單獨的CR或LF做爲行中斷符。
只要有可能，HTTP環境或RFC1521環境下的代理或網關應當將本文檔3.6.1節中描述
的文本介質類型中的所有行中斷符都轉換成CRLF。注意，由於存在着內容編碼
（Content-Encoding）問題，以及HTTP允許使用多字符集，而其中的某些字符集不用字節
13和10做爲CR和LF，這樣就使實際的處理更加複雜。
C.2 日期格式轉換（Conversion of Date Formats）
HTTP/1.0使用受限制的日期格式集（3.3節）以簡化日期比較的處理。其它協議的代理
和網關應當保證消息中的任何日期標題域與HTTP/1.0格式一致，否則，要對其進行改寫。
C.3 內容編碼介紹（Introduction of Content-Encoding）
RFC1521不包括殊如HTTP/1.0中內容編碼標題域之類的概念。由於內容類型域是介質
類型的修飾，因而從HTTP到MIME兼容協議中的代理和網關必須在將消息向前推送之前，
更改內容類型標題域（Content-Type）的值或者對實體主體（Entity-Body）進行解碼（有些
Internet mail內容類型的實驗性應用採用介質類型參數爲";conversions=<content-coding>"來
替代內容解碼，而事實上，該參數並非RFC1521的組成部分）。
C.4 無內容傳輸編碼（No Content-Transfer-Encoding）
HTTP不使用RFC1521的CTE（Content-Transfer-Encoding）域。與MIME協議兼容的
代理和網關在向HTTP客戶端傳遞迴應消息前都必須清除任何無標識的CTE編碼
（"quoted-printable"或"base64"）。
從HTTP到MIME兼容協議的代理和網關要負責保證協議上消息格式正確及編碼傳輸
安全，所謂安全傳輸是指滿足對應協議所規定的限制或約束標準。代理或網關應當用適當的
內容傳輸編碼（Content-Transfer-Encoding）來標識數據，以提高在目的協議上實現安全傳輸
的可能性。
C.5 多個主體的HTTP標題域（HTTP Header Fields in
Multipart Body-Parts）
在RFC1521中，大多數多個主體組成的標題域通常會被忽略，除非其域名以"Content-"開
頭。在HTTP/1.0中，多個主體部分（multipart body-parts）所包含的任何HTTP標題域，只
對對應的部分有意義。
D. 附加特性（Additional Features）
該附錄中包括的一些協議元素存在於一些HTTP實現中，但並非對所有的HTTP/1.0的
應用都適用。開發者應注意這些特性，但不能依賴它們來與其它的HTTP/1.0應用程序進行
交互。
D.1 附加請求方法（Additional Request Methods）
D.1.1 PUT
PUT方法請求服務器將附件的實體儲存在提供的請求URI處。如果該請求URI指向的
資源已經存在，則附件實體應被看做是當前原始服務器上資源的修改版本。如果請求URI
沒有指向現存的資源，該URI將被該請求的用戶代理定義成爲一個新的資源，原始服務器
將用該URI產生這個資源。
POST與PUT兩種請求的基本區別在於對請求URI的理解不同。在POST請求方法中
的URI所標識的資源將做爲附件實體被服務器處理，該資源可能是數據接收處理過程、某
些其它協議的網關、或可被註釋的單獨實體。與此相反，用戶代理很清楚它發出的PUT請
求中附帶URI所標識的實體指向何處，而服務器處不應將該請求用到其它資源頭上。
D.1.2 DELETE
DELETE方法請求原始服務器刪除由請求URI所指定的資源。
D.1.3 LINK
LINK方法建立與請求URI所指定資源或其它已存在資源之間的一個或多個連接關係。
D.1.4 UNLINK
UNLINK方法刪除與請求URI所指定資源之間的一個或多個連接關係。
D.2 附加標題域定義（Additional Header Field Definitions）
D.2.1 Accept
Accept請求標題域用於指示可被接受的請求迴應的介質範圍列表。星號"*"用於按範圍
將介質類型分組，用"*/*"指示可接受全部介質類型；用"type/*"指示可接受type類型的所有
子類型。對於給定請求的上下文，客戶端應當表示出哪些類型是它可以接受的。
D.2.2 可接受的字體集（Accept-Charset）
Accept-Charset請求標題域用來指示除了US-ASCII和ISO-8859-1外，首選的字符集。
該域將使客戶端有能力理解更廣泛的或有特殊用途的字符集，從而在服務器上可以存放採用
此類字符集的文檔。
D.2.3 可接受編碼（Accept-Encoding）
Accept-Encoding請求標題域與Accept相似，但是限制了迴應中可接受的內容編碼
（content-coding）值。
D.2.4 可接受語言（Accept-Language）
Accept-Language請求標題域與Accept相似，但限制了請求迴應中首選的自然語言集。
D.2.5 內容語言（Content-Language）
Content-Language實體標題域描述了附加實體中爲聽衆指定的自然語言。注意，這可能
與在實體內部使用的各種語言不是一碼事。
D.2.6 連接（Link）
Link實體標題域描述了實體和某些其它資源之間的關係。一個實體可能包括多個連接
值。處於元信息級的Link指明瞭分層結構和導航路徑之間的關係。
D.2.7 MIME版本（MIME-Version）
HTTP消息可能包括一個單獨的MIME版本的普通標題（general-header）域，用以指示
用來構造消息的MIME協議的版本。MIME版本標題域的使用，正如RFC1521[5]中定義的
那樣，應當用來指示消息是否符合MIME規範。然而不幸的是，一些老的HTTP/1.0服務器
不加選擇地發送此域，導致此域已經被廢棄。
D.2.8 在….後重試（Retry-After）
Retry-After迴應標題域可與503（服務不可用）迴應一起使用，用於指示服務器停止響
應客戶請求的時間長短。該域的值可用HTTP格式的日期表示，也可以用整數來表示迴應時
間後的秒數。
D.2.9 標題（Title）
Title實體標題域用於指示實體的標題。
D.2.10 URI
URI實體標題域可能包含一些或全部統一資源標識（Uniform Resource Identifiers），見
3.2節，通過這些標識來表示請求URI所指定的資源。並不擔保根據URI一定能夠找到指定
的資源。
RFC1945——Hyptertext Transfer Protocol – HTTP/1.0 超文本傳輸協議1.0
1
RFC文檔中文翻譯計劃