1 引言（2005-9-16）
1．1目的
HTTP是一個為分布式的協作的超媒體的信息系統而建立的應用層上的協議。自從1990年就被www采用。第一個版本，HTTP/0。9，是一個簡單的跨INTERNET傳輸原始數據的協議。HTTP/1.0（在RFC1945[6]描述），允許信息以類似MIME形式存在（包含關于傳輸數據的描述元數據和一些關于REQUEST/RESPONSE語義描述符）。但是，HTTP/1。0并沒有考慮到多級代理，緩存，持久連接的需要，或著虛擬主機。另外，越來越多的HTTP/1。0的不兼容實現也使得一個新版本的出現變的必要（需要一個統一版本來使協議雙方確定彼此實現了哪些功能）。
這份規范定義了HTTP/1。1協議。這份協議比HTTP/1。0包含了更嚴格的限制，以此來保證實現的可靠性，兼容性。
實際的信息系統要求更多功能而不僅僅是簡單的取數據，將包括查詢，前臺更新，注解。HTTP允許一個開放的方法和頭的集合來表示REQUEST的確切要求（對基于URI,URL,URN指定的資源的要求）。而傳遞的信息則采用類似MIME信息格式。
HTTP也被用來做客戶端和處理其他信息系統（SMTP，NNTP，FTP，GOPHTER，WAIS）。的代理/網關的交流。這樣，HTTP允許各種各樣的應用訪問基本的多媒體資源。
1.? 2要求
在這個文檔里出現的關鍵詞“MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”按RFC2119[34]描述的那樣解釋。
如果有1個或多個MUST，REQUIRED水平的要求未滿足，那么這個實現就是不兼容的。如果滿足所有的MUST，REQUIRED，SHOULD水平的要求，那么這個實現就“unconditionallycompliant”;
滿足所有MUST但是不是所有SHOULD是“conditionally compliant”。
1．3術語
這個規范用了許多術語來描述在HTTP交流中的參與者和對象。
Connection
在2個要交流的程序間建立的虛擬傳輸層信路。
Message
基本的HTTP交流單元。由結構化的字節流構成，其結構符合SECTION4的詞法定義；通過CONNECTION傳遞。
Request
一個HTTP request message，SECTION 5 DES。
Response
一個HTTP response message，SECTION 6 DES。
Resource
一個能夠被URI標識的網絡數據對象或服務，SECTION3。2 DES。資源可以有多種表示，并且可以在其他方面有所變化。
Entity
被一個request或response作為有效負荷傳輸的信息。由頭區的元數據信息和體區的數據區組成，SECTION7 des。
Representation
在一個response里的屬于content negotiation的entity，SECTION12 des。在1個response中可以存在多個representation。
Content negotiation
一種機制，用來選擇合適的representation來服務一個request，SECTION12 des。
Variant
一個資源可以在任何給定時刻擁有多個representation。每一個被命名為variant。
Client
一個用來建立連接發送request的程序。
User agent
發送一個request的client。最常見的是瀏覽器
Server
接受連接用來為request服務并且發送回response的應用程序。任何一個程序都可以既做server，又做client,這里的概念指的就是在一次connection中的角色，而不是一般意義下的程序的能力。同樣，任何server可以作為一個origin server，proxy,gateway,或者tunnel，基于請求的性質做出不同的行為。
Orgin server
一個指定的資源的所在地或被創建地的server。
Proxy
一個中間程序，既做server又做client(做client是為了其他的的clients)。請求被內部服務或者被傳遞（有可能做下翻譯）到其他server。一個proxy必須實現規范關于client和server的雙重要求。一個“transparent proxy“是一個不對request和response做超越代理鑒定要求處理的proxy，相反就是做。除了“transparent proxy”或者“non-transparent proxy”被明確指定的特殊行為外，HTTP proxy 的要求也適用于這兩種proxy。
Gateway
一個用來為其他server服務的server。不象一個proxy，一個gateway接受請求就好象他是請求resource的origin server一樣；而請求client可能根本就不知道經過了一個gateway。
Tunnel
一個中間程序，在兩個conncetion之間做一個透明傳遞。一旦激活，它將不被認為是HTTP交流的一部分，雖然它可能是被HTTP請求初始化的。當兩個connection都關閉后它也消失了。
Cache
程序對reponse message的局部存儲，包括控制，查詢，刪除存儲的子系統。一個cache存儲cache response用來應對未來的同樣的請求，達到降低reponse時間和帶寬消耗的目的。任何client和server都可以包括一個cache，但是一個cache不能被一個tunnel使用。
Cacheable
如果一個cache可以存儲response message的備份來應對以后的請求，那么這個response就是cacheable。SECTION13 des。即使一個response是Cacheable，也有另外的限制來決定是否一個cache可以用一個cache拷貝來應對請求。
First-hand
一個response是從origin server或經過了幾個proxy過來的那么就是first-hand。如果它的有效性被origin server校驗過那它也是first-hand。
Explicit expiration time
Origin server確定的關于一個entity不應再由一個cache未經進一步校驗就返回的時間。
Herristic expiration time
如果一個Explicit expiration time不可用，那么這個時間被緩存使用
age
一個response的age是自從它被發送或成功地被origin server校驗后的時間段
freshness lifetime
一個response自從產生到expiration time之間的時間長度
fresh
一個response是fresh的，如果它的age還沒有超過它的freshness lifetime。
Stale
一個response是stale的，如果它的age超過了它的freshness lifetime。
Semantically transparent
一個cache一一種Semantically transparent的方式工作，對于特定的一個response，這時它的使用既沒有影響request client也沒有影響origin server（和沒經過cache一樣），但是卻提高了性能。
Validator
一個協議元素被用來找出一個cache entity 是不是等同于一個entity。
Upstream/downstream
描述了一個message的流動：所有的message從upstream流向downstream。
Inbound/outbound
是指message的request和response路徑。前者只流向origin server，后者指流向user agent。
1.4整體運行框架
HTTP協議是一個request/response協議。一個client發送一個request給一個server，由一個request method,uri,協議版本，緊跟著mime類似的信息（包含request描述符，client的信息，和與一個server傳遞數據可能的容量）。Server回以一個狀態行（包括message的協議版本，一個成功或失敗的代碼），緊跟一個MIME類似的message（包括server信息，entity的元數據，可能的entity-body容量。HTTP和MIME的關系appendix19.4。
大多數的HTTP連接被一個user agent發起，請求某些origin server上的資源。在簡單情況，可以如圖所示：
request chain ------------------------>
UA -------------------v------------------- O
<----------------------- response chain
一個更加復雜點的情況：有多個中間體介于request/response chain。有3個普遍的中間體形式：proxy，gateway，tunnel。一個proxy是一個轉送站，接受一個request,更改全部或部分message，根據uri重新發request。一個gateway是一個接受站，就象居于其他一些server之上的server一樣，如果必要，會把requeset傳給它下面的server。一個tunnel是一個接力點，連接2個連接而不改變任何message；可以被用來處理防火墻。
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- response chain
上面的圖展示了3個中間體abc在user agent和origin server之間。一個request或response message穿越整個鏈需要通過4個獨立的連接。這個區別是很重要的，因為一些 HTTP通訊選項只能加到最近的，非tunnel鄰居，只能到chain的末端或所有連接。雖然圖是畫地直線，但是每一個參與者可能同時處理多個通訊。比如，B在處理A的request 的同時可能正在接受其他clients發過來的request，而把它們轉向非c的server。
任何參與通訊的只要不是tunnel都可以用一個內部cache來處理request。這會縮短通訊鏈如果有一方有對該request的cached reponse。下面展示了結果鏈如果B有一個從O的cache copy，而UA，或A沒有。
request chain ---------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
<--------- response chain
并不是所有的response的緩存都是有用的，一些request可能會包含關于緩存要求的描述符。HTTP對于緩存的方式控制和response，des13。
事實上，緩存和代理的構架現在正在被整個WWW實驗和部署。這些系統包括國家級的代理緩存來存儲越洋的帶寬，系統廣播或多點播送cached entries，組織那些零散的緩存到CD-ROM等等。HTTP系統也在公司內網的寬帶連接和PDA的低能耗無線斷續連接系統中被使用。HTTP1。1的目標是支持在協議誕生期間已經部署的各種配置，使得WEB應用能夠達到高可靠性，至少是在失敗后有可靠的提示。
HTTP通訊通常是跨TCP/IP連接地發生。默認端口是TCP80[19]，但是其他的端口也可以被使用。這就使HTTP可以作為INTERNET上其他協議的上層協議，或其他網絡的協議。HTTP只要求一個可靠連接，任何能提供這樣的保證的協議都可以被使用；把HTTP/1。1的request和response的結構轉化成正在被討論的協議的數據單位超出了本規范的范圍。
在HTTP/1。0，大多數實現使用一個新的連接應對request/response交換。在HTTP/1。1中，一個連接可以被多個request/response交流使用，雖然連接可以因為多個原因被關閉。
?
?