組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：黃曉東（黃曉東  xdhuang@eyou.com）
譯文發布時間：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