組織：中國互動出版網(wǎng)（http://www.china-pub.com/）

RFC文檔中文翻譯計(jì)劃（http://www.china-pub.com/compters/emook/aboutemook.htm）

E-mail：ouyang@china-pub.com

譯者：黃曉東（黃曉東? xdhuang@eyou.com）

譯文發(fā)布時(shí)間：2001-7-14

版權(quán)：本中文翻譯文檔版權(quán)歸中國互動出版網(wǎng)所有狞贱∶壳欤可以用于非商業(yè)用途自由轉(zhuǎn)載，但必須

保留本文檔的翻譯及版權(quán)信息。

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）

關(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)用級協(xié)議蛇损，它適應(yīng)了分布式超媒體協(xié)作系統(tǒng)對

靈活性及速度的要求赁温。它是一個(gè)一般的坛怪、無狀態(tài)的、基于對象的協(xié)議股囊，通過對其請求方法

（request methods）進(jìn)行擴(kuò)展袜匿，可以被用于多種用途，比如命名服務(wù)器（name server）及分

布式對象管理系統(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)識（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)識（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. 請求（Request） 21

5.1? 請求隊(duì)列（Request-Line） 21

5.1.1 方法（Method） 22

5.1.2 請求URI（Request-URI） 22

5.2? 請求標(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? 附加請求方法（Additional Request Methods） 51

D.2? 附加標(biāo)題域定義（Additional Header Field Definitions） 51

1.? 介紹（Introduction）

1.1? 目的（Purpose）

HTTP（Hypertext Transfer Protocol）是應(yīng)用級協(xié)議，它適應(yīng)了分布式超媒體協(xié)作系統(tǒng)對

靈活性及速度的要求柳沙。它是一個(gè)一般的岩灭、無狀態(tài)的、基于對象的協(xié)議赂鲤，通過對其請求方法

（request methods）進(jìn)行擴(kuò)展噪径，可以被用于多種用途，比如命名服務(wù)器（name server）及分

布式對象管理系統(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允許使用開放的命令集來表示請求的目的，它使用基于URI[2]（Uniform Resource

Identifier）泵琳，即統(tǒng)一資源標(biāo)識的規(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)行基本的超媒體資源訪問迫悠，并簡化用戶代理的實(shí)現(xiàn)。

1.2? 術(shù)語（Terminology）

本規(guī)范用了許多與參與方巩梢、對象及HTTP通訊相關(guān)的術(shù)語创泄，如下：

連接（connection）

兩個(gè)應(yīng)用程序以通訊為目的在傳輸層建立虛擬電路艺玲。

消息（message）

HTTP通訊的基本單元，在連接中傳輸?shù)慕Y(jié)構(gòu)化的鞠抑、有順序的字節(jié)（其含義在第四

節(jié)中定義）饭聚。

請求（request）

HTTP的請求消息（在第五節(jié)定義）

回應(yīng)（response）

HTTP的回應(yīng)消息（在第六節(jié)定義）

資源（resource）

網(wǎng)絡(luò)上可以用URI來標(biāo)識的數(shù)據(jù)對象或服務(wù)（見3.2節(jié)）

實(shí)體（entity）

可被附在請求或回應(yīng)消息中的特殊的表示法、數(shù)據(jù)資源的表示搁拙、服務(wù)資源的回應(yīng)等秒梳，

由實(shí)體標(biāo)題（entity header）或?qū)嶓w主體（entity body）內(nèi)容形式存在的元信息組成。

客戶端（client）

指以發(fā)出請求為目的而建立連接的應(yīng)用程序箕速。

用戶代理（user agent）

指初始化請求的客戶端酪碘，如瀏覽器、編輯器盐茎、蜘蛛（web爬行機(jī)器人）或其它終端

用戶工具兴垦。

服務(wù)器（server）

指接受連接，并通過發(fā)送回應(yīng)來響應(yīng)服務(wù)請求的應(yīng)用程序庭呜。

原始服務(wù)器（origin server）

存放資源或產(chǎn)生資源的服務(wù)器。

代理（proxy）

同時(shí)扮演服務(wù)器及客戶端角色的中間程序犀忱，用來為其它客戶產(chǎn)生請求募谎。請求經(jīng)過變

換，被傳遞到最終的目的服務(wù)器阴汇，在代理程序內(nèi)部数冬，請求或被處理，或被傳遞搀庶。代

理必須在消息轉(zhuǎn)發(fā)前對消息進(jìn)行解釋拐纱，而且如有必要還得重寫消息。代理通常被用

作經(jīng)過防火墻的客戶端出口哥倔，用以輔助處理用戶代理所沒實(shí)現(xiàn)的請求秸架。

網(wǎng)關(guān)（gateway）

服務(wù)器之間的服務(wù)器。與代理不同咆蒿，網(wǎng)關(guān)接受請求就好象它就是被請求資源所在的

原始服務(wù)器东抹，發(fā)出請求的客戶端可能并沒有意識到它在與網(wǎng)關(guān)進(jìn)行通訊。網(wǎng)關(guān)是網(wǎng)

絡(luò)防火墻服務(wù)器端的門戶沃测。對非HTTP系統(tǒng)資源進(jìn)行訪問時(shí)缭黔，網(wǎng)關(guān)做為中間的協(xié)議

翻譯者。

隧道（tunnel）

隧道就好象連接兩端看不見的中繼器蒂破。處于激活狀態(tài)時(shí)馏谨，它雖然是由HTTP請求來

初始化的，但它并不參與HTTP通訊附迷。當(dāng)需要中繼連接的兩端關(guān)閉后惧互，隧道也自然

終止哎媚。在入口有需求及中間程序無法或不該解釋要中繼的通訊時(shí)，通常要用到隧道

技術(shù)壹哺。

緩存（cache）

指程序本地存儲的回應(yīng)消息和用來控制消息存儲抄伍、重獲、刪除的子系統(tǒng)管宵。

緩存回應(yīng)的目的是為減少請求回應(yīng)時(shí)間截珍，以及未來一段時(shí)間對網(wǎng)絡(luò)帶寬的消耗。任

何客戶端及服務(wù)端都可以包含緩存箩朴。服務(wù)器在以隧道方式工作時(shí)不能使用緩存岗喉。

任何指定的程序都有能力同時(shí)做為客戶端和服務(wù)器。我們在使用這個(gè)概念時(shí)炸庞，不是看程

序功能上是否能實(shí)現(xiàn)客戶及服務(wù)器钱床，而是看程序在特定連接時(shí)段上扮演何種角色（客戶或服

務(wù)器）。同樣埠居，任何服務(wù)器可以扮演原始服務(wù)器查牌、代理、網(wǎng)關(guān)滥壕、隧道等角色纸颜，行為的切換取

決于每次請求的內(nèi)容。

1.3? 概述（Overall Operation）

HTTP協(xié)議是基于請求/回應(yīng)機(jī)制的绎橘⌒菜铮客戶端與服務(wù)器端建立連接后，以請求方法称鳞、URI涮较、

協(xié)議版本等方式向服務(wù)器端發(fā)出請求，該請求可跟隨包含請求修飾符冈止、客戶信息狂票、及可能的

請求體（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)行初始化，并通過它來組裝請求以獲取存儲在一些原

始服務(wù)器上的資源诗眨。在最簡單的情況下金顿，通過用戶代理（UA）與原始服務(wù)器（O）之間一

個(gè)簡單的連接（v）就可以完成屉符。

request chain ------------------------>

UA -------------------v------------------- O

<----------------------- response chain

更復(fù)雜的情況是當(dāng)請求/回應(yīng)鏈之間存在一個(gè)或更多中間環(huán)節(jié)尉间。總體看來厂财，有三種中間

環(huán)節(jié)：代理（proxy）、網(wǎng)關(guān)（gateway）峡懈、隧道（tunnel）璃饱。

代理（proxy）是向前推送的代理人（agent），它以絕對形式接收URI請求肪康，重寫全部

或部分消息荚恶，并將經(jīng)過改寫的請求繼續(xù)向URI中指定的服務(wù)器處推送。

網(wǎng)關(guān)是接收代理磷支，它處于服務(wù)器層之上谒撼，在必要時(shí)候，它用服務(wù)器可識別的協(xié)議來傳遞

請求雾狈。

隧道不改變消息廓潜，它只是連接兩端的中繼點(diǎn)。在有中間層（如防火墻）或中間層無法解

析消息內(nèi)容的情況下善榛，需要靠隧道技術(shù)來幫助通訊穿越中間層辩蛋。

request chain -------------------------------------->

UA -----v----- A -----v----- B -----v----- C -----v----- O

<------------------------------------- response chain

上面的圖形表示在用戶代理和原始服務(wù)器之間有三個(gè)中間層（A，B和C）移盆。由圖可見悼院，

請求或回應(yīng)消息在整個(gè)信息鏈上運(yùn)行需要通過四個(gè)單獨(dú)的連接，它與在此之前介紹的簡單情

況是有區(qū)別的味滞，而且此區(qū)別是十分重要的樱蛤。因?yàn)镠TTP通訊選項(xiàng)可以設(shè)置成幾種情況钮呀，如只

與最近的非隧道鄰居連接剑鞍、只與信息鏈末端連接、或者可與鏈中全部環(huán)節(jié)連接等等爽醋。雖然上

面的圖是線性的蚁署，而實(shí)際上每個(gè)參與環(huán)節(jié)都在同時(shí)與多方進(jìn)行通訊活動。例如蚂四，B在接受除

A之外其它客戶端請求的同時(shí)光戈，向除C之外的其它服務(wù)器推送請求，在這個(gè)時(shí)刻遂赠，它可能

接受到A的請求久妆，并給予處理。

參與通訊的任何一方如果沒有以隧道方式進(jìn)行工作跷睦，必須要借助內(nèi)部緩存機(jī)制來處理請

求筷弦，如果鏈上某個(gè)參與方碰巧緩存了某個(gè)請求的回應(yīng)，那就相應(yī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)都可以被緩存爹殊，某些請求所包含的修飾符中可能對緩存行為進(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請求和回應(yīng)在數(shù)據(jù)傳輸過程中的數(shù)據(jù)結(jié)構(gòu)問題，不在本文討論范圍之內(nèi)士嚎。

實(shí)驗(yàn)室應(yīng)用除外呜魄，當(dāng)前的做法是客戶端在每次請求之前建立連接，而服務(wù)器端在發(fā)送回

應(yīng)后關(guān)閉此連接莱衩。不管客戶端還是服務(wù)器端都應(yīng)注意處理突發(fā)的連接中斷爵嗅，因?yàn)殡p方都有可

能因?yàn)橛脩舨僮鳌⒆詣映瑫r(shí)笨蚁、程序失敗等原因關(guān)閉與對方的連接睹晒。在這種情況下，不管請求

處于什么樣的狀態(tài)括细，如單方或雙方同時(shí)關(guān)閉連接伪很，都會導(dǎo)致當(dā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]很類似呆盖，本文對所有機(jī)制的說明都是以散文和補(bǔ)充反饋的方式來描述的。

對于實(shí)現(xiàn)者來說贷笛，要想理解這些約定应又，必須對這些符號很熟悉。補(bǔ)充反饋方式（augmented

BNF）包括下面的結(jié)構(gòu)：

要解釋的名詞＝名詞解釋（name = definition）

規(guī)則的名字（name）就是它本身（不帶任何尖括號乏苦，“<”株扛，“>”），后面跟個(gè)等號＝，

然后就是該規(guī)則的定義席里。如果規(guī)則需要用多個(gè)行來描述叔磷，利用空格進(jìn)行縮進(jìn)格式排

版。某些基本的規(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*元素”意思是至少有一個(gè)，

而“1*2元素”表明允許有1個(gè)或2個(gè)雹嗦。

［規(guī)則］（[rule]）

方括號內(nèi)是可選元素范舀。如“［元素1　元素2］”與“*1（元素1　元素2）”是一回

事。

N　規(guī)則（N rule）

表明循環(huán)的次數(shù)：“（元素）”就是“*（元素）”了罪，也就是精確指出

取值锭环。因而，2DIGIT 就是2位數(shù)字, 3ALPHA 就是由三個(gè)字母組成字符串捶惜。

＃規(guī)則（#rule）

“#”與“*”類似田藐，用于定義元素列表荔烧。

完整形式是“#元素”表示至少有個(gè)至多有個(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）

分號后面是注釋碱茁，僅在單行使用裸卫。

隱含*LWS（implied *LWS）

本文的語法描述是基于單詞的。除非另有指定纽竣，線性空格（LWS）可以兩個(gè)鄰近符

號或分隔符（tspecials）之間任意使用墓贿，而不會對整句的意思造成影響。在兩個(gè)符號之

間必須有至少一個(gè)分隔符蜓氨，因?yàn)樗鼈円惨鰹閱为?dú)的符號來解釋募壕。實(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ī)則將用于本文后面對結(jié)構(gòu)基本解析刀荒。

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ī)定缠借，除實(shí)體主體（Entity-Body干毅，見附錄B容錯(cuò)應(yīng)用）外，所有協(xié)議元

素的行結(jié)束標(biāo)志都是CRLF（按字節(jié)順序）泼返。在實(shí)體主體內(nèi)部的行結(jié)束標(biāo)志定義及

其對應(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分隔的單詞或特殊字符組成虾啦，這些特殊字符

必須置于引號中間的字符串內(nèi)，作為參數(shù)值使用痕寓。

Word = 符號（token）| 被引號引起來的字符串

token = 1*<除控制字符（CTLs）或tspecials之外的任意字符>

tspecials ? ? = "(" | ")" | "<" | ">" | "@"

| "," | ";" | ":" | "\" | <">

| "/" | "[" | "]" | "?" | "="

| "{" | "}" | SP | HT

在HTTP頭域中可用括號表示注釋文字傲醉。注釋只允許寫在包含注釋的域，做為域值

定義的一部分呻率。在除此之外其它域中硬毕，括號將被視為域值。

comment = "(" *( ctext | comment ) ")"

ctext = <除圓括號外的任何TEXT>

被雙引號圈中的文本字符串將被視為一個(gè)單詞礼仗。

quoted-string = ( <"> *(qdtext) <"> )

qdtext = <除了雙引號及控制字符之外的任何字符吐咳，包括LWS >

在HTTP/1.0中不允許使用后斜線“\”來引用單字符。

3.? 協(xié)議參數(shù)（Protocol Parameters）

3.1? HTTP版本（HTTP Version）

HTTP采用主從（.）數(shù)字形式來表示版本元践。協(xié)議的版本政策傾向于讓發(fā)

送方表明其消息的格式及功能韭脊，而不僅僅為了獲得通訊的特性，這樣做的目的是為了與更高

版本的HTTP實(shí)現(xiàn)通訊单旁。只增加擴(kuò)展域的值或增加了不影響通訊行為的消息組件都不會導(dǎo)致

版本數(shù)據(jù)的變化沪羔。當(dāng)協(xié)議消息的主要解析算法沒變，而消息語法及發(fā)送方的隱含功能增加了象浑，

將會導(dǎo)致從版本號（）增加蔫饰；當(dāng)協(xié)議中消息的格式變化了，主版本號（）也

將發(fā)生改變愉豺。

HTTP消息的版本由消息第一行中的HTTP版本域來表示篓吁。如果消息中的協(xié)議版本沒有

指定，接收方必須假定它是符合HTTP/0.9的簡單標(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版本低孩擂。

版本號前面的0將被接收方忽略狼渊，而在發(fā)送方處也不應(yīng)產(chǎn)生箱熬。

本文檔定義了HTTP協(xié)議的0.9及1.0版本类垦。發(fā)送完整請求（Full-Request）及完整

回應(yīng)（Full-Response）消息的應(yīng)用必須指明HTTP的版本為“HTTP/1.0”。

HTTP/1.0服務(wù)器必須：

o識別HTTP/0.9及HTTP/1.0請求命令中的請求隊(duì)列（Request-Line）的格式城须。

o理解任何HTTP/0.9及HTTP/1.0中的合法請求格式蚤认。

o 使用與客戶端相同版本的協(xié)議進(jìn)行消息回應(yīng)。

HTTP/1.0 客戶端必須：

o 識別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請求時(shí)，必須小心處理請求的推送良瞧，因?yàn)?/p>

協(xié)議版本表明發(fā)送方的能力陪汽，代理或網(wǎng)關(guān)不應(yīng)發(fā)出高于自身版本的消息。如果收到高版本的

請求褥蚯，代理或網(wǎng)關(guān)必須降低該請求的版本挚冤，并回應(yīng)一個(gè)錯(cuò)誤。而低版本的請求也應(yīng)在被推送

前升級赞庶。

代理或網(wǎng)關(guān)回應(yīng)請求時(shí)必須遵照前面列出的規(guī)定训挡。

3.2? 統(tǒng)一資源標(biāo)識（Uniform Resource Identifiers）

URI有許多名字，如WWW地址歧强、通用文件標(biāo)識（Universal Document Identifiers）澜薄、通

用資源標(biāo)識（Universal Resource Identifiers [2]），以及最終的統(tǒng)一資源定位符（Uniform

Resource Locators (URL) [4]）和統(tǒng)一資源名（URN）摊册。在涉及HTTP以前肤京，URI用簡單格式

的字符串描述－名字、位置茅特、或其它特性蟆沫，如網(wǎng)絡(luò)資源。

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>

權(quán)威的URL語法及語義信息請參見RFC1738[4]和RFC1808[9]舟山。上面所提到的BNF中

包括了合法URL中不允許出現(xiàn)的符號（RFC1738），因?yàn)镠TTP服務(wù)器并沒有限制為只能用

非保留字符集中的字符來表示地址路徑卤恳，而且HTTP代理也可能接收到RFC1738沒有定義

的URI請求累盗。

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端口蠢琳。對于絕對路徑的URI來說啊终，擁有被請求的

資源的服務(wù)器主機(jī)通過偵聽該端口的TCP連接來接收該URI請求。如果URL中沒有給出

絕對路徑傲须，要作為請求URI（參見5.1.2節(jié)）使用蓝牲，必須以“/”形式給出。

注意：雖然HTTP協(xié)議獨(dú)立于傳輸層協(xié)議泰讽，http URL只是標(biāo)識資源的TCP位置例衍，而對

于非TCP資源來說，必須用其它的URI形式來標(biāo)識已卸。

規(guī)范的HTTP URL形式可通過將主機(jī)中的大寫字符轉(zhuǎn)換成小寫（主機(jī)名是大小寫敏感

的）來獲得佛玄。如果端口是80，去掉冒號及端口號累澡，并將空路徑替換成“/”翎嫡。

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í)可識別全部三種格式，但是它

們不可以產(chǎn)生第三種時(shí)間格式(asctime) 望几。

注意：對于接收到由非HTTP應(yīng)用產(chǎn)生的日期數(shù)據(jù)時(shí)绩脆，提倡對接收到的日期值進(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ù)

器端在用戶描述愧杯、請求登錄等情況下使用這類格式涎才。

3.4? 字符集（Character Sets）

HTTP所使用的字符集定義和描述MIME時(shí)用的相同：

本文檔用字符集（character set）來指明利用一個(gè)或多個(gè)表將順序字節(jié)轉(zhuǎn)換成順序字

符的方法。注意力九，不需要其它方向的無條件轉(zhuǎn)換耍铜，因?yàn)椴皇撬械淖址伎梢杂媒o

定字符集來表示邑闺，同時(shí)，一個(gè)字符集也可能提供一種以上的字節(jié)順序來表示一種特

殊的字符业扒。這種定義傾向于允許不同類型的字符編碼通過簡單的單表映射來實(shí)現(xiàn)检吆，

如舒萎，從表US-ASCII切換到復(fù)雜表如ISO2202程储。實(shí)際上，與MIME字符集名相關(guān)的

定義必須完整指定從字節(jié)到字符的映射臂寝，特別是不允許通過利用外部配置信息來確

定精確的映射章鲤。

注意：術(shù)語字符集（character set）歸于字符編碼（character encoding）。事實(shí)上咆贬，

由于HTTP與MIME共同使用同樣的注冊败徊，所以其術(shù)語也應(yīng)一致。

HTTP字符集由大小寫敏感的符號組成掏缎。全部的符號定義參見IANA字符集注冊

[15]皱蹦。因?yàn)樽蕴幉粫槊總€(gè)字符集單獨(dú)定義一套符號，所以我們在這看到的字符

集名大多是與HTTP實(shí)體使用相關(guān)的眷蜈。這些在RFC 1521 [5] 中注冊的字符集沪哺，即

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允許使用專用符號做為字符集值辜妓，但是任何在IANA字符集注冊表[15]

中有預(yù)定義值的符號都必須表明其所屬的字符集。應(yīng)用應(yīng)當(dāng)將其對字符集的使用限

制在IANA注冊表規(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)容譯碼值用于指示對資源進(jìn)行的編碼轉(zhuǎn)換。內(nèi)容譯碼主要用于將經(jīng)過壓縮鸥印、加密等操

作的文件進(jìn)行還原灰瞻，使其保持其原來的介質(zhì)類型。典型情況下辅甥，經(jīng)過編碼保存的資源只能經(jīng)

過解碼或類似的操作才能還原酝润。

content-coding = "x-gzip" | "x-compress" | token

注意：出于對未來兼容性的考慮，HTTP/1.0應(yīng)用應(yīng)將"gzip" 和"compress" 分別與

"x-gzip"和"x-compress"對應(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)對多種格式編碼的解碼浑塞。

在這段文字中借跪，提到了兩個(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)識編碼格式的做法不是很理想果港，在將來可能不會繼續(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ù)可參照屬性/值對的方式萝衩，用類型/子類型的格式來寫。

Parameter = attribute "=" value

Attribute = token

Value = token | quoted-string

其中没咙，類型猩谊、子類型、參數(shù)屬性名是大小寫敏感的镜撩。而參數(shù)值不一定是大小寫敏感的预柒，

這得看參數(shù)名的語法而定。在類型和子類型袁梗、屬性名和屬性值之間不能有LWS（空格）宜鸯。當(dāng)

接收到不能識別的介質(zhì)類型的參數(shù)時(shí)，用戶代理應(yīng)當(dāng)忽略它們遮怜。

一些老的HTTP應(yīng)用不能識別介質(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]）注冊即碗。介質(zhì)類型注冊過程請參見RFC1590[13]。不鼓勵(lì)使用未注冊

的介質(zhì)類型陌凳。

3.6.1標(biāo)準(zhǔn)及文本缺拾痢（Canonicalization and Text Defaults）

Internet介質(zhì)類型是用規(guī)范形式注冊的。一般來說合敦，在通過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)的字符集值撒会，

這樣可以保證接收方能正確地對其進(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）注冊

中卻找不到專為HTTP/1.0所指定的內(nèi)容闸英。HTTP用戶代理只得自己來做接收多部分類型的

工作，其過程和行為與MIME用戶代理是相同或相似的介袜。HTTP服務(wù)器不應(yīng)假定HTTP客戶

端都有能力處理多部分類型甫何。

所有的多部分類型都使用通用的語法卑雁，而且必須在介質(zhì)類型值部分包括邊界參數(shù)

（boundary parameter）付秕。消息的主體是其自身，做為協(xié)議元素啃炸，它必須只使用CRLF做為段

間（body-parts）的行中斷符。多段主體（Multipart body-parts）中可能包括對各段有重要意

義的HTTP標(biāo)題域加派。

3.7? 產(chǎn)品標(biāo)識（Product Tokens）

是通訊應(yīng)用程序用來標(biāo)識其自身的一個(gè)簡單符號叫确，常和任意字母及版本描述一起使用。

大多數(shù)產(chǎn)品標(biāo)識也將其產(chǎn)品的重要組成部分的版本號一起列出芍锦，中間用空格分隔竹勉。

按慣例，在標(biāo)識應(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)識應(yīng)當(dāng)短小，因而禁止利用該域填寫廣告或其它無關(guān)信息孽水。雖然任何符號字符都

可能出現(xiàn)在產(chǎn)品版本中票腰，該符號應(yīng)當(dāng)只用于做版本定義，也就是說女气，同一個(gè)產(chǎn)品的連續(xù)版本

之間只能通過產(chǎn)品版本值進(jìn)行區(qū)分杏慰。

4.? HTTP 消息（HTTP Message）

4.1? 消息類型（Message Types）

HTTP消息由客戶端到服務(wù)器的請求和由服務(wù)器到客戶端的回應(yīng)組成。

HTTP-message? = Simple-Request ; HTTP/0.9 messages

| Simple-Response

| Full-Request ; HTTP/1.0 messages

| Full-Response

完整的請求（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

簡單請求（Simple_Request）與簡單回應(yīng)（Simple-Response）不允許使用任何標(biāo)題信息，

并限制只能使用唯一的請求方法（GET）

Simple-Request? = "GET" SP Request-URI CRLF

Simple-Response = [ Entity-Body ]

不提倡使用簡單方式請求格式霎肯，因?yàn)樗乐沽朔?wù)器在接到簡單請求時(shí)對返回實(shí)體的介

質(zhì)類型進(jìn)行驗(yàn)證擎颖。

4.2? 消息標(biāo)題（Message Headers）

HTTP標(biāo)題域，包括主標(biāo)題（General-Header,4.3節(jié)）观游、請求標(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)題域由后緊跟冒號的名字异旧，單空格（SP），字符及域值組

成提佣。域名是大小寫敏感的吮蛹。雖然不提倡，標(biāo)題域還是可以擴(kuò)展成多行使用拌屏，只要這些行以一

個(gè)以上的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>

標(biāo)題域接收的順序并不重要，但良好的習(xí)慣是倚喂，先發(fā)送主標(biāo)題每篷，然后是請求標(biāo)題或回應(yīng)

標(biāo)題瓣戚，最后是實(shí)體標(biāo)題。

當(dāng)且僅當(dāng)標(biāo)題域的全部域值都用逗號分隔的列表示時(shí)（即焦读，#（值））子库，多個(gè)有相同域名

的HTTP標(biāo)題域才可以表示在一個(gè)消息里。而且必須能在不改變消息語法的前提下矗晃，將并發(fā)

的域值加到第一個(gè)值后面仑嗅，之間用逗號分隔，最終能將多個(gè)標(biāo)題域結(jié)合成“域名：域值”對张症。

4.3? 普通標(biāo)題域（General Header Fields）

有幾種標(biāo)題域是請求與回應(yīng)都要使用的仓技，但并不用于被傳輸?shù)膶?shí)體。這些標(biāo)題只用于被

傳輸?shù)南ⅰ?/p>

General-Header = Date ; Section 10.6

| Pragma ; Section 10.12

普通標(biāo)題域名稱只有在與協(xié)議版本的變化結(jié)合起來后俗他，才能進(jìn)行可靠的擴(kuò)展脖捻。實(shí)際上，

新的或?qū)嶒?yàn)中的標(biāo)題域只要能被通訊各方識別兆衅，其語法就可使用地沮，而無法識別的標(biāo)題域都將

被視為實(shí)體域。

5. 請求（Request）

從客戶端到服務(wù)器端的請求消息包括涯保，消息首行中诉濒，對資源的請求方法周伦、資源的標(biāo)識符

及使用的協(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服務(wù)器收到簡單請求及志，它必須回應(yīng)一個(gè)HTTP/0.9格式的簡單回應(yīng)。

HTTP/1.0的客戶端有能力接收完整回應(yīng)寨腔，但不能產(chǎn)生簡單請求速侈。

5.1? 請求隊(duì)列（Request-Line）

請求隊(duì)列以一個(gè)方法符號開頭，跟在請求URI及協(xié)議版本的后面迫卢，以CRLF為結(jié)尾倚搬。

該元素用空格SP分隔。除了最后的CRLF乾蛤，不允許出現(xiàn)單獨(dú)的CR或LF符每界。

Request-Line = Method SP Request-URI SP HTTP-Version CRLF

注意，簡單請求與完整請求的請求隊(duì)列之間的區(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)變化的上荡；如果用某種方法訪問資源被拒絕趴樱，客

戶端可從回應(yīng)中的返回碼得到通知。服務(wù)器端在方法無法識別或沒有實(shí)現(xiàn)時(shí)，返回狀態(tài)代碼

501（尚未沒實(shí)現(xiàn)）叁征。

這些方法被HTTP/1.0的應(yīng)用程序普遍使用纳账，完整定義請參見第8節(jié)。

5.1.2 請求URI（Request-URI）

請求URI就是統(tǒng)一資源標(biāo)識符（3.2節(jié)）捺疼，用來標(biāo)識要請求的資源塞祈。

Request-URI = absoluteURI | abs_path

上面兩種請求URI方式可根據(jù)實(shí)際的請求方式選擇使用。

絕對URI（absoluteURI）格式只在代理（proxy）在產(chǎn)生請求時(shí)使用帅涂。代理的責(zé)任是將

請求向前推送议薪，并將回應(yīng)返回。如果請求是GET或HEAD方式媳友，而且之前的回應(yīng)被緩存斯议，

如果代理忽略標(biāo)題域的過期信息限制，它可能使用緩存中的消息醇锚。注意哼御，代理可能將請求推

送至另外一個(gè)代理，也可將請求直接送至絕對URI中所指定的目的服務(wù)器焊唬。為了避免請求

循環(huán)恋昼，代理必須能夠識別它的所有服務(wù)器名，包括別名赶促、本地變量及數(shù)字形式的IP地址液肌。

下面是一個(gè)請求隊(duì)列的例子：

GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0

最普通的請求URI形式就是原始服務(wù)器或網(wǎng)關(guān)用來標(biāo)識資源的方式。在這種方式下鸥滨，

只有給出絕對路徑的URI才能被傳輸（見3.2.1節(jié)）嗦哆。例如，如客戶端希望直接從原始服務(wù)

器上接收資源婿滓，它們將產(chǎn)生一個(gè)與主機(jī)"www.w3.org"80端口的TCP連接老速，并在完整請求之

后發(fā)送下面的命令：

GET /pub/WWW/TheProject.html HTTP/1.0

注意絕對路徑不可以為空，如果URI中沒有內(nèi)容凸主，也必須加上一個(gè)"/"（server root）橘券。

請求URI以編碼字符串方式傳輸，有些字符可能在傳輸過程中被轉(zhuǎn)義（escape）卿吐，如變

成“%HEXHEX”形式旁舰。具體這方面內(nèi)容請參見RFC1738[4]。原始服務(wù)器在正確解釋請求

之前必須對請求URI進(jìn)行解碼但两。

5.2? 請求標(biāo)題域（Request Header Fields）

請求標(biāo)題域允許客戶端向服務(wù)器端傳遞該請求的附加信息及客戶端信息鬓梅。該域做為請求

的修飾部分，遵照編程語言程序調(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

請求標(biāo)題域名只有在與協(xié)議版本的變化結(jié)合起來后绽快，才能進(jìn)行可靠的擴(kuò)展芥丧。實(shí)際上，新

的或?qū)嶒?yàn)中的標(biāo)題域只要能被通訊各方識別坊罢，其語法就可使用续担，而無法識別的標(biāo)題域都將被

視為實(shí)體域。

6.? 回應(yīng)（Response）

在接收活孩、解釋請求消息后物遇，服務(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)請求是HTTP/0.9的或者服務(wù)器端只支持HTTP/0.9時(shí)憾儒，只能以Simple-Response方式

回應(yīng)询兴。如果客戶端發(fā)送HTTP/1.0完整請求后，接收到的回應(yīng)不是以狀態(tài)行（Status-Line）

開頭的起趾，客戶端將其視為簡單回應(yīng)诗舰，并相應(yīng)對其進(jìn)行分析。注意训裆，簡單請求只包括實(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ū)分完整請求和簡單請求。簡單回應(yīng)可能允許這種表達(dá)式出現(xiàn)在

實(shí)體主體的開始部分愧口，但會引起消息的誤解睦番。因?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ù)字組成，表示請求是否被理解或被滿足厚骗。原因分析是

用簡短的文字來描述狀態(tài)代碼產(chǎn)生的原因示启。狀態(tài)代碼用來支持自動操作，原因分析是為人類

用戶準(zhǔn)備的领舰》蛏ぃ客戶端不需要檢查或顯示原因分析迟螺。

狀態(tài)代碼的第一位數(shù)字定義了回應(yīng)的類別，后面兩位數(shù)字沒有具體分類舍咖。首位數(shù)字有5

種取值可能：

o 1xx:：保留矩父，將來使用。

o 2xx：成功 － 操作被接收排霉、理解窍株、接受（received, understood, accepted）。

o 3xx：重定向（Redirection）－ 要完成請求必須進(jìn)行進(jìn)一步操作攻柠。

o 4xx：客戶端出錯(cuò) － 請求有語法錯(cuò)誤或無法實(shí)現(xiàn)球订。

o 5xx：服務(wù)器端出錯(cuò) － 服務(wù)器無法實(shí)現(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)代碼是可擴(kuò)展的较店，而只有上述代碼才可以被當(dāng)前全部的應(yīng)用所識別士八。HTTP

應(yīng)用不要求了解全部注冊的狀態(tài)代碼，當(dāng)然梁呈，如果了解了更好婚度。實(shí)際上，應(yīng)用程序必須理解

任何一種狀態(tài)代碼官卡，如果碰到不識別的情況蝗茁，可根據(jù)其首位數(shù)字來判斷其類型并處理。另外寻咒，

不要緩存無法識別的回應(yīng)哮翘。

例如，如果客戶端收到一個(gè)無法識別的狀態(tài)碼431毛秘，可以安全地假定是請求出了問題饭寺，

可認(rèn)為回應(yīng)的狀態(tài)碼就是400。在這種情況下叫挟，用戶代理應(yīng)當(dāng)在回應(yīng)消息的實(shí)體中通知用戶艰匙，

因?yàn)閷?shí)體中可以包括一些人類可以識別的非正常狀態(tài)的描述信息。

6.2? 回應(yīng)標(biāo)題域（Response Header Fields）

回應(yīng)標(biāo)題域中包括不能放在狀態(tài)行中的附加回應(yīng)信息抹恳。該域還可以存放與服務(wù)器相關(guān)的

信息员凝，以及在對請求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)題域只要能被通訊各方識別，其語法就可使用骤公，而無法識別的標(biāo)題域都將被

視為實(shí)體域抚官。

7.? 實(shí)體（Entity）

完整請求和完整回應(yī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í)體卒煞、請求資源。

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)題域叼架，

但是不能假定接收方可以識別這些域畔裕。對于不可識別的標(biāo)題域，接收方一般是忽略不管乖订，而

代理則繼續(xù)將其向前推送扮饶。

7.2? 實(shí)體主體（Entity Body）

與HTTP請求或回應(yīng)一起發(fā)送的實(shí)體主體的格式和編碼信息都在實(shí)體標(biāo)題域

（Entity-Header）中定義。

Entity-Body? ? = *OCTET

實(shí)體主體只在請求方法有要求時(shí)才會被放在請求消息中乍构。請求消息標(biāo)題域處的內(nèi)容長度

標(biāo)題域（Content-Length header field）的標(biāo)志將指明請求中的實(shí)體主體是否存在甜无。包含實(shí)體

主體的HTTP/1.0請求必須包含合法的內(nèi)容長度標(biāo)題域。

對回應(yīng)消息來說哥遮，消息中是否包含實(shí)體主體取決于請求方法和回應(yīng)代碼岂丘。所有的HEAD

請求方法的回應(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ù)壓縮屬性的被請求資

源咖摹。內(nèi)容編碼的缺省值是none。

任何包括實(shí)體主體的消息必須含有內(nèi)容類型（Content-Type）標(biāo)題域难述，以定義主體的類

型萤晴。只有當(dāng)內(nèi)容類型標(biāo)題域中沒有給出介質(zhì)類型時(shí)吐句，如簡單回應(yīng)消息，接收方可能對該URL

所指定的資源進(jìn)行判斷店读，如其內(nèi)容及擴(kuò)展名等等嗦枢，從而猜測出該主體的介質(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)閉連接來指示請求主體的結(jié)

束彼棍。因而灭忠，HTTP/1.0請求如果包含主體，就必須在內(nèi)容長度（Content-Length）標(biāo)題域中給

出合法的值座硕。如果請求包括實(shí)體主體弛作，且內(nèi)容長度沒指定，服務(wù)端將無法識別或無法從其它

域中計(jì)算出其主體長度坎吻，在這種情況下缆蝉，服務(wù)端將會返回400（非法請求）回應(yīng)。

注意：一些老的服務(wù)器在發(fā)送包含由服務(wù)器端動態(tài)插入的數(shù)據(jù)流文件時(shí)瘦真，支持非法的內(nèi)

容長度使用刊头。要強(qiáng)調(diào)的是，未來版本的HTTP協(xié)議將會很快改變這種情況诸尽。除非客戶端自己

知道正在從一個(gè)支持它的服務(wù)器端得到回應(yīng)原杂，否則不應(yīng)依賴于內(nèi)容長度域的正確性。