組織：中國互動出版網(wǎng)（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：黃曉東（黃曉東? xdhuang@eyou.com）
譯文發(fā)布時間：2001-7-14
版權：本中文翻譯文檔版權歸中國互動出版網(wǎng)所有。可以用于非商業(yè)用途自由轉載，但必須
保留本文檔的翻譯及版權信息。
Network Working Group? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? T. Berners-Lee
Request for Comments: 1945? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? MIT/LCS
Category: Informational? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? R. Fielding
UC Irvine
H. Frystyk
MIT/LCS
May 1996
超文本傳輸協(xié)議 -- HTTP/1.0
（Hyptertext Transfer Protocol – HTTP/1.0）
關于下段備忘（Status of This Memo）
本段文字為Internet團體提供信息，并沒有以任何方式指定Internet標準。本段文字沒
有分發(fā)限制。
IESG提示（IESG Note）：
IESG已在關注此協(xié)議，并期待該文檔能盡快被標準跟蹤文檔所替代。
摘要（Abstract）
HTTP（Hypertext Transfer Protocol）是應用級協(xié)議，它適應了分布式超媒體協(xié)作系統(tǒng)對
靈活性及速度的要求。它是一個一般的、無狀態(tài)的、基于對象的協(xié)議，通過對其請求方法
（request methods）進行擴展，可以被用于多種用途，比如命名服務器（name server）及分
布式對象管理系統(tǒng)。HTTP的一個特性是其數(shù)據(jù)表現(xiàn)類型允許系統(tǒng)的構建不再依賴于要傳輸
的數(shù)據(jù)。
HTTP自從1990年就在WWW上被廣泛使用。該規(guī)范反映了“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? 基本規(guī)則（Basic Rules） 10
3.? 協(xié)議參數(shù)（Protocol Parameters） 12
3.1? HTTP版本（HTTP Version） 12
3.2? 統(tǒng)一資源標識（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? 產(chǎn)品標識（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? 狀態(tài)行（Status-Line） 24
6.1.1 狀態(tài)代碼和原因分析（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.? 狀態(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? 客戶端錯誤（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? 轉換為規(guī)范形式（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）是應用級協(xié)議，它適應了分布式超媒體協(xié)作系統(tǒng)對
靈活性及速度的要求。它是一個一般的、無狀態(tài)的、基于對象的協(xié)議，通過對其請求方法
（request methods）進行擴展，可以被用于多種用途，比如命名服務器（name server）及分
布式對象管理系統(tǒng)。HTTP的一個特性是其數(shù)據(jù)表現(xiàn)類型允許系統(tǒng)的構建不再依賴于要傳輸
的數(shù)據(jù)。
HTTP自從1990年就在WWW上被廣泛使用。該規(guī)范反映了“HTTP/1.0”的普通用法。
該規(guī)范描述了在大多數(shù)HTTP/1.0客戶機及服務器上看起來已經(jīng)實現(xiàn)的特性。規(guī)范將被
分成兩個部分：HTTP特性的實現(xiàn)是本文檔的主要內容，而其它不太通行的實現(xiàn)將被列在附
錄D中。
實用的信息系統(tǒng)需要更多的功能，而不僅僅是數(shù)據(jù)的獲取，包括搜索、前端更新及注解。
HTTP允許使用開放的命令集來表示請求的目的，它使用基于URI[2]（Uniform Resource
Identifier），即統(tǒng)一資源標識的規(guī)則來定位（URL[4]）或命名（URN[16]）方法所用到的資
源。HTTP使用與郵件（Internet Mail [7]）和MIME（Multipurpose Internet Mail Extensions [5]）
相似的格式來傳遞消息。
HTTP也作為用戶代理、代理服務器/網(wǎng)關與其它Internet協(xié)議進行通訊的一般協(xié)議，這
些協(xié)議是，SMTP [12], NNTP [11], FTP [14], Gopher [1], and WAIS [8]等。HTTP允許不同的
應用可以進行基本的超媒體資源訪問，并簡化用戶代理的實現(xiàn)。
1.2? 術語（Terminology）
本規(guī)范用了許多與參與方、對象及HTTP通訊相關的術語，如下：
連接（connection）
兩個應用程序以通訊為目的在傳輸層建立虛擬電路。
消息（message）
HTTP通訊的基本單元，在連接中傳輸?shù)慕Y構化的、有順序的字節(jié)（其含義在第四
節(jié)中定義）。
請求（request）
HTTP的請求消息（在第五節(jié)定義）
回應（response）
HTTP的回應消息（在第六節(jié)定義）
資源（resource）
網(wǎng)絡上可以用URI來標識的數(shù)據(jù)對象或服務（見3.2節(jié)）
實體（entity）
可被附在請求或回應消息中的特殊的表示法、數(shù)據(jù)資源的表示、服務資源的回應等，
由實體標題（entity header）或實體主體（entity body）內容形式存在的元信息組成。
客戶端（client）
指以發(fā)出請求為目的而建立連接的應用程序。
用戶代理（user agent）
指初始化請求的客戶端，如瀏覽器、編輯器、蜘蛛（web爬行機器人）或其它終端
用戶工具。
服務器（server）
指接受連接，并通過發(fā)送回應來響應服務請求的應用程序。
原始服務器（origin server）
存放資源或產(chǎn)生資源的服務器。
代理（proxy）
同時扮演服務器及客戶端角色的中間程序，用來為其它客戶產(chǎn)生請求。請求經(jīng)過變
換，被傳遞到最終的目的服務器，在代理程序內部，請求或被處理，或被傳遞。代
理必須在消息轉發(fā)前對消息進行解釋，而且如有必要還得重寫消息。代理通常被用
作經(jīng)過防火墻的客戶端出口，用以輔助處理用戶代理所沒實現(xiàn)的請求。
網(wǎng)關（gateway）
服務器之間的服務器。與代理不同，網(wǎng)關接受請求就好象它就是被請求資源所在的
原始服務器，發(fā)出請求的客戶端可能并沒有意識到它在與網(wǎng)關進行通訊。網(wǎng)關是網(wǎng)
絡防火墻服務器端的門戶。對非HTTP系統(tǒng)資源進行訪問時，網(wǎng)關做為中間的協(xié)議
翻譯者。
隧道（tunnel）
隧道就好象連接兩端看不見的中繼器。處于激活狀態(tài)時，它雖然是由HTTP請求來
初始化的，但它并不參與HTTP通訊。當需要中繼連接的兩端關閉后，隧道也自然
終止。在入口有需求及中間程序無法或不該解釋要中繼的通訊時，通常要用到隧道
技術。
緩存（cache）
指程序本地存儲的回應消息和用來控制消息存儲、重獲、刪除的子系統(tǒng)。
緩存回應的目的是為減少請求回應時間，以及未來一段時間對網(wǎng)絡帶寬的消耗。任
何客戶端及服務端都可以包含緩存。服務器在以隧道方式工作時不能使用緩存。
任何指定的程序都有能力同時做為客戶端和服務器。我們在使用這個概念時，不是看程
序功能上是否能實現(xiàn)客戶及服務器，而是看程序在特定連接時段上扮演何種角色（客戶或服
務器）。同樣，任何服務器可以扮演原始服務器、代理、網(wǎng)關、隧道等角色，行為的切換取
決于每次請求的內容。
1.3? 概述（Overall Operation）
HTTP協(xié)議是基于請求/回應機制的。客戶端與服務器端建立連接后，以請求方法、URI、
協(xié)議版本等方式向服務器端發(fā)出請求，該請求可跟隨包含請求修飾符、客戶信息、及可能的
請求體（body）內容的MIME類型消息。
服務器端通過狀態(tài)隊列（status line）來回應，內容包括消息的協(xié)議版本、成功或錯誤代
碼，也跟隨著包含服務器信息、實體元信息及實體內容的MIME類型消息。
絕大多數(shù)HTTP通訊由用戶代理進行初始化，并通過它來組裝請求以獲取存儲在一些原
始服務器上的資源。在最簡單的情況下，通過用戶代理（UA）與原始服務器（O）之間一
個簡單的連接（v）就可以完成。
request chain ------------------------>
UA -------------------v------------------- O
<----------------------- response chain
更復雜的情況是當請求/回應鏈之間存在一個或更多中間環(huán)節(jié)。總體看來，有三種中間
環(huán)節(jié)：代理（proxy）、網(wǎng)關（gateway）、隧道（tunnel）。
代理（proxy）是向前推送的代理人（agent），它以絕對形式接收URI請求，重寫全部
或部分消息，并將經(jīng)過改寫的請求繼續(xù)向URI中指定的服務器處推送。
網(wǎng)關是接收代理，它處于服務器層之上，在必要時候，它用服務器可識別的協(xié)議來傳遞
請求。
隧道不改變消息，它只是連接兩端的中繼點。在有中間層（如防火墻）或中間層無法解
析消息內容的情況下，需要靠隧道技術來幫助通訊穿越中間層。
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- response chain
上面的圖形表示在用戶代理和原始服務器之間有三個中間層（A，B和C）。由圖可見，
請求或回應消息在整個信息鏈上運行需要通過四個單獨的連接，它與在此之前介紹的簡單情
況是有區(qū)別的，而且此區(qū)別是十分重要的。因為HTTP通訊選項可以設置成幾種情況，如只
與最近的非隧道鄰居連接、只與信息鏈末端連接、或者可與鏈中全部環(huán)節(jié)連接等等。雖然上
面的圖是線性的，而實際上每個參與環(huán)節(jié)都在同時與多方進行通訊活動。例如，B在接受除
A之外其它客戶端請求的同時，向除C之外的其它服務器推送請求，在這個時刻，它可能
接受到A的請求，并給予處理。
參與通訊的任何一方如果沒有以隧道方式進行工作，必須要借助內部緩存機制來處理請
求，如果鏈上某個參與方碰巧緩存了某個請求的回應，那就相應于縮短了請求/回應鏈。下
面的圖例演示了當B緩存了從O經(jīng)由C過來的回應信息，而UA和A沒緩存的情況：
request chain ---------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
<--------- response chain
并非所有的回應都可以被緩存，某些請求所包含的修飾符中可能對緩存行為進行了特別
指明。一些基于HTTP/1.0的應用使用了啟發(fā)式的方法來描述哪些回應可被緩存，而哪些則
不可以，但遺憾的是，這些規(guī)則并沒有形成標準。
在Internet上，HTTP通訊往往基于TCP/IP的連接方式。缺省的端口是TCP 80[15]口，
但也可以使用其它端口。并不排除基于Ineternet上的其它協(xié)議或網(wǎng)絡協(xié)議的HTTP實現(xiàn)方
式，HTTP只是假定傳輸是可靠的，因而任何能提供這種保證的協(xié)議都可以被使用。至于
HTTP/1.0請求和回應在數(shù)據(jù)傳輸過程中的數(shù)據(jù)結構問題，不在本文討論范圍之內。
實驗室應用除外，當前的做法是客戶端在每次請求之前建立連接，而服務器端在發(fā)送回
應后關閉此連接。不管客戶端還是服務器端都應注意處理突發(fā)的連接中斷，因為雙方都有可
能因為用戶操作、自動超時、程序失敗等原因關閉與對方的連接。在這種情況下，不管請求
處于什么樣的狀態(tài)，如單方或雙方同時關閉連接，都會導致當前的請求被終止。
1.4? HTTP and MIME
HTTP/1.0使用了多種結構來定義MIME，詳見RFC1521[5]。附錄C描述了Internet承
認的Internet介質類型與mail介質類型的不同工作方式，并給出二者區(qū)別的基本解釋。
2.? 標志轉換及通用語法（Notational Conventions and
Generic Grammar）
2.1? 補充反饋方式（Augmented BNF）
與RFC822[7]很類似，本文對所有機制的說明都是以散文和補充反饋的方式來描述的。
對于實現(xiàn)者來說，要想理解這些約定，必須對這些符號很熟悉。補充反饋方式（augmented
BNF）包括下面的結構：
要解釋的名詞＝名詞解釋（name = definition）
規(guī)則的名字（name）就是它本身（不帶任何尖括號，“<”，“>”），后面跟個等號＝，
然后就是該規(guī)則的定義。如果規(guī)則需要用多個行來描述，利用空格進行縮進格式排
版。某些基本的規(guī)則使用大寫，如SP, LWS, HT, CRLF, DIGIT, ALPHA,等等。定義
中還可以使用尖括號來幫助理解規(guī)則名的使用。
字面意思（"literal"）
文字的字面意思放在引號中間，除非特別指定，該段文字是大小寫敏感的。
規(guī)則1｜規(guī)則2（rule1 | rule2）
“｜”表示其分隔的元素是可選的，比如，“是｜否”要選擇‘是’或‘否’。
（規(guī)則1 規(guī)則2）（(rule1 rule2)）
在圓括號中的元素表明必選其一。如（元素1（元素2｜元素3）元素4）可表明兩
種意思，即“元素1 元素2 元素4”和“元素1 元素3 元素4”
*規(guī)則（*rule）
在元素前加星號“*”表示循環(huán)，其完整形式是“*元素”，表明元素最少產(chǎn)
生次，最多次。缺省值是0到無限，例如，“1*元素”意思是至少有一個，
而“1*2元素”表明允許有1個或2個。
［規(guī)則］（[rule]）
方括號內是可選元素。如“［元素1 元素2］”與“*1（元素1 元素2）”是一回
事。
N 規(guī)則（N rule）
表明循環(huán)的次數(shù)：“（元素）”就是“*（元素）”，也就是精確指出
取值。因而，2DIGIT 就是2位數(shù)字, 3ALPHA 就是由三個字母組成字符串。
＃規(guī)則（#rule）
“#”與“*”類似，用于定義元素列表。
完整形式是“#元素”表示至少有個至多有個元素，中間用“,”或
任意數(shù)量的空格（LWS-linear whitespace）來分隔，這將使列表非常方便，如“（*LWS
元素 *（ *LWS "," *LWS 元素 ））”就等同于“1#元素”。
空元素在結構中可被任意使用，但不參與元素個數(shù)的計數(shù)。也就是說，“（元素1），，
（元素2）”僅表示2個元素。但在結構中，應至少有一個非空的元素存在。缺省
值是0到無限，即“#（元素）”表示可取任何數(shù)值，包括0；而“1#元素”表示至
少有1個；而“1#2元素”表示有1個或2個。
；注釋（; comment）
分號后面是注釋，僅在單行使用。
隱含*LWS（implied *LWS）
本文的語法描述是基于單詞的。除非另有指定，線性空格（LWS）可以兩個鄰近符
號或分隔符（tspecials）之間任意使用，而不會對整句的意思造成影響。在兩個符號之
間必須有至少一個分隔符，因為它們也要做為單獨的符號來解釋。實際上，應用程序在
產(chǎn)生HTTP結構時，應當試圖遵照“通常方式”，因為現(xiàn)在的確有些實現(xiàn)方式在通常方
式下無法正常工作。
2.2? 基本規(guī)則（Basic Rules）
下面的規(guī)則將用于本文后面對結構基本解析。
US-ASCII 編碼字符集定義[17]。
OCTET = <8-bit的順序數(shù)據(jù)，即bytes>
CHAR = < US-ASCII字符（取值為0 – 127的OCTET）>
UPALPHA = < US-ASCII 大寫字符"A"到"Z">
LOALPHA =
ALPHA = UPALPHA | LOALPHA
DIGIT = < US-ASCII 數(shù)字"0"到"9">
CTL = < US-ASCII 控制字符（取值0到31的octet ）和DEL （127）>
CR =
LF =
SP =
HT =
<"> =
HTTP/1.0規(guī)定，除實體主體（Entity-Body，見附錄B容錯應用）外，所有協(xié)議元
素的行結束標志都是CRLF（按字節(jié)順序）。在實體主體內部的行結束標志定義及
其對應的介質類型定義，見3.6節(jié)的描述。
CRLF = CR LF
HTTP/1.0的頭可以折成許多行，只要每個后續(xù)行以空格或水平制表符開頭。所有
的線性空格（LWS），同空格（SP）有相同的語義。
LWS = [CRLF] 1*( SP | HT )
實際上，有些應用并沒有考慮處理這樣多行的頭，所以從兼容性上考慮，HTTP/1.0
應用最好不要產(chǎn)生折成多行的頭。
TEXT規(guī)則只是用于描述消息解釋器不關心的域的內容及其取值。文本內容可包含
不同于US-ASCII的字符。
TEXT = <除了控制字符（CTLs）之外的任何OCTET，包括LWS >
在標題域中的收件人域如包含US-ASCII字符集以外的字符，這些字符將按照
ISO-8859-1標準來解釋。
十六進制數(shù)字型字符在幾個協(xié)議元素中到。
HEX = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
許多HTTP/1.0頭域的內容由被LWS分隔的單詞或特殊字符組成，這些特殊字符
必須置于引號中間的字符串內，作為參數(shù)值使用。
Word = 符號（token）| 被引號引起來的字符串
token = 1*<除控制字符（CTLs）或tspecials之外的任意字符>
tspecials ? ? = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
在HTTP頭域中可用括號表示注釋文字。注釋只允許寫在包含注釋的域，做為域值
定義的一部分。在除此之外其它域中，括號將被視為域值。
comment = "(" *( ctext | comment ) ")"
ctext = <除圓括號外的任何TEXT>
被雙引號圈中的文本字符串將被視為一個單詞。
quoted-string = ( <"> *(qdtext) <"> )
qdtext = <除了雙引號及控制字符之外的任何字符，包括LWS >
在HTTP/1.0中不允許使用后斜線“\”來引用單字符。
3.? 協(xié)議參數(shù)（Protocol Parameters）
3.1? HTTP版本（HTTP Version）
HTTP采用主從（.）數(shù)字形式來表示版本。協(xié)議的版本政策傾向于讓發(fā)
送方表明其消息的格式及功能，而不僅僅為了獲得通訊的特性，這樣做的目的是為了與更高
版本的HTTP實現(xiàn)通訊。只增加擴展域的值或增加了不影響通訊行為的消息組件都不會導致
版本數(shù)據(jù)的變化。當協(xié)議消息的主要解析算法沒變，而消息語法及發(fā)送方的隱含功能增加了，
將會導致從版本號（）增加；當協(xié)議中消息的格式變化了，主版本號（）也
將發(fā)生改變。
HTTP消息的版本由消息第一行中的HTTP版本域來表示。如果消息中的協(xié)議版本沒有
指定，接收方必須假定它是符合HTTP/0.9的簡單標準。
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
注意，主從版本應當被看作單獨的整數(shù)，因為它們都有可能增加，從而超過一位整
數(shù)。因而，HTTP/2.4比HTTP/2.13版本低，而HTTP/2.13又比HTTP/12.3版本低。
版本號前面的0將被接收方忽略，而在發(fā)送方處也不應產(chǎn)生。
本文檔定義了HTTP協(xié)議的0.9及1.0版本。發(fā)送完整請求（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 使用與客戶端相同版本的協(xié)議進行消息回應。
HTTP/1.0 客戶端必須：
o 識別HTTP/1.0回應中狀態(tài)隊列（Status-Line）的格式。
o 理解HTTP/0.9及HTTP/1.0中合法回應的格式。
當代理及網(wǎng)關收到與其自身版本不同的HTTP請求時，必須小心處理請求的推送，因為
協(xié)議版本表明發(fā)送方的能力，代理或網(wǎng)關不應發(fā)出高于自身版本的消息。如果收到高版本的
請求，代理或網(wǎng)關必須降低該請求的版本，并回應一個錯誤。而低版本的請求也應在被推送
前升級。
代理或網(wǎng)關回應請求時必須遵照前面列出的規(guī)定。
3.2? 統(tǒng)一資源標識（Uniform Resource Identifiers）
URI有許多名字，如WWW地址、通用文件標識（Universal Document Identifiers）、通
用資源標識（Universal Resource Identifiers [2]），以及最終的統(tǒng)一資源定位符（Uniform
Resource Locators (URL) [4]）和統(tǒng)一資源名（URN）。在涉及HTTP以前，URI用簡單格式
的字符串描述－名字、位置、或其它特性，如網(wǎng)絡資源。
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? ? ? = "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? ? ? =
reserved, extra, safe, and unsafe>
權威的URL語法及語義信息請參見RFC1738[4]和RFC1808[9]。上面所提到的BNF中
包括了合法URL中不允許出現(xiàn)的符號（RFC1738），因為HTTP服務器并沒有限制為只能用
非保留字符集中的字符來表示地址路徑，而且HTTP代理也可能接收到RFC1738沒有定義
的URI請求。
3.2.2 http URL
“http”表示要通過HTTP協(xié)議來定位網(wǎng)絡資源。本節(jié)定義了HTTP URL的語法和語義。
http_URL? ? ? = "http:" "http://" host [ ":" port ] [ abs_path ]
host? ? ? ? ? = <合法的Internet主機域名或IP地址（用十進制數(shù)及點組成）
，見RFC1123，2.1節(jié)定義>
port? ? ? ? ? = *DIGIT
如是端口為空或沒指定，則缺省為80端口。對于絕對路徑的URI來說，擁有被請求的
資源的服務器主機通過偵聽該端口的TCP連接來接收該URI請求。如果URL中沒有給出
絕對路徑，要作為請求URI（參見5.1.2節(jié)）使用，必須以“/”形式給出。
注意：雖然HTTP協(xié)議獨立于傳輸層協(xié)議，http URL只是標識資源的TCP位置，而對
于非TCP資源來說，必須用其它的URI形式來標識。
規(guī)范的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]）。第二種格
式在普通情況下使用，但是它是基于已經(jīng)廢棄的RFC850[10]中的日期格式，而且年不是用
四位數(shù)字表示的。HTTP/1.0 客戶端及服務器端在解析日期時可識別全部三種格式，但是它
們不可以產(chǎn)生第三種時間格式(asctime) 。
注意：對于接收到由非HTTP應用產(chǎn)生的日期數(shù)據(jù)時，提倡對接收到的日期值進行填充。
這樣做是因為，在某些時候，代理或網(wǎng)關可能通過SMTP或NNTP來獲取或發(fā)送消息。
所有的HTTP/1.0 date/timp時間戳必須用世界時間（Universal Time，UT），即格林威治
時間來表示（Greenwich Mean Time，GMT），沒有任何修改的余地。前面的兩種格式用了
“GMT”表示時區(qū)，在讀ASC表示的時間時，也應假定是這個時區(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時間戳格式，不要求客戶端及服務
器端在用戶描述、請求登錄等情況下使用這類格式。
3.4? 字符集（Character Sets）
HTTP所使用的字符集定義和描述MIME時用的相同：
本文檔用字符集（character set）來指明利用一個或多個表將順序字節(jié)轉換成順序字
符的方法。注意，不需要其它方向的無條件轉換，因為不是所有的字符都可以用給
定字符集來表示，同時，一個字符集也可能提供一種以上的字節(jié)順序來表示一種特
殊的字符。這種定義傾向于允許不同類型的字符編碼通過簡單的單表映射來實現(xiàn)，
如，從表US-ASCII切換到復雜表如ISO2202。實際上，與MIME字符集名相關的
定義必須完整指定從字節(jié)到字符的映射，特別是不允許通過利用外部配置信息來確
定精確的映射。
注意：術語字符集（character set）歸于字符編碼（character encoding）。事實上，
由于HTTP與MIME共同使用同樣的注冊，所以其術語也應一致。
HTTP字符集由大小寫敏感的符號組成。全部的符號定義參見IANA字符集注冊
[15]。因為注冊處不會為每個字符集單獨定義一套符號，所以我們在這看到的字符
集名大多是與HTTP實體使用相關的。這些在RFC 1521 [5] 中注冊的字符集，即
US-ASCII [17] 及ISO-8859 [18]字符集，還有一些其它字符集被強烈建議在MIME
字符集參數(shù)內部使用。
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注冊表規(guī)定的范圍之內。
實體主體的字符集如果屬于US-ASCII 或ISO-8859-1字符集，則勿需標記，否則，
應當用主體字符編碼方式中的最基本命名來標記。
3.5? 內容譯碼（Content Codings）
內容譯碼值用于指示對資源進行的編碼轉換。內容譯碼主要用于將經(jīng)過壓縮、加密等操
作的文件進行還原，使其保持其原來的介質類型。典型情況下，經(jīng)過編碼保存的資源只能經(jīng)
過解碼或類似的操作才能還原。
content-coding = "x-gzip" | "x-compress" | token
注意：出于對未來兼容性的考慮，HTTP/1.0應用應將"gzip" 和"compress" 分別與
"x-gzip"和"x-compress"對應起來。
所有的內容譯碼值都是大小寫敏感的。HTTP/1.0在內容編碼（10.3節(jié)）頭域中使用內
容譯碼值。雖然該值描述的是內容譯碼，但更為重要的是，它指明了應當用什么機制來進行
解碼。注意，單獨的程序可能有能力實現(xiàn)對多種格式編碼的解碼。
在這段文字中，提到了兩個值：
x-gzip
文件壓縮程序"gzip" (GNU zip，由Jean-loup Gailly開發(fā))的編碼格式。該格式屬于
典型的帶有32位CRC 校驗的Lempel-Ziv譯碼 (LZ77)。
x-compress
文件壓縮程序"compress"的編碼格式，該格式適用于LZW（Lempel-Ziv-Welch）譯
碼。
注意：用程序名來標識編碼格式的做法不是很理想，在將來可能不會繼續(xù)這樣做。現(xiàn)在
之所以這樣做是出于歷史的原因，并非良好的設計。
3.6? 介質類型（Media Types）
HTTP在Content-Type header域（10.5節(jié)）中使用Internet介質類型[13]，用以提供開放
的可擴展的數(shù)據(jù)類型。
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
參數(shù)可參照屬性/值對的方式，用類型/子類型的格式來寫。
Parameter = attribute "=" value
Attribute = token
Value = token | quoted-string
其中，類型、子類型、參數(shù)屬性名是大小寫敏感的。而參數(shù)值不一定是大小寫敏感的，
這得看參數(shù)名的語法而定。在類型和子類型、屬性名和屬性值之間不能有LWS（空格）。當
接收到不能識別的介質類型的參數(shù)時，用戶代理應當忽略它們。
一些老的HTTP應用不能識別介質類型參數(shù)，所以HTTP/1.0的應用程序只能在定義消
息內容時使用介質參數(shù)。
介質參數(shù)（Media-type）值用Internet授權分配數(shù)字（Internet Assigned Number
Authority ，IANA [15]）注冊。介質類型注冊過程請參見RFC1590[13]。不鼓勵使用未注冊
的介質類型。
3.6.1標準及文本缺省（Canonicalization and Text Defaults）
Internet介質類型是用規(guī)范形式注冊的。一般來說，在通過HTTP協(xié)議傳輸實體主體
（Entity-Body）之前，必須先將其表示成適當?shù)囊?guī)范格式。如果主體用使用了一種
Content-Encoding進行編碼，下面的數(shù)據(jù)在編碼前必須轉換成規(guī)范形式：
"text"類型的介質子類型在規(guī)范形式中使用CRLF做為文本行中斷。實際上，為和實體
主體（Entity body）內的使用方式保持一致，HTTP允許傳輸純以CR或LF單獨表示行中斷
的文本介質。HTTP應用程序必須將其通過HTTP方式接收到的文本介質中的CRLF、CR、
LF看做是行中斷符。
另外，如果文本介質的字符集沒有使用字節(jié)13和10做為CR和LF，象一些多字節(jié)字
符集，HTTP允許使用該字符集指定的任何順序的字節(jié)替代CR和LF做為行中斷，這種行
中斷的靈活運用方式僅可于實體主體（Entity-Body）中。一個純CR或LF不應在任何HTTP
控制結構（如標題域-header field和多塊分界線-multipart boundaries）中替代CRLF。
參數(shù)"charset"在定義數(shù)據(jù)的字符集（3.4節(jié)）時，與一些介質類型一起使用。當發(fā)送方
沒有顯式給出字符參數(shù)時，HTTP在接收時將"text"的介質子類型定義為缺省
值"ISO-8859-1"。"ISO-8859-1"字符集或其子集以外的數(shù)據(jù)必須要標記其相應的字符集值，
這樣可以保證接收方能正確地對其進行解析。
注意：許多當前HTTP服務器提供的數(shù)據(jù)使用"ISO-8859-1"以外的其它字符集，而且也
沒有正確的進行標記，這種工作方式限制了互操作性，建議不要采用。做為一種補救方法，
一些HTTP用戶代理提供了配置選項，使用戶可以在字符集參數(shù)沒指定的情況下，自行更改
缺省的介質類型解釋方式。
3.6.2 多部分類型（Multipart Types）
MIME提供了多部分（"multipart"）類型的數(shù)字――在一個單獨的消息實體主體
（Entity-Body）內可以封裝幾個實體（entities）。雖然用戶代理可能需要了解每種類型，從
而可以正確解釋每部分主體的意圖，但是在IANA[15]的多部分類型（multipart types）注冊
中卻找不到專為HTTP/1.0所指定的內容。HTTP用戶代理只得自己來做接收多部分類型的
工作，其過程和行為與MIME用戶代理是相同或相似的。HTTP服務器不應假定HTTP客戶
端都有能力處理多部分類型。
所有的多部分類型都使用通用的語法，而且必須在介質類型值部分包括邊界參數(shù)
（boundary parameter）。消息的主體是其自身，做為協(xié)議元素，它必須只使用CRLF做為段
間（body-parts）的行中斷符。多段主體（Multipart body-parts）中可能包括對各段有重要意
義的HTTP標題域。
3.7? 產(chǎn)品標識（Product Tokens）
是通訊應用程序用來標識其自身的一個簡單符號，常和任意字母及版本描述一起使用。
大多數(shù)產(chǎn)品標識也將其產(chǎn)品的重要組成部分的版本號一起列出，中間用空格分隔。
按慣例，在標識應用程序時，組件以其重要性順序排列。
Product = token ["/" product-version]
product-version = token
例如：
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
產(chǎn)品標識應當短小，因而禁止利用該域填寫廣告或其它無關信息。雖然任何符號字符都
可能出現(xiàn)在產(chǎn)品版本中，該符號應當只用于做版本定義，也就是說，同一個產(chǎn)品的連續(xù)版本
之間只能通過產(chǎn)品版本值進行區(qū)分。
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]中實體傳
輸部分規(guī)定的消息格式。兩者的消息都可能包括標題域（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節(jié)）、請求標題（Request-Header ,5.2節(jié)）、
回應標題（Response-Header ,6.2節(jié)）及實體標題（Entity-Header,7.1節(jié)），都遵照RFC822-3.1
節(jié)[7]給出的通用格式定義。每個標題域由后緊跟冒號的名字，單空格（SP），字符及域值組
成。域名是大小寫敏感的。雖然不提倡，標題域還是可以擴展成多行使用，只要這些行以一
個以上的SP或HT開頭就行。
HTTP-header = field-name ":" [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content =
and consisting of either *TEXT or combinations
of token, tspecials, and quoted-string>
標題域接收的順序并不重要，但良好的習慣是，先發(fā)送主標題，然后是請求標題或回應
標題，最后是實體標題。
當且僅當標題域的全部域值都用逗號分隔的列表示時（即，#（值）），多個有相同域名
的HTTP標題域才可以表示在一個消息里。而且必須能在不改變消息語法的前提下，將并發(fā)
的域值加到第一個值后面，之間用逗號分隔，最終能將多個標題域結合成“域名：域值”對。
4.3? 普通標題域（General Header Fields）
有幾種標題域是請求與回應都要使用的，但并不用于被傳輸?shù)膶嶓w。這些標題只用于被
傳輸?shù)南ⅰ?/p>
General-Header = Date ; Section 10.6
| Pragma ; Section 10.12
普通標題域名稱只有在與協(xié)議版本的變化結合起來后，才能進行可靠的擴展。實際上，
新的或實驗中的標題域只要能被通訊各方識別，其語法就可使用，而無法識別的標題域都將
被視為實體域。
5. 請求（Request）
從客戶端到服務器端的請求消息包括，消息首行中，對資源的請求方法、資源的標識符
及使用的協(xié)議。考慮到局限性更大的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的客戶端有能力接收完整回應，但不能產(chǎn)生簡單請求。
5.1? 請求隊列（Request-Line）
請求隊列以一個方法符號開頭，跟在請求URI及協(xié)議版本的后面，以CRLF為結尾。
該元素用空格SP分隔。除了最后的CRLF，不允許出現(xiàn)單獨的CR或LF符。
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
注意，簡單請求與完整請求的請求隊列之間的區(qū)別在于是否有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
可以訪問指定資源的方法列表是可以動態(tài)變化的；如果用某種方法訪問資源被拒絕，客
戶端可從回應中的返回碼得到通知。服務器端在方法無法識別或沒有實現(xiàn)時，返回狀態(tài)代碼
501（尚未沒實現(xiàn)）。
這些方法被HTTP/1.0的應用程序普遍使用，完整定義請參見第8節(jié)。
5.1.2 請求URI（Request-URI）
請求URI就是統(tǒng)一資源標識符（3.2節(jié)），用來標識要請求的資源。
Request-URI = absoluteURI | abs_path
上面兩種請求URI方式可根據(jù)實際的請求方式選擇使用。
絕對URI（absoluteURI）格式只在代理（proxy）在產(chǎn)生請求時使用。代理的責任是將
請求向前推送，并將回應返回。如果請求是GET或HEAD方式，而且之前的回應被緩存，
如果代理忽略標題域的過期信息限制，它可能使用緩存中的消息。注意，代理可能將請求推
送至另外一個代理，也可將請求直接送至絕對URI中所指定的目的服務器。為了避免請求
循環(huán)，代理必須能夠識別它的所有服務器名，包括別名、本地變量及數(shù)字形式的IP地址。
下面是一個請求隊列的例子：
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0
最普通的請求URI形式就是原始服務器或網(wǎng)關用來標識資源的方式。在這種方式下，
只有給出絕對路徑的URI才能被傳輸（見3.2.1節(jié)）。例如，如客戶端希望直接從原始服務
器上接收資源，它們將產(chǎn)生一個與主機"www.w3.org"80端口的TCP連接，并在完整請求之
后發(fā)送下面的命令：
GET /pub/WWW/TheProject.html HTTP/1.0
注意絕對路徑不可以為空，如果URI中沒有內容，也必須加上一個"/"（server root）。
請求URI以編碼字符串方式傳輸，有些字符可能在傳輸過程中被轉義（escape），如變
成“%HEXHEX”形式。具體這方面內容請參見RFC1738[4]。原始服務器在正確解釋請求
之前必須對請求URI進行解碼。
5.2? 請求標題域（Request Header Fields）
請求標題域允許客戶端向服務器端傳遞該請求的附加信息及客戶端信息。該域做為請求
的修飾部分，遵照編程語言程序調用參數(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
請求標題域名只有在與協(xié)議版本的變化結合起來后，才能進行可靠的擴展。實際上，新
的或實驗中的標題域只要能被通訊各方識別，其語法就可使用，而無法識別的標題域都將被
視為實體域。
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方式
回應。如果客戶端發(fā)送HTTP/1.0完整請求后，接收到的回應不是以狀態(tài)行（Status-Line）
開頭的，客戶端將其視為簡單回應，并相應對其進行分析。注意，簡單請求只包括實體主體，
它在服務器端關閉連接時終止。
6.1? 狀態(tài)行（Status-Line）
完整回應消息的第一行就是狀態(tài)行，它依次由協(xié)議版本、數(shù)字形式的狀態(tài)代碼、及相應
的詞語文本組成，各元素間以空格（SP）分隔，除了結尾的CRLF外，不允許出現(xiàn)單獨的
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ū)分完整請求和簡單請求。簡單回應可能允許這種表達式出現(xiàn)在
實體主體的開始部分，但會引起消息的誤解。因為大多數(shù)HTTP/0.9的服務器都只能回
應"text/html"類型，在這種情況下，不可能產(chǎn)生完整的回應。
6.1.1 狀態(tài)代碼和原因分析（Status Code and Reason
Phrase）
狀態(tài)代碼（Status-Code）由3位數(shù)字組成，表示請求是否被理解或被滿足。原因分析是
用簡短的文字來描述狀態(tài)代碼產(chǎn)生的原因。狀態(tài)代碼用來支持自動操作，原因分析是為人類
用戶準備的。客戶端不需要檢查或顯示原因分析。
狀態(tài)代碼的第一位數(shù)字定義了回應的類別，后面兩位數(shù)字沒有具體分類。首位數(shù)字有5
種取值可能：
o 1xx:：保留，將來使用。
o 2xx：成功 － 操作被接收、理解、接受（received, understood, accepted）。
o 3xx：重定向（Redirection）－ 要完成請求必須進行進一步操作。
o 4xx：客戶端出錯 － 請求有語法錯誤或無法實現(xiàn)。
o 5xx：服務器端出錯 － 服務器無法實現(xiàn)合法的請求。
HTTP/1.0的狀態(tài)代碼、原因解釋在下面給出。下面的原因解釋只是建議采用，可任意
更改，而不會對協(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? = *
HTTP狀態(tài)代碼是可擴展的，而只有上述代碼才可以被當前全部的應用所識別。HTTP
應用不要求了解全部注冊的狀態(tài)代碼，當然，如果了解了更好。實際上，應用程序必須理解
任何一種狀態(tài)代碼，如果碰到不識別的情況，可根據(jù)其首位數(shù)字來判斷其類型并處理。另外，
不要緩存無法識別的回應。
例如，如果客戶端收到一個無法識別的狀態(tài)碼431，可以安全地假定是請求出了問題，
可認為回應的狀態(tài)碼就是400。在這種情況下，用戶代理應當在回應消息的實體中通知用戶，
因為實體中可以包括一些人類可以識別的非正常狀態(tài)的描述信息。
6.2? 回應標題域（Response Header Fields）
回應標題域中包括不能放在狀態(tài)行中的附加回應信息。該域還可以存放與服務器相關的
信息，以及在對請求URI所指定資源進行訪問的下一步信息。
Response-Header = Location ; Section 10.11
| Server ; Section 10.14
| WWW-Authenticate ; Section 10.16
回應標題域名只有在與協(xié)議版本的變化結合起來后，才能進行可靠的擴展。實際上，新
的或實驗中的標題域只要能被通訊各方識別，其語法就可使用，而無法識別的標題域都將被
視為實體域。
7.? 實體（Entity）
完整請求和完整回應消息可能會傳輸請求或回應中的實體。實體由實體標題
（Entity-Header）域、（通常還有）實體主體（Entity-Body）組成。從這種角度看，客戶端
與服務器都將扮演發(fā)送方及接收方的角色。某一時刻的角色定位則取決于在這個時刻誰在發(fā)
送實體，而誰又在接收實體。
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）機制允許在不改變協(xié)議的前提下定義附加的實體標題域，
但是不能假定接收方可以識別這些域。對于不可識別的標題域，接收方一般是忽略不管，而
代理則繼續(xù)將其向前推送。
7.2? 實體主體（Entity Body）
與HTTP請求或回應一起發(fā)送的實體主體的格式和編碼信息都在實體標題域
（Entity-Header）中定義。
Entity-Body? ? = *OCTET
實體主體只在請求方法有要求時才會被放在請求消息中。請求消息標題域處的內容長度
標題域（Content-Length header field）的標志將指明請求中的實體主體是否存在。包含實體
主體的HTTP/1.0請求必須包含合法的內容長度標題域。
對回應消息來說，消息中是否包含實體主體取決于請求方法和回應代碼。所有的HEAD
請求方法的回應都不應包括主體，即便是實體標題域中指明有主體也一樣。在主體中不應包
括這些回應信息，全部1xx（信息）、204（無內容）和304（未修改）。而其它的回應必須包
括實體主體或其內容長度標題（Content-Length header）域的定義值為0。
7.2.1 類型（Type）
當消息中包括實體主體，主體的數(shù)據(jù)類型由標題域中的內容類型（Content-Type）和內
容編碼（Content-Encoding）決定。定義了二層順序編碼模式：
entity-body := Content-Encoding( Content-Type( data ) )
內容類型（Content-Type）指定了下列數(shù)據(jù)的介質類型（media type）。內容編碼
（Content-Encoding）可用于指示附加內容解碼方式，通常用于有數(shù)據(jù)壓縮屬性的被請求資
源。內容編碼的缺省值是none。
任何包括實體主體的消息必須含有內容類型（Content-Type）標題域，以定義主體的類
型。只有當內容類型標題域中沒有給出介質類型時，如簡單回應消息，接收方可能對該URL
所指定的資源進行判斷，如其內容及擴展名等等，從而猜測出該主體的介質類型。如果還無
法確定介質類型，接收方應當將其視為" application/octet-stream"型。
7.2.2 長度（Length）
當實體主體被包括在消息中，主體長度可以有兩種方式確定。如果內容長度
（Content-Length）標題域存在，其字節(jié)值就是實體主體長度；否則，其主體長度由服務端
關閉連接時確定。
由于服務端無法在連接關閉時發(fā)送回應信息，所以不能用關閉連接來指示請求主體的結
束。因而，HTTP/1.0請求如果包含主體，就必須在內容長度（Content-Length）標題域中給
出合法的值。如果請求包括實體主體，且內容長度沒指定，服務端將無法識別或無法從其它
域中計算出其主體長度，在這種情況下，服務端將會返回400（非法請求）回應。
注意：一些老的服務器在發(fā)送包含由服務器端動態(tài)插入的數(shù)據(jù)流文件時，支持非法的內
容長度使用。要強調的是，未來版本的HTTP協(xié)議將會很快改變這種情況。除非客戶端自己
知道正在從一個支持它的服務器端得到回應，否則不應依賴于內容長度域的正確性。
