rfc1945-http1.0自譯本-(2) (轉)

rfc1945-http1.0自譯本-(2) (轉)[@more@]

1.  介紹（Introduction）

 :namespace prefix = o ns = "urn:schemas--com::office" />

1.1  目的（Purpose）

  HTTP（Hypertext Traner Protocol）是應用級，它適應了分散式超協作對靈活性及速度的要求。它是一個一般的、無狀態的、基於的協議，透過對其請求方法（request methods）進行擴充套件，可以被用於多種用途，比如命名（name server）及分散式物件管理系統。HTTP的一個特性是其資料表現型別允許系統的構建不再依賴於要傳輸的資料。

  HTTP自從1990年就在WWW上被廣泛使用。該規範反映了“HTTP/1.0”的普通用法。

  該規範描述了在大多數HTTP/1.0客戶機及伺服器上看起來已經實現的特性。規範將被分成兩個部分：HTTP特性的實現是本文件的主要內容，而其它不太通行的實現將被列在附錄D中。

  實用的資訊系統需要更多的功能，而不僅僅是資料的獲取，包括搜尋、前端及註解。HTTP允許使用開放的命令集來表示請求的目的，它使用基於URI[2]（UnifoRe ntifier），即統一資源標識的規則來定位（URL[4]）或命名（URN[16]）方法所用到的資源。HTTP使用與（Inte [7]）和MIME（Multipurpose Internet Mail Extensions [5]）相似的格式來傳遞訊息。

  HTTP也作為、代理伺服器/閘道器與其它Internet協議進行通訊的一般協議，這些協議是，SMTP [12], NNTP [11], [14], Gopher [1], and WAIS [8]等。HTTP允許不同的應用可以進行基本的超媒體資源訪問，並簡化使用者代理的實現。

 

1.2  術語（Tenology）

  本規範用了許多與參與方、物件及HTTP通訊相關的術語，如下：

連線（connection）

  兩個應用以通訊為目的在傳輸層建立虛擬電路。

訊息（message）

HTTP通訊的基本單元，在連線中傳輸的結構化的、有順序的位元組（其含義在第四節中定義）。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational   [Page 4]

 

 

請求（request）

  HTTP的請求訊息（在第五節定義）

回應（response）

  HTTP的回應訊息（在第六節定義）

資源（resource）

  上可以用URI來標識的資料物件或服務（見3.2節）

  實體（entity）

可被附在請求或回應訊息中的特殊的表示法、資料資源的表示、服務資源的回應等，由實體標題（entity header）或實體主體（entity body）內容形式存在的元資訊組成。

客戶端（client）

  指以發出請求為目的而建立連線的應用程式。

使用者代理（user agent）

指初始化請求的客戶端，如、編輯器、蜘蛛（爬行機器人）或其它終端使用者工具。

伺服器（server）

  指接受連線，並透過傳送回應來響應服務請求的應用程式。

原始伺服器（origin server）

  存放資源或產生資源的伺服器。

代理（）

同時扮演伺服器及客戶端角色的中間程式，用來為其它客戶產生請求。請求經過變換，被傳遞到最終的目的伺服器，在代理程式內部，請求或被處理，或被傳遞。代理必須在訊息轉發前對訊息進行解釋，而且如有必要還得重寫訊息。代理通常被用作經過的客戶端出口，用以輔助處理使用者代理所沒實現的請求。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 5]

 

 

閘道器（gateway）

伺服器之間的伺服器。與代理不同，閘道器接受請求就好象它就是被請求資源所在的原始伺服器，發出請求的客戶端可能並沒有意識到它在與閘道器進行通訊。閘道器是網路防火牆伺服器端的門戶。對非HTTP系統資源進行訪問時，閘道器做為中間的協議翻譯者。

隧道（tunnel）

隧道就好象連線兩端看不見的中繼器。處於啟用狀態時，它雖然是由HTTP請求來初始化的，但它並不參與HTTP通訊。當需要中繼連線的兩端關閉後，隧道也自然終止。在入口有需求及中間程式無法或不該解釋要中繼的通訊時，通常要用到隧道技術。

快取（cache）

  指程式本地的回應訊息和用來控制訊息儲存、重獲、刪除的子系統。

 

快取回應的目的是為減少請求回應時間，以及未來一段時間對網路頻寬的消耗。任何客戶端及服務端都可以包含快取。伺服器在以隧道方式工作時不能使用快取。

 

任何指定的程式都有能力同時做為客戶端和伺服器。我們在使用這個概念時，不是看程式功能上是否能實現客戶及伺服器，而是看程式在特定連線時段上扮演何種角色（客戶或伺服器）。同樣，任何伺服器可以扮演原始伺服器、代理、閘道器、隧道等角色，行為的切換取決於每次請求的內容。

 

1.3  概述（Overall Operation）

  是基於請求/回應機制的。客戶端與伺服器端建立連線後，以請求方法、URI、協議版本等方式向伺服器端發出請求，該請求可跟隨包含請求修飾符、客戶資訊、及可能的請求體（body）內容的MIME型別訊息。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 6]

 

 

  伺服器端透過狀態佇列（status line）來回應，內容包括訊息的協議版本、成功或錯誤程式碼，也跟隨著包含伺服器資訊、實體元資訊及實體內容的MIME型別訊息。

  絕大多數HTTP通訊由使用者代理進行初始化，並透過它來組裝請求以獲取儲存在一些原始伺服器上的資源。在最簡單的情況下，透過使用者代理（UA）與原始伺服器（O）之間一個簡單的連線（v）就可以完成。

 

  request chain ------------------------&gt

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

 

 

  更復雜的情況是當請求/回應鏈之間存在一個或更多中間環節。總體看來，有三種中間環節：代理（proxy）、閘道器（gateway）、隧道（tunnel）。

代理（proxy）是向前推送的代理人（agent），它以絕對形式接收URI請求，重寫全部或部分訊息，並將經過改寫的請求繼續向URI中指定的伺服器處推送。

閘道器是接收代理，它處於伺服器層之上，在必要時候，它用伺服器可識別的協議來傳遞請求。

隧道不改變訊息，它只是連線兩端的中繼點。在有中間層（如防火牆）或中間層無法解析訊息內容的情況下，需要靠隧道技術來幫助通訊穿越中間層。

 

   request chain --------------------------------------&gt

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

   

 

  上面的圖形表示在使用者代理和原始伺服器之間有三個中間層（A，B和C）。由圖可見，請求或回應訊息在整個資訊鏈上執行需要透過四個單獨的連線，它與在此之前介紹的簡單情況是有區別的，而且此區別是十分重要的。因為HTTP通訊選項可以設定成幾種情況，如只與最近的非隧道鄰居連線、只與資訊鏈末端連線、或者可與鏈中全部環節連線等等。雖然上面的圖是線性的，而實際上每個參與環節都在同時與多方進行通訊活動。例如，B在接受除A之外其它客戶端請求的同時，向除C之外的其它伺服器推送請求，在這個時刻，它可能接受到A的請求，並給予處理。

  參與通訊的任何一方如果沒有以隧道方式進行工作，必須要藉助內部快取機制來處理請求，如果鏈上某個參與方碰巧快取了某個請求的回應，那就相應於縮短了請求/回應鏈。下面的圖例演示了當B快取了從O經由C過來的回應資訊，而UA和A沒快取的情況：

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 7]

 

 

  request chain ----------&gt

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

 

 

  並非所有的回應都可以被快取，某些請求所包含的修飾符中可能對快取行為進行了特別指明。一些基於HTTP/1.0的應用使用了啟發式的方法來描述哪些回應可被快取，而哪些則不可以，但遺憾的是，這些規則並沒有形成標準。

  在Internet上，HTTP通訊往往基於的連線方式。預設的埠是TCP 80[15]口，但也可以使用其它埠。並不排除基於Ineternet上的其它協議或網路協議的HTTP實現方式，HTTP只是假定傳輸是可靠的，因而任何能提供這種保證的協議都可以被使用。至於HTTP/1.0請求和回應在資料傳輸過程中的資料結構問題，不在本文討論範圍之內。

  實驗室應用除外，當前的做法是客戶端在每次請求之前建立連線，而伺服器端在傳送回應後關閉此連線。不管客戶端還是伺服器端都應注意處理突發的連線中斷，因為雙方都有可能因為使用者操作、自動超時、程式失敗等原因關閉與對方的連線。在這種情況下，不管請求處於什麼樣的狀態，如單方或雙方同時關閉連線，都會導致當前的請求被終止。

 

1.4  HTTP and MIME

  HTTP/1.0使用了多種結構來定義MIME，詳見1521[5]。附錄C描述了Internet承認的Internet介質型別與mail介質型別的不同工作方式，並給出二者區別的基本解釋。

 

2.  標誌轉換及通用語法（Notational Conventions and Generic Grammar）

 

2.1  補充反饋方式（Augmented BNF）

  與RFC822[7]很類似，本文對所有機制的說明都是以散文和補充反饋的方式來描述的。對於實現者來說，要想理解這些約定，必須對這些符號很熟悉。補充反饋方式（augmented BNF）包括下面的結構：

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational   [Page 8]