超文本傳輸協議（HTTP Protocol）

 

 超文本傳輸協議（HTTP Protocol）

 

Network Working Group(網絡工作組)                             R. Fielding
Request for Comments: 2616                                   UC Irvine
Obsoletes(過時棄用）: 2068                                    J. Gettys
Category: Standards Track （類別:標準組 ）                                Compaq/W3C
                                                              J. Mogul
                                                                Compaq
                                                            H. Frystyk
                                                               W3C/MIT
                                                           L. Masinter
                                                                 Xerox
                                                              P. Leach
                                                             Microsoft
                                                        T. Berners-Lee
                                                               W3C/MIT
                                                             June 1999

 

                超文本傳輸協議-HTTP/1.1


說明
   本文檔規定了互聯網社區的標準組協議，並需要討論和建議以便更加完善。請參考
“互聯網官方協議標準”（STD 1）來了解本協議的標準化狀態。本協議不限流傳發布。

版權聲明
   Copyright (C) The Internet Society (1999).          All Rights Reserved.
　Copyright  www.cnpaf.net (2007).          All Rights Reserved.

摘要

超文本傳輸協議（HTTP）是一種爲分佈式，合作式，多媒體信息系統服務，面向
應用層的協議。它是一種通用的，不分狀態（stateless)的協議，除了諸如名稱服務和分佈對象管理系統之類的超文本用途外，還可以通過擴展它的請求方式，錯誤代碼和報頭[47]來
完成許多任務。HTTP的一個特點是數據表示方式的典型性和可協商性允許獨立於傳輸數據
而建立系統。
HTTP在1990年WWW全球信息剛剛起步的時候就得到了應用。本說明書詳細闡述了HTTP/1.1
協議，是RFC 2068的修訂版[33]。

目錄（略）

1 引論

1.1 目的

超文本傳輸協議（HTTP）是一種爲分佈式，合作式，多媒體信息系統服務，面向應用層的
協議。在1990年WWW全球信息剛剛起步的時候HTTP就得到了應用。HTTP的第一個版本叫做HTTP/0.9,是一種爲互聯網原始數據傳輸服務的簡單協議。由RFC 1945[6]定義的HTTP/1.0進一步完善了這個協議。它允許消息以類似MIME的格式傳送，包括有關數據傳輸的維護信息和關於請求/應答的句法修正。但是，HTTP/1.0沒有充分考慮到分層代理，高速緩存的作用以及對穩定連接和虛擬主機的需求。並且隨着不完善的進程應用的激
增，HTTP/1.0迫切需要一個新的版本,以便使兩個通信應用程序能夠確定彼此的真實性能。

這裏規定的協議叫做“HTTP/1.1".這個協議與HTTP/1.0相比，要求更爲嚴格，以確保各項功能得到可靠實現。

實際的信息系統除了簡單的檢索外，要求更多的功能性（functionality)，包括查找(search)，前端更新(front-end update)和註解(annotation)。HTTP允許可擴充的方法集和報頭集以指示請求的目的[47]。它是建立在統一資源標識符（URI） [3]提供的地址（URL）[4]和名字（URN）上[20]，以指出方法應用於哪個資源的。消息以類似於一種叫做多用途網絡郵件擴展（MIME）[7] 的互聯網郵件的格式傳送。

HTTP也是用於用戶代理之間及代理/網關到其他網絡系統的通用通信協議，這樣的網絡系統可能由SMTP[16],NNTP[13],FTP[18],Gopher[2]和WAIS[10]協議支持。這樣，HTTP允許不同的應用程序對資源進行基本的超媒體訪問。

1.2 要求

本文的關鍵詞"MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT","SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", 和 "OPTIONAL"將由RFC 2119[34]解釋。

一項進程如果不能滿足協議提供的一個或多個MUST或REQUIRED等級的要求，是不符合要求的。一項進程如果滿足所有MUST或REQUIRED等級以及所有SHOULD等級的要求，則被稱爲“絕對符合”（unconditionally compliant）的；若滿足所有MUST等級的要求但不能滿足所有SHOULD等級的要求則被稱爲“部分符合”（conditionally compliant）的。

1.3 術語

本說明用到了若干術語，以表示HTTP通信中各參與者和對象扮演的不同角色。

連接（Connection）
爲通信而在兩個程序間建立的傳輸層虛擬電路。

消息(Message)
HTTP通信中的基本單元。它由一個結構化的八比特字節序列組成，與第4章定義的句法相匹配，並通過連接得到傳送。
 
請求(Request)
一種HTTP請求消息，參看第5章的定義。
 
應答(Response)
一種HTTP應答消息，參看第6章的定義。

資源(Resource)
一種網絡數據對象或服務，可以用第3.2節定義的URI描述。資源可以以多種表現方式
（例如多種語言，數據格式，大小和解決方案）或其他不同的途徑獲得。

實體(Entity)
作爲請求或應答的有效負荷而傳輸的信息.一個實體包含報頭形式的維護信息和消息體形式的內容,由第7節詳述.

表示方法(Representation)
一個應答包含的實體是由內容協商決定的,如第12章所述.一個特定的應答狀態所對應的表示方法可能有多個.
 
內容協商(Content Negotiation)
爲請求服務時選擇適當表示方法的機制（mechanism),如第12節所述.任何應答裏實體的表示方法都是可協商的(包括出錯應答).

變量（Variant)
在任何給定時刻,與一個資源對應的表示方法可以有一個或更多.每個表示方法稱作一個變量.使用變量這個術語並不必然意味着資源是由內容協商決定的.

客戶機（Client）
爲發送請求建立連接的程序.

用戶代理(User agent)
初始化請求的客戶端程序.常見的如瀏覽器,編輯器,蜘蛛(網絡穿越機器人),或其他的終端用戶工具.

服務器(Server)
同意連接以便通過發回應答爲請求提供服務的應用程序.任何給定的程序都有可以既做客戶端又做服務器;我們使用這些術語僅指特定連接中程序完成的任務,而不是指通常意義上程序的性能.同樣,任何服務器都可以基於每個請求的性質扮演原服務器,代理,網管,或者隧道等諸角色之一。

原服務器（Origin server)
給定的資源駐留或創建的地方.
 
代理服務器（ Proxy）
一個既做服務器又做客戶端的中介程序.,其用途是代表其他客戶發送請求.請求在內部得到服務,或者經過一定的翻譯轉至其他服務器.一個代理服務器必須能同時履行本說明中客戶端和服務器要求.“透明代理”（transparent proxy）是一種除了必需的驗證和鑑定外不修改請求或相應的代理.“非透明代理”（non-transparent proxy）是一種修改請求或應答以便爲用戶代理提供附加服務的代理,附加服務包括類註釋服務,媒體類型轉換,協議簡化,或者匿名濾除等.除非經明確指出,HTTP代理要求對兩種代理都適用.

網關（gateway）
爲其他服務器充當中介的服務器.與代理服務器不同,網關接收請求,彷彿它就是被請求資源所在的原服務器;提出請求的客戶可能覺察不到它正在同網關通信.
一個在兩個連接之間充當盲目中繼（blind relay)的中間程序.一旦有效,隧道便不再被認爲是HTTP通信的用戶,雖然隧道可能已經被HTTP請求初始化了.當兩端的中繼連接都關閉的時候,隧道不再存在.

高速緩存（Cache）
一個程序應答信息的本地存儲和控制此信息存儲、檢索和刪除的子系統,一個高速緩衝存儲器存儲應答爲的是減少對將來同樣請求的應答時間和網絡帶寬消耗,任一客戶或服務器都可能包含一個高速緩存,但高速緩存不能應用於一個充當隧道的服務器.

可緩存（Cacheable）
       如果一個高速緩存允許存儲應答信息的一份拷貝運用於應答後繼請求的拷貝,一個應答就是可緩存的.用來確定HTTP應答的緩存能力（cacheability）的規則在13節中有定義.即使一個資源是可緩存的,也可能對一個高速緩存能否將緩存拷貝用於某特定請求存在附加的約束.

直接（first-hand）
      如果一個應答直接到來並且沒有緣於原服務器,或若干代理服務器的不必要的延時,那麼這個應答就是直接的.如果它的有效性已經被原服務器直接認證,那麼這個應答也同樣是第一手的.

明確終止時間（explicit expiration time）   
原服務器預算一個實體在無需進一步確認的情況下不再被高速緩存返回的時間.

探索終止時間（heuristic expiration time）    
當沒有外在的終止時間可利用時, 由高速緩存所指定的終止時間.

年齡（Age）
     一個應答的年齡是從它被髮送,或被原服務器成功確認到現在的時間.

保鮮壽命（Freshness lifetime）
一個應答生成和過期之間的時間長度.

保鮮（Fresh）  
如果一個應答的年齡還沒有超過保鮮壽命,它就是保鮮的.

陳舊（Stale）
     一個應答的年齡已經超過了它的保鮮壽命,就是陳舊的.

語義透明（semantically transparent）
當它的使用除了改善性能外既未影響請求客戶機也未影響原服務器時, 高速緩存對於某特定的應答就是工作於語義透明方式了.當高速緩存語義透明時,客戶恰好收到與原服務器直接處理請求後得到的應答（除了逐段轉接的報頭部分）完全相同的應答。

有效性判別器（Validator）
  一個用來查找一個高速緩存記錄是否是一個實體的等效拷貝的協議元素(例如,一個實體標記（entity tag）或最終更改時間（Last-Modified time)).

上游/下游（upstream/downstream）
     上游和下游描述了消息的流動:所有消息都從上游流到下游.

向內/向外（inbound/outbound）
向內和向外指的是消息的請求和應答路徑:"向內"即"移向原服務器","向外"即"移向用戶代理".
　Copyright  www.cnpaf.net (2007).          All Rights Reserved.

1。4 總體操作

HTTP協議是一種請求/應答協議。 與主機建立連接後，客戶以請求方法，URI和協議版本的形式向服務器發送請求，繼以類MIME信息，其中包括請求修改，客戶信息和可能的正文內容。
服務器用包括消息協議版本和成功或錯誤代碼的狀態進行應答，繼以包括服務器信息，實體維護信息和可能的實體內容的類MIME消息。HTTP和MIME之間的關係如附錄19.4節所闡述。

大部分的HTTP通信由用戶代理引發，由應用到一些原服務器上資源的請求構成。最簡單的情形，可以經用戶代理（UA）和原服務器（O）之間的單一連接（v）完成。請求鏈------------------------>用戶代理(UA)-------------------單一連接（v) -------------------原服務器（O） <-----------------------應答鏈

當一個或一個以上的中介在請求/應答鏈中出現的時候，會出現更復雜的情形。常見的中介形式有三種：代理，網關和隧道。代理是一種轉送工具，它接收絕對形式的URI請求，重寫全部或部分消息，然後把重新格式化後的請求發送到URI確定的服務器上。網關是一種接收工具，它充當其他服務器的上層，必要時將請求翻譯爲下層服務器的協議。隧道不改變消息而充當兩個連接之間的中繼點；它用於通信需要穿過中介（如防火牆），甚至中介不能理解信息內容的時候。
請求鏈-------------------------------------->UA-----v-----A-----v-----B-- ---v-----C-----v-----O <-------------------------------------應答鏈


上圖顯示了用戶代理和原服務器之間的三個中介（A，B和C)。遊歷整條鏈的請求或應答消息需通過四個獨立的連接。這個特性很重要，因爲某些 HTTP通信選項只能應用於到最近的非隧道鄰居，鏈的終點的連接，或者沿着鏈的所有連接。圖表儘管是線性的，每部分可能都在忙於多路同時通信。例如，B可以接收來自不同於A的許多客戶的請求，並且／或者轉送到不同於C的服務器，與此同時，它還在處理A的請求。


任何非隧道的通信成員都可以使用內部的高速緩存來處理請求。高速緩存的作用是如果沿着鏈的一個成員對請求採用了高速緩衝的應答，請求/應答鏈就會大大縮短。以下圖解作爲結果產生的鏈，假定B擁有來自O（通過C）的一個從前應答的備份，請求尚未被UA或A緩存。
請求鏈---------->UA-----v----------A-----v-----B-----C----O <---------應答鏈

並不是所有的應答都能有效地緩存，一些請求可能含有修改量，對緩存動作有特殊的要求。緩存動作和緩存應答的HTTP要求將在第13節定義。

實際上，目前萬維網上有多種結構和配置的高速緩存和代理被實驗或使用。這些系統包括節省越洋帶寬的全國代理層，廣播或多點通信緩存接口，通過CD-ROM分配子緩存數據的機構，等等。HTTP系統應用在寬頻帶連接的企業局域網中，通過PDAs的低耗無線連接和斷續連接的訪問。 HTTP1.1的目標是支持各種各樣的應用配置，引進協議結構滿足那些需要較高可靠性，可以排除故障或至少指示故障的網絡應用的要求。

HTTP通信在通常發生在TCP/ＩＰ連接上。默認端口是TCP 80,不過其它端口也可以使用。在互聯網或其他網絡上，這並不妨礙HTTP應用在其他協議的頂端。http僅僅期望可靠的傳輸；任何提供這種保證的協議都可以使用；協議傳輸數據單元的HTTP/1.1請求和應答結構的映象已經超出了本說明書的範圍。

在http/1.0中，大部分的實現爲每個請求/應答交換使用了新連接。而http/1.1中，一個連接可以用於一個或更多請求/應答交換，雖然連接可能會因爲各種原因中斷（見第8.1節）。

2 符號慣例和一般語法

2．1 擴充BNF

本文檔規定的所有機制都用兩種方法描述：散文體（prose)和類似於RFC 822的擴充Backus-Naur Form(BNF)。要理解本說明書，使用者需熟悉符號表示法。擴充BNF包括下列結構：

名字=定義
一條規則的名字僅僅是名字本身（沒有任何"<"和">"）,跟等於號"="後面的定義是分離的。僅當連續線的空格用來表示一條長於一行的規則時空白纔是重要的。某些基本規則使用大寫字母，如SP，LWS，HT，CRLF，DIGIT，ALPHA，等等。無論何時，只要它們的存在有利於識別規則名字，就可以在定義的範圍內使用角括號。

“文字”
文字原文使用引號。除特殊情況，原文對外界不敏感。

規則1 | 規則2
由豎線("|"）分開的元素是可選的，例如，"yes | no"表示yes或no都是可接受的。

（規則1 規則2）
圍在括號裏的多個元素視作一個元素。這樣“(elem (foo | bar) elem)”允許標記序列“elem foo elem”和elem bar elem”。

*規則
前面的字符"*"表示重複。完整的形式是"*元素",表示元素至少出現次，至多出現次。默認值是0和無窮大，所以"*(元素)"允許任何數值，包括零；"1*元素"至少需要一次；"1*2element"允許一次或兩次。


[規則]
方括號裏是任選元素；"[foo bar]"相當於"*1(foo bar)".

N 規則
特殊的重複：“(元素)”相當於“*(元素)”； 也就是說，(元素)正好出現了次。這樣2DIGIT是一個兩位數字，3ALPHA是一個由三個字符組成的字符串。

#規則
類似於"*",結構"#"是用來定義一系列元素的。完整的形式是"#元素,表示至少個元素，至多個元素，元素之間被一個或多個逗號(",")以及可選的線性白色空間(LWS)隔開了。這就使得列表的一般形式變得非常容易；像
( *LWS element) *( *LWS ","*LWS element ))
就可以表示爲
1#element
無論在哪裏使用這個結構，空元素都是元許的，但是不計入元素出現的次數。換句話說，“(元素), , (元素) "是允許的，但是僅僅視爲兩個元素。因此，在至少需要一個元素的地方，必須存在至少一個非空元素。默認值是0和無窮大，這樣，“#element”允許任何數字，包括零；“1#element”至少需要1個元素；“1#2element”允許1個或2個元素。

；註釋
用分號引導的註釋，從規則正文的右邊一段距離開始直到行尾。這是做註釋的簡單方法，註釋與說明是同樣有用的。

隱含 *LWS
本說明書所描述的語法是基於字的。除非特別註明，線性空白可出現在任何兩個相鄰字之間（標記或引用字符串），以及相鄰字和間隔符之間，並不改變一個域的含義。任何兩個標記之間（下面會對"token(標記)"進行定義）必須有至少一個分割符，否則將會被理解爲單一標記。

2．2基本規則

下面的規則描述了基本的解析結構，貫穿於本說明書的全文。US-ASCII(美國信息交換標準碼)字符規定是由ANSI X3.4-1986[21]定義的。

 

       OCTET          = <任意八比特的數據序列>
       CHAR           = <任意ASCII字符（八進制 0-127）>
       UPALPHA        = <任意大寫字母"A"..."Z">
       LOALPHA        = <任意小寫字母"a"..."z">
       ALPHA          = UPALPHA | LOALPHA
       DIGIT          = <任意數字0，1，...9>
       CTL            = <任意控制字符(octets 0 - 31)及刪除鍵DEL（127）>
       CR             =
       LF             =
       SP             =
       HT             =
       <">            =


HTTP/1.1將CR LF的順序定義爲任何協議元素的行尾標誌，除了報文以外（寬鬆應用見附錄19.3）.報文內部的行尾標誌是由它的關聯媒體類型定義的，如3.7節所述。

       CRLF           = CR LF

如果延長線由空格或水平製表開始，HTTP/1.1 的報頭域值可以摺疊到到複合線上。所有的
線性空白，包括摺疊，具有同SP一樣的語義。接收者在解釋域值或將消息轉送到下游時可以用單個SP替代任何線性空白。

       LWS            = [CRLF] 1*( SP | HT )

文本規則僅僅適用於描述域的內容和不會被消息語法分析程序解釋的值。*TEST的字可以
包含ISO-8859-1[22]裏的字符，也可以包含字符規定裏的字符[14]。

       TEXT           = <除CTLs以外的任意OCTET，但包括LWS>

一個CRLF僅僅在作爲報頭域延續的一部分時纔在TEXT定義裏允許使用。

十六進制數字字符用在數個協議元素裏。

       HEX            = "A" | "B" | "C" | "D" | "E" | "F"
                      | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT


許多HTTP/1.1的報頭域值是由LWS或特殊字符分隔的字構成的。這些特殊字符必須包含在引用字符串裏，方可用在參數值（如3.6節定義）裏。

       token  （標記）        = 1*<除CTLs與分割符以外的任意 CHAR >
       separators（分割符）    = "(" | ")" | "<" | ">" | "@"
                      | "," | ";" | ":" | "/" | <">
                      | "/" | "[" | "]" | "?" | "="
                      | "{" | "}" | SP | HT

用圓括號括起來的註釋可以包含在一些HTTP報頭域裏。只有作爲域值定義的一部分時註釋纔是允許的。在其他域裏，圓括號視作域值的一部分。

       comment （註釋）= "(" *( ctext | quoted-pair | comment ) ")"
       ctext          = <除"(" and ")"以外的任意TEXT >

一個文本字符若在雙引號裏，則當作一個字。

       quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
       qdtext         = <除<">以外的任意TEXT >

反斜線("/")可以用作單一字符引用結構，但僅在引用字符串或註釋裏。

       quoted-pair    = "/" CHAR

 


3 協議參數

3.1 HTTP版本
　Copyright  www.cnpaf.net (2007).          All Rights Reserved.

HTTP使用"<主要>.<次要>"的編號方案表示協議版本。協議的版本方針是希望允許發送者表示消息的格式和性能以便理解更深一層的HTTP通信，而不僅僅是當前通信獲得的特徵。消息構件的增加不影響通信動作，或僅僅增加了擴展域值，版本號並沒有因此變化。協議的改變增加了一些特徵，沒有改變一般的消息解析規則，但是增加了消息的語義或者暗含了發送者新增的性能，這時<次要>數字便要增大。當協議的消息格式改變時，<主要>數字增大。

HTTP消息的版本在消息的第一行HTTP-版本域裏表示。

       HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT

注意主要和次要數字必須看作是兩個分離的整數，二者都可以增加到比單位數還大。這樣，HTTP/2.4的版本比HTTP/2.3低，依次HTTP/2.3的版本比HTTP/12.3低。首位的零必定被接收者忽視，一定不要發送。

一個發送包含HTTP版本"HTTP/1.1"的請求或應答消息的應用，必須至少有條件的服從本說明書。至少有條件服從本說明書的應用應該在消息裏使用"HTTP/1.1"的HTTP-版本，任何與 HTTP/1.0不兼容的消息則必須這樣做。關於何時發送特殊的HTTP-版本值，更多資料請參看
RFC 2145[36].

一項應用的HTTP版本是應用至少有條件服從的最高HTTP版本.

代理和網關轉送的消息的協議版本與應用版本不同時，需要小心。既然協議版本表示發送者的協議性能，代理/網關一定不能發送標示版本高於它本身的實際版本的消息。如果收到更高版本的請求，代理/網關必須降低請求的版本，或者發出出錯應答，或者切換到隧道動作。

由於自RFC 2068[33]發佈後發現的HTTP/1.0代理協同工作問題，高速緩存代理必須，網關可以，隧道必須不將請求提升到它們支持的最高版本。代理/網關的應答的主要版本號必須同請求相同。

注：HTTP版本的轉換可能會包含相關版本必需或禁止的頭域修改。

3.2 統一資源標識符（URI）

URIs的許多名字已爲人所知：WWW地址,通用文件標識符，通用資源標識符[3]，以及最後統一資源定位器(URL)[4]和統一資源名稱 (URN)[20]的結合。只要與HTTP相關，統一資源定位器只是格式化的字符串，它通過名稱，地址，或任何別的特徵確定了資源的位置。


3.2.1 一般語法


根據使用時的上下文，HTTP裏的URI可以表示成絕對形式或基於已知的URI的相對形式。兩種形式的區別是根據這樣的事實：絕對URI總是以一個摘要名字作爲開頭，其後是一個冒號。關於URL更詳盡的信息請參看"統一資源標識符(URI):一般語法和語義",RFC 2396 [42](代替了RFCs 1738 [4]和RFC 1808 [11]).本說明書採用那份說明書裏關於"URI-索引","絕對URI","相對URI","端口","主機","絕對路徑"和"權力"的定義.

HTTP協議不對URI的長度作事先的限制.服務器必須能夠處理它們服務的任何資源的URI,並且應該能夠處理無限長度的URI,如果它們提供可以產生這種URI的基於GET的形式.

注:服務器在依賴長於255字節的URI時應謹慎,因爲一些舊的客戶或代理實現可能不支持這些長度.

3.2.2 http URL

http方案通過HTTP協議定出網絡資源的位置.本節定義了這種方案-http URL特殊的語法和語義.
   http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

如果端口爲空或未給出,就假定爲80.語義即:已識別的資源放在服務器上,在那臺主機的那個端口上監聽TCP連接,對資源的請求的URI爲絕對路徑(5.1.2節). 無論什麼可能的時候,URL裏使用IP地址都是應該避免的(參看RFC 1900 [24]).如果絕對地址沒有出現在URL裏,它用作對資源的請求的URI時必須作爲"/"給出.如果代理收到一個不是充分資格域名的主機名,一定不能改變主機名.


3.2.3 URI 比較

當比較兩個URI是否匹配時,客戶應該對整個URI進行區分大小寫,以八字節爲單元的比較.以下情況例外:

-一個爲空或未給定的端口等同於那個URI索引裏的默認端口;

-主機名的比較必須是不區分大小寫的;

-方案名的比較必須是不區分大小寫的;

-一個空絕對路徑等同於絕對路徑"/".

   Characters other than those in the "reserved" and "unsafe" sets are equivalent to their ""%" HEX HEX" encoding.
除了"保留"或"危險"集裏的字符(參見RFC 2396 [42]) ,字符等同於它們的""%" HEX HEX"編碼.

例如,以下三個URI是等同的:

      http://abc.com:80/~smith/home.html
      http://ABC.com/~smith/home.html
      http://ABC.com:/~smith/home.html


3.3 日期/時間格式

3.3.1 完整日期

歷史上的HTTP應用一直允許三種不同的表示日期/時間印記的格式:

      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標準提出來的,它表示一個由RFC 1123 [8](RFC 822[9]的升級版本)定義的固定長度的子集.第二種格式使用比較普遍,但是基於廢棄的RFC 850 [12],需要(應該)用四位數表示年份.對日期值進行語法分析的HTTP/1.1客戶和服務器必須接受所有三種格式(爲了同HTTP/1.0兼容),雖然它們必須只產生RFC 1123格式以在頭域裏表示HTTP日期值.

注:鼓勵日期值的接收者在接受可能由非HTTP應用發來的日期值時要堅定,這種非HTTP應用有時是通過代理/網關到SMTP或NNTP檢索或張貼消息.

所有的HTTP日期/時間印記都必須毫無例外的以格林威治平均時間(GMT)表示.爲了HTTP,GMT完全等同於UTC(協調世界時間).這在前兩種形式裏用三個字母的時區縮寫-GMT的蘊含來表示,並且讀取ASC時間格式時必須先被假定.HTTP日期區分大小寫,除了在語法中作爲SP特別包括的 LWS外,一定不能包括額外的LWS.
       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對日期/時間印記格式的請求僅僅應用在協議流裏.客戶和服務器不必爲了用戶簡報,請求記錄及其他而使用這些格式.

3.3.2 Delta秒

一些HTTP頭域收到消息後,允許以十進制整數秒錶示的時間值.
       delta-seconds  = 1*DIGIT

3.4 字符集

HTTP使用的關於術語"字符集"的定義和MIME中所描述的一樣.

本文檔中的術語"字符集"指一種用一個或更多表格將一個八字節序列轉換成一個字符序列的方法.注意另一方向的無條件轉換是不需要的,在這種轉換裏, 並不是所有的字符都能在一個給定字符集裏得到,並且字符集可能提供多個八進制序列表示一個特定字符.這個定義將允許各種字符編碼方式,從簡單的單表格映射如US-ASCII到複雜的表格交換方法如ISO-2022的技術裏所使用的.然而,與MIME字符集名字相關聯的定義必須充分說明從八字節變換到字符所實現的映射.特別的,使用外部輪廓信息來決定精確映射是不允許的.

注:這裏使用的術語"字符集"更一般的被稱作一種"字符編碼".不過既然HTTP和MIME使用同樣的註冊表,共用術語是很重要的.

HTTP字符集用不區分大小寫的標記表示.完全標記集合由IANA字符集註冊表[19]定義.
       charset = token

儘管HTTP允許用任意標記作爲字符集的值,任何在IANA字符集註冊表裏有預先確定值的標記必須表示該註冊表定義的字符集.對那些IANA定義的字符集,應用應該限制使用字符集.

實現者應該注意IETF字符集的要求[38][41].

3.4.1 失蹤字符集

一些HTTP/1.0軟件將沒有字符集參數的內容類型頭錯誤的理解爲"接收者應該猜猜."若發送者希望避免這種情況,可以包含一個字符集參數,即使字符集是ISO-8859-1;當知道不會使接收者混淆時,也應該這樣做.

不幸的是,一些舊的HTTP/1.0不能適當處理詳細的字符集參數.HTTP/1.1接收者必須重視發送者提供的字符集標註;當最初顯示文檔時，那些提供"猜"字符集服務的用戶代理必須使用內容類型域中的字符集，如果它們支持那個字符集，而不是接收者的首選項。參看3.7.1節。

3.5 內容編碼

內容編碼值表示一種已經或可以應用於實體的編碼變換。內容編碼主要用來允許文檔壓縮，換句話說，有效的變換而不損失它的基本媒體類型的特性，也不丟失信息。經常地，實體以編碼形式儲存,直接傳送,只能由接收者譯碼.

       content-coding   = token

所有內容編碼值都是不區分大小寫的.HTTP/1.1在接收譯碼(14.3節)和內容譯碼(14.11節)的頭域裏使用內容編碼值.儘管該值描述了內容編碼,更重要的是它指出需要什麼編碼機制
來除去編碼.

互聯網賦值機構(IANA)充當內容編碼值標記的註冊處.最初,註冊表包含下列標記:

  gzip（壓縮程序）
一種由文件壓縮程序"gzip"(GNU zip)---如RFC 1952所描述---生成的編碼格式.這種格式是一種32位CRC Lempel-Ziv編碼(LZ77).   [譯者注]CRC:循環冗餘校驗

   compress（壓縮）
由通用UNIX文件壓縮程序"compress"生成的編碼格式.這種格式是一種具有可適應性的Lempel-Ziv-Welch編碼.
對未來的編碼來說,用程序名識別編碼格式是不可取,令人氣餒的.在這裏他們的用處是作爲歷史實踐的代表而不是好的方案.爲了同以前的HTTP實現相兼容,應用應該將"x-gzip"和"x-compress"分別等同於"gzip"和"compress".
 
   deflate（縮小）
RFC 1950 [31]定義的"zlib"格式與RFC 1951 [29]描述的"deflate"壓縮機制的組合.

   Identity（標識）
    缺省(標識)編碼;無論如何,不進行轉化的應用.這種內容譯碼僅被用於接受譯碼報頭,並且不能被用在內容編碼報頭.

  新的內容譯碼值的標記應該註冊;爲了允許客戶和服務器間的互用性,內容譯碼運算的規範需要實現一個可被公開利用並能獨立實現的新值,並且與這節中內容譯碼定義的目的相一致.

3.6  傳輸編碼

   傳輸編碼值被用來表示一個已經,能夠,或可能需要應用於一個實體的編碼轉化,爲的是能夠確保通過網絡安全傳輸.這不同於內容譯碼,傳輸譯碼是消息的特性而不是原始實體的特性.
       transfer-coding = "chunked" | transfer-extension
       transfer-extension      = token *( ";" parameter )

   參數採用屬性/值對的形式.

       參數                   = 屬性  "=" 值
       屬性                   = 標記
       值                     = 標記  |   引用-串（quoted-string）

   所有傳輸譯碼值是不直觀的.HTTP/1.1在TE頭域(14.39節)和傳輸譯碼頭域(14.41節)運用傳輸譯碼.

   無論何時一個傳輸譯碼都被應用於一個消息體,傳輸譯碼的設置必須包括"大塊",除非消息被結束連接停止.當"大塊"傳輸譯碼被應用時,它必須是應用於消息體的最後傳輸譯碼.這些規則允許接受從而確定消息的傳輸長度(4.4節)

   傳輸譯碼與MINE[7]的內容傳輸譯碼值相類似,它被定義能夠實現傳送服務器超過7位的二進制數據的安全傳輸.不過,安全傳輸對純8位傳輸協議有不同的焦點.在HTTP中,消息體唯一不安全的特性是確定確切的體的長度的這個難點(7.2.2節),或在共享傳輸上加密的要求.

   網絡分配數字權威(IANA)擔任了傳輸譯碼值標記註冊處的角色.起初,註冊包含如下標記:"大塊"(3.6.1節),"身份"(3.6.2節),"gzip"(3.5節),"壓縮"(3.5節),和"縮小"(3.5節).

   新的傳輸譯碼值標記應和新的內容譯碼值標記以相同的方式註冊(3.5節).

服務器接收到一個不能理解的傳輸譯碼實體時應返回501(不實現),並且切斷聯繫.服務器不能向HTTP/1.0客戶發送傳輸譯碼.

3.6.1 成塊傳輸代碼（Chunked Transfer Coding）

   成塊編碼更改消息主體,爲的是將它以一系列大塊的形式傳送,每一個連同它自己尺寸的指示器,被一個包含實體頭域的可隨意選擇的trailer跟隨.這允許有力量的地生產同接受所必需的消息一起轉化的內容,從而檢驗它已經獲得全部消息.
       Chunked-Body   = *chunk(大塊)
       大塊-正文           last-chunk(最後-大塊)
                        trailer(追蹤者)
                        CRLF

       chunk          = chunk-size [ chunk-extension ] CRLF
        大塊          =  大塊-尺寸 [ 大塊 -擴展]CRLF
                        chunk-data CRLF
                         大塊-數據 CRLF
       chunk-size     = 1*HEX
       大塊數據
       last-chunk     = 1*("0") [ chunk-extension ] CRLF
        最後-大塊     = 1*("0") [大塊-擴展]CRLF           

       chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
       大塊-擴展                大塊-外部-名稱      大塊-外部-值
       chunk-ext-name = token
        大塊-外部-名稱= 標記
       chunk-ext-val  = token | quoted-string
         大塊-外部-值 = 標記  |  引用-串
       chunk-data     = chunk-size(OCTET)
        大塊-數據     = 大塊 -尺寸(八位子節)
       trailer        = *(entity-header CRLF)
        追蹤者        = * (實體-領先 CRLF)

   大塊尺寸域是用16進製表示大塊尺寸的一串數字.成塊編碼以任一尺寸爲0的大塊結束,後綴以trailer,以一個空行終止.

   trailer允許發送者在消息末尾包含附加的HTTP頭域.trailer頭域可被應用於簡要說明包含trailer的頭域 (14.40節)

   一個服務器在應答中運用傳輸譯碼時不能在任何頭域使用trailer,除非以下至少一條爲真:
   a)        請求包括一個TE頭域時表明"trailer"在應答的轉移譯碼中是可被接受的,就像14.39節中描述的那樣;或者
   b) 服務器是爲了應答的原始服務器,trailer的域完全由隨意的元數據構成,這個接收者可以在不接受這個元數據的情況下使用消息(在一個原始服務器可接受的方式中).另一方面,原始服務器願意接受trailer域可能會在通往客戶的通道上被默默放棄的這種可能性.

   當消息被一個HTTP/1.1代理人接受並且8轉寄至一個HTTP/1.0接受器時,這種需求防止了一個互用性的失誤.它避免了一個依據協議將使在代理者上安置一個可能無限大的緩衝器成爲必要的情形發生.

   對一個大塊主體進行解碼處理的例子已在附錄19.4.6中作過介紹

  所有HTTP/1.1應用程序必須能接受和解碼"大塊"傳輸譯碼,並且必須忽略它們不理解的大塊擴展擴展名.

3.7 媒體類型

   爲了提供公開的,可擴展的數據輸入和規範流通,HTTP在目錄類型(14.17節)和認可(14.1節)頭域中運用網絡媒體類型.

       媒體類型       = 類型 "/" 亞類型*(";" 參數  )
       類型           = 標記
       亞類型       = 標記

   參數可能在屬性/值的形式上遵循類型/亞類型.(如3.6節定義)

   類型,亞類型,和參數屬性名稱是不直觀的.參數值直觀與否,取決於參數名稱的意義.
線性的白色空間(LWS)不能被用於類型和亞類型之間,也不能用於一種屬性及他的值之間.一個參數存在與否對媒體類型的處理有着重要的意義,取決於它在媒體類型註冊中的定義.

  注意一些舊的HTTP應用軟件不能識別媒體類型參數.向一箇舊的HTTP應用軟件傳送數據時,只有當類型/亞類型精確度需要時,才能實現媒體類型參數.

   媒體類型值已經在網絡分配數碼權威(IANA[19])註冊.媒體類型的註冊程序在RFC 1590[17]中略述.使用未經註冊的媒體類型是不會得心應手的.

3.7.1 規範化和原文缺省

   網絡媒體類型以語言的語音典型形式註冊.一個通過HTTP通訊傳輸的實體必須被以先於傳送的適當的規範的形式描繪,除'text'類形以外,就像下段定義的那樣.

   當在規範的形式中,'text'類型的媒體亞類型運用GRLF作爲全文行的間斷.HTTP放鬆了這個要求,當一個完整實體被間斷完成時,允許全文媒體以簡單的GR或LF獨立作爲一行的隔斷的傳輸. 在通過HTTP承認的原文媒體中,作爲一個行的間斷的代表,HTTP應用程序必須接受CRLF,空的CR,和空的LF. 而且,如果原文在一個特性設置中被表現,沒有分別用8位字節13和10表示CR和LF,就像某種多重字節特性設置,HTTP允許使用任何被爲了表現CR和 LF在行間斷中的等同的特性設置所定義的任何8位字節次序.這個關於行間斷的伸縮性僅僅應用於再一個實體中的原文媒體;一個空的CR或LF在任意HTTP 控制的結構中都不能代替CRLF.(例如頭域和多部邊界)

   如果一個實體把一個目錄譯碼譯成電碼,在下面的譯碼必須被定義成在上面先被譯碼的形式.

   "charset"參數和一些媒體類型一起使用用來定義數據的特性設置(3.4節).當發送者沒有提供清楚的charset參數,通過HTTP接受時 "text"類型的媒體類型就被定義成有一個爲"ISO-8859-1"的默認charset值.特性設置的數據不同於"ISO-8859-1"或它的子集必須被標以適當的charset值. 參見3.4.1節中兼容性問題.

3.7.2 多部分類型（Multipart type)

   MIME提供了一系列"多重部分"類型---在單個消息體內一個或多個實體的包裝.所有的多重部分類型共享一個公共的序列,就像RFC 2046的5.1.1節中定義的那樣.
   必須包括一個作爲媒體類型值一部分的邊界參數.這個消息體自成爲一個要素協議,因此在兩部分間只能用CRLF來表現行的間斷.不同於RFC 2046,任一多重消息的末尾必須爲空;HTTP應用程序不能傳送末尾(即使原始的多重部分包含一個末尾).存在這些制約爲的是保護一個多重部分消息實體的固有本質,結束多重部分邊界已經在消息體的"結尾"加以表明.

   通常,HTTP將一個消息體視爲與任何其他媒體類型無異:嚴格如有效負載.當消息體出現在206應答時,有一個例外就是"多重部分/字符串"類型(附錄 19.2),將會被一些HTTP隱藏裝置打斷,就像13.5.4和14.16節中描述的那樣.除此情況外,一個HTTP用戶代理應該遵循與一個MINE用戶代理相同或相似的行爲,在多重部分類型收據之上.MIME頭域在一個多重部分消息體的每一個部分裏,對超過MIME意義的定義的HTTP沒有任何意義.

  通常, 一個HTTP用戶代理應該遵循與一個MINE用戶代理相同或相似的行爲,在多重部分類型收據之上.如果一個應用程序收到一個不能識別的多重部分亞類型,這個應用程序必須將它視爲與"多重部分/混合"相等.

  注:"多重部分/形態-數據"形式已被在適合於通過POST請求方法處理的傳送形式數據明確定義,就像在RFC 1867[15]中描述的那樣.

3.8 產品標記

   產品標記被用來承認通過軟件名和譯本識別它們自己的通訊應用軟件.很多域還把產品標記用於認可次級產品,專業產品構成應用軟件中有重要意義的部分被一一列出,用白色間隔分開.按照慣例,按產品對於識別應用軟件的重要性的順序列出它們.

       產品           = 標示  ["/" 產品 -版本]
       產品-版本       = 標示

   例:
        用戶-代理:   CERN-LineMode/2.15 libwww/2.17b3
      服務器: Apache/0.8.4
   產品標示應言簡意賅.它們不能用來做廣告或其他不重要的信息.雖然任一標示可能出現在產品-版本上,但這個標示僅能被用來做一個版本標識(i.e., 同類產品中成功的版僅區別在產品值的產品版本部分）

3.9 質量值(Quality Values)

  HTTP內容流通(12節)運用簡短的"浮點"數字來表明不同可流通參數之間的重要聯繫("重要性").一個重要性從0到1規格化了一個真實的數字,0是最小值,是最大值.如果一個參數爲0的質量值,那麼這個參數的內容不被客戶接受.HTTP/1.1應用軟件不能產生多於小數點後三位數字.這些值的用戶配置也應受限於這種方式.
       qvalue         = ( "0" [ "." 0*3DIGIT ] )
                      | ( "1" [ "." 0*3("0") ] )

   "質量值" 是一個不當的用詞,因爲這些值僅僅表現想要得到的質量中的降級關係.

3.10 語言標記

   一個語言標記和自然的語言一樣說,寫,或被人類用於與其他人傳遞信息.計算機語言明顯不包括在內.HTTP在認可語言和目錄語言域內運用語言標記.

   HTTP語言標記的語法和註冊像RFC 1766[1]中定義的一樣.總之,一個語言標記是由一部分或多部分構成:一個主要語言標記和可能爲空的一系列下標籤.

        語言標記      = 主要標記    *("_"  下標籤)
        主要標記   = 1*8ALPHA
      
        下標籤        = 1*8ALPHA
      
    標籤中不允許出現空格，標籤對個例不敏感（case-insensitive）.由IANA來管理語言標記中的名字間隔.典型的標籤包括:

       en, en-US, en-cockney, i-cherokee, x-pig-latin

   任何兩個字母的主要標籤是一個ISO-639語言的縮寫,兩個大寫字母的下標籤是一個ISO-3166的國家代碼.(上面的最後三個標籤是未經註冊的標籤;除最後一個之外所有都是可在將來註冊的例子標籤).

3.11 實體標籤

   實體標籤用來從相同請求資源中比較兩個或更多實體.HTTP/1.1在Etag(14.19節),If-match(14.24節),If-None- match(14.26節),和If-rang(14.27節)頭域中運用實體標籤.關於它們怎樣像高速緩衝存儲器確認一樣使用和比較的解釋在 13.3.3節中.一個實體標籤由一個給定的不透明的一行組成,可能加上一個虛弱指示器的前綴.

      entity-tag = [ weak ] opaque-tag
      weak       = "W/"
      opaque-tag = quoted-string

   一個"堅固的(strong)實體標籤"在兩個實體八位子節相等時可能會被一個資源裏的兩個實體共享.

   一個"虛弱(weak)的實體標籤",由"W/"前綴表示,在實體相等且可以互相替代而在語義上不發生重大的變動時,可能會被一個資源力的兩個實體共享.一個虛弱的實體標籤只能在虛弱對比時使用.

   一個實體標籤必須在所有與一個特殊資源相連繫實體的譯本中是獨一無二的.一個給定的實體標籤值可以被不同的URI請求用來獲得實體.相同實體標籤值在不同URI請求獲得實體的聯合中的運用不意味着那些實體的等同.

3.12 範圍單位(Range Units)

    HTTP/1.1允許一個客戶要求單獨部分的應答實體被包括在應答內.HTTP/1.1在範圍(14.35節)和目錄範圍頭域(14.16節)運用範圍單位.一個實體可根據不同的結構單位分解成子區域.

       範圍-單位       = 字節-單位 |  其他-範圍-單位
      字節-單位        =  "字節"
      其他-範圍-單位   = 標記

   HTTP/1.1中定義的唯一的範圍單位是"字節".HTTP/1.1實現時可能忽略其他單位指定的範圍。
   HTTP/1.1的設計允許應用軟件不依靠有關範圍的知識而實現


4 HTTP消息

　Copyright  www.cnpaf.net (2007).          All Rights Reserved.

4.1  消息類型

      HTTP消息由從客戶到服務器的請求和從服務器到客戶的回答組成.
              HTTP-消息 = 請求|回答 ;HTTP/1.1 消息
       請求(第五節)和回答(第六節)的消息是用一般的消息格式RFC 822[9]來傳輸實體的(消息的有效載荷).這兩種消息都是由開始行,零或者更多的頭域(也叫做頭),象徵頭結束的空行(譬如說一個只有回車字符的行)組成,有時可能會有一個信息體.
       一般的消息=開始行
                  *(消息頭 CRLF)
                  CRLF
                   [消息的內容]
       開始行    =請求行|狀態行
       爲了健壯性,服務器必須在期望收到要求行的地方忽略任何接收到的空行.換句話說,如果服務器在讀一條信息開始的協議流時先收到了CRLF,它必須忽略這個CRLF.
       一般一個有問題的HTTP/1.0客戶端在POST請求後會產生額外的CRLF.爲了重述什麼是BNF明確禁止的,一個HTTP/1.1客戶端沒有必要開始和跟隨一個額外的CRLF的請求.

4.2 消息頭
     HTTP頭域包括常規頭(4.5節)請求頭(5.3節),應答頭(6.2節)和實體頭(7.1節)域,它們遵循RFC822 [0]3.1節中給出的同一個常規的格式.每一個頭域由一個緊跟":"的名字和域值構成.域名是大小寫不敏感的.域值可能在任何LWS的前面,儘管單個的 SP是首先的.頭域能通過把各個額外行(至少有一個SP或HT)前置來擴展成多行.當產生HTTP結構的時,應用必須遵循"共同格式",那兒它被知道或定義,即使有時存在一些不能接受任何東西的操作.

  共同的格式.

消息-頭=域名":"[域值]
域名=記號
域值=*(域的內容|LWS)
域的內容=<由八位的字節構成域值,它由文本或組合標記,分割符,和引用的字符串組成>

這個域的內容不包括任何引導的或連接的LWS:位於域內容屬性的第一個不是空白的地方的前面或最厚的布是空白的地方的後面.去掉這些引導或連接的LWS可能不會影響域內容的意思,任何位於域內容之間的LWS在解釋域的內容或傳送消息的下載流的時候可以用單個的SP替換.
用不同域名收到的頭域的順序不是重要的.但是,一個好的習慣是先送常規頭,接着是請求頭或應答頭,最後是實體頭域.

多個消息頭域使用同一個域可能會出現在一些消息中,在這些消息中,可能也只可能是整個域用逗號分割的列表定義(例如,#(值)).這些必須有可能在沒有改變消息的情況下被組合成一個"域名:域值"對,在這些被逗號隔開的域中後面的域植被添加到第一個域中.那些用同一個域名組成一個頭域的順序是重要的,因此當一個消息在傳輸的時候代理一定不能改變這些域值的順序.

4.3 消息體

  HTTP消息的消息體備用用來傳輸由要求和應答組成的實體.這些消息體僅僅當傳輸譯碼被應用的時候才和實體不同,這用傳輸編碼的頭域標明(14.41節).

     消息體=實體|<編碼的實體>

傳輸編碼常用來表示那些應用程序爲了安全和保證消息的正確傳輸的傳輸碼.傳輸編碼是一種消息的屬性而不是實體,因此沿着請求/應答鏈它可以被任何應用程序加上或去掉.

   當一個消息中允許有消息體時的規則和請求應答時的不一樣.

   一個請求的消息體是用來傳達內容長度或請求傳輸編碼頭的傳輸編碼頭域的信息.如果請求方式的規範不允許請求中加入實體則一個請求中也必須不能包括消息體. 一個服務器必須讀和處理任何請求的消息體;如果請求方法沒有定義一個實體的表述,則當處理這個請求是必須忽略消息體.

   對於應答消息,一個消息是否包括消息體依賴於請求的方法和應答的狀態代碼(6.1.1節).對於所有頭請求方法的應答都不能包括消息體,即使有時實體頭域的存在讓人相信它們包括了.所有1XX(信息的),204(無內容的),和304(沒有修改的)的應答都不能包括消息體.所有其他的應答必須包括消息體, 雖然它可能長度爲零.

4.4 消息的長度

     一條消息的傳輸長度是消息體出現在消息中的長度,也就是說,當傳輸代碼被處理以後.當一條消息包含消息體,實體的輸長度有以下幾條決定(以先後順序):

     1。任何迴應信息不應包含在信息體中，如1xx，204,304迴應和任何對頭請求的迴應。這種情況都是在頭域結束後第一行爲空白行,不管實體域是否出現。

     2。傳輸代碼頭域(屬於general-header域)出現的話而且有值而不是身份，那麼傳輸長度就可以使用chunked大塊來確定，除非信息由於連接關閉而中斷了.

     3。如果Content-Length頭域(屬於實體頭)出現，那麼它的值是信息體傳輸長度。如果傳輸頭域和Content-Length頭域都出現了，而長度不一致，那麼Content-Length頭域中的值就不該傳。

     4。如果被1.0代理傳送的範圍頭域不能理解多部份/位範圍；服務器必須採用1，2，3的方式界定信息體長度。

     5。當服務器正在關閉連接.(正在關閉連接不能用來說明應答體的結束,因爲它將導致服務器沒有可能送回一個應答信號.)

爲了與HTTP/1.0應用程序兼容,HTTP/1.1請求包含的消息體必須包括一個有效內容長度的頭域,除非知道服務器適應HTTP/1.1.如果一個請求包含一個消息體並沒有給出內容長度,那個服務器會應答400(錯誤的請求)如果他不能判斷消息長度的話,或者應答411(要求成都)如果它堅持想要收到一個有效內容的長度.

所有的HTTP/1.1應用程序必須接受"CHUNKED"傳輸代碼(3.6節),因此允許這種機制來處理消息當消息的程度不能被決定.

消息沒有必要都不包括內容長度頭域和non-identity傳輸代碼.如果消息包括了一個non-identity傳輸代碼,傳輸長度必須忽略.

當一個內容的長度在消息體允許的地方給出時,這個域值必須和消息體中八進制數一致.HTTP/1.1用戶代理必須通報使用者當一個無效的長度被接受和發現.

4.5 常規頭域

   這兒有一些頭域能適應一般的請求和應答消息,但是它沒有應用漁船樹種的實體.這些頭域只應用於那些被髮射的消息.

     常規的頭域=高速緩存控制         ;14.9節
                |連接         ;14.10節
                |數據         ;14.18節
                |程序         ;14.32節
                |追蹤         ;14.40節
                |傳輸編碼     ;14.41節
                |升級         ;14.42節
                |路由         ;14.45節
                警告          ;14.46節

   常規頭域的名字的真正擴展必須和協議版本的變化相結合。然而，新的或實驗性質的頭域可能被賦予常規頭域的意義，如果信息傳輸中的所有部分都承認它們爲常規頭域的話，未被承認的頭於一般當實體頭域看待。


5 請求

從客戶機到服務器的請求,其首行包括利用資源的方式,區分資源的標識,以及協議的版本號
請求   =請求行                       ;  5.1節
       *((常規報頭                    ;  4.5節
         |請求報頭                    ;  5.3節
         實體報頭)CRLF)              ;  7.1節
           CRLF       
         [消息正文]                   ;  4.3節

5.1 請求行

   請求-行的開頭是方法標識,接下來是請求URL和協議版本號,以回車換行結束.各部分之間用空格符(SP)分隔,除了最後的回車換行外,不允許有回車(CR)和換行(LF).

       請求-行  ==方式(空格) 請求URI(空格)  HTTP版本號(回車換行)

5.1.1方法

  方法標記指的是在請求URI所指定的資源上所實現的方式,這種方式是條件敏感的

Method     = "OPTIONS"                     ;9.2節
             | "GET"                        ;9.3節
             | "HEAD"                       ;9.4節
             |"POST"                        ;9.5節
             |"PUT"                         ;9.6節
             |"DELETE"                      ;9.7節
             |"TRACE"                       ;9.8節
             |"CONNECT"                     ;9.9節
             | 擴展方式(extension-method)

擴展方式=   標記

資源允許的方法列表能由允許(Allow)報頭域詳細指定．既然被允許方法的設置可以動態的改變,返回的應答碼總是通知客戶機當前方法是否被允許. 如果原服務器知道方法，但方法不被請求的資源允許，原服務器應當返回狀態碼405(方法不允許)．如果方法不被原服務器承認和實現,原服務器應當返回狀態碼501(沒有實現）.獲取(GET)和報頭(HEAD)方法應當被所有的多功能服務器支持．其他所有的方法是可選的，然而，假若以上的方法沒有實現，則他們必須被在第九章裏所說明的同一種語法定義所實現．

5.1.2 請求URL

　　請求URL是一種全球統一的應用於資源請求的資源標識符（３.2 節）．
　
　　　　請求URL   ="*"|絕對URL|絕對路徑|主機authotity

請求URI的四個選項在一般情況下是互相關聯的,星號"*"表示請求不是應用於某種特別的資源,而是服務器本身,只有當所用的方法不是資源必要的方法纔是允許的.舉例如下

             選項(OPTIONS)*HTTP/1.1

當代理服務器產生請求時，絕對URI地址是不可缺少的．代理服務器被要求轉寄來自高速緩衝存儲器有效的請求或服務,返回應答．注意到代理服務器可以把請求轉發給另一臺代理服務器或直接轉發給絕對URI地址說明的服務器．爲了避免請求循環，代理服務器必須識別所有的服務器名字，包括任何別名，本地變異名，數字IP地址．請求行舉例如下：
　　　　　
　　　　　ＧET  http://www.w3.org/pub/www/TheProject.html  HTTP/1.1

爲了在未來的HTTP版本的所有請求中轉換絕對URL地址，所有基於ＨTTP/1.1的服務器必須接受絕對URL地址的組成，雖然基於HTTP/1.1的客戶機將只產生請求發給代理服務器

主機(authority)組成部分只是在連接方法(CONNECT)中用到（９.9節）．

最通用形式的請求ＵＲI用於標識在原服務器或網關上的資源.這種情況下，絕對ＵＲＬ路徑必須作爲請求ＵＲＬ傳送（看３.２.１節，絕對路徑），ＵＲＩ局域網地址(authority)(必須輸入主機報頭域．例如，希望直接得到原服務器頂層資源的客戶機將在"ｗｗｗ．ｗ３．ｏｒｇ"主機的端口８０建立ＴＣＰ連接發送以下行：
　　
　　　GET /pub/WWW/TheProject.html HTTP/1.1
      Host:www.w3.org

接下來是請求的其他部分，注意絕對路徑不能是空的；假如沒有初始的URI，必須給出"／"（服務器根目錄）．

請求ＵＲＬ用在3.2.1節裏說明的格式傳輸．如果用"%HEX　HEX"[42]碼編碼,爲了正確的翻譯請求，原服務器必須譯碼．對於有適當狀態碼的無效的請求，服務器必須給予應答．

當透明的代理服務器轉發收到的請求ＵＲＬ地址給下一臺網內的服務器時，禁止其重寫 "絕對路徑"部分,上面提到的用"／"代替空的絕對地址不在此例．

注：當原服務器不恰當的用非保留ＵＲＬ字符作保留用時，"禁止重寫"規則防止
代理服務器更改請求的含義，實現程序將瞭解前面的一些HTTP/1.1代理服務器就將知道改寫了請求ＵＲＩ．

5.2請求定義的資源

一個INTERNET請求所定義的精確資源由請求URL和主機報頭域所決定.

當決定HTTP/1.1協議標識的資源時，不允許資源與請求主機不同的原服務器可以忽略主機報頭域的值，（但看１９.６.１節瞭解支持HTTP/1.1主機上的另一種需求）.

基於主機的請求區分資源的服務器(有時指虛擬的主機或空白的主機名)必須用以下的規則決定HTTP/1.1請求所請求的資源．

１． 如果請求URI是絕對地址，主機是請求URI的一部分．任何主機報頭域應當忽略．
２． 假如請求URI不是絕對地址，且請求包括一個主機報頭域，則主機由該域的值所決定．
３． 假如由規定１或規定２定義的主機是無效的主機，則應答當是一個400出錯信息

爲了找出真正被請求的資源，一個缺乏主機標識域的HTTP/1.0請求接收者可以嘗試使用試探的方法（例如檢測ＵＲＩ路徑對於特定的主機是唯一的這個性質）．

５.3請求報頭域

請求的報頭域允許客戶傳遞關於請求，客戶自己的附加信息給服務器．這些域作爲請求修飾成分，和程序語言中方法調用的參數有差不多的含義．

　　　請求報頭　＝　接收(Accept)　　　　　　　　　　                ;14.1節
                   |接收Charset (Accept-Charset)              ;14.2節
                   |接收編碼(Accept-Encoding)          ;14.3節
                   |接收語言(Accept-Language)               ;14.4節
                   |認證(Authorization）                        ;14.8節
                   |期望(Expect)                              ;14.20節
                   |源(From)                                  ;14.22節
                   |主機(Host)                               ;14.23節
                   |假如匹配(If-Match)                       ;14.24節
                   |假如修改(If-Modified-Since)              ;14.25節
                   |假如不匹(If-None-Match)            ;14.26節
                   |假如歸類(If-Range)                 ;14.27節
                   |假如不修改(If-Unmodified-Since )         ;14.28節
                   |最大轉發量(Max-Forwards                      ;14.31節
                   |代理認證( Proxy-Authorization)         ;14.34節
                   |範圍(Range)                                 ;14.35節
                   |提交者(Referer)                          ;14.36節
                   |TE                                  ;14.39節
                   |用戶代理(User-Agent)                  ;14.43節

隨着協議版本的變化,請求報頭域的名字可以可靠的擴展．然而新的或擴展的報頭域可以給出請求報頭域的語法，其前提是通信中所有部分承認它們是請求報頭域．不被承認的報頭域被當作實體報頭域．

６ 應答

接收和翻譯一個請求信息後，服務器發出一個HTTP應答信息．

　　　　　應答　　　＝狀態行　                                 ;6.1節
　　　　　　　　　　　*((常規報頭(general-header）                ; 4.5節
                       |應答報頭(response-header)            ;6.2節
                       |實體報頭(entity-header)CRLF)          ;7.1節
                             CRLF
                      [應答正文]                             ;7.2節

6.1 狀態行

應答信息的第一行是狀態行,由協議版本以及數字狀態碼和相關的文本說明組成,各部分間用空格符隔開，除了最後的回車或換行外，中間不允許有回車換行．
　　　　　
　　　狀態行　＝　HTTP版本 SP狀態碼 SP 原因短語 CRLF

6.1.1狀態碼與註解

狀態碼是試圖理解和滿足請求的三位數字的整數碼，這些碼的完整定義在第十章．註解短語是特意給出的關於狀態碼的文本描述．狀態碼用於自動控制而註解短語是面向用戶的．客戶機不需要檢查和顯示註解短語．

狀態碼的第一位數字定義應答類型．後兩位數字沒有任何類型任務．第一位數字有五種值：

-1xx: 報告的                - 接收到請求,繼續進程.
-2xx  成功                  - 操作成功的收到.
-3xx  重發              - 爲了完成請求,必須採取進一步措施.
-4xx  客戶端出錯            - 請求包括錯的順序或不能完成.
-5xx  服務器出錯            - 服務器無法完成顯然有效的請求.

爲HTTP/1.1定義的狀態碼單獨的值，和一個相應的一系列註解短語的例子，介紹如下,這兒列出的註解短語只是建議――它們可以被相當的沒有感情色彩的協議取代．

　　狀態碼　＝
　　             "100" ;         10.1.1節:         繼續         
                    |"101"   ;  10.1.2節:         轉換協議   
                    |"200"   ;  10.2.1節:         OK
                |"201"   ;        10.2.2節:   創建              
                    |"202"   ;  10.2.3節:   接受       
　　                |"203"   ;  10.2.4節:        非權威信息 
                                                  
                    |"204"   ;   10.2.5節:  無內容     
                    |"205"   ;   10.2.6節:  重置內容    
                    |"206"   ;   10.2.7節:  局部內容    
                    |"300"   ;   10.3.1節:  多樣選擇    
                |"301"   ;   10.3.2節:  永久移動    
                |"302"   ;   10.3.3節:  創建        
                    |"303"   ;   10.3.4節:  觀察別的部分        
                    |"304"   ;   10.3.5節:  只讀                
                    |"305"   ;   10.3.6節:  用戶代理            
                    |"307"   ;   10.3.8節   臨時重發            
                |"400"   ;   10.4.1節:  壞請求              
                    |"401"   ;   10.4.2節:  未授權的            
                    |"402"   ;   10.4.3節:  必要的支付          
                    |"403"   ;   10.4.4節:  禁用                
                    |"404"   ;   10.4.5節:  沒找到               
                    |"405"   ;   10.4.6節:  不允許的方式        
                    |"406"   ;   10.4.7節:  不接受               
                |"407"   ;   10.4.8節:  需要代理驗證
                |"408"   ;   10.4.9節：         請求超時            
　　　　        |"409"   ;   10.4.10節；        衝突                
　　　　        |"410"   ;   10.4.11節： 停止                
　　　　        |"411"   ;   10.4.12節： 需要的長度          
　　　　        |"412"   ；  10.4.13節；        預處理失敗          
　　　　        |"413"   ;   10.4.14節： 請求實體太大    
　　　　        |"414"   ;   10.4.15節；        請求-URI太大    
                |"415"   ;   10.4.16節： 不支持的媒體類型 
                |"416"   ；  10.4.17節：        請求的範圍不滿足 
                |"417"   ;   10.4.18節： 期望失敗         
                |"500"   ;   10.5.1節:   服務器內部錯誤     
                |"501"   ;   10.5.2節:          不能實現           
                |"502"   ;   10.5.3節:   壞網關             
                |"503"   ;   10.5.4節:          服務不能實現       
                |"504"   ;   10.5.5節:   網關超時           
                |"505"   ;   10.5.6節:   HTTP版本不支持
              |擴展碼 

擴展碼 =3DIGIT
註解短語=*

HTTP狀態碼是可擴展的．HTTP應用程序不需要理解所有已註冊狀態碼的含義，儘管那樣的理解顯而易見是很合算的．但是，應用程序必須瞭解由第一位數字指定的狀態碼的類型，任何未被識別的應答應被看作是該類型的Ｘ00狀態，有一個例外就是未被識別的狀態碼不能緩存．例如，如果客戶機收到一個未被識別的狀態碼431，　Copyright  www.cnpaf.net (2007).          All Rights Reserved.
則可以安全的假定請求有錯，且其對待應答的情況是彷彿客戶端收到的是400狀態碼．在這種情況下，用戶代理應當把實體和應答一起提交給用戶，因爲實體很可能包括說明不平常狀態的人認可讀的信息．

６.2應答報頭域

應答頭允許服務器傳送應答的附加信息,這些信息不能放在狀態行裏.這些報頭域給出有關服務器的信息以及請求URI指定的資源的下一步的通路．

　　　應答報頭  =  接收範圍                        ; 14.5節
                   |生存時間         ; 14.6節
                   |Etag            ; 14.19節
                   |位置                 ; 14.30節
                   |代理認證            ; 14.33節
                   |等會再試            ; 14.37節
                   |服務器             ; 14.38節
                   |變化               ; 14.44節
                   |WWW認證                ; 14.47節

隨着協議版本的變化,應答報頭可以可靠的擴展．而且，如果通信的所有組成部分都把它當作應答報頭域,新的或試驗性的應答報頭域可以被給定應答報頭域的含義，未被承認的報頭域被當作實體報頭域．


7。 實體。

在未經特別規定的情況下，請求與應答的報文也可以傳送實體。 實體包括實體報頭域與實體正文，而有些應答只包括實體報頭。在本節內，接收者與發送者既可以指用戶端，也可以指服務器，視由誰收發實體而定。

7。1 實體報文域

實體報文域定義了關於實體正文的維護信息（參數），或在無正文情況下定義了請求的資源。其中一些參數是可選的，一些則是由技術指標規定必須的。

實體報頭 = 允許（Allow）；                        14.7節
                        |內容編碼；                                14.11節
                        |內容語言；                                14.12節
                        |內容長度；                                14.13節
                        |內容位置；                                14.14節
                        |內容-MD5；                                14.15節
                        |內容範圍；                                14.16節
                        |內容類型；                                14.17節
                        |過期(Expires)；                        14.21節
                        |上次修改；                                14.29節
                        |擴展報頭

擴展報頭=報文報頭

擴展報頭機制允許在不改變協議的前提下定義額外的實體報頭域，但不保證這些域在收端能夠被識別。未被識別的域應當被接收者忽略，且必須被透明轉發。


7。2 實體正文。

經由HTTP請求或應答發送的實體正文部分（如果存在的話）的格式與編碼方式應由實體報文域決定。
    
       實體正文= *八位字節

如4。3節所述，實體正文只有當報文正文存在時才存在。實體正文是通過對報文正文按某種保證安全性且便於傳輸的傳輸編碼進行解碼得到的。

7。2。1。 類型。

對於報文中的實體正文而言，其數據類型由報頭中的"內容類型"與"內容編碼"域決定。也即定義了一個雙層有序的編碼模型：

    實體正文=內容編碼（內容類型（數據））

"內容類型"規定了基本數據的媒體類型。
"內容編碼"則可用來指明對數據施加的任何附加的，通常以數據壓縮爲目的的編碼方式，並將其作爲所請求資源的一項屬性。 沒有缺省的編碼方式。

任一包含了實體正文的HTTP/1。1報文都應包括"內容類型"報頭域，以定義正文的媒體類型。當且僅當"內容類型"域未給出媒體類型時，接收者纔可以通過查看資源的內容，擴展名或URL來猜測其媒體類型。若媒體類型仍然未知，接收者應將其作爲"應用/八位字節流"類來處理。

7。2。2 實體長度

報文的實體長度指的是在對報文進行傳輸編碼前報文正文的長度。4。4節定義了確定報文正文傳輸長度的方法。


8。連接

8。1 持續連接。

8。1。1 目的

在持續連接之前，爲獲取每一URL都建立了獨立的TCP 連接， 這就加重了HTTP服務器的負擔，易引起INTERNET阻塞。嵌入式圖片與其它相關數據通常使用戶在短時間內對同一服務器提交多個請求。目前已有針對這些性能問題的分析以及原型實施的結果[26]，[30]。 實施的具體過程和對實際HTTP/1。1（RFC 2068）的測試均顯示了良好的結果[39]。 對其他方法也有了初步探究，如T/TCP [27]。

持續HTTP 連接有着諸多的優點：

--- 通過建立與關閉較少的連接，不僅節省了路由器與主機（客戶機，服務器，代理服務器，網關，隧道或高速緩衝存儲機）的CPU時間，還節省了主機用於TCP協議控制塊的內存。

--- HTTP請求與應答可以進入連接流水線。 流水線方式使得客戶無須挨個等待應答即發起多個請求，從而更充分的利用了單個的TCP連接，減少了崩潰時間。

--- 在減少TCP連接中數據包個數的同時，使TCP有了充裕的時間來確定網絡的擁塞狀況，緩解了網絡擁塞。

--- 因爲無須在創建TCP連接握手上耗費時間，而使連續請求造成的延遲現象得到改善。

--- 由於出錯不會導致TCP連接的關閉，HTTP可以更好的實現自我完善。使用較新版HTTP的用戶會樂於嘗試一些新功能，與舊版服務器通信時，則會在接到出錯報告後用舊模式重試。

HTTP的實現應當採用持續連接。

8。1。2 總體操作

HTTP/1.1 與早期HTTP 版本的一個顯著區別在於持續連接是任何HTTP連接的缺省方式。也就是說，除非另有指定，客戶機總應當假定服務器會保持持續連接，即便在接到服務器的出錯應答時也應如此。

持續連接提供了一種可以由客戶機或服務器發信號終止TCP連接的機制。終止連接的信號利用了"連接"報頭域（14.10節）。一旦出現了終止連接的信號，客戶機便不可再向此連接提出任何新請求。

8。1。2。1 談判

除非請求的連接報頭域中包括了"終止連接"的符號，HTTP/1。1服務器總可以假定HTTP/1。1 客戶機想要維持持續連接。如果服務器想在發出應答後立即終止連接，它應當發送一個含有終止要求的連接報頭域。

無論是客戶機或服務器發起終止連接，這都是本次連接的最後一個請求。

除非經明確指出，客戶機與服務器不應假定低版HTTP會自動採用持續連接方式。請參見19。6。2節關於與HTTP/1。0客戶機後向兼容性的有關內容。

爲了維持持續連接，連接中的報文都必須有如4。4節所述的自定義報文長度（即不是由連接終止定義的長度）。

8。1。2。2 流水線

支持持續連接的客戶機可以以流水線方式發送請求（即無須等待應答而發送多個請求）。服務器則必須將其應答按接到請求的順序發出。

建立連接後立即採用持續連接與流水線方式的客戶機應作好初次流水線嘗試失敗後重試的準備，而不可在持續連接尚未確定時就連續發送請求。客戶機還必須爲服務器在發出所有應答之前就結束連接的情況作好重發請求的準備。

客戶機不應該用非等冪方法或非等冪方法序列（參見9。1。2節）連發請求。否則，過早終止的傳輸層連接會導致不確定的結果。

8。1。3 代理服務器

使代理服務器正確地實現14。10節所規定的連接報頭域的屬性是非常關鍵的。

代理服務器必須獨立於它所連接的客戶機，原服務器（或其它代理服務器）而發出持續連接的信號。每一持續連接僅針對傳輸層鏈接。

代理服務器不可與一臺HTTP/1.0客戶機建立HTTP/1。1持續連接（請參見RFC 2068 [33] 中關於HTTP/1。0客戶機上實現"維持活躍態"報頭問題的探討及資料）

8。1。4 實際的考慮

服務器通常有一個時限值，超過一定時間即不再維繫處於非活躍態的連接。代理服務器會選一個較高的值，因爲客戶機很可能會與同一服務器建立多個連接。持續連接方式的採用對於客戶機與服務器的時限均未提出任何要求。當客戶機或服務器希望超時終止時，它應按規範終止傳輸連接。客戶端與服務器端應始終注意對方是否終止了連接，並適當的予以應答。若客戶機或服務器未能及時檢測到對方已終止了連接，將會造成不必要的網絡資源浪費。

客戶機，服務器，或代理服務器可能在任意時刻終止傳輸連接。比如，客戶機可能正想發出新的請求，而此時服務器卻決定關閉"閒置"的連接。在服務器看來，連接是在閒置狀況下被關閉的， 而客戶機卻以爲請求在進行中。

這表明客戶機，服務器與代理服務器必須有能力從非同步的連接終止事件中恢復。只要請求序列是等冪的（參見9。1。2節），客戶端軟件就應自動重新發起傳輸層連接並重傳被廢棄的請求序列。對非等冪方法或序列不可自動重試，但用戶代理可以向手工操作員提供重發請求的機會。用戶代理軟件對應用程序基於句法理解的確認可以用來代替人工方式。若重試失敗，則不應允許再試。

服務器在每次連接中只要有可能，總應至少應答一個請求。除非出於網絡或客戶端的故障，服務器不應在傳送應答的中途斷開連接。

使用持續連接的客戶機應限制與某一服務器同時連接的個數。單用戶客戶機不應與任一服務器或代理服務器保持兩個以上的連接。代理服務器與其它服務器或代理之間應維護2*N個連接，其中N是同時在線的用戶數。設定這一規則是爲了改進HTTP應答時間且避免擁塞。

8。2 報文傳輸要求、

8。2。1 持續連接與流量控制

HTTP/1。1服務器應當保持持續連接並使用TCP的流量控制機制來解決臨時過載，而不是在終止連接後指望客戶端的重試。後一方法會惡化網絡阻塞。

8。2。2 監視連接中出錯狀態的報文

發送報文正文的HTTP/1。1（或更新）客戶機應在傳輸請求的同時監視連接是否處於出錯狀態。若客戶機發現了錯誤，它應當立即停止正文的傳送。若正文是以塊編碼方式發送的（3。6節），可以用一長度爲零的塊和空報尾來提前標記報文結束。若正文前有"內容長度"報頭，則客戶機必須關閉連接。

8。2。3 100號狀態的用途

100號狀態的目的在於幫助那些發送含有請求正文的請求報文的客戶機在發送請求正文之前推測服務器看到請求報頭後是否願意接收請求。有些時候，如果服務器不看正文就棄置報文的話，客戶機對正文的發送就多此一舉了。

對HTTP/1。1 客戶機的要求：

--- 若客戶機在發送請求正文之前等候100（繼續）應答，則它必須發送填有"100--繼續"期望的"期待請求"報頭域（14。20節）。

--- 若客戶機不需要發送請求正文，則它不得發送填有"100--繼續"期望的"期待請求"報頭域（14。20節）。

由於存在舊的實現方法，協議允許出現諸如客戶機發出了"期望：100-繼續" 卻沒接到417（期望失敗）或100（繼續）狀態的混亂局面存在。 因此，當客戶機將這一報頭域發給它從未接到100（繼續）狀態的原服務器（通常是通過代理）時， 客戶機不應在發送請求正文前無限期地等待。

對HTTP/1。1原服務器的要求：

--- 在接到"期望"請求報頭域填有"100-繼續"期望的請求時，原服務器必須以100（繼續）狀態應答並繼續讀入數據流，或者以終止狀態碼應答。原服務器在發送100（繼續）應答之前不得等待。若以終止狀態碼應答，它既可關閉傳輸層連接，也可繼續讀入數據而丟棄請求的剩餘部分。但此時它不得按客戶機所請求的方式運行。

--- 如請求報文不含填有"100-繼續"的"期望"報頭域， 原服務器不應發送100（繼續）應答。當請求來自HTTP/1。0（或更早）客戶機時也不得發送100（繼續）應答。對此規定有一例外：爲了與RFC 2068兼容，服務器對於未含填有"100-繼續"的"期望"報頭域的PUT或POST 請求可以應答100（繼續）狀態。這一例外的目的在於儘量減少由100（繼續）狀態的未申明等待引起的客戶機處理延遲，僅適用於HTTP/1。1請求，和其它HTTP 版本的請求無關。

--- 若已經接到相應請求的部分或全部請求正文，原服務器可以免發100（繼續）應答。

--- 一旦請求正文被收到處理，發出100（繼續）應答的原服務器除非過早切斷傳輸層連接，否則最終必須發送終止狀態碼。

--- 若原服務器接到不含填有"100-繼續"的"期望"報頭域的請求，該請求含有請求正文，而服務器又在從傳輸層連接讀入正文之前就應答了終止狀態碼，則服務器不應在讀完全部請求或客戶機終止連接前關閉連接。 否則，客戶機可能無法可靠地接收應答報文。然而，這一要求在闡釋中不應阻止服務器防衛拒絕服務的攻擊或有嚴重缺陷的客戶程序。

對代理服務器的要求：

--- 若代理服務器接到包含填有"100-繼續"的"期望"報頭域的請求，且代理服務器要麼知道下一站服務器遵循HTTP/1。1或更高版協議，要麼不知下一站服務器的HTTP版本，則它必須連同"期望"報頭域一起轉發此請求。

--- 若且代理服務器知道下一站服務器版本是HTTP/1。0或更低，則它不得轉發此請求，而應應答以417（期望失效）狀態。

--- 代理服務器應當維護一高速緩存，以記錄新近訪問到的下一站點服務器的HTTP版本號。

--- 若接到的請求來自於版本是HTTP/1。0（或更低）的客戶機，不含填有"100-繼續"的"期望"報頭域的請求，則代理服務器不得轉發100（繼續）應答。 這一要求可覆蓋1xx應答轉發的一般規則（參見10。1節）。

8．2．4 服務器過早關閉連接時客戶機的行爲

如果HTTP/1。1 客戶機發出一條含有請求正文但不含填有"100-繼續"的"期望"報頭域的請求，並且客戶機直接與HTTP/1。1原服務器相連，在從服務器處接到任何狀態信息之前就發現連接被關閉，那麼客戶機應當重試請求。在重試時，客戶機何以採用如下所述的"二進制指數後退算法"以確保獲得可靠應答：

1． 向服務器發起一新連接。
2． 發送請求的報頭。
3． 初始化變量R爲通往服務器的往返時間的估計值（比如基於建立連接的時間），或在無法估計往返時間時設爲一常數值5秒。
4． 計算T=R*（2**N），N爲此前重試請求的次數。
5． 等待服務器發來的出錯應答或是T秒（兩者中時間較短的）。
6． 若沒等到出錯應答，T秒後發送請求正文。
7． 若客戶機發現連接被提前終止，轉到第1步，直到請求被接受，接到出錯應答，或是用戶因不耐煩而終止了重試進程。

在任意環節上，客戶機如果接到出錯狀態，
--- 不應再繼續， 並且
--- 如完成請求報文的發送則應終止連接


９ 方法定義

HTTP/1.1常規方法的定義如下.雖然這個定義可以展開,但附加的方法不能被假定分享和個別擴展的客戶機和服務器同樣的語義.

主機請求應答報頭(14.23節)必須符合所有的HTTP/1.1請求.

9.1 安全和等冪(Idempotent)方法

9.1.1 安全方法

實現程序應當知道軟件通過在Internet上的交互來扮演用戶,且應該仔細的允許用戶知道任何它們可能採取的行動,這些行動可能給他們自己或他人帶來無法預料的結果.

特別的.這樣的慣例已經形成,就是GET和HEAD方法除了補救外不應該有別的採取措施的含義.這些方法應該被看作"安全".這允許用戶代理描繪其他方法,像POST,PUT,DELETE,在某種意義上,用戶知道某種不安全的行爲被請求的事實.

自然, 隨着GET請求的實現,不可能保證服務器不產生副作用;事實上,一些動態的資源考慮到那樣的特徵.在這裏重要的區別是用戶沒有請求副作用,因此不應該爲此承擔責任.

9.1.2 等冪方法

方法也可以等冪的性質,這種情況下(除了出錯或終止問題)N>0個同樣請求的副作用和單個請求一樣.方法GET,HEAD,PUT, DELETE都有這種性質.而且,方法OPTIONS和TRACE不應該有副作用,等冪就是這樣的含義.然而,有可能幾個請求的序列是不等冪的,即使在那樣的序列中所有方法單獨實現都是等冪的(如果整個序列整體的實現結果總是相同的,即不因序列整體,部分的重新實現而變化,則序列是等冪的).例如,如果一個序列實現的結果依賴一個序列中後來可以修改的值,則該序列不是等冪的.

沒有副作用的序列是等冪的(倘若在同樣的資源配置下不同時操作)

9.2  OPTIONS(選項）

OPTIONS方法描述了在請求URI確定的請求/應答過程中通信條件是否可行的信息.該方法允許客戶機確定條件或設備,其與資源或服務器的沒有暗示資源操作或初始化資源重建的情況下的性能有關,

這種方法的應答是不能緩存的.

如果OPTIONS請求包括一個實體(用來指示內容長度或傳輸碼的存在),接着媒體類型應該有一個內容內型域來確定.雖然這種規定對那樣的主體沒有定義任何功能,未來HTTP的擴展可以用OPTIONS域來安排更多細節性的有關服務器的詢問.一臺不支持擴展的服務器可以拋棄請求正文.

如果請求URI是一個星號("*"), OPTIONS請求特意應用於總的服務器而不是特定的服務資源.既然服務器的通信條件取決於資源,"*"請求只是作爲"ping" 或 "no-op類型的方法纔有用;它只能允許客戶機測試服務器的性能.例如,這能被用來檢測一臺代理機即是否支持HTTP/1.1.

如果請求URI不是一個星號("*"), OPTIONS請求只是當和資源通信時應用於條件是否可能.

應答200應當包括表示服務器實現和可應用於資源的可選擇的特徵報頭域,.可能包括這種規範定義未定義的擴展.規範沒有定義正文,但未來HTTP的擴展可能會定義,商議內容可能會用於選擇適當的應答格式.如果沒有應答體被包括進來,應答必須包括一個值爲零的內容長度域.

最大轉發請求報頭域可以用於請求過程中特定的代理機.當代理機收到可以繼續傳播的絕對URI的OPTIONS請求時,代理機必須檢測最大轉發域.如果最大轉發域的值是零,代理機禁止轉發信息.相反的,代理機將回答它自己的通信條件.如果是大於零的整數,當代理機轉發請求時,該域的值將逐漸減小.如果請求中沒有該域,則轉發請求當中也會沒有.


9.3 GET（獲取）

GET方法重建信息的內容(正文的形式)由請求URI來確定.如果請求URI指數據產生的過程,它是在應答中產生,被當作正文返回的數據,而不是過程的源文本,除非文本碰巧是過程的輸出.

如果請求信息包括 If-Modified-Since, If-Unmodified-Since,If-Match, If-None-Match, or If-Range報頭域, GET的語義將變成"條件（conditial） GET". 只有在條件報頭域(conditional header)所描述的環境下, 條件GET方法請求實體被傳輸. "條件GET"方法用於減少不必要的網絡使用,這種使用允許在沒有多種請求或客戶機已經獲傳輸數據的情況下刷新緩存實體.

如果請求信息包括範圍（Range)報頭域, GET方法的語義將變成"部分(partial)GET","部分GET"請求只要求傳輸部分實體,如14.35節指定的那樣. 部分GET方式通過允許當客戶端沒有得到全部的傳輸數據時部分的重建數據來減少不必要的網絡使用.

只有當GET請求碰到13章裏所描述的支持HTTP緩存的設備時,應答纔是可緩存的.

當使用表格形式時.請參看15.1.3節關於安全的考慮.


9.4 HEAD（報頭）

除了應答中禁止返回消息正文外,HEAD方法與GET方法一樣.包含在HTTP報頭以後應答報頭頭請求的信息與POST去應答GET請求的信息是相同的.這種方法能用於獲得關於實體更多的信息,沒有傳輸實體正文本身的請求暗示了這種信息.這個方法常用來檢查超文本鏈接的有效性,可到達性和最近的修正.

當包含在應答中的信息可以用來更新以前緩存的來自資源的實體時,對HEAD請求的應答是可緩存的.如果新域的值顯示緩存的實體不同於當前的實體時(這將在內容長度,內容-MD5,ETAG或最後更新時間中表現出來),緩衝區就拋棄緩存的實體.


9.5 POST（張貼）
在POST 方法適用的請求中,原服務器接收附加在請求後的實體,該實體後作爲請求行裏請求URI指定的資源的次要部分,. POST 被設計爲具有如下的功的統一的方法:

- 已有資源的註解.
- 在電子佈告版,新聞組,郵箱或類似的主題組貼一些信息.
- 提供數據塊,像確認表單數據處理的結果.
- 通過附加的操作擴充數據庫.


POST方法實現的實際功能取決於服務器,且往往取決於請求URI.POST實體屬於URI,就像文檔屬於包括它的目錄,新聞主題屬於它所在的新聞組,或紀錄屬於數據庫.

POST方法實現的操作不會作用於URI可以鑑識別的資源.在這種情況下,無論2000(OK)還是2004(無目錄)是合適的應答狀態,取決於應答是否包括描述結果的實體.

如果原服務器上已經建立了資源,應答將是201(建立)且包括描述請求狀態,指向新的資源的實體和一個本地報頭(看14.30節).

這種方法的應答是不可緩存的,除非應答包括合適的緩衝控制或終止報頭域.然而,303(看別的)應答可直接用於用戶代理重建可緩存資源.

POST 請求必須像8.2節所描述的那樣服從消息傳輸的需要.

參見15.1.3節關於安全性的考慮.

9.6 PUT（放置）

PUT方法要求所附實體存儲在提供的請求URI下.假如請求URI指的是已經存在的資源,所附的實體應當被當作原服務器中已修改的版本. 假如請求URI指的不是已經存在的資源,而URI可以被客戶代理定義成新的資源,原服務器可以建立該URI資源.假設建立了新資源,原服務器必須通過 201(建立)應答通知用戶代理.如果修改了已有資源,將發送200(OK)或204(無內容)應答表示請求的成功完成.如果對於該URI資源不能創建或修正,將給出合理的出錯應答來反映問題所在.實體容器不能忽視任何不被理解或實現的內容-*(例如內容範圍)報頭,這時必須返回501(未實現)應答.

如果請求經過高速緩衝存儲器和請求URI標識一個或多個當前緩存的實體,這些實體將被拋棄.這個方法的應答是不可緩存的.

POST和PUT請求基本的不同點反映在請求URI的不同意義.POST方法中的URI標識將處理附加實體的資源.資源可以是數據接收過程,一個網關和一些協議,或一個接收註解的分散的實體.與之相對照的是, PUT請求中的URI標識請求所附的實體-用戶代理了解什麼URI是有意的和服務器禁止試圖應用請求於別的資源.假如服務器希望請求應用於不同的URI,

它必須是301(永久移動)應答;用戶代理可以自己決定關於是否改變請求路由.

單個的資源可以被許多不同的URI確定.例如,一個主題可以有一個URI識別當前版本,這從URI識別每一個特定的版本分離開來.在這種情況下,PUT請求中一般的URI導致服務器,而其他的URI由原服務器定義.

HTTP/1.1沒有定義PUT方法如何影響原服務器的狀態.

PUT請求必須服從8.2節描述的信息傳輸需要.

除了特定的實體報頭說明,POST方法中的實體頭應該應用於POST方法創建或修改的資源.

9.7 DELETE（刪除）

DELELE方法要求原服務器釋放請求URI指向的資源.這種方法可以通過原服務器上人的強行干涉而制止(括其他手段).客戶機不能擔保操作已經實現了,即使從原服務器返回的狀態碼說明操作已經成功的完成.但如果當時應答未給出的話,服務器不應該表示成功,它打算釋放資源或移到不能訪問的位置.

假如應答包括描述狀態的實體,成功的應答是200(OK),如果操作仍未制定,則應答爲202(接收),如果操作已制定但應答不包括實體,則應答爲204(無內容).

如果請求經過緩存和請求URI識別一個或多個當前緩存的實體,這些實體將被拋棄.這個方法的應答是不可緩存的.

如果請求經過緩存和請求URI識別一個或多個當前緩存的實體,這些實體將被拋棄.這個方法的應答是不可緩存的.

如果請求經過高速緩衝存儲器和請求URI標識一個或多個當前緩存的實體,這些實體將被拋棄.這個方法的應答是不可緩存的.

9.8 TRACE（跟蹤）

TRACE方法用於調用遠程的,應用層循環請求消息.請求最終的接收者應當反射從客戶機作爲200應答的實體正文收到的信息.最終的接收者也是原服務器或在請求中收到最大轉發數量值第一個代理服務器或網關 (看14.31節).TRACE請求不包括實體.

TRACE允許客戶端了解在請求的另一端收到的內容和用數據測試或診斷信息.經由報頭域的值尤其重要,因爲它表示請求過程的路徑.最大轉發數域的使用允許客戶端限制請求鏈的長度,這對在無限循環中找出前向路徑的代理服務器是很有用的.

如果請求有效,在實體正文中應答包括整個請求信息,具有"消息/http"的 內容-形式.這種方法的應答禁止緩存.

9.9 CONNECT（連接）
本說明中保留CONNECT方法用於能動態建立起隧道的代理服務器(例SSL 隧道[44]).

 

10.狀態代碼定義

   每一段狀態代碼在下面被描述,包括他所能遵循的方法的描述和在應答中所必需的維護信息.

10.1 信息 1xx

狀態代碼的類簡單描述了一個臨時的回答,只是由狀態行和可選擇的報頭所組成,並且由空行所決定,狀態代碼類沒有所需的報頭.自從HTTP/1.0沒有定義任何1xx狀態代碼,在實驗的條件下服務器嚴禁發送一個1xx應答給HTTP/1.0客戶.
客戶必須準備在接受通常應答之前接受一個或者多個1xx應答，甚至客戶並不期待一個100狀態的報文。不被期待出現的1xx狀態應答也許會被用戶端的代理所忽略。
   
代理服務器必須轉寄1xx應答，除非代理服務器和客戶之間的聯繫被切斷，或者除非代理服務器本身請求1xx應答的發生。（舉例說明如果一個代理服務器在它轉寄一個請求時會加上一個"期望:100-----繼續區域",它接下來就不需要轉寄100回答應答）.

10．1．1   100 繼續

  客戶應該和他自己的請求繼續。中間的應答被用於告知客戶請求的初始部分已經收到並且還沒有被服務器所拒絕。客戶應該繼續發送剩下的請求，或者如果請求早已完成，那就忽略請求。服務器必須發送一個初始回答應答當請求完成時。如果想知道這部分狀態代碼用法及操作處理的詳細討論，那麼請看8.2.3章節。

10．1．2 101轉換協議

    服務器瞭解並且願意順從客戶的請求，經過升級的報文報頭區域，爲的就是一個應用協議的變化使之能夠在連接中使用。服務器會轉換協議使之成爲那些通過應答升級報頭的區域定義的立即在決定101應答的空行之後的協議。

    協議應該僅僅在這樣做有利的時候實行轉換。比如，轉換成爲一個新版本的HTTP協議與老版本相比更加有利，轉換成爲一個實時同步的協議也許會有利,當被傳送的資源需要利用這樣的特徵

10．2 成功 2xx

這種狀態代碼類簡要的說明了客戶的請求被成功的接收，理解，和接受

10.2.1 200 OK

     請求已經成功。連同應答一起返回的信息是依賴於在請求中使用方法的。例如：

GET                    與被請求的資源相應的實體在應答中一起發送。
HEAD          與被請求資源相對應的沒有報文正文的報頭區域在應答中發送。
POST           描述或者包含行動結果的實體。
TRACE          底端服務器已經接收的包含請求報文的實體

10.2.2  201 創建

請求已經完成同時導致新的資源被創造.新創造的資源和地址報頭區域給出資源的最專業的URI可以被隨應答實體返回的URI參考.應答應該包含用戶或者用戶代理可以從中選擇出的一系列最最合適資源的特徵和地址.實體的格式通過在內容形式報頭區域給出的媒體形式來詳細說明.最初的服務器必須在返回201 狀態代碼以前創造資源.如果行動不能馬上執行,服務器應該以202接受應答來應答它.

一個201應答可以由一個爲了剛剛創造出的請求變量而顯示出來的當前實體標記符的值的Etag應答報頭區域,參見14.19節。.

10.2.3 202 接受.

爲了處理,請求被接受,但是處理並沒有完成.請求最終有可能或者不可能遵照行事,因爲在處理過程實際發生時,它有可能被不允許.沒有什麼設備可以從如此的異步操作中重新發送狀態代碼

202應答是故意無委託的.它的目的就在於爲了其他一些過程,在沒有要求用戶代理直到過程執行結束還堅持連接到服務器的情況下,允許服務器接受請求 (也許是一批有所指向的一天只處理一次).實體和應答返回應該包括當前的請求狀態,和或者一個指向狀態監聽器的指針或者關於什麼時間用戶期待請求完成的估計.

.
10.2.4 203  非權威信息
在實體報頭中返回的維護信息並不是原服務器可用的最終的設置,但是他們是從一個本地的或是第三方的拷貝.提出的設置也許是原始版本的子集或是父集.舉例來說,包括有關於也許導致被原服務器識別的維護信息的父集的本地註解信息.這種應答代碼的用法並不必需,而且只有當應答爲200時才適用.


10.2.5 204 沒有內容

服務器完成請求並不需要返回實體的正文,並且也許想返回升級過的維護信息.應答也許包含新的或者是升級過的的實體報頭形式的維護信息,如果這些當前的可以與請求的變量相關聯.

如果客戶是個用戶代理,她就不應該改變它的文件觀點以區別於那個導致請求被髮送的文件觀點.這樣的應答主要是故意允許爲了行動的輸入發生在沒有導致對用戶代理主動的文件觀點改變的情況下,儘管任何新的或者是升了級的維護信息應該是適應於用戶代理現在的主動觀點的.

204應答嚴禁包含報文正文,並且這樣總是由在報頭區域之後的第一個空行決定的.

10.2.6 205 重置內容
 
服務器已經完成了請求,用戶代理應該重新設置導致請求被髮送的文件觀點.這種應答主要是故意允許輸入行動通過用戶輸入發生,伴隨而來的是對給出形式的清理爲了讓用戶可以輕鬆開始另一個輸入行動.應答嚴禁包含任何實體.

10.2.7 206  局部內容

   服務器對於資源已經完成了部分GET請求.請求必須包含一個範圍報頭區域(14.35節),
   指出了想要的範圍,而且也有可能包含一個使請求條件化如果-範圍報頭區域

   應答必須包含以下的報頭區域:

或者是一個內容範圍報頭區域指出包含此現應答的範圍,或者是對每個部分來說一個多部分的/字節範圍的內容形式都包含內容範圍報頭.如果內容長度報頭區域在當前應答中,那麼它的值必須和實際在報文正文重傳送的OCTET相匹配.

     -日期
     -Etag或者內容位置,如果能夠在一個200應答中對於同一個請求發送報頭.
     -終止,緩存控制,和/或者變化,如果區域值與對於同一個變量以前發送的應答中的區域值不一樣.
 
如果206應答是一個使用強緩存確認的的如果範圍請求的結果,那麼應答不應該包含其他實體報頭. 如果應答是一個使用弱緩存確認的的如果範圍請求的結果,那麼應答嚴禁包含其他實體報頭,這麼做是爲了防止緩存實體正文和升級報頭之間的矛盾性.否則,應答必須包含所有對同一個請求返回的200應答中的實體報頭.

如果Etag或者上次更改的報頭不嚴格匹配,緩存嚴禁將一個206請求與其他以前緩存的內容連接起來

一個並不支持範圍和內容範圍的緩存嚴禁緩存206(部分)應答.

10.3 重新定向 3xx.

這種狀態代碼類指出了爲了完成請求用戶代理而所需要做的更進一步的行動.必需的行動          可以被沒有與用戶發生交互作用的用戶代理執行並且在當且僅當在第二個請求中所需的方法是GET 或者是HEAD.客戶應該偵察最終的重新定向環路,因爲對於每一個重新定向來說這樣的環路產生網絡交通.

註解:老版本的規範推薦最大數量爲5的重新定向.內容開發者應該知道也許有貫徹這樣複雜限制的客戶.

10.3.1 300 多樣選擇.
  
被請求的資源符合任何一套表示法之一,每種資源和她自己的特定地址,並且爲了使用戶可以選擇一個首選的表示法和依照那個地址重新定向, 代理驅動的協商信息可以被提供出來.
除非它是一個HEAD請求,應答都應該有包含一系列用戶或者用戶代理可以從中選擇的最最合適的資源特性和地址.實體格式被在內容形式報頭區域給出的煤體形式詳細說明.依靠用戶代理的格式和容量,最最合適的那個選擇有可能自動完成.不管怎樣,這種規範並沒有定義自動選擇的標準.如果服務器有了一個陳述的首選, 那麼它應該包含爲了關於那個陳述的特定的URI;用戶代理爲了自動重新定向可以使用地址區域值.除非指出另外的那麼應答就可以緩存.

10.3.2 301 永久移動

被請求的資源已經分配了一個新的永久的URI,任何對資源的未來參考應該使用返回的URI中的一個.有編輯連接能力的客戶應該對於被請求的URI從可能的服務器中返回的一個或者多個參考中實現自動連接參考.這種應答是可以緩存的除非它指出其他的.

新的永久的URI應該在應答中的地址區域給出.除非請求方法是HEAD,應答的實體應該包括一個段指向新的URI的超文本文本註解

如果301狀態編碼在對應於HEAD或者GEI方法中收到,用戶代理嚴禁自動的重新定向請求除非它可以被用戶確認,因爲這樣可能會改變請求發生的條件.

註解:當在接受到一個301狀態編碼後自動重新定向某一郵政請求,一些現存的HTTP/1.0用戶代理將錯誤的將它改成GET方法.

10.3.3 302 創立

被請求的資源已經分配了一個新的永久的URI,任何對資源的未來參考應該使用返回的URI中的一個.有編輯連接能力的客戶應該對於被請求的URI從可能的服務器中返回的一個或者多個參考中實現自動連接參考.這種應答是可以緩存的除非它指出其他的.

對臨時的URI應該給予地址區域.除非請求的方法是HEAD,相應的實體應該包含一個短的指向一個新的URI的超級連接的超文本提示

如果302狀態代碼在一個應答非GEI或者HEAD請求中的過程中被接收到,那麼用戶代理嚴禁自動重新定位除非它可以被用戶證實,因爲它可能變化它的請求實現的條件.

註解: RFC 1945 和 RFC 2068 詳細說明了客戶不被允許改變在重新定位請求使用的方法.但是大多數存在的用戶代理將302視爲一個303應答, 不管最初的請求方法而在位置區域值實現一個GET方法.狀態代碼303和307被加在服務器上以希望它能夠清楚客戶所期待的那種反作用.

10.3.4 303 觀察別的部分

對請求的應答可以在不同的URI中找到,並且應答應該在對資源的GET方法中重新得到.這種方法存在主要是爲了允許郵政活性的輸出腳本重新定向用戶代理於一個選擇的資源.新的URI不是一個最初請求資源的替代參考.303應答嚴禁緩存,但是對於第二個請求(重新定向)可以緩存.

不同的URI應該在相應的位置區域給出除非請求的方法是HEAD,相應的實體應該包含一個短的指向一個新的URI的超級連接的超文本提示.

註解: 許多HTTP/1.1以前的用戶不理解303狀態.當客戶之間的協同工作能力被關注時,302狀態代碼也許會作爲替代而使用,因爲大多數用戶代理就向這裏描述的303那樣反作用於302應答.

10.3.5 304 只讀

如果客戶提出一個條件的GET請求並且訪問也已經允許,但是文檔並沒有修改,服務器應該應答這些狀態編碼.304應答嚴禁包含報文正文,並且總是由報頭區域之後的第一個空行決定的.

應答必須包括以下報頭區域:
-日期,除非數據亢長是14.18.1部分必須的.

如果一個無時鐘原服務器遵守這些規則,並且代理服務器和客戶將自己的日期加入任何成標準的應答中去,緩存會工作正常.

-Etag或者內容位置,如果能夠在一個200應答中對於同一個請求發送報頭.

-終止,緩存控制,和/或者變化,如果區域值與對於同一個變量以前發送的應答中的區域     
   值不一樣.

如果條件化的GET使用了強的緩存??(請參閱13.3.3部分內容),那麼應答中就不應該有其他實體報頭.否則,應答中嚴禁包含其他實體報頭,這樣子保護了緩存實體正文和升級報頭之間的矛盾性

如果304應答指出了當前尚未緩存的實體,那麼緩存就必須忽視應答並且無條件的重複請求

如果緩存使用成爲標準的204應答取勝疾緩存的入口,緩存就必須升級自己的入口以反映在應答中給出的任何新的區域值.

10.3.6 305 使用代理服務器

地址區域的被請求的資源必須通過代理服務器.地址區域給除了代理服務器的URI. 期望容納者通過代理服務器重複這一單一請求.305應答必須由原服務器產生.

註解: RFC2068並不清晰於305有意於重新定向一個單一請求,並且此請求還只能由原服務器產生.不留心這些限制會產生相當嚴重的安全後果.

10.3.7 306(沒有用的)

306狀態編碼在以前的規範中使用,現在已經不再用了,代碼也保留了下來.

10.3.8 307臨時重發.

  請求的資源臨時存在在另一個不同的URI下.由於重新定位有時可能變化,客戶應該繼續使用請求URI以備將來用途.這個應答只有當被緩存控制或是終止報頭區域指出時纔是可以存儲的.

臨時的URI應該在應答中的地址區域給出.除非請求的方法是HEAD,應答的實體應該包括一個短的指向一個新的URI的超文本提示, 許多HTTP/1.1以前的用戶不理解307狀態.因此,提示應該包括用戶在新的URI中爲了重複原始請求所必需的信息.

如果307狀態代碼作爲應答不僅僅是GET或者HEAD等方法而接收,那麼用戶嚴禁重新定向請求除非它可以被用戶確認,這也是可能的.


10.4 客戶錯誤 4xx

狀態代碼4xx類是專門使用在客戶看上去錯誤的情形下的.除非當應答一個HEAD請求時,服務器因該有一個包括錯誤情形的解釋的實體,以及它是否一個臨時或者終了的條件.這些狀態編碼可以應用於任何請求方法.用戶代理應該向用戶顯示任何包括的實體.

如果客戶在發送數據,使用TCP的服務器的實現應該小心以保證在服務器關掉了所有的輸入連接時客戶承認收到包含應答的包.在關掉之後如果客戶繼續發送數據給服務器,服務器TCP堆會發送一個重製包,也許這樣子會在服務器開始被訪問以及HTTP應用程序被解釋的情況下,會擦掉客戶不知道的輸入緩衝.

10.4.1 400 壞請求

請求由於畸形的語法而不被服務器所理解.客戶不應該重複自己的請求在沒有改變的情況下.

10.4.2 401 未授權的

請求需要用戶的鑑定.應答必需有用於對被請求資源的挑戰的包含WWW鑑定報頭區域.如有合適的認證報頭區域,客戶可以重複請求.如果請求已經包含了認證的信任書,那麼401應答就指出了認證由於這些信任書而被拒絕.如果401應答包括和上一個應答同樣的挑戰並且用戶代理已經嘗試認證了至少一次,那麼應該給用戶在應答中給出的實體,因爲實體中可能包含相應的診斷信息.HTTP訪問認證在"HTTP Authentication: Basic and Digest Access Authentication" 中有所解釋.

10.4.3 402 必需的支付
 
這種代碼被保存下來以便將來使用.


10.4.4 403 禁用

服務器理解了請求,但是拒絕實現它.認證不會幫助,請求也不應該重複.如果請求的方法不是HEAD並且服務器願意將請求爲什麼沒有實現告訴大家,它應該在實體中描述拒絕的理由.如果服務器並不想將這條信息告訴客戶,狀態代碼404(沒找到)可以替代使用之.


10.4.5 404 沒有找到

服務器並沒有找到任何可以匹配請求URI.條件是永久的還是暫時的也沒有任何的跡象.410狀態編碼應該在服務器知道老的資源是永遠不可以得到的並且沒有以前的地址的情況下,通過一些內在的可配置的機構,才應該使用.這種狀態編碼當服務器不想精確展示爲什麼請求被拒絕或者何時沒有其他的應答可以利用的時候被廣泛的應用.

 

10.4.6 405 不被允許的方法

在請求行中特殊指定的方法不允許訪問由請求URI指定的資源.應答必需有一個包括一些對於被請求的資源有效的方法的允許報頭.


10.4.7 406 不接受

請求指定的資源只可能產生依照在發送請求中的接受報頭有不接受的內容特性的應答實體.

除非它是一個HEAD請求,應答應該有包括一系列可茲利用的實體特性和位置,從中用戶和用戶代理可以找出最最適合的.實體的格式由在內同形式報頭區域給出的媒體形式所指定.依靠此格式和用戶代理的性能,最佳的選擇可能自動的完成.然而,這中規範並沒有定義任何針對此自動選擇的標準

註解: HTTP/1.1服務器允許返回依照在請求中發送的接受報頭不被接受的應答.在某些情況下,發送一個406應答甚至更加有利.用戶代理被鼓勵去檢查輸入應答的報頭以判斷是否可以接受.

如果應答不被接受,那麼用戶代理應該暫時停止接收更多數據並且向用戶查詢是否需要更進一步的行動決定.


10.4.8 407 代理服務器認證所必需

這種代碼很相近於401,但是它指出了客戶必須和代理服務器之間認證自己.代理服務器必需返回一個代理服務器----認證報頭區域,該區域包括是爲了被請求的資源而用於代理服務器的挑戰.客戶可能隨着一個合適的代理服務器認證報頭區域一起重複它的請求.  HTTP訪問認證在" HTTP Authentication: Basic and Digest Access Authentication"中有解釋.


10.4.9 408 請求超時

在服務器準備等待的時間段內,客戶並沒有產生請求.客戶也許會在以後的任意一時間內重複請求.

10.4.10 409 衝突

由於與資源的現在狀態的衝突請求遊客能不能完成.代碼只有在用戶被期待有可能解決衝突和提交請求的地方的情況下允許使用.應答體應該包括對於用戶認識衝突來源的足夠多的信息.理想的,應答體應該有對於用戶和用戶代理可以解決問題的足夠多的信息量.然而,這也許是不可能的或者是不必需的.

衝突通常會發生在應答PUT請求的時候.例如,版本正在被使用而且正在PUT的實體有和以前請求(第三方)衝突的資源的變更的話,服務器會使用409應答來指出它不能完成請求.在這種情形下,應答實體可能會包括一系列在內容形式應答中定義的兩種版本的區別之處.
10.4.11 410 停止
服務器上的被請求的資源不再可用,而且不知道以前的地址.我們期望此條件被認爲是永遠的.有連接編輯能力的客戶在用戶同意的情況下,應該刪掉對請求URI的參考.如果服務器並不知道,或者沒有設備去決定是否條件是永久的,狀態代碼404(未找到)此時應該使用.這種應答是不可被緩存的除非另外指出.

410應答主要是通過通告請求者資源有意不可獲得和服務器主人希望那些遠方連接到資源的連接都被請除掉這兩條信息用於援助WEB維護.這樣的事情很普通發生在時間受限,增加的服務和不再服務器端工作的的屬於私人性質的資源這些情況下.我們並不需要標註所有的永久不可用的資源"沒了"或是標註上任意一段長度的時間-----這些交給那些服務器的主人自己去判斷吧.


10.4.12 411 必需的長度

服務器拒絕接受沒有定義的內容長度的請求. 如果加上了一個有效的"包含有請求報文正文中的長度"的內容長度報頭區域,那麼客戶可能重複請求.


10.4.13 412 預處理失敗

在一個或者多個請求中給出的預處理在被服務器驗證的時候會被評價爲錯誤的.這種應答代碼允許客戶將預處理放在當前資源維護信息(報頭區域數據),並且這樣作以防止有其他的適應資源請求的法的而非所要的那一個.


10.4.14 413 請求實體太大

服務器拒絕處理一個請求因爲請求比服務器所能和所願處理的還要大.服務器可能關掉連接以防止客戶繼續請求.

如果條件是暫時的,服務器應該有一個重新試-在之後報頭區域以便於指出這是暫時的在什麼時間以後客戶可以再試一次.
10.4.15 414 請求的URI過長

服務器拒絕請求的服務因爲請求的URI比服務器所願意解釋的要長.這種比較珍稀的條件之可能發生在黨課互補恰當的將POST請求變爲有長查詢信息的 GET請求的情況下,或是客戶落到了一個重新定向的URI黑洞中時,再或者是在一些使用固定長度緩衝區用以讀或者處理請求的URI的服務器遭到鑽安全漏洞的黑客的攻擊的時候.


10.4.16 415 不被支持的媒體類型

服務器拒絕提供服務給請求因爲請求的實體所請求的方法是在一種不被請求資源支持的格式下.

10.4.17 416 請求範圍不滿足

如果請求包括範圍請求報頭區域,或者是在區域內沒有範圍說明符的值溢出當前選擇資源的延伸,再或者是請求沒有包含如果--範圍請求--報頭區域,服務器應該返回連同狀態代碼的一個應答.(對於字節-範圍,它意味着所有的字節範圍說明中的第一字節???的值比當前選擇資源的長度要大)

當狀態代碼返回一個字節範圍請求時,應答應該包含一個詳細說明選擇資源的長度的內容範圍區域.(請參閱14.16).應答嚴禁使用多部分/字節範圍的內容形式.

10.4.18 417 期望失敗

在請求報頭區域給出的預料不可能被服務器實現,或者,如果服務器是代理服務器,服務器有請求不可能被下一個??服務器實現的模糊的證據


10.5 服務器錯誤 5xx

應答狀態代碼用阿拉伯數字"5"表示服務器知道它自己有錯誤或者自己不能實現請求等這些情況.除了當應答一個HEAD請求,服務器應該有一個包括錯誤形式的解釋的實體和它是否暫時或者永久的條件的解釋的實體.用戶代理應該顯示任何包括的實體給用戶.這些應答代碼對於任何請求的方法都是適用的.


10.5.1 500 服務器內部錯誤

服務器遇到預料到的防止它完成請求的情況.


10.5.2 501 不能實現

服務器不支持完成請求所必需的功能性. 當服務器並不認識請求的方法並且沒有能力對於任何資源支持時,這是合適的應答


10.5.3 502 壞網關

服務器,當被用作一個網關或者是代理服務器時,就會從上流的服務器收到無效的應答以試圖完成請求的訪問.


10.5.4 503 難以獲得的服務.

由於暫時的過載或者服務器維護,服務器此時不能處置請求.這說明了這是一個暫時的條件過一些耽擱會減輕.如果知道,耽擱的長度應會在重新試-在之後報頭中指出.如果沒有重新試-在之後給出,客戶應該處理處置應答就像處理一個500應答一樣。

註解：503狀態代碼的存在並不暗示着服務器必需使用它當它變得過載時。有些服務器只想簡單的拒絕連接。

10.5.5 504 網關超時

服務器,當被用作是網關或者是代理服務器時, 由於URI指定的上游服務器或者其他一些輔助服務器以有資格嘗試完成請求,並沒有收到及時的應答.

註解:設備註解:一些展開的代理服務器都知道返回400或者500當DNS查找時間過長時.

10.5.6 505 HTTP版本不支持

服務器並不支持,或者拒絕支持,在請求信息中用到了HTTP協議版本.服務器指出它不能或是不願完成使用與客戶端一樣的版本的請求,就像在章節3.1中描述的那樣,???????.應答應該包含描述爲什麼那個版本不爲支持而爲什麼其他協議被服務器支持的實體..


11.入口驗證

HTTP提供了一些可以選擇的用於服務器挑戰用戶請求和用戶提供驗證信息的的挑戰-應答驗證機制.入口驗證的大體框架,和基礎及分類驗證的規範在" HTTP 規範:"基礎及分類入口驗證"中詳細說明.這份說明從規範中採用了"挑戰"和"外交國書"的定義


12.內容談判

大多數HTTP應答都有一個包括人類用戶解釋信息的實體.自然地,相對於請求它需要提供給用戶"最佳利用"的實體.很不幸的是,對於服務器和存儲器來說,不是所有的用戶都有同樣的關於"什麼是最好的"的判斷準則,並且並不是所有的用戶代理有相同的解釋實體形式的能力.爲此,HTTP爲了"內容談判" 提供了一些機制-----當有很多種可能的表示時如何選擇對於一個請求的最佳的表示.

註解: 這不是所謂的"格式談判,因爲變化的表現也許是相同的媒體形式,但是使用那種型號的不同性能的,還也許是使用了不同的語言.
任何包含一個實體正文的的應答都有可能受配於談判,甚至包括那些錯誤的應答.

在HTTP中有兩種可能的內容談判:服務器驅動的和代理驅動的談判.這兩種談判是相互正交的,這樣他們可以單獨或者混合使用.混合使用的一種被稱爲透明的談判的方法,發生在當緩存使用由最初的爲了後來的請求而提供服務器驅動談判的服務器提供的代理驅動談判信息時.

12.1 服務器驅動談判

如果對於一個請求的最佳表示的選擇由服務器提供的運算法則來完成,我們就叫它是服務器驅動談判.選擇是基於應答中可行的解釋和在請求報文的特定報頭區域的內容或是其他一些適合請求的信息(如客戶的網絡地址).

服務器驅動在從所有可行的表示法中挑選最佳的運算法則對於客戶很難描述時是有利的,或者是當服務器要求將它的"最佳估計"和第一應答一起送給客戶端時有利.爲了提高服務器的估計能力,用戶代理可以包含爲了這樣一個應答描述自己參數選擇的請求報頭區域.


服務器驅動談判有這些缺點:

1. 對於任何用戶來說決定什麼是最佳的實際上是不可能的,因爲那樣需要有關於用戶代理能力和應答所想要發揮的用途的所有完整的信息.
2. 讓用戶代理在每一個請求中描述自己的能力也是很低效的並且對於用戶的隱私也是潛在的威脅.
3. 它複雜了原服務器的實現和相對於請求的運算法則.
4.它可能會限制一個公共緩存的能力,因爲緩存對於不同的請求將使用同樣的應答.

HTTP/1.1 包含以下通過描述用戶代理的性能和用戶的參數選擇使服務器驅動談判成爲可能的請求報頭區域: 接受(章節14.1),???(章節14.2),接受編碼(14.3),接受語言(14.4),以及用戶代理(14.43).然而,原服務器並不受限於這些尺寸,並且可能會基於請求的各各方面而變化不同的應答,包括在請求報頭區域之外的信息或者在此規範中沒有定義的擴展報頭區域.

不同的報頭區域可以用作表達
服務器用作選擇服從服務器驅動談判的表示法的變量.請查閱章節13.6關於緩存中不同報頭區域的用法和章節14.44關於服務器不同報頭區域的用法.

12.2 代理驅動談判
在代理驅動談判中,對於一個應答的最佳表示法的選擇是在代理從原服務器端收到最初的應答後實現的.選擇是基於一系列可用的應答的通過自己URI鑑定的表示法,其中包括初應答的報頭區域和實體正文.從表示法中的選擇可以自動實現(如果用戶有能力這麼做)或者人工的用戶從產生的菜單(可能是超文本)中選擇.

代理驅動的談判,當應答有可能不同於普通使用的尺寸時或者是原服務器不能夠從檢查請求中決定用戶代理的性能時,並且一般說來當公共的緩存被用作分散服務器負載和減少網絡用法.

代理驅動的談判也有需要二次請求以獲得最佳替換表示法這樣一個缺點.只有當緩存在使用時二次應答纔有效.作爲補充,規範中並沒有定義支持自動選擇的任何機制,雖然它也沒有阻止任何機制被髮展如像在HTTP/1.1中的擴展那樣.

在當服務器不願或是不能提供不同的使用服務器驅動談判的應答時,HTTP/1.1定義了300(多種選擇)和406(不接受)這兩種狀態編碼以使代理驅動談判成爲可能.

12.3 透明的判斷

透明的判斷是服務器驅動和代理驅動談判的結合體.當緩存被供給了一系列可茲利用的應答的表示法並且變量的尺寸被緩存充分理解時,緩存可以執行代表爲了資源的後來請求的原服務器服務器驅動的判斷.

透明的談判有分散這樣的優點, 否則是原服務器必需的談判工作,以及當緩存可以正確估計應答時可去除用戶代理二次請求的沿時.

此規範沒有定義任何關於透明判斷的機制,雖然它也沒有像在HTTP/1.1中使用的擴展那樣阻止發展機制.
13 HTTP中的緩存
    HTTP典型應用於能通過採用緩存技術而提高性能的分佈式信息系統。HTTP/1.1協議包括的許多元素都儘可能的進行緩存操作。因爲這些元素與協議的其他方面有着千絲萬縷的聯繫，而且他們相互作用、影響。因此，獨立於算法、報頭、響應代碼等的細節描述來講述HTTP中緩存的基本設計是大有裨益的。
    如果不對緩存技術做明顯改善，他將一無用處。HTTP/1.1中緩存的目的是降低在衆多情況下發送請求的需要，同時降低在其他情況下發送完整響應的需要。前者使衆多操作中往返流程減少，我們用"過期" 機制來達到這一目的（見13.2節）；後者使網絡帶寬需求降低，我們用"認證"機制來達到這一目的（見13.3節）。

 
    對性能,可用性和分離操作的需要要求我們能放寬語義透明度的要求.HTTP1.1協議允許源服務器,緩存和代理客戶在必要時明確降低透明度.然而,因爲不透明操作會迷惑不專業的用戶,而且可能同某些服務器應用不兼容(如).在下列情況下,協議需要透明度被降低:
    僅當代理或源服務器提出明確的協議層次的放寬請求.
    僅當緩存或代理向終端用戶提出明確的放寬警告.

因此,HTTP1.1協議滿足如下要素:
      1.當各部分都提出要求時,協議提供完全的語義透明度.
      2.協議允許源服務器或用戶代理明確請求且控制不透明操作.
      3.協議允許緩存對未達到要求的語義透明度的響應發出警告.      
說明:服務器,緩存,或代理設備可能面臨的設計決策不在本說明書討論範圍之內.如果有關於語義透明度的決策,此設備應盡力保持語義透明度除非有仔細而完整的分析表明破壞透明度將有重大好處.

13.1.1緩存 正確性
   在如下列情況下,一個正確的緩存必須從他所存儲的內容中選出最新者來響應請求. (參見13.2.5,13.2.6,13.12節)
   
1. 經過檢驗,源服務器對收到響應重新確認生效返回的結果與原來相同.（參見13.3節）

2．."足夠保鮮"(參見13.2節).在缺省值情況下,它表示對代理,源服務器和緩存
的最低的保鮮性要求(參見14.9節);如果源服務器詳細說明,那麼保鮮性要求僅是對源服務器本身而言有效.如果某一存儲的響應對代理和源服務器的最低保鮮要求仍不滿足,慎重考慮,緩存應返回響應並加入適當警告報頭(參見13.1.5,14.46節),除非這種響應是被禁止的(參見14.9節).

3.  304(未修改),305(代理人重寄),或 錯誤(4xx,5xx)響應信息.

 
        如果緩存無法與源服務器通信,則當響應能正確的從緩存發出時,緩存應
如上響應;如果不能,則緩存應發出錯誤或警告信息以說明存在通信故障.
        如果緩存收到響應(不論是一個完整響應還是一個304響應),它會將其轉寄
給請求客戶,當收到的響應被刷新時,緩存應該轉寄給請求客戶而不須加入新的警告
信息(且無需去掉已經存在的警告報頭).緩存不能僅僅因爲某一響應在傳送過程中
"過時"了而令響應重新生效,這將引入一個死循環.一個用戶代理收到沒有警告的過
時響應應對用戶顯示警告.  


13.1.2 警告信息
        當緩存器返回響應既不是第一手的也不是最保鮮(fresh)的,此響應必須附加警告,
使用一般警告報頭.此警告報頭信息和剛剛定義的警告在14.46中有詳述,此警告允許
客戶採取適當行動.
        警告信息可以被用作他途,不論是否與緩存有關.警告的使用,而非錯誤狀
態代碼區分了前述響應和實際錯誤.
        警告信息由三類阿拉伯數字代碼表示.第一個數字表明當重發成功後警告信
息是否必須或必須不被刪除.

   See section 14.46 for the definitions of the codes themselves.
1xx 這是描述響應刷新或重發狀態的警告信息,因此在重發成後功必須被刪除掉
    1xx警告信息僅當確認一個緩存實體時才由緩存器產生.它不能由代理端產生.
2xx 一個描述實體內容或報頭的警告信息,它不因重新確認而被矯正,而且在成功的
     重新確認後也不能被刪除.

代碼定義見14.46

        HTTP1.0 緩存器存儲響應中的所有警告信息,且不會刪除第一類警告.
傳給HTTP1.0的警告信息帶有一個附加的警告數據區,它阻礙了未來的HTTP1.1兼
容錯誤緩存警告.
        警告信息也傳送一個警告文本.此文本可以使用任何自然語言,而且可以
隨意選擇準用的字符.

        響應可以附加多重警告,包括屬於同一類代號的警告.例如,服務器可能
提供同樣的錯誤而文本包括英語和巴斯克語兩種.
        當響應附加了多重警告信息時,把所有的信息都顯示給用戶是不合理的
也是不現實的.此版本的HTTP並未指定嚴格規定警告顯示的優先權和順序,但卻
給出了一些提示.

13.1.3 緩存控制機制
在HTTP1.1協議中的基本緩存機制是隱含指示給緩存器.在某些情況下,
一服務器或代理可能需要給緩存器以明確的指示,我們用緩存器控制報頭來達到
這一目的.
          緩存器控制報頭允許代理或服務器傳送多種指示,既可以是請求,也可
以是響應.這些指示代替缺省的緩存算法.作爲一般規律,當出現明顯的報頭內
容衝突時,最根本的協調辦法是實用性原則(即爲,選擇能最好保持予以透明度
的報頭),可是,在某些情況下,緩存控制指示明顯的削弱了語義透明度.

        緩存器控制指示詳述於14.9節

13.1.4直接的用戶代理警告
        很多用戶代理允許用戶覆蓋基本緩存機制.例如，用戶代理可能允許用戶
指定緩存實體是無效的。或者，用戶代理還可能習慣於加上緩存控制：對任何請
求最大值=3600。用戶代理不應該默許非透明的行爲或造成明顯低效率的行爲，但
可以由用戶的明確行動來外在配置。
        如果用戶已經覆蓋了基本緩存機制，用戶代理應向用戶明確指出，一旦
此改變作用於信息顯示，可能與透明度要求發生衝突。協議通常允許用戶代理來
決定響應是否已經失效，當實際發生時，該指示需要單獨顯示。該指示不必是對
話框，它可以是一個圖標。
        如果用戶對緩存機制的覆蓋使緩存器效率反常降低，用戶代理應連續的
將這一狀態提示給用戶以防止用戶無意中佔用了額外資源或面臨過長的延遲。

13.1.5 規則和警告的例外情況
           在某些情況下，緩存操作員會選擇設置緩存當用戶未提出請求時發出過時
的響應。這一決定不應草率作出，但有時爲了提高性能，尤其當緩存與源服務器
不良連接時，又是必須的。一旦緩存器返回一個失效的響應，這一定標明（使用
警告報頭）令代理端軟件生效來警告用戶，可能存在潛在的問題。

        協議還允許用戶代理採取措施來獲得第一手的或最新的響應。因此，
如果用戶代理明確請求第一手的或最新的，緩存器不能返回過時響應，除非由於
技術上或政策上的原因而無法實現。
13.1.6 由客戶控制的行爲
           當源服務器是滿期信息的最初來源，在某些情況下，客戶將需要控制
緩存器決定是否回覆緩存的響應而不使其生效。客戶需要使用緩存器控制報頭的
幾項指示來作此工作。
 
        一個客戶的請求可以指定它能接受的未確認響應的最長時限；指定一個
零點控制確認所有響應。一客戶還可以指定響應期滿前的最小時限。所有這些操
作增強了對緩存行爲的控制，所以將不能放寬緩存器的語義透明度。
 
        一客戶也可以指定它接受失效響應，直到達到最大值。這放鬆了對緩存
器的控制，也就可能與源服務器對語義透明度的限制發生衝突。但對不良連接
時支持分離操作和提高性能來說又是必須的。


13.2          過期(Expiration)模型
13.2.1         服務器指定模型
           當緩存器能完全避免向源服務器發送請求時，它工作於最佳狀態。
避免請求的根本機制是源服務器給出一個明確的未來過期時間，這樣響應信
息或許可以滿足後來的請求。換句話說，緩存器不必首先聯繫服務器就能回覆
一個最新響應。
 
        我們期望服務器能指定一個對響應的明確預期過期時間，以確保在到達期
限之前，實體沒有發生變化。當過期時間仔細選擇時，這通常可以保持語義透明度。
   此過期機制僅應用於緩存器作出的響應，而不針對直接傳遞給請求客戶的
第一手響應。
 
        如果一源服務器要強制一個語義透明的緩存器來確認每一個請求，它可
以指定一個明確的已過去過期時間。這表明響應總是失時效的，因此緩存器應在用
其答覆後來的請求之前確認之。（見14.9.4）      

 
        如果源服務器想強制HTTP1.1緩存器無論如何配置都確認每條請求,則應
該使用"必須再確認"緩存器控制指示.(見14.9)

        服務器指定明確的過期時間既可以使用過期報頭,也可以使用最大期限(Max_age)
報頭.
        過期時間不能用來強制用戶代理刷新其顯示或重載其資源；它只應用於緩
存機制，當一個對某資源的新請求發出時，此機制僅須檢測該資源的過期狀態。
（見13.13）

13.2.2         啓發式過期
        由於源服務器並不總是提供明確的過期時間,HTTP緩存器典型設置爲啓發
式過期時間,採取使用其他報頭值的算法來估計一個近似的過期時間。HTTP1.1說明
書中並未給出詳細算法，但卻利用最壞情況來限制其結果。由於啓發式過期次數可
能影響語義透明度，故應慎重使用，而且我們鼓勵源服務器提供儘可能大的過期
次數。

13.2.3 年齡(Age)計算
           爲了解緩存實體是否爲最新，緩存器需要知道其年齡是否已超過保鮮時
限。我們在13.2.4節中討論如何計算後者，本節討論如何計算響應或緩存實體的
年齡。
        在此討論中我們用“NOW”來表示“主機進行計算時時鐘的當前值”。
使用HTTP協議的主機，除了運行源服務器和緩存器的主機，應當使用NTP[28]
或其他類似協議來將其時鐘同步到一個全球性的精確時間標準上來。

        HTTP1.1協議要求源服務器儘可能在發送每條響應時都附加一個日期
報頭來標明此響應產生的時間.(見14.18)我們用"日期值"這一短語來表示日期報
頭的值----一種適於算術操作的形式.

        當從緩存獲得響應消息時,HTTP1.1用年齡響應報頭來傳達其年齡信息.
年齡值是緩存器估計的源服務器生成或重新確認響應的時間值.
        本質上,年齡值是響應信息在從源服務器開始的所有緩存器駐留的時間
加上其在網絡路徑上傳輸的時間.
        我們用年齡值（"age_value"）來標明年齡報頭的值----一種適於算術操作的表示方法.
        一個人的年齡可以通過兩種完全獨立的途徑來計算:
        1.如果本地時鐘與源服務器時鐘同步的相當好,則用"NOW"-日期值,若結果
爲負,則取零.
        2.如果從源服務器開始的所有緩存器均執行HTTP1.1則就取年齡值（age_value）.

        如上我們有兩種方法計算響應的年齡,我們合併二者如下:
矯正後接收到的年齡值=MAX(NOW-DATA_VALUE,AGE_VALUE)
        而且無論那種方法都能得到可靠的結果.

        由於網絡附加延時,一些重要時隙會在服務器產生響應和下一個緩存器或客
戶收到它之間被忽略.如果不經修訂,這一延遲會帶來不正常的低年齡.      

      corrected_initial_age = corrected_received_age
                            + (now - request_time)

        因爲導致返回年齡值的請求一定在年齡值的產生之前就發出了，我們可以
通過記錄請求發出的時間來矯正網絡附加延時。則當收到一個年齡值時，它必將被
認爲與發出請求的時間有關，而不是收到響應的時間。這將保證不論經歷多少延時，
其表現都是穩定的。
當緩存收到響應時的算法摘要：
      /*
       * age_value
       *      is the value of Age: header received by the cache with
       *              this response.
       * date_value
       *      is the value of the origin server's Date: header
       * request_time
       *      is the (local) time when the cache made the request
       *              that resulted in this cached response
       * response_time
       *      is the (local) time when the cache received the
       *              response
       * now
       *      is the current (local) time
       */

      apparent_age = max(0, response_time - date_value);
      corrected_received_age = max(apparent_age, age_value);
      response_delay = response_time - request_time;
      corrected_initial_age = corrected_received_age + response_delay;
      resident_time = now - response_time;
      current_age   = corrected_initial_age + resident_time;
        以上段落英文更明白一些。

        緩存實體的當前年齡是從緩存實體最後被服務器確認的時間（以秒記）
加上校正初始年齡。當緩存實體產生一條響應，它必須包含一個年齡報頭區：與緩
存實體當前年齡一樣的值。

        響應中存在年齡報頭區意味着這不是第一手響應。但反之未必，因爲那僅
當所有緩存器均使用HTTP1.1時才成立。
13.2.4         過期計算：
           爲了確定一條響應是新是舊，我們需要將其保鮮期限和年齡進行比較，年齡的計算見13。2。3節，本節講解怎樣計算保鮮期限，以及一條響應是否已經被排出。在下面的討論中，數值可以用任何適於算術操作的形式表示。
        我們用“過期數值”（"expires_value"）來標明過期報頭，我們用“最大年齡值”來標明緩存控制報頭的秒數。（question?）
 
最大年齡在過期之前指示，所以一旦響應中出現最大年齡，計算將變得非常簡單。

      freshness_lifetime = max_age_value

  否則，若緩存中出現“Expires”，計算如下：
      freshness_lifetime = expires_value - date_value

        注意上述運算不受時鐘誤差影響，因爲所有信息均來自源服務器。
   如果 Expires, 緩存控制: max-age, 或 緩存控制: s-maxage (見 14.9.3) 均未在響應中出現,且響應對緩存沒有其他限制，緩存可以用啓發式算法計算freshness lifetime。緩存器必須對年齡大於24小時又不帶警告的響應附加113號警告。

而且，如果響應有最後修改時間，啓發式過期值應不大於時間片。典型設置爲片斷的10%
   計算響應是否過期非常簡單：

      response_is_fresh = (freshness_lifetime > current_age)

13.2.5 澄清過期值
        由於過期值不是嚴格制定的，所以可能兩個緩存器對相同資源制定的刷新值不同。
 
        如果客戶對一個在其緩存中以刷新的請求作出一個恢復的非第一手響應，而且緩存實體中的日期值比響應中的新。，則客戶可以忽略此響應。如果這樣，將要求“緩存控制”：max-age=0 來強迫檢查源服務器。
           如果緩存器有兩個描述相同而確認器不同的響應，它必須使用有最近日期報頭的那個。
13.2.6 澄清多重響應
        因爲客戶可能收到經多重路徑來的響應，所以有些響應流經一簇緩存器，而另一些響應流經另一簇緩存器，客戶收到響應的順序可能與源服務器發響應的順序不同，我們希望客戶能選用最新的響應。
        實體標籤和過期值都不能影響響應順序，晚一點的響應可能帶有早的過期時間。日期值的精度也只有一秒。
        當緩存器要重新確認一個緩存實體，而且受到響應的日期報頭晚於已存在的實體，則客戶應無條件的重複請求。

       Cache-Control: max-age=0

強制任何中間緩存器確認它們的副本。

       Cache-Control: no-cache

或者強制它們從源服務器獲取一個新的副本。
如果日期值相同，可以使用任何一個響應。

13.3        確認模式
           當緩存器想要用一個失時效的條目來相應客戶的請求,他首先必須向源
服務器(如果可能則向一中間緩存器)檢驗這一緩存條目是否仍然可用.我們稱之爲
"確認"緩存條目.由於我們不想當緩存條目爲可用時必須爲再傳送整條響應而付出
代價,而且不想當緩存條目不可用時也必須多傳一圈,HTTP1.1協議支持使用條件反應方法.

          協議支持條件響應方法的關鍵特徵圍繞"緩存確認器"展開.當源服務器
生成一個完整響應時,它同時傳送一類確認器一直伴隨着緩存條目.當一客戶(用戶
代理或代理緩存器)對含有緩存條目的資源做出條件請求時,他同時在請求中包含有相互關聯的確認器.

          服務器則覈對此確認器和當前確認器,如果他們匹配(見13.3.3),則返回
一個特定狀態碼(通常爲304)且不含條目內容.否則,返回整個響應(包含條目內容)
這樣,我們避免了在確認器匹配時傳送整條響應,同時也避免了在不匹配時往返傳輸.

        在HTTP1.1協議中,一個條件請求除了帶有特別的報頭(包含確認器)來暗中
的將它轉入條件算法以外,和普通報頭沒有差別.

        協議中包括緩存確認機制的主動和被動兩種狀態.具體說來,請求可以在
當且僅當又匹配確認時執行,也可以在當且僅當沒有匹配確認時執行.

        說明:沒有確認器的響應也可以緩衝存儲且接受服務直至被排出,除非這是
被緩存控制指令明確禁止的.可是,如果沒有確認器,則緩存不能有條件的恢復它,這表明無法刷新除非被排出.
      
13.3.1 最後修改日期        (Last-Modified Dates)
        最後修改報頭值經常被用作確認器.簡言之,一緩存條目在最後修改期後
未經修改則被認爲是有效的.
13.3.2         標籤緩存確認器(Entity Tag Cache Validators)
           標籤響應報頭值,一個實體標籤,提供了一個"模糊"緩存確認器.這將允許
在不便存儲修改信息的情況下進行可靠的確認,包括HTTP日期數據不充足和源服
務器不想因使用修改日期而帶來麻煩的情況.
          實體標籤描述見3.11節,有關其報頭的描述見14.19,14.24,14.26,14.44.
13.3.3         強,弱確認器
        由於源服務器和緩存器會比較兩個確認器來確定他們是否代表相同的條目,所以通常希望實體發生任何變化,確認器也相應變化,這樣的確認器爲強確認器.
        同時還會有這樣的情況,服務器傾向於僅在發生重要的語義變化時才改變確認器.在資源變化時確認器未必變化的稱爲弱確認器.
實體標籤通常是強確認,但協議提供一種機制來標誌弱　Copyright  www.cnpaf.net (2007).          All Rights Reserved.
確認.可以認爲,強確認在實體的每一字節變化時均變化,而弱確認僅在實體含義變化時才變化,強確認是某一特定實體的標誌,而弱確認是某一類同義實體的標誌.
注: 強確認的例子:一個整數,他隨着每次實體發生變化而定值增長.
        一個實體的修改時間(以秒計算)可以作爲弱確認器,因爲實體可能在一秒內變化兩次.
        對弱確認的支持是可選的.支持弱確認可帶來等價體的高效緩存.
        當客戶生成一個在確認報頭中包含確認器的請求或服務器進行比較時均要用到確認器.
        強確認可在任何情況下使用,而弱確認僅在不依賴嚴格相等時纔可用.
        客戶可以發出簡單GET請求,伴隨強,弱確認器均可.客戶在發其他請求時,不能用弱確認.
HTTP1.1協議定義確認的唯一功能是比較.有兩種比較功能,這依賴於是否允許弱確認.
        -- 爲了同等考慮,兩確認器必須完全一樣且均非弱確認.
        -- 兩確認器必須完全相同,且至少有一個被標明爲"弱".

        除非被明確標清,實體標籤是強的.
        最後修改時間被用作請求的確認器時默認爲弱的,除非從下列規則導出強的結論.
        確認器不會在一秒內變化兩次.
或者
    
      -確認器可能被用戶用於If-Modified-Since 或者 If-Unmodified-Since報頭。
      -此緩存實體包含一日期值，他給出源服務器發出響應的時間。
      -最後修改時間至少比日期值早六十秒。
或者
      -確認器已經被中間緩存器同緩存實體比較過
      -此緩存實體包含日期值，給出源服務器發出響應的時間。
      -最後修改時間至少比日期值早六十秒。

        此種方法基於以下事實:如果兩條響應在同一秒內被髮出但有相同的最後修改時間,則至少有一條響應日期值和最後修改時間是相同的.
        如果客戶在僅有最後修改時間沒有模糊確認器的情況下執行子範圍修復,
則僅當最後修改時間是強確認時纔可以.
        若緩存器或源服務器收到一個條件請求,而不是完整GET響應,則必須使用強比較函數.
          此規定允許HTTP1.1協議下,緩存器和客戶可以對從HTTP1.0中得到的值安全的進行子域恢復.

13.3.4         關於何時使用實體標籤和最後修改時間的規則
           我們對源服務器，客戶和緩存器採用一套規則和建議來規定在何時，出
於何種目的，應採用何種確認器。
   HTTP/1.1 源服務器：
        -應該發送一實體標籤除非它做不到。
        -可以發送弱實體標籤如果其滿足性能要求或不能發送強確認。
        換句話說，對http1.1服務器來說,比較好的做法是同時發送強實體標籤和最後修改值.
        說明:爲保證語義透明緩存,服務器必須避免兩個不同實體重複利用同一
強實體標籤值或者兩類不同語義的實體重複使用同一弱實體標籤值.
   HTTP/1.1 客戶：
        -若服務器用實體標籤,則必須對任何緩存條件請求都使用此實體標籤.
        -僅當服務器提供最後修改值時,它應該在非子域條件請求中使用該值.
        -僅當HTTP1.0服務器提供了最後修改值時,他可以在子域緩存條件請求
        中使用該值.
        -若兩者均被提供,則兩者均應使用.

        當一服務器收到的請求既包括最後修改時間也包括一個或多個實體標籤,
則它一定不能發出304代碼,除非這是協調好的.
        當一個HTTP1.1緩存代理收到上述請求時,一定不能返回一個本地緩存響
應給客戶,除非它對所有請求都是一致的.
        說明:一般規律是傳送儘量多的非冗餘信息.
        HTTP1.0客戶和緩存器忽略實體標籤.
13.3.5 不確認條件
           其他報頭的比較不被用於確認緩存實體.
13.4 緩存能力響應
             除非被明確限制,緩存系統可以將一成功的響應作爲緩存實體一直存儲,如果它是保鮮的可以不確認而返回它,如果成功確認,也可以返回它.

        說明:某些HTTP1.0緩存器可能違反這一條而不提示警告.
        還有,某些情況下可能不便保留一實體,或將其返回給後續請求.
   注意14.8節防止共享緩存存儲和回覆一個早先的包含授權報頭的請求.      
          包含狀態碼200,203,206,300,301或410的響應可能會被用於回覆後面的響應.
        帶有其他一些狀態碼的響應不能用於回覆後面的請求,除非有明確的緩存控制
或其他報頭允許之.

13.5 從緩存器構造響應
           緩存器的目的是存儲響應請求的信息來響應後面的請求.再很多情況下,緩
存器僅返回響應的適當部分給請求者.如果緩存器保有一個基於前面請求的實體,它
可能必須將其與新響應合併.

13.5.1 端到端和Hop-by-hop報頭
        爲定義緩存器行爲,我們將報頭分成兩類:
        端到端報頭和hop_by_hop報頭（僅對簡單的傳輸層連接有意義，不被緩存，
                                    也不被代理服務器向前傳遞）
            
    hop-by-hop 報頭:

      - Connection                   連接
      - Keep-Alive                保活      
      - Proxy-Authenticate        代理人鑑別
      - Proxy-Authorization        代理人授權
      - TE
      - Trailers                軌跡
      - Transfer-Encoding        傳輸編碼
      - Upgrade                        升級

所有其他均爲端到端報頭
13.5.2         不可更改報頭
           HTTP1.1的某些特徵,如分類鑑定,基於某一端到端報頭值.一透明代理不能
修改端到端報頭除非報頭要求或明確許可.
 
傳輸代理不能修改下列各項，如果他們不存在，也不能添加。
      - Contents location
         目錄區
      - Content-MD5
      
      - ETag

      - Last-Modified
        最後修改時間

              - Expires

        但它可以添加這些區域.如果排除報頭被添加,則必須賦值來標明次響應的
日期報頭.
     
        包括不變形緩存控制指示或有請求.
      - Content-Encoding
        內容編碼
      - Content-Range
        內容區
      - Content-Type
        內容類型
        警告:對端到端報頭的不必要修改可能導致在今後高版本協議引入更強的鑑
定機制後鑑定失敗
        內容長度區的去留規則見4.4節.
13.5.3         聯合報頭（Combining Headers）
        但緩存向服務器發出確認請求,若服務器回覆304或206響應,則緩存器構
造響應回覆給請求客戶.      
        若狀態碼爲304,則緩存器使用緩存實體的報文構造響應,若狀態碼爲206
且標籤和最後修改時間恰好匹配,則緩存器可以將存儲的和剛收到的實體和並作爲
新響應的報文(見 13.5.4).

緩存實體中的端到端報頭用於構造響應,排除以下內容:
        -1xx警告報頭被刪除
        -2xx保留
        -304或206響應中的報頭代替緩存實體中的相應部分。
除非要刪除緩存實體，緩存器必須用收到的響應報頭取代端到端報頭。換句話說，
接收到的端到端報頭覆蓋緩存實體中已有的端到端報頭。
    
注意：此規則允許源服務器用304或206響應來刷新緩存器中的相應實體。


13.5.4 聯合字節範圍
        一條響應可能僅傳送一條正文的一部分，經過幾次這種傳送，一緩存器可能會
收到同一條正文的好幾部分。
 
        如果緩存器已經收到正文的一部分，且又收到了另一部分，緩存器可以
將新收到的內容與已有內容合併，當所有收到的響應及緩存實體含有強確認時。

13.6 緩存談判響應
     使用服務器驅動內容轉讓(見12.1),由響應中的變化報頭區說明, 改變了緩存器能用響應回覆後續請求的條件和過程.(服務器使用變化報頭區見14.44)    
 
     服務器要用變化報頭區告知緩存器在衆多可緩存響應類型用什麼樣的請求
報頭區來用服務器驅動轉讓.變化區命名此類報頭區爲"選擇"請求報頭.
 
        當緩存器收到指定一個或　Copyright  www.cnpaf.net (2007).          All Rights Reserved.
更多包含變化報頭區的緩存實體的後續請求,緩存器不能用這樣的緩存實體來構造新請求的響應,除非新請求中所有選中的請求報頭與初始請求相應部分匹配. 
 
        當且僅當兩個請求中的選擇請求報頭可以從前一請求變形爲後一請求時稱爲匹配.變形指,在相應的BNF允許的位置增加或刪除LWS,或者按照4.2節中的消息報頭規則合併合併同名的多個消息報頭區.

 
        一個變化報頭區數值"*"一般不能匹配而且對該資源的後續請求,服務器只能粗略解釋.
 
        如果舊的請求報頭不能匹配新的,緩存器不能用相應緩存實體來回復響應
除非它第一個將請求發給服務器且服務器回覆304,包括實體標籤或內容地址說明
實體可用.
 
        如果一實體標籤用於標誌緩存的代表,向前傳遞的請求應該是條件的且包
括實體標籤.這給服務器揭示了緩存器剛剛緩存的所有實體,所以如果其中任何實體與請求實體匹配,服務器可以用304響應中的ETag報頭區來稿置緩存實體可達.如果新請求中的實體標籤與已存在實體匹配,則新響應應該用於刷新存在實體的報頭區, 並將結果返回給客戶.
 
        如果任何已存在緩存實體僅包括相關實體的部分內容,它的實體標籤不能
包含於If-None-Match報頭區中, 除非此請求是對一個被該實體完全滿足的區域.
 
        如果緩存器收到一個成功響應,已存在實體不能回覆將來的響應且應該被刪除.
 
13.7 共享和非共享緩存

        出於安全和保密考慮，有必要區分共享和非共享緩存。非共享緩存是僅
供一個用戶使用的緩存器，此種情況下，可用性由適當的安全機制控制。其它緩
存器均被認爲是共享緩存。此協議的其它部分給出了其它的一些限制以防止隱私
的丟失和可達控制的失敗。

13.8 錯誤和不完全響應緩存行爲

        緩存器收到不完整響應時也可以存儲它，但是必須把它看作部分響應。
部分相應可以合併（見13.5.4）;合併結果可能是完整的或仍是部分的.緩存器
不能把部分相應回覆給客戶,除非有明確要求.
        如果緩存器在試圖重新確認一實體時收到5xx響應，它既可以將其傳送給
客戶也可以認爲服務器響應失敗。後一種情況，它可以回覆一個以前接收到的響應
除非緩存實體明確要求“必須確認”

13.9  GET 和 HEAD 的副作用：

        除非服務器明確禁止緩存它們的響應，對任何資源應用GET和HEAD算法，
如果響應曲子緩存器，都不會引起能導致錯誤的副作用。他們確實有副作用，但
緩存器在決定緩存時不必考慮。緩存器總是“看源服務器的臉色行事”。
 
一個例外：有些應用習慣於在query URLs時使用GET和HEAD，從而帶來顯著的副作用，
緩存器不能認爲對他們的響應是刷新的，除非服務器明確給出過期時間。這說明不能
從緩存器取出HTTP1.0服務器對URIs的響應。

13.10 刷新或刪除後的無效性
        某些算法對源服務器資源的操作將使一個或多個已存在的緩存實體不可
用，即爲，雖然他們還是“新鮮”的，但卻不能準確反映源服務器想回復給請求
的信息。

        HTTP協議無法保證所有此類實體均被標明無效。例如，引起源服務器變
化的請求可能沒到達存貯緩存實體的代理服務器，但是，有一些規則幫助減少類
似的錯誤。

 
        本節中，“使一個實體失效”表示緩存器或者刪除該實體的所有instances，或者標明其爲不可用，而且在重新用於回覆後面的響應前必須有重新確認命令。

        某些HTTP算法必將導致緩存器使一個實體失效。這是實體被URI請求或內
容區域報頭提到。這些算法是:

      - PUT
      - DELETE
      - POST

        爲了防止服務器拒絕處理，基於URI或內容區域報頭的失效處理僅當主機
部分與URI請求相同時才進行。

          緩存器向它不理解的算法傳遞請求時令所有被URI請求指明的實體失效。

13.11 強制寫通過（ Write-Through）
        所有可能對源服務器資源進行修改的算法都要寫給源服務器。這通常包括
所有算法除了GET和HEAD。緩存在將此種請求轉給內地服務器並獲得相應答覆前不
能對請求客戶做出響應。

        相反情況（write-back）在HTTP1.1中是不允許的，這是由於提供一致更新
非常困難且服務器緩存和網絡的故障比“write-back”早。


13.12 緩存替換
        如果收到一個新的響應，它的同源響應均已被緩存，緩存器就要用新響應
回覆當前請求，且將其插入緩存器存儲區，並用其回覆所有被退回的舊響應。
        說明：一個日期報頭比已存響應舊的新響應是不可緩存的。


13.13 歷史紀錄

        用戶代理經常使用歷史體制來重新獲得以前的實體。
        歷史機制和緩存是不同的，尤其歷史對資源的當前狀態是不透明的，更準
確地說就是歷史紀錄明示用戶在獲得資源時看到了什麼。
        默認情況，過期時間不用在歷史機制中。若實體仍然在存，即使它過期
歷史機制仍可以顯示它，除非用戶明確提出要代理刷新過期紀錄。
           這並不能解釋爲禁止歷史體制告訴用戶事情已經過時。

    
        說明：如果歷史紀錄未必阻止用戶看過時資源，這將強制服務提供者避免
使用HTTP過期控制和緩存控制。

                            　
14 報頭域定義
  本節定義了所有HTTP/1.1種標準頭域的語法和語義。對於實體頭域，發送者和接收者指的是客戶端和服務器，它是由實體的發送和接收者來定義的。


14．1接受（Accept）

接受請求報頭區域可以同作詳細說明特定對於響應來說可以接受的媒體形式.接
受報頭可以同作說明,請求對於一小組需要的形式來說是受限的,就像在爲了內
嵌圖像的請求的情況下一樣.

  Accept         = "Accept" ":"
                        #( media-range [ accept-params ] )

       media-range    = ( "*/*"
                        | ( type "/" "*" )
                        | ( type "/" subtype )
                        ) *( ";" parameter )
       accept-params  = ";" "q" "=" qvalue *( accept-extension )
       accept-extension = ";" token [ "=" ( token | quoted-string ) ]

星號字符用作將媒體形式聚集成爲一個範圍."*/*"指出了所有的媒體形式,"type/
*"指出了某種形式的圖表類形.媒體範圍可能包含適用於那個範圍的媒體形式參數.
每個媒體範圍可能跟隨着一個或者多個接受-參數.開始爲字母"q"的參數指出相關
質量的因素.任何一個開頭字母爲"q"將媒體範圍參量和接受參量區分開來.質量要
因素允許用戶或者是用戶代理使用從零到一的值來指出對於此媒體形式來說喜歡
的相關程度,缺省時q的值是1.

註釋:q參數名字可以用來將媒體形式從接受擴展參量中分辨出來,這是由於以前的
練習.雖然這保護了任何任何首字母爲q的參量被煤體範圍一起使用,這樣的事件被
認爲不太可能在LANA註冊中被給與缺少的"q"參量或者在Accept中任何媒體形式的
珍稀用法.未來的媒體形式從註冊和"q"參量中氣餒了.
例子:
Accept: audio/*; q=0.2, audio/basic
該例應該被解釋作"我喜歡audio/basic,但是如果在質量中€標記向下之後是最佳
可利用的話,就給我發送任何音頻形式.如果當前沒有接受報頭區域,那麼可以認爲
是客戶接受了所有的媒體形式.如果當前有　Copyright  www.cnpaf.net (2007).          All Rights Reserved.
接受報頭區域並且如果服務器不能發送
根據組合接受區域的值可以接受的響應的話,那麼服務器應該發送一個406響應.
一個精心挑選的例子
Accept: text/plain; q=0.5, text/html,
        text/x-dvi; q=0.8, text/x-c
口頭上的,這個可以被解釋作"text/html和text/x-c是首選的媒體形式,但是如果他
們並不存在,那麼給他們發送text/x-dvi實體,如果它不存在,則發送text/plain實
體."
媒體範圍可以不被更多特定媒體範圍或者特定媒體形式考慮.如果多餘一個的媒體
範圍適用於一個給出的形式的話,那麼最最特定的參考優先.比如"Accept: text
/*, text/html, text/html;level=1, */*"就有以下的優先:
1) text/html;leve=1
2) text/html
3) text/*
4) */*

和一個給出的形式相關聯的媒體形式質量要素就是由尋找有和形式相匹配的的最
最優先的媒體形式來決定的,比如:
Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
        text/html;level=2;q=0.4, */*;q=0.5
會使以下的值有關聯
text/html;level=1         = 1
text/html                 = 0.7
text/plain                = 0.3
image/jpeg                = 0.5
text/html;level=2         = 0.4
text/html;level=3         = 0.7

註釋:一個用戶代理可能會被提供一套默認的針對於特定媒體範圍的值.然而,除非
用戶代理是個關閉的系統並且不可以和其他翻譯代理相互作用,這套缺省可以由用
戶自己來配置.

14．2 接受-字符集（Accept-Charset）
   接受-字符集請求報頭區域可以用來指出什麼特性裝置可以爲響應所接受.這個區域允許有能力理解更復雜或者是特定目的特性的裝置的客戶通知給在那些特性裝置中有能力描述文檔的服務器服務器是否具有上述所述的能力.

Accept-Charset = "Accept-Charset" ":"
              1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )

特性裝置的值在3.4章節中描述.每一個??可以分配一個表示用戶對??喜愛程度的相關聯質量的值.缺升值是q=1.一個例子是:

Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

特殊的值"*",如果在接受-??區域顯示的話,則可以與每一個並沒有在接受??中其他
什麼地方提起的特性裝置相匹配.如果沒有'*'在當前接受-??區域,那麼所有沒有明
確提出的特性裝置都回得到一個爲零的質量值,除去在相同情況下可以得到1的
iso-8859-1.如果沒有接受-??報頭在當前,那麼缺省設置就是任何特性裝置都是可
接受的.如果當前存在接受-??報頭並且服務器不能發送根據接受-??報頭可以接受
的響應的話,那麼服務器就會發送一個錯誤響應和406狀態代碼,在不可接受響應在
發送過程中時也是允許的,

14．3 接收編碼(Accept-Encoding)
接收編碼(Accept-Encoding)請求報頭域和接收(Accept)相似,但限定響應中可接收的內容碼(content-codings)(3.5節).
        Accept-Encoding  = "Accept-Encoding" ":"
                      1#( codings [ ";" "q" "=" qvalue ] )
       codings          = ( content-coding | "*" )
Examples of its use are:
       Accept-Encoding: compress, gzip
       Accept-Encoding:
       Accept-Encoding: *
       Accept-Encoding: compress;q=0.5, gzip;q=1.0
       Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
根據接收編碼(Accept-Encoding)域測試內容碼(content-coding)是否可接受的服務器採用這些規則:
如果內容碼(content-coding)是接收編碼(Accept-Encoding)域中列出的一系列內容碼(content-codings)中的一種,則它是可接受的,除非它跟着 a qvalue of 0.(定義在3.9節, a qvalue of 0.意思是不可接受的)
接收編碼(Accept-Encoding)域中的特殊符號”*”匹配任何報頭域中沒有明確列出的可利用的內容碼(content-coding).
如果多種內容碼(content-codings)是可接受的,則具有最高非零qvalue的內容碼(content-codings)是優先的.
"identity" 內容碼(content-codings)總是可接受的,除非特定的說明其是不可接受的,因爲接收編碼(Accept-Encoding)域包括 "identity;q=0"或者因爲域中包括"*;q=0"和不明確的包括"identity"內容編碼.如果接收編碼域的值爲空,則只有 "identity"編碼是可接收的.
如果接收編碼域出現在請求中,且根據接收編碼報頭服務器不能發送可接收的響應,則服務器應當發送帶有406(Not Acceptable)狀態碼的出錯響應.

如果請求中沒有接收編碼域,服務器可以假定客戶機將接收任意的內容編碼.在這種情況下,如果"identity"是可利用的內容編碼之一,則服務器應該採用"identity"內容編碼,除非有額外的信息說明別的內容編碼對客戶機更有用.

  注意:如果請求中沒有包括接收編碼域,且"identity"內容碼是不可利用的,則能被HTTP/1.0客戶機解讀(i.e."gzip" and "compress")的內容碼一般是優先的.當發送別的內容碼是,一些老的客戶機顯示不正確的信息.服務器也許會以關於用戶代理或客戶機的信息爲基礎做出決定.

  注意:大多數HTTP/1.0應用程序不承認或遵守域內容碼相關的qvalues.這意味着qvalues將不工作或被x-gzip or x-compress允許.


14．4 認可術語
   The Accept-Language request-header field is similar to Accept, but
   restricts the set of natural languages that are preferred as a
   response to the request. Language tags are defined in section 3.10.
認可術語請求報頭區與認可是相近的，但規定了一套自然語言用來響應請求.術語
標識在3.10節說明.
       Accept-Language = "Accept-Language" ":"
                         1#( language-range [ ";" "q" "=" qvalue ] )
       language-range  = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
每個語言範圍均被賦以一個品質因數,它代表用戶用這種語言的鐘愛程度.品質因
數默認值爲一.例如:
 
       認可語言: da, en-gb;q=0.8, en;q=0.7

   表示:我喜歡丹麥語,但也接受不列顛英語和其它種英語.一種語言範圍對應一
種術語標識如果它正好等於標識,或者如果它正好等於標識的前綴,例如第一個跟
在前綴後面的標識符是'-'.特殊範圍"*",如果在認可術語區中出現，對應所有標
識符。

說明：使用前綴匹配規則並不表示如果用戶理解一戴又標識的術語，他就也理解
所有代前綴標識的術語。
        認可術語區指定給語言標識的語言品質因數是匹配標識的最大語言範圍
的品質數值。如果在此區內沒有語言範圍匹配此標識，則品質因數制定爲0。如果
請求中沒有認可術語報頭，服務器應假設所有語言被等同接受。如夠出現了認可
術語報頭，則所有品質因數大於0的語言均是可接受的。

        在每個請求中發送認可術語報頭說明可接受語言與保護用戶隱私識背道而
馳的，對此問題的專門討論見15.1.4
        鑑於可理解性高度依賴於個別用戶,推薦客戶應用用戶理解的語言.如果
選擇用戶不理解的,則請求中不能加入認可術語報頭區.
說明:當選擇用戶可接受語言時,我們提醒實現者如下事實,用戶並不熟悉術語匹
配的細節,所以應給出適當提示.

 


14．5接收範圍(Accept-Range)
接收範圍(Accept-Range)響應報頭域允許服務器給出對資源請求的接收範圍:
           Accept-Ranges     = "Accept-Ranges" ":" acceptable-ranges
          acceptable-ranges = 1#range-unit | "none"
接收byte-range請求的源服務器可以發送
           Accept-Ranges: bytes
但沒必要那樣做.客戶機可以產生byte-range請求,即使是它沒有收到相關的報頭域.
Range units定義在3.12節.

不接收任何種類對資源的範圍(range)請求的服務器可以發送
            Accept-Ranges: none
來建議客戶機不要嘗試範圍(range)請求.

14．6 年齡（Age）
Age響應報頭域表示發送者對傳輸時間的估計,既然響應是由源服務器產生的.假如緩存的響應沒有超過它的壽命,則認爲它是有活力的(fresh).13.2.3節說明了Age值的計算.
                 Age = "Age" ":" age-value
                 age-value = delta-seconds
Age值是十進制非負整數,以秒爲單位.

如果高速緩存存儲器收到一個大於它所能表示的上限整數的值,或它的Age計算溢出,它必須傳送值爲2147483648 (2^31)的Age報頭域. 帶有高速緩存存儲器的HTTP/1.1服務器產生的每一個響應(從它本身的高速緩存存儲器中)都必須包括Age報頭域. 高速緩存存儲器應當採用至少31位的算法.


14．7 允許（Allow）

允許 (Allow)實體報頭域中列出了由　Copyright  www.cnpaf.net (2007).          All Rights Reserved.
請求指定資源支持的幾種方法--URI。這一報頭域的目的嚴格限於通知接收者與資源相聯繫的方法有哪些。允許報頭域必須出現在405（方法不被允許）應答中。

允許="允許""：" #方法

使用示例：

          允許: GET, HEAD, PUT

這一報頭域不能阻止用戶使用其他方法。然而允許域給出的指示應予以執行。由原服務器在處理每一請求時定義允許的方法集。
允許域可由PUT請求提供，以建議新資源支持某些方法。服務器不必一定支持這些方法，且應在允許域中給出實際支持的方法。
因爲用戶有其他與原服務器通信的渠道，故代理服務器即便不理解域中指明的所有方法，也不得修改允許報頭域

14．8         授權（Authorization）
用戶代理往往希望服務器自我驗證,但在收到401響應後則沒有必要了.用戶代理通過包括Authorization請求報頭域的請求那樣做. Authorization請求報頭域的值由包含用戶代理驗證信息的信任狀所組成,這些用戶代理處於請求資源的領域.
             Authorization  = "Authorization" ":" credentials
HTTP Authentication中描述了HTTP訪問的身份鑑定: Basic and Digest Access Authentication" [43].假如請求在特定的領域中通過了驗證,則同樣的信任狀對該領域內所有其它請求都是有效的(假定驗證方案本身不需要,否則信任狀依照亟待解決的問題或用同步時鐘而不同)

當共享的高速緩衝存儲器(看13.7節)接收具有驗證(Authorization)域的請求時,必須返回相應的響應作爲其他請求的應答,除非是接下來的特殊情況之一.
如果響應包括s-maxage緩存控制指示信息,高速緩存可以用響應來應答併發的請求.但(如果已超過了特定的最大生存期)代理服務器的高速緩存首先必須重新生效,用來自新請求的請求報頭允許源服務器驗證新的請求.(這是爲s-maxage定義的行爲.)假如響應包括"s-maxage=0",代理服務器必須在重新利用之前使之生效.

如果響應包括must-revalidate緩存控制指示信息,高速緩存可用響應來應答併發請求.但如果響應失去時效,所有緩存首先必須使它重新生效河源服務器一致,用來自新請求的請求報頭允許源服務器驗證新的請求.

假如響應包括public緩存控制指示信息,它可以被返回來應答併發請求.

14．9 緩存-控制（Cache-control）

緩存-控制通用-報頭域用於標明請求/應答鏈上所有緩存機制必須遵守的指令。這些指令規定了一些意在預防緩存對請求或應答造成不良影響的行爲。它們通常覆蓋了缺省的緩存算法。 緩存指令是單方向的，因爲請求中指令的存在並不意味着應答中也會有同樣的指令。

請注意HTTP/1。0緩存機可能並不實現緩存-控制，而是隻實現
Pragma:無-緩存（參見14。31節）。

代理服務器或網關的應用程序必須不顧緩存指令對其本身的意義，毫無例外的讓它們通過，因爲這些指令可能對請求/應答鏈上的所有接收者都適用。

緩存-控制="緩存-控制""：" 1#緩存-指令
緩存-指令="緩存-請求-指令|緩存-應答-指令
緩存-請求-指令=
           "無-緩存"                           ; 14.9.1節
         | "無-存儲"                           ; 14.9.2節            
         | "最大-時限""=" delta-秒                         ; 14.9.3, 14.9.4節
         | "最大-陳舊" ["="delta-秒]                       ; 14.9.3節
         | "最小-保鮮"["="] delta-秒                       ; 14.9.3節
         | "不傳輸"                            ; 14.9.5節
         | "僅當緩存時"                        ; 14.9.4節
         |   緩存-擴展                         ; 14.9.6節

緩存-應答-指令=
"公共" ;                                                                 14。9。1節
|" 私有"["="<"" 1#域名〈"〉];                               14。9。1節                                        |"無緩存" ["="<"" 1#域名〈"〉]；                           14。9。1節
|"不存儲"                                              14。9。2節
|"不傳輸"                                              14。9。5節
|"必須經重新確定有效"                                          14。9。4節
|"代理服務器重新確定有效"                                      14。9。4節
|"最大時限""="delta-秒                                         14。9。3節
|"s-最大時限""="delta-秒                                       14。9。3節
|緩存-擴展                                                  14。9。6節

當指令不伴有1#域名參數出現時，該指令適用於整個請求或應答。

當指令伴有1#域名參數出現時，它僅適用於被命名的域，而不適於請求或應答的其他部分。這一機制支持可擴展性；HTTP協議將來的版本可以通過將指令應用於HTTP/1。1中未定義的域來實現。

緩存-控制指令 可分爲如下幾類：

-- 對可緩存的範圍的限制；這可能只由原服務器指定。
-- 對緩存內容的限制；這可由原服務器或用戶代理指定。
-- 對基本過期無效機制的改進；這可由原服務器或用戶代理指定。
-- 對緩存重新確認有效及重載的控制；這可能僅由用戶代理指定。
-- 對實體傳輸的控制
-- 緩存系統的擴展。

14．9．1 何謂可緩存的

缺省情況下，若請求方法，請求報頭域和應答狀態指明瞭應答爲可緩存的，則它就是可以緩存的。 13。4節總結了這些可緩存性的缺省情況。 下列緩存-控制應答指令允許原服務器覆蓋缺省的應答的可緩存性：

公共

指明應答可被任意高速緩存機緩存，即便在該應答通常是不可緩存的或只可由不共享的高速緩存機緩存的情況下也是如此。（參見14。8節，關於認證的附加詳述）

私有

表明應答報文的所有部分都是爲單一用戶準備的且不得被共享緩存機緩存。

這使原服務器可以申明應答的特定部分是針對單一用戶的，對其他用戶的請求而言並非有效應答。 私有（不共享）緩存可以緩存應答。

注：私有一詞僅用來控制應答在何處可被緩存， 而不能保證報文內容的私有性。

不緩存

若指令"不緩存"沒有指定域名，則緩存機不得應答那些未經原服務器重新確認有效的後繼的請求。

這使得原服務器即便對設置爲回送陳舊應答給客戶請求的高速緩存機也能防止緩存。

若指令"不緩存"確實指定了一個或多個域名，則高速緩存機可以在其他的緩存要求限制下應答後繼請求。 然而，指定的域名不得在用於應答那些未經原服務器重新確認有效的後繼請求。這使得原服務器防止了應答中某些報頭域重複使用，同時又允許緩存應答的剩餘部分。

注：大多數HTTP/1。0高速緩存機不會認出或遵守這一指令。

14．9．2 哪些可被高速緩存機保存

不保存

"不保存"指令的目的在於防止無意中泄露或滯留了敏感信息（比如存在備用磁帶上了）。

"不保存"指令適用於整個報文，可在請求或　Copyright  www.cnpaf.net (2007).          All Rights Reserved.
應答中發送。若由請求方發送，則高速緩存機不得保存該請求或其應答的任何部分。若由應答方發送，高速緩存機不得保存該應答和相應請求的任何部分。該指令對非共享與共享高速緩存機都適用。 "不得保存"在這裏意味着緩存機不得有意地將信息保存在非易逝存儲器上，且必須盡最大努力將信息在轉發後儘快從易逝存儲器上轉移。

即使這一指令是與應答相聯繫的，用戶也可能明言要在緩存系統之外保存該應答（比如通過"另存爲"對話框）。 歷史緩存區可作爲例行公事保存這些應答。

這一指令地目的在於滿足某些在意信息經未知渠道偶然泄漏到緩存數據區的用戶與服務程序作者提出的要求。雖然這一指令的使用可能改善了保密性，但值得提醒的是，它又絕非保證保密性的充分的或可靠的機制。

14．9．3 對基本過期失效機制的改進

實體的過期時間可由原服務器的"過期"報頭（參見14。21節）指定。或者，它也可由應答中的"最大-年齡"指令說明。當被緩存的應答含有"最大-年齡"緩存-控制指令時，應答若現有年齡大於出現對同一資源的新請求中所給年齡值（以秒爲單位）則被視爲陳舊。應答中的"最大-年齡"指令意味着該應答是可緩存的（如，"公共"），除非存在其他更嚴格的緩存指令。

若應答同時含有過期報頭與"最大-年齡"指令，最大-年齡指令覆蓋過期報頭，即便過期報頭中的描述更嚴格也不例外。這一規則使原服務器可就給定應答爲HTTP/1。1（或更新的版本）緩存機提供比HTTP/1。0緩存機更長的過期時間。這在某一HTTP/1。0緩存機出於諸如類似同步時鐘的原因錯算了年齡或過期時間的情況下可能有用。

許多HTTP/1。0緩存機會按照與緩存-控制應答指令"不緩存"等價的方式來處理小於或等於應答日期值的過期值。若HTTP/1。1緩存機接到這種應答，且應答不含緩存-控制報頭域，則它應視應答爲不可緩存，從而保持與HTTP/1。0服務器的兼容性。

注：在兼有不懂新特性的舊版緩存機的網絡上，一臺原服務器可能願意採用較新的HTTP緩存控制功能，如"私有"指令。這樣，原服務器就需要將新特性與其值小於等於日期值的過期報頭域結合起來。這將防止舊版緩存機誤緩存應答。

s-最大年齡

若應答包含s-最大年齡指令，則對共享緩存機（而非私有緩存機）而言，由該指令指定的最大年齡覆蓋其他最大年齡指令或過期報頭的指定。 S-最大年齡指令也暗示了代理服務器-重新確定有效指令的句法（參見14。9。4節），也就是說，在首先經原服務器重新確認爲有效之前，共享緩存機不得用那些變得陳舊了的目錄來應答後繼請求。 私有高速緩存機忽略此s-最大年齡指令。

請注意，大多數與此規範不相適的舊版緩存機並不執行任何緩存-控制指令。 想要使用緩存-控制指令來限制而非避免遵守HTTP/1。1的緩存機進行緩存得原服務器可以利用最大-年齡指令覆蓋過期報頭的條件以及早於HTTP/1。1的緩存機不檢查最大-年齡指令這一事實。

其他指令允許用戶代理修改基本過期失效機制。 這些指令可由請求指定：

最大-年齡

表明客戶機願接受其年齡不大於指定時間（以秒計算）的應答。除非也含"最大-陳舊"指令，否則客戶機不願接受陳舊應答。

最小-保鮮

表明客戶機願接受其保鮮壽命不小於現有年齡與指定時間之和（以秒計算）的應答。也就是說，客戶機想要一至少在一定時間內保持保鮮的應答。

最大-陳舊

表明客戶機願接受已經過期的應答。 若指定最大-陳舊爲某值，則客戶機願接受過期時間不超過給定秒數的應答。若未指定最大-陳舊的值，則客戶機願接受任意年齡的陳舊應答。

若緩存機或出於請求的最大-陳舊指令，或出於緩存機被設置爲覆蓋應答過期時間的原因，最終返回了一個陳舊的應答，緩存機都必須在舊應答上添加一警告報頭，採用警告110（應答是陳舊的）。

高速緩存機可被設置成不經確認就返回陳舊應答，但這不應與任何"必須"等級的關於緩存重確認的要求（如"必須-重新確認有效"緩存-控制指令）衝突。

若新請求與緩存的條目均包括"最大-年齡"指令，則取兩者間較小值來決定該請求的緩存條目的保鮮程度。


14．9．4  緩存重新確認有效和重載控制

有時用戶代理可能希望或出於需要堅持讓　Copyright  www.cnpaf.net (2007).          All Rights Reserved.
緩存機與原服務器之間重新確認緩存條目的有效性（而不只是通向原服務器的傳輸路徑中的下一高速緩存機），或是從原服務器處重載緩存條目。端到端的重新確認有效手續在緩存機或原服務器高估了緩存應答的過期時間時可能需要。端到端重載在緩存條目由於某些原因被侵蝕時可能需要。

如果客戶機沒有自己的本地緩存拷貝，即所謂"未指明的端到端重新確認有效"，或客戶機沒有本地的緩存拷貝，即所謂"經指明的端到端重新確認有效"， 都有可能要求端到端的重新確認有效。

客戶機可用緩存-控制請求指令來指明三種行動中的一種：

端到端重載

請求包括"不緩存"緩存-控制指令，或是與HTTP/1。0客戶機兼容的"Pragma:不緩存"。

請求的"不緩存"指令中不得含有域名。服務器應答這種請求時不得使用緩存的拷貝。

經指明的端到端重新確認有效

請求包括"最大-年齡=0"緩存-控制指令，從而迫使通向原服務器路徑上的每一高速緩存機都與下一緩存機或服務器之間重新確認自身條目的有效性。初始請求包括由客戶機現有的確認模塊決定的緩存有效性確認過程。

未指明的端到端重新確認有效

請求包括"最大-年齡=0"緩存-控制指令，從而迫使通向原服務器路徑上的每一高速緩存機都與下一緩存機或服務器之間重新確認自身條目的有效性。初始請求中不包括緩存條件有效性確認過程。沿途第一個含有此資源緩存條目緩存機（如果存在的話）包括決定於現有的有效性確認模塊的緩存-有效性確認。

最大-年齡

當中轉緩存機被"最大-年齡=0"的指令迫使重新確認其緩存條目有效性，且客戶機在請求中提供了自己的有效性確認器時，所供的有效性確認器可能不同於緩存條目中現存的有效性確認模塊。在這一情況下，緩存機可以在不影響句法透明性的前提下將其中的任一有效性確認模塊用於自己的請求。
然而，對有效性確認器的選擇可能影響性能。 最好的方法是讓中轉緩存機採用自己的有效性確認模塊來構造請求。若服務器應答以304（未經修改），則緩存機可以將自己的確認後拷　Copyright  www.cnpaf.net (2007).          All Rights Reserved.
貝連同200（OK）應答一起發回給客戶機。但若服務器發回新的實體和有效性確認器，則中轉緩存機可使用強比較函數比較返回的有效性確認器與客戶機請求中提供的有效性確認器。若客戶機的有效性確認器與原服務器的一致，則中轉緩存機僅需發送回304（未經修改）。否則，它就發回新的實體和200（OK）應答。
若請求含有"不緩存"指令，則它不得包括最小-保鮮，最大-陳舊或最大-年齡指令。

僅當經緩存時

在某些情況下，如網絡連接極爲糟糕時，客戶機可能想要緩存機只返回它現存的應答，而不要與原服務器之間進行重載或重新確認有效性。爲實現這一點，客戶機可以在請求中包括"僅當經緩存時"指令。若它收到這一指令，緩存機應該應答以符合請求其他限制的緩存條目，或是應答以504（網關超時）狀態。然而，當一組緩存機是作爲呢部內部聯繫良好的同一系統來操作的話，這樣的請求可能會在那組緩存機內部轉發。

必須-重新確認有效性

由於緩存機可能被設置爲忽略服務器指定的過期時間，且客戶機請求可能包括最大-陳舊指令（與前者效用相似），協議還包括了一種由原服務器要求後繼使用中重新確認緩存條目有效性的機制。

當緩存機接到的應答中有必須-重新確認有效性指令時，該緩存機不得在條目變得陳舊後不經與原服務器重新確認有效性就用來應答後繼請求。（也就是說，若僅由原服務器的"過期"報頭或"最大-年齡"取值確定緩存的應答已陳舊，緩存機就每次都必須執行端到端有效性重新確認。）

"必須重新確認有效性"指令對支持某些協議特性可靠運作是必要的。在所有情況下，HTTP/1。1緩存機必須遵守"必須重新確認有效性"指令；特別是，若緩存機出於任何原因無法到達原服務器，則它必須產生504（網關超時）應答。

當且僅當對實體的請求的有效性重確認的失敗會導致錯誤的操作（比如未申明但未被執行的最終事務）時，服務器應該發送"必須重新確認有效性"指令。 接收者不得采取任何違背該指令的自動行動，也不得在重確認失敗時自動提供未經確認的實體拷貝。

雖不提倡如此，但受到嚴格的連接限制的用戶代理還是可以違背這一指令，但在這麼做的同時必須明確警告用戶提供的是未經有效性確認的應答。每一未確認的訪問都必須伴有警告，且應要求明確的用戶許可。

代理服務器-重新確認有效性

除了不適於非共享用戶代理緩存機之外， "代理服務器-重新確認有效性"指令與"必須重新確認有效性"指令含義相同。它可用於對經認證的請求的應答，以允許用戶的緩存機保存應答，並在稍後無須重新確認就返回應答（因爲它已經被該用戶認證了），同時仍然要求服務於多個用戶的代理每次都重新確認有效性（從而確保每一用戶都通過認證）。 請注意這種經認證的應答還需要"公共"緩存-控制指令，使得它們可以被緩存。


14．9．5 不得轉換指令
不得轉換

中轉緩存機（代理服務器）的實現者們發現轉換某些實體正文的媒體類型是很有用的。 比如，一臺非透明的代理服務器可以在圖象格式之間進行轉換，以節省緩存空間或減少慢速鏈路上的數據通信量。

然而，當這些轉換應用於某些應用的實體正文時，會引發嚴重的操作方面的問題。比如，醫學圖象應用，科學數據分析和端到端認證都依賴於接收到與原實體正文一比特都不差的實體正文。

所以，如果報文包括了"不得轉換"指令， 中轉緩存機或代理服務器就不得改變13。5。2節中列出的受"不得轉換"指令影響的報頭。這意味着緩存機或代理服務器不得改變由這些報頭定義的實體正文的任何方面，包括實體正文值本身。

14．9．6 緩存控制擴展

緩存-控制報頭域可通過一個或多個緩存-擴展標誌的使用來實現擴展。其中每一標誌都賦予一可選的值。 信息性的擴展（那些無須改變緩存機行爲的）可以不經改變其他指令的句法而添加。

行爲性擴展被設計爲現有基本緩存指令的修正。 新指令與標準指令都有提供，於是不理解新指令的應用程序會缺省地按採用標準指令規定的行爲，而理解新指令的應用程序則將其認作標準指令提出的要求的修正。這樣，緩存-控制指令可以無須改變基本協議就得到擴展。

這一擴展機制依賴於HTTP緩存機對所有初始HTTP版本中緩存-控制指令和某些擴展方式的遵守，以及對所有它不理解的指令的忽略。

例如，考慮一個假想中的名爲"共同體"的新應答指令，作爲"私有"這裏指令的修正。我們定義這個新的指令以表明除了非共享緩存機之外，任何只可被同一共同體成員共享的緩存機都可以緩存此應答。原服務器若想允許UCI共同體在它們的共享緩存機之間使用本來是私有的應答，只需在該應答中添入：

緩存-控制：私有， 共同體="UCI"

見到這一報頭域的緩存機即便不理解"共同體"緩存-擴展也能正確操作，因爲它還見到並理解"私有"指令，就會按缺省的安全方式行事。

未經認出的緩存-指令必須被忽略；按照假定，任何可能未被HTTP/1。1高速緩存機認出的緩存-指令都與標準指令（或應答的缺省可緩存性）相結合使用，從而是緩存機的行爲即便在它不理解擴展指令時也儘可能保持正確。

14．10 連接

連接這一概括報頭域允許發送者指定某一特定連接中的選項設置，且不得由代理服務器在以後的連接中傳送。

連接報頭遵循如下語法：

連接="連接""：" 1#（連接-標誌）
連接-標誌=標誌

HTTP/1。1代理服務器必須在轉發報文之前即解析連接報頭域，針對域中每一連接-標誌，從報文中移開所有與連接-標誌同名的報頭域。 連接選項是由連接報頭域中的連接-標誌指明的，而非任何附加的報頭域，因爲這些附加報頭在缺少與連接選項相關的參數時無法被傳送。

連接報頭中列出的報文報頭不得含有諸如緩存-控制之類的端到端報頭。

HTTP/1。1定義了"close"選項，以供發送者宣佈連接在完成應答後將被關閉。例如

連接：close

無論是出現在請求或應答的報頭域中，都表明連接不應被視爲在完成現有請求/應答後是"持續的"（參見8。1節）。

不支持持續連接的HTTP/1。1應用程序必須在每一報文中都添上"close"連接選項。

接收到含有連接報頭的HTTP/1。0（或更低版本）報文的系統必須爲每一連接-標誌都去除或忽略報文中與之同名的報頭域。這樣做避免了早於HTTP/1。1版本的代理服務器誤轉發這些報頭域。

14．11 內容編碼

"內容編碼"實體報頭域是作爲媒體類型的修正。此域存在時，其值表明對實體正文采用了何種附加的內容編碼，從而須採用何種解碼機制以獲取"內容類型"報頭域中指出的媒體類型。"內容編碼"的主要目的是使文件可以在不喪失其基本媒體類型身份的同時被壓縮。

內容編碼="內容編碼" "：" 1#內容譯碼

內容譯碼由3。5節定義。其應用示例爲：

內容編碼：gzip

內容譯碼是由請求定義（URI）的實體特性。通常，實體正文以編碼方式存儲，只在翻譯或類似使用前才解碼。然而，非透明代理服務器在確知新譯碼可被接受者認可的情況下可能會改變內容譯碼，除非報文中含有"不得轉換"的緩存控制謂詞。

若實體的內容譯碼不具備同一性，則應答必須包含列有所用非同一內容譯碼的內容編碼實體報頭（14。11節）。

若請求報文中的實體內容編碼對原服務器而言不可接受，則服務器應以415（不被支持的媒體類型）狀態碼應答。

若實體採用多種編碼，則內容譯碼應按它們的使用順序列出。

關於編碼參數的其他信息和由未被此說明定義的實體報頭域給出。

14．12 內容語言

內容語言實體報頭域描述了實體面向的受衆的使用語言。請注意，這不一定等同於實體正文中用到的所有語言。

實體語言="實體語言""："1#語言標記

語言標記由3。10節定義。內容語言的主要目的在於讓用戶根據自己喜用的語言確認並區別衆實體。由是，若正文內容只是針對懂荷蘭語的人的話，相應的域應爲：

內容語言：da

若未指明內容語言，缺省值爲內容針對所有語種的受衆。這既可能指發送者認爲內容與任意自然語言無關，也可能指發送者不知此內容應面向何種語言。

要面向多種聽衆，可列出多種語言。例如，同時用毛裏土語和英語發行的"Waitangi之約"就可以用：

內容語言：mi,en

然而，實體中有多個語種並不代表它一定是爲多語種的觀衆準備的。比如"初學拉丁文"之類的語言啓蒙教程，顯然是針對英語觀衆的。這裏，恰當的"內容語言"應只包括"en"。

內容語言可用於任意媒體類型 -- 它不限於文本式文件。

14．13 內容長度

內容長度實體報頭域按十進制或八位字節數指明瞭發給接收者的實體正文的大小，或是在使用HEAD方法的情況下，指明若請求爲GET時將發送實體正文的大小。

內容長度="內容長度""："1*DIGIT

示例：

內容長度：3495

除非按4。4節的規則被禁用，應用程序應使用此域指明報文正文的傳輸長度。

任何不小於零的內容長度均爲有效值。 4。4節描述瞭如何在未知內容長度時測定報文長度的方法。

請注意此域的含義域MIME中的相應定義迥異。MIME中，它是"報文/擴展正文"內容類型的可選域；在HTTP中，除非按4。4節的規則被禁用，一旦報文長度在傳送前被確定，就應發送此域。

14．14 內容位置

內容位置可用來在從一獨立於請求資源的URI的位置訪問實體時提供報文中實體的資源位置。服務器應根據應答實體爲此變量提供一內容位置；尤其是在資源和多個實體相聯繫，而這些實體各享獨立位置，可被分別訪問時，服務器應爲特定的返回變量提供內容位置。

內容位置="內容位置""："（絕對URI|相對URI）

內容位置的值也決定了實體的基礎URI。

內容位置值並非原請求URI的替代；它只是申明瞭請求中對應特定實體的資源位置。

此後的請求若想確定特定實體的來源，可以指定內容位置URI爲請求的URI。

緩衝存儲機不能以爲若實體的內容位置URI異於訪問URI就可用此實體來應答那一內容位置URI下的後續請求。但如13。6節所述，內容位置可用於區分從同一請求資源得到的多個實體。

若內容位置是相對URI，則此相對URI是相對於請求URI來解釋的。

PUT或POST請求中內容位置報頭的含義未定；服務器可自由忽略。

14．15 內容-MD5

如RFC 1864[23]中所定義的，內容-MD5實體報頭域是實體正文的MD5摘要，以期提供端到端的實體正文的報文完整性檢驗（MIC）。（注：MIC有利於檢測實體正文傳送中的偶發改動，但不一定能防範惡意襲擊。）

內容-MD5="內容-MD5""：" MD5-摘要
MD5-摘要=< 由RFC 1864 定義的的 基64的128比特MD5摘要>

內容-MD5報頭域可由原服務器或客戶機生成，用作實體正文的完整性檢驗。只有原服務器或客戶機可生成內容-MD5報頭域；不得由代理服務器和網關生成，否則會有悖於其作爲端到端完整性檢驗的價值。任何實體正文的接收者，包括代理服務器和網關，都可檢查此域中摘要值與實體正文是否相符。

MD5摘要的計算基於實體正文的內容，包括任何所用的內容譯碼，但不包括任何對報文正文進行的傳輸編碼。若接到的報文有傳輸編碼，則必須在覈對內容-MD5與所收正文之前解除編碼。

這樣造成的後果是：摘要完全按照它們若未經傳輸編碼而被髮出的順序進行逐字節計算。

HTTP 將RFC 1864拓寬到允許對MIME組成的媒體類型（如multipart/*,message/rfc822）計算摘要，但這並不改變如前所述的摘要計算方法。

由此產生了一系列影響。組件類型的實體正文可能會包括多個正文部分，每一部分都有自己的MIME和HTTP報頭（包括內容-MD5,內容-傳輸-編碼，和內容編碼報頭）。如果正文部分有內容-傳輸-編碼或內容編碼報頭，則被假定爲正文部分的內容已經過編碼處理，且正文部分依樣包括在內容-MD5摘要中。 正文部分不得含有傳輸編碼報頭域。

不可在摘要計算或覈對之前就將任何斷線轉換爲CRLF：實際傳輸的文本中使用的斷線轉換協定必須原封不動的參與摘要計算。

注：雖然HTTP的內容-MD5定義和RFC 1864中關於MIME實體正文的完全一樣， 但HTTP 實體正文在對內容-MD5的應用上仍然有幾處與MIME實體正文有所區別。首先，HTTP不象MIME會用內容-傳輸編碼，而是使用傳輸編碼與內容編碼。其次，HTTP比MIME更多地使用二進制內容類型，故值得提出的是：在此種情況下，用於計算摘要的字節序也即由類型定義的傳輸字節順序。最後，HTTP允許文本類傳輸時採用數種斷線協定，而不只是規範的使用CRLF的形式。

14．16 內容-範圍

內容-範圍實體報頭與部分實體正文一起發送，用於指明在全部實體正文中，那一部分正文應該應用於何處。 範圍的單位在3。12節中有定義。

內容-範圍 = "內容-範圍""："內容-範圍-說明
內容-範圍-說明 = 字節-內容-範圍-說明
字節-內容-範圍-說明 =字節-單位 SP
                     字節-範圍-方面-說明 "/"
                    （實例-長度|"*"）
字節-範圍-方面-說明 =（首字節位置 "-" 末字節位置） |"*"
實例-長度  =1*DIGIT

除非無法或很難測定，報頭應指明全部實體正文的總長度。星號"*"表示生成應答信息時實例長度未知。

與字節-範圍-指定符的值（參見14。35。1節）不同的是，字節-範圍-方面-說明僅可指明一個範圍，且必須包含首末字節的絕對位置。

其字節-範圍-方面-說明的末字節值小於首字節值或實例-長度值小於等於末字節值的字節-內容-範圍-說明是無效的。收到無效的字節-內容-範圍-說明值時接收者必須忽略此值與隨其傳輸的任何內容。

應答時發送狀態碼416（請求的範圍無法滿足）的服務器應在內容-範圍域中填上字節-範圍-方面-說明爲"*"。實例-長度項指明被選資源的現有長度。狀態碼爲206（部分內容）的應答不應將內容-範圍域的字節-範圍-方面-說明填爲"*"。

假定實體共含1234字節，字節-範圍-方面-說明項的示範值爲：

頭500字節： 字節0-499/1234
次500字節： 字節500-999/1234
除頭500 字節外的所有： 字節500-1233/1234
末500字節： 字節734-1233/1234

當HTTP報文包含單一範圍的內容時，（比如，對單一範圍請求，或對一組互有覆蓋但無遺漏的請求的應答）此內容在傳輸時內容-範圍報頭與內容-長度報頭會顯示實際傳輸的字節數。例如：

HTTP/1。1 206 部分內容
日期： 星期三， 1995年11月15日 06：25：24 （格林威治時間）
上次修改時間：星期三， 1995年11月15日 04：58：08 （格林威治時間）
內容-範圍：字節21010-47021/47022
內容-長度： 26012
內容-類型：image/gif

當HTTP報文包含多個範圍時（比如，對多個未重疊範圍請求的應答），它們會被當作多部分報文來傳送。

用於此目的的多部分媒體類型如附錄19。2節中所述定義爲"multipart/byteranges"。 其兼容性問題述於附錄19。6。3中。

對單一範圍請求的應答不得使用multipart/byteranges媒體類型。若對多範圍請求的應答結果爲單一範圍，可以採用只有一個部分的 multipart/byteranges媒體類型發送。無法對multipart/byteranges報文解碼的客戶機不得在單一請求中申請多個字節範圍。

當客戶機在單一請求中申請多個字節範圍時，服務器應按請求中出現的順序發回信息。

若服務器出於句法無效的原因忽略了字節-範圍-說明，它應視無效的範圍報頭域不存在來處理請求。（正常情況下，這意味着發回含有全部實體的200應答。）

如果服務器接到請求報頭域中含無法滿足的範圍（也即，所有字節-範圍-說明值的首字節值大於所選資源現有長度）的請求（含條件-範圍請求報頭域的除外），則它應應答以代碼416（請求的範圍無法滿足）（參見10。4。17節）。

注： 客戶機對無法滿足範圍的請求報頭不能指望服務器一定發回416（請求的範圍無法滿足）而非200（OK）的應答，因爲不是所有服務器都處理這一請求報頭。

14．17 內容-類型

內容-類型實體報頭域指明發給接收者的實體正文的媒體類型，或在HEAD方法中指明若請求爲GET時將發送的媒體類型。

內容-類型="內容-類型""："媒體類型

媒體類型有3。7節定義。 此域的示例如下：

內容-類型：text/html; charset（字符集）=ISO-8859-4

7．2．1節提供了關於確定實體媒體類型方法的進一步論述。

14．18  日期

  日期頭域描述消息產生的日期和時間，它和RFC822中的ORIG-DATE語義一樣。域值是一個在3。3。1描述的HTTP日期；它必須用RFC1123[8]數據格式發送。

      Date="Date""："HTTP-date

  舉個例子

         Date:Tue,15 Nov 1994 08:12:31GMT

原服務器在所有的應答中必須包括一個日期頭域，除了這些特例：
　　１ 如果應答的狀態代碼時１００（繼續）獲１０１（選者協議），相應可以在服務的選項中包括日期頭域。

　　2 如果應答狀態代碼傳送服務器錯誤，如５００（ｉｎｔｅｒｎｅｔ服務器錯誤）獲５０３（服務器不可達），它沒有困難或不可能產生有效的日期。

　　3 如果服務器沒有時鐘，不能提供合理的當前時間的近似值，這個應答沒必要包括日期頭域，但在這種情況下必須遵照
14．18．1節中的規則。

一個收到的消息沒有日期頭域的話會被接收者加上一個，如果這條消息將被那個接收者或網關儲存並進由一個需要日期的協議。一個沒有時鐘的http執行不能緩存沒有重新使之關於每一個使用有效的應答。一個http緩存，特別是一個共享的緩存，必須使用一種機制使它與外界可靠的時鐘保持同步。

客戶端秩序在包括實體的消息中發送日期頭域，正如在PUT和POST請求的過程，甚至它是隨意的。一個沒有時鐘的客戶端不能在請求中發送日期頭域。

一個日期頭中的http-date沒必要描述一個後續消息的產生的日期和時間。它必須描述消息產生的最有用的日期和實踐的近似值。除非執行沒有方法產生一個恰當的相當精確的日期和時間。理論上說，日期必須是實體產生之前的那一刻，實際上，日期能是消息產生的任何時候的時間而不會影響其語義。

14．18．1 沒有時鐘的原服務器的運作

  一些原服務器的執行可能沒有可用的時鐘。一個沒有時鐘的原服務器不能指定一個應答斷開或維持修改的值除非這些值是和系統或用戶可靠的時鐘資源相關聯的。它可以指定一個知道的終止值，在服務配置的時間或以前，這是過去的（這允許應答的預終止而不保存每個資源分離的分割值）。


14．19  ETag

Etag應答報頭域提供了請求變量的當前實體標籤。與實體標籤一起使用的報頭由14。14，14。26，14。44節描述。

實體標籤可用於比較來自同一資源的不同實體。（參見13。3。3節）

Etag="ETag" "Etag"":" 實體-標籤

例：

      ETag: "xyzzy"
      ETag: W/"xyzzy"
      ETag: ""


14．20 期望

期望請求報頭域用於指明客戶機需要特定的服務器行爲。

期望="期望""："1#期望值
期望值="100-繼續"|期望值-擴展
期望值-擴展=標號["="（標號|引用-字符串） *期望-參數]
期望-參數="；"標號["="（標號|引用-字符串）]

對請求的期望域中期望值不理解或與其不相容的服務器必須應答以相應的出錯狀態。 如果所有期望都無法滿足，服務器必須應答以417（期望失敗）狀態。 若請求有其他問題，則應應答以其他4xx狀態。

本報頭域依照可擴展語法定義，以滿足將來擴展需要。若服務器接到的請求含有它不支持的期望-擴展，則它必須應答以417（期望失敗）狀態。

期望值的比較對於未經引用的標號（包括"100-繼續"標號）是而言對個例敏感的，對引用字符串的期望-擴展而言是對個例不敏感的。

期望機制是逐站進行的：即HTTP/1。1代理服務器在無法滿足請求期望時必須.回送417（期望失敗）狀態。 然而，期望請求報頭本身卻是端到端的；它必須隨請求一起轉發。

許多舊版的HTTP/1。0和HTTP/1。1應用程序不理解期望報頭。

參見8。2。3節中100（繼續）狀態的使用。

14．21 過期（Expire）

"過期"實體報頭域給出了在何日何時之後應答即被視爲陳舊。除非首先經原服務器（或含有此實體較新拷貝的中介代理服務器緩存）確認爲有效，緩存一般不會返回陳舊的緩存目錄值。 請參見13。2節中對過期模型的深入論述。

其格式爲由3。3。1節中HTTP-日期定義的絕對日期與時間； 它必須遵照RFC 1123的日期格式：

過期="過期""：" HTTP-日期

使用示例爲：

過期： 星期四，1994年12月1日， 16：00：00 格林威治時間

注：若應答包含填有最大時限謂詞（參見14。9。3節）的緩存-控制域，則謂詞作用覆蓋過期域。

HTTP/1。1客戶機和緩存必須把其它無效的，尤其是含有"0"值的日期格式按過去值（即"已經過期"）處理。

要將應答標爲"已經過期"，原服務器鬚髮送和日期報頭值相等的過期日期值。（參見13。2。4節的過期計算規則）

爲標記應答爲"永不過期"，原服務器鬚髮送過期日期晚於發送應答的時間一年左右的過期日期。HTTP/1。1服務器不應發送超過將來一年的過期日期。

對於原本不可被緩存的應答而言，除非緩存控制域中另有指定，否則

過期報頭域中填有將來的某一日期和時間值即是表明該應答允許緩存，

14．22 From
    From請求報頭域，如果給定的話，應該（SHOULD）包括控制請求用戶代理的人的互聯網E-MAIL地址。這個地址應該（SHOULD）是適用於機器的，就像在RFC 822 [9]裏定義的“mailbox"以及在RFC 1123 [8]修訂的：
  
    From   = "From" ":" mailbox
    例如：
          From: [email protected]

    報頭域可以（MAY）用作記錄日誌的目的和作爲認證無效或者多餘請求源的方法。他不應該（SHOULD NOT）用作不安全形式的訪問保護。這個域的解釋是請求正在爲某個給定的人執行，它承擔這個方法執行的責任。特別的，自動控制代理應該（SHOULD）包括這個域這樣一來如果接收端出現問題的話，對運行這個自動控制程序有責任的人能夠得到聯繫。

    這個域的互聯網E-MAIL地址可以（MAY）從發出請求的互聯網主機中分離出來。例如，當一個請求通過一個代理服務器是應該（SHOULD）使用原發出者的地址。

    客戶機不應該（SHOULD）發出沒有得到用戶批准的From域，因爲它可能和用戶的個人利益或者他們站點的安全政策衝突。強烈建議用戶在任何一次請求之前能夠取消，授權，和修改這個域的值。

14．23 主機（Host）
    主機（Host）請求報頭域說明了正在請求的資源的互聯網主機和端口號，就包括在用戶或者提交的資源指定的源URI中（一般是一個HTTP URL,就像在3.2.2部分描述的）。Host域的值必須（MUST）代表源URL給定的源網關或者服務器的授權命名。這允許源服務器或網關區分內部不明確的URL，例如單個IP地址上有多個主機域名的服務器的根“/”URL.
  
    Host = "Host" ":" host [ ":" port ] ; 3.2.2節

    一個沒有任何追蹤端口信息的“主機”暗示使用請求服務的缺省端口（例如，“80”對應HTTP URL）。例如，源服務器上對<http://www.w3.org/pub/WWW/>的請求將完全包括：
    
       GET /pub/WWW/ HTTP/1.1
       Host: www.w3.org

在所有的HTTP/1.1請求信息中客戶機必須（MUST）包括Host報頭域。如果被請求的URI不包括被請求服務的互聯網主機域名，那麼Host報頭域必須（MUST）是空值。

一個HTTP/1.1的代理服務器必須（MUST）確保它向前傳遞的任何報文確實包括代理服務器可識別的請求服務的適當的Host報頭域。所有基於互聯網的HTTP/1.1服務器必須（MUST）對任何缺少Host報頭域的HTTP/1.1請求報文響應狀態代碼400（壞的請求）。

見5.2和19.6.1.1節和主機關聯的其他請求。

14。24 If-Match
  
If-Match報頭域是用一種方法使得它是有條件的。由以前從源獲得的一個或更多實體的客戶機能夠校驗那些實體中的一個現在包括在If-Match報頭域的一系列聯合的實體標籤。實體標籤在3.11節定義。這種特徵的目的是允許用對報頭進行最少量處理的方法對高速緩存信息進行有效的修正。它也用來在更新請求時防止源的錯誤版本無意識的修改。作爲一種特殊情況，“*”匹配任何現有源的實體。

       If-Match = "If-Match" ":" ( "*" | 1#entity-tag )

如果任何一個實體標籤匹配在對類似GET請求的響應中返回的實體的實體標籤，或者如果給出“*”以及對那個源任何現存的實體，那麼服務器可以（MAY）在執行請求的方法就好像If-Match報頭域不存在一樣。

服務器必須（MUST）用功能強大的比較函數來比較在If-Match中的實體標籤。

如果沒有一個實體標籤匹配，或者給出了“*”而沒有現有的實體，服務器一定不要（MUST NOT)執行請求的方法，並且返回412響應（預處理失敗）。當客戶機希望防止更新的方法，例如PUT，修改自從客戶機上一次找到以後已經改變的源的時候，這種行爲是很有用的。

如果請求將會導致除2XX或412以外的任何狀態，沒有If-Match報頭域，那麼If-Match報頭必須（MUST）被忽略。

"If-Match: *" 的含義是當源服務器（或高速緩存，很可能使用Vary機制，見14.44節）選擇的表示法存在時，方法就應該被執行，並且當表示法不存在時，一定不要（MUST NOT）執行。

想要更新源的請求（例如PUT）可以（MAY）包括If-Match報頭域來發出信號如果相應於If-Match值的實體（單個實體標籤）不再是源的表示法請求方法應訂不能（MUST NOT）得到應用。這允許用戶表明如果源已經改變而他們不知道的話他們不希望請求成功。
例如：

       If-Match: "xyzzy"
       If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
       If-Match: *

既有If-Match報頭域又有If-None-Match或If-Modified-Since報頭域的請求的結果本規範沒有定義。

14．25 If-Modified-Since

    用一種方法使If-Modified-Since請求報頭域被用來使得如果請求的變量自從這個域說明的時間以來沒有被修改過，實體將不會從服務器返回；相反的，將返回304響應（沒有修改的）而沒有任何報文實體。

       If-Modified-Since = "If-Modified-Since" ":" HTTP-date

這個域的一個例子是：

       If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

    有If-Modified-Since報頭沒有Range報頭的GET方法請求只有如果自從If-Modified-Since 報頭給定的時間以來認證實體已經被修改過，它纔會被傳遞。決定這個的運算法則包括以下的情況：

        a）如果請求通常將會導致除狀態200之外的任何情況，或者如果傳遞的If-Modified-Since日期是無效的，響應和對正常的GET的響應完全一樣。比服務器現在的時間晚的日期是無效的。

        b）如果自從If-Modified-Since日期以來變量已經修改了，響應和對正常GET的完全一樣。

        c）如果自從一個有效的If-Modified-Since日期以來變量沒有修改過，服務器應該返回響應304（沒修改）。

    這種特徵的目的是允許用對頭部最小量的處理來有效的更新高速緩存的信息。

        註釋：Range請求報頭域修改了If-Modified-Since的含義；完整的詳細信息見 14.35。

        註釋：If-Modified-Since的時間是由服務器說明的，它的時鐘可能和客戶機的不同步。

        註釋：當處理一個If-Modified-Since報頭域的時候，一些服務器使用精確的比較函數而不是稍差的函數，來決定是否發送響應304（沒修改）。當給高速緩存確認發送If-Modified-Since報頭域時爲了得到最好的結果，建議客戶機只要可能就採用從先前Last-Modified 報頭域收到的精確日期字符串。

        註釋：如果客戶機在If-Modified-Since報頭域中用任意的日期代替從Last-Modified報頭得到的對同樣請求的日期，客戶機應該注意到這個日期是由服務器對時間的理解來解釋的事實。由於客戶機和服務器之間時間編碼的不同，客戶機應該考慮時鐘不同步和舍入的問題。這包括瞭如果在第一次請求的時間和後來請求的If-Modified-Since日期之間文檔已經改變而出現競爭的可能性，以及如果If-Modified-Since從客戶機得到的日期沒有得到服務器時鐘的修正而出現時鐘傾斜有關問題的可能性。由於網絡反應時間的原因客戶機和服務器之間對不同時間基準的修正是最佳的近似。

    既有If-Modified-Since報頭域又有If-Match或If-Unmodified-Since報頭域的請求的結果本規範沒有定義。

 

14．26 “如果不匹配”（If-None-Match）
        If-None-Match報頭區伴隨一種使其條件化的算法使用。一個已從源端獲得
實體的客戶可以校驗得出：這些實體沒有通過在If-None-Match報頭區標明相應實體
標籤而流通。此特徵的目的是達到最小代價的高效緩存信息刷新。它也可以防止一
些算法無意中修改客戶認爲不存在而實際存在的資源。

        作爲特殊情況，特徵值“*”匹配資源的任何當前實體。
       If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )


        如果任何實體標籤與將被用來回復GET請求的實體匹配，或給出“*”且
針對該資源的實體存在，則服務器不能執行被請求的算法，除非由於資源的修改
數據不能匹配If-Modified-Since報頭區提供的相應內容而被要求那樣做。
與之相反，如果請求算法是GET或HEAD，服務器應回覆304響應，包含有匹配實
體的緩存相關報頭區。所有其它算法，服務器必須回覆412狀態碼。


           13.3節說明怎樣判斷兩實體標籤匹配.弱比較函數只能用於GET或HEAD請求。
 
        如果沒有實體標籤匹配，則服務器將執行被請求的算法只當If-None-Match
報頭區不存在，但必須同時也忽略請求中的If-Modified-Since報頭區。即，如果沒
有實體標籤匹配則不能回覆304響應。
        如果沒有If-None-Match報頭區的請求最終回覆非2xx及304響應，則
If-None-Match報頭一定要被忽略。（見13.3.4）
    "If-None-Match: *"的意思是：當源服務器選擇的代表（representation）
存在時算法不可用而當七其存在時可用 此特徵在防止PUT操作的______時是有用
的.

   
     例:
       If-None-Match: "xyzzy"
       If-None-Match: W/"xyzzy"
       If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
       If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
       If-None-Match: *

           含有If-None-Match報頭區及If-Match或者If-Unmodified-Since（此後不可
修改）報頭區的請求結果在此說明中不做定義


14．27 If-Range
如果客戶機在其緩存中有實體的部分拷貝，並希望向緩存中添入整個實體的更新後拷貝，它可以在條件 GET（If-Unmodified-Since 和If-Match兩者兼用或只取其一）中使用範圍請求報頭域。然而，若由於實體已被修改而導致條件不滿足，客戶機就需要再次發出獲取當前整個實體正文的請求。

If-Range允許客戶機“攔截”第二次請求。 簡要說來，其含義爲“若實體未改變，請發送我缺少的部分給我；否則，發給我整個實體”。
若客戶機不具備實體的實體標籤，但有上次修改日期，它可以在If-Range報頭中使用此日期（服務器通過檢查一兩個字符即可區分合法HTTP日期與任意形式的實體標籤）。If-Range報頭應只和範圍報頭一起使用，且在請求不含範圍報頭或服務器不支持亞範圍操作時必須被忽略。
若If-Range報頭中給出的實體標籤於實體當前的實體標籤相吻合，則服務器應使用206（部分內容）應答來指明實體的亞範圍。 若實體標籤不相符，服務器應使用200（OK）應答返回整個實體。


14．28 If-Unmodified-Since
If-Unmodified-Since請求報頭域用來使某方法變爲條件的。若請求的資源在此域中指定的時間之後即未被修改，則服務器應按If-Unmodified-Since報頭不存在的方式執行所請求的操作。

若請求的變量在給定時間之後已被修改，則服務器不得執行所請求的操作，且必須返回412（前提條件不滿足）應答。
      If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-日期

   此域的應用實例:

       If-Unmodified-Since: 星期六, 1994年10月29日 19:43:31 格林威治時間

如果正常情況下（即沒有If-Unmodified-Since報頭時），請求會得到除了2xx與412狀態的結果，則If-Unmodified-Since報頭應被忽略。
若指定的日期無效，本域亦被忽略。
本說明未定義一個既有If-Unmodified-Since報頭，又有If-None-Match 或If-Modified-Since報頭的請求的結果。


14．29 上次修改
上次修改實體報頭域指明原服務器認爲的變量上次被修改的日期和時間。

上次修改="上次修改""："HTTP-日期

應用示例如下：

上次修改： 星期二， 1994年11月15日， 12：45：26 格林威治時間

此報頭域的確切含義取決於原服務器的處理和原資源的性質。 對文件而言，它可能僅僅指示文件系統上次修改時間。對動態包含各個部分的實體而言，它可能指的是其組成部分的上次修改值中最近的一個。 對數據庫網關而言，它可能就是記錄的上次更新時間戳。對虛擬對象而言，它可能是上次內部狀態改變的時間。

原服務器不得發送遲於服務器生成此報文時間的上次修改日期。 在這種情況下資源的上次修改意味着將來的某一時刻，服務器必須以報文生成日期取代之。

原服務器應儘量在靠近其生成應答日期值的時刻獲取上次修改值。 這樣接收者可以更準確的估計實體的修改時間，當實體在應答生成時間的前後有所改動時尤爲如此。

HTTP/1。1服務器應儘可能發送"上次修改"信息。

14．30 位置（Location）
除了應用於關於請求完成或新資源確認的請求,URI位置響應報頭域還用於使收件人重發到某個地址.對 201(Created)響應,位置是請求建立的新資源.對3xx響應.Location應當指出服務器的關於資源自動重定向的首選URI.該域的值由單個絕對的URI組成.
                      Location       = "Location" ":" absoluteURI
例如：

       Location: http://www.w3.org/pub/WWW/People.html

注: Content-Location報頭域(14.14節)不同於Location, Content-Location定義了請求附屬實體的源地址.因此響應有可能既有Location報頭域,也有Content-Location報頭域.看13.10節一些方法的緩存需求.

14．31 最大前向(Max-Forwards)
最大前向請求頭域提供一種帶有TRACE(9.8節)和OPTION(9.2節)方法的機制以限制那些能夠向下一個本地服務器轉送請求的代理或網關.當客戶嘗試跟蹤一個似乎失敗或在中間鏈循環的請求鏈時,這一點十分有用.
       Max-Forwards   = "Max-Forwards" ":" 1*DIGIT

最大前向值是一個表示剩餘的請求轉送時間的十進制整數.

每個代理或網關接受包含最大前向頭域的TRACE或OPTION請求時必須在轉送請求前　Copyright  www.cnpaf.net (2007).          All Rights Reserved.
檢查和修正它的值.如果接收到的值是zero(0),接收者一定不能轉送這個請求;相反,它必須像最終接收者一樣響應.如果接收到的最大前向值大於0,轉送的消息必須包含一個經過修正的最大前向域,其域值減一.

對本說明書定義的所有其它方法以及任何沒有明確將它歸作定義的一部分的擴展方法,最大前向頭域可以被忽略.

14．32 實用(Pragma)

   實用常規頭域被用來包含特殊的執行指令，它可沿請求/接受鏈應用於任何接收端。從協議的觀點所有的實用指示了詳細的可選行爲；不管怎樣，一些系統可以被要求那些行爲與指示的相一致。

            Pragma                ="pargma"":"1#pragma-directive
            Pragma-directive         ="no-cache"|extension-pragma
            Extension-pragma        =token["="(token|quoted-dtring)]

當一個非緩存的指示出現在請求的消息中，應用程序必須跟隨這個原服務器的請求，甚至這是個正在被請求的緩存的複製。這個實用的指示的語義和非緩存指示（14。9節）一致，他的定義是爲了和http/1.0保持一致。當一個非緩存的請求被送到一個不知道是否支持http/1.1的服務器，客戶端必須包括兩個頭域。

使用指示必須被代理和網關應用程序過，不管對於那些應用程序有沒有意義。因爲這些指令可以被請求/應答鏈上的所有接受者應用。不可能爲一個特殊的接收者定義一個實用，然而，實用指示必須被不相關的接收者忽略。

  HTTP/1.1高速緩衝器必須把"Pragma：no_cache"當作客戶端發送了"cache_control:no-cache".在http中不會有新的指令定義。

     注意：因爲Pragma: no-cache的意思並沒有作爲應答的頭域在十幾種定義，他不提供可靠的應答中Cache-Control: no-cache的替代。
14．33 代理認證(Proxy-Authenticate)
代理認證的響應頭域必須是407響應的一部分.這個域的值由表示認證方案的複雜問題和應用於這個請求URI的代理的參數組成.
       Proxy-Authenticate  = "Proxy-Authenticate" ":" 1#challenge

HTTP訪問認證進程如"HTTP認證:基本和分類訪問認證"[43]所描述.與www認證不同,代理認證的頭域僅僅應用於當前連接,不應該轉到下游客戶.但是,中間代理可能需要向下遊客戶請求獲得它自己的證書,有時候看起來這好像代理在轉送代理認證頭域.

14．34 代理授權
代理授權的請求頭域允許客戶將它自己(或的使用者)看作和需要認證的代理一樣.代理授權的域值由包含用戶代理對代理服務器的授權信息和正在被請求的資源界組成. [譯者注]realm:數據庫中的一種邏輯子域，它包含了有約定的數據的聚集的全部(具體)值.
       Proxy-Authorization     = "Proxy-Authorization" ":" credentials

HTTP訪問認證進程如"HTTP認證:基本和分類訪問認證"[43]所描述.與授權不同,代理授權的頭域僅僅應用於下一個需要認證的外地代理,用的是代理認證域.當多個代理在鏈中使用時,代理授權的頭域由第一個期待收到證書的外地代理消耗.代理可以從客戶請求向下一個代理轉發證書,如果那是代理協同認證給定請求的機制.

14．35 範圍
14.35.1 字節範圍
既然所有的HTTP實體都以字節序列形式的HTTP消息表示,字節範圍的概念對任何HTTP實體都是有意義的.(不過並不是所有的客戶和服務器都需要支持字節範圍操作.

HTTP裏字節範圍的詳述應用於實體正文(不必和消息體一樣)的字節序列.

一個字節範圍操作可以確定字節的單一範圍,或一個單一實體裏的一組範圍.

       ranges-specifier = byte-ranges-specifier
       byte-ranges-specifier = bytes-unit "=" byte-range-set
       byte-range-set  = 1#( byte-range-spec | suffix-byte-range-spec )
       byte-range-spec = first-byte-pos "-" [last-byte-pos]
       first-byte-pos  = 1*DIGIT
       last-byte-pos   = 1*DIGIT

Byte-range-spec裏的First-byte-pos值給出了一個範圍裏第一個字節的偏移量.
last-byte-pos值給出了這個範圍裏最後一個字節的偏移量;也就是說,確定的字節位置包含在內.字節偏移量初始值爲零.
如果存在last-byte-pos值,它一定大於或等於那個byte-range-spec裏的
first-byte-pos,否則byte-range-spec在句法上是非法的.接收者收到包括一個或更多句法非法的byte-range-spec值的byte-range-set時必須忽略包括那個byte-range-set的頭域.

如果last-byte-pos值不存在,或者大於或等於實體正文的當前長度,則認爲
last-byte-pos等同於一個字節數少於實體正文當前長度的last-byte-pos.

通過選擇last-byte-pos,客戶能夠限制檢索字節的數量而不必知道實體的大小.

suffix-byte-range-spec用來表示實體正文的後綴,其長度由後綴長度值給出.(也就是說,這種形式規定了實體正文的最後N個字節.)如果實體短於確定的後綴長度,則使用整個實體正文.

如果一個句法正確的byte-range-set至少包括一個這樣的byte-range-spec:它的
first-byte-pos比實體正文的當前長度小,或至少包括一個後綴長度非零的
suffix-byte-range-spec,那麼byte-range-set是可以滿足的.否則是不可滿足的.

如果byte-range-set是不可滿足的,服務器應該返回一個帶有206狀態(局部內容)的響應,其中包括實體正文的可滿足範圍.
byte-ranges-specifier(字節-範圍-說明符)值的例子(假定實體正文長度爲10000):

-- 第一個500字節(字節偏移量0-499,包括0和499):
bytes=0-499

-- 第二個500字節(字節偏移量500-999,包括500和999):
bytes=500-999

-- 最後500字節(字節偏移量9500-9999,包括9500和9999):
      bytes=-500 或 bytes=9500-

-- 僅僅第一個和最後一個字節(字節0和9999):
bytes=0-0,-1

-- 關於第二個500字節(字節偏移量500-999,包括500和999)的幾種合法但不規範的敘述:
         bytes=500-600,601-999
         bytes=500-700,601-999

14.35.2 範圍檢索請求
HTTP檢索請求使用有條件或無條件GET方法,可以利用範圍請求頭來請求實體的一個或更多子範圍而不是整個實體,範圍請求頭部應用於作爲請求結果返回的實體.

     Range = "Range" ":" ranges-specifier

服務器可以忽落範圍頭.但是,HTTP/1.1源服務器和中間高速緩存應該在可能的時候支持字節範圍,既然範圍支持部分失敗傳輸的有效恢復,並且支持對大實體的部分檢索.

如果服務器支持範圍頭和確定的範圍,或範圍對實體是合適的:

-- 如果GET是以別的方式成功的,無條件GET裏範圍頭的存在修改返回的東西.換句話說,響應攜帶的是狀態代碼206(部分內容)而不是200(好).

-- 如果GET以別的方式成功且條件爲真,有條件GET(一種使用If-Modified-Since和If-None-Match二者之一或全部,或者If -Unmodified-Since和If-Match二者之一或全部的請求)裏範圍頭的存在修改返回的東西.它並不影響返回的304(未修改)響應,如果條件爲假.

某些情形下,使用Range header(範圍頭)輔以If-Range header(假設範圍頭)可能更合適.

如果支持範圍的代理收到範圍請求,將請求轉發到本地服務器,以及收到回覆的整個實體,它應該只把請求的範圍返回給客戶.它應該將接收到的整個響應存儲在高速緩存中,如果這跟它的高速緩存分配方針一致的話.

14．36 參考者（Referer）
參考者（Referer）請求頭域允許客戶確定獲得請求URI的資源地址(URI)-爲了服務器的利益.Referer請求頭允許服務器生成關於到資源的反向連接(back-link)的列表,爲了興趣,記錄,優化的高速緩存等等.它也允許追蹤過時的或錯誤類型的連接(link)以便維護.如果請求URI是從一個沒有自己的URI的源獲得的,如從使用者鍵盤的輸入,那麼一定不要發送Referer域.

       Referer        = "Referer" ":" ( absoluteURI | relativeURI )

  例如:

       Referer: http://www.w3.org/hypertext/DataSources/Overview.html

如果域值是相對URI,它應該理解爲與請求URI相關.URI一定不能包括片斷.安全考慮請參看15.1.3節.

14．37 稍後重試
稍後重試應答報頭域可以和503（服務不可達）應答一起使用，以指示服務對於發出請求的客戶機而言預計有多久不可達。本域也可與任何3xx（重新定向）應答一起用於指示用戶代理在重定向請求前被要求等待的最小時間。本域的值可以是應答時間只有的HTTP-日期或整值的秒數（十進制）。

稍後重試=“稍後重試”“：”（HTTP-日期|delta-秒）

應用的例子有二：

稍後重試：星期五，1999年12月31 23:59:59 格林威治時間
稍後重試：120

在後一例中，延遲時間爲2分鐘。

14．38 服務器

服務器應答報頭域包含了原服務器用於處理請求的軟件信息。 此域可包含多個產品標記（3。8節），以及鑑別服務器與其他重要亞產品的註釋。產品標記按它們對於鑑別應用程序的重要性的順序排列。
服務器=“服務器”：“1*（產品|註釋）
例：

服務器：CERN/3。0 libwww/2.17

若應答是通過代理服務器轉發的，則代理程序不得修改服務器應答報頭域。作爲替代，它應添入路由（Via）報頭（如14。45節定義）。
注：揭示特定的軟件版本可能會使服務器易於受到那些針對已知的軟件安全漏洞的攻擊。 建議服務器實現者將此域作爲可設置項。

14．39 TE
TE請求報頭域指明瞭它願意從應答中接收哪種擴展傳輸編碼以及是否願接收成塊傳輸-代碼中的trailer域。其值可由關鍵字“trailers”，由逗號隔開的含可選接收參數的擴展傳輸-代碼列表組成。

       TE        = "TE" ":" #( t-codings )
       t-codings = "trailers" | (傳輸-擴展 [接收-參數 ] )
關鍵字“trailers”的存在表明客戶機願意接收如3。6。1節中定義的成塊傳輸-代碼中的trailer域。 此關鍵字爲傳輸-代碼值而保留，但它本身不代表一種傳輸-代碼。
應用舉例：
       TE: deflate
       TE:
       TE: trailers, deflate;q=0.5
TE報頭域僅適用於立即連接。所以無論何時HTTP/1。1消息中有TE，連接報頭域（參見14。10節）中就必須提供關鍵字。
服務器利用下述規則，依據TE域來裁定傳輸-代碼是否可被接受：

如果關鍵字“trailers”在列，則成塊傳輸-代碼總被接受。 客戶機已代表它自己與下游客戶機指出願接受成塊應答中的trailer域。這意味着，可能的話，客戶機正申明要麼所有下游客戶機都願接收轉發應答中的trailer域，要麼它將試圖代表下游接收者暫存應答。
注：HTTP/1。1並未定義任何限制塊狀應答大小，以保證客戶機能夠暫存整個應答的方法，
若被檢驗的傳輸-代碼在TE域中有列出，它就可被接受，除非伴有qvalue爲0值（如3。9節定義， qvalue 的0值表示“不可接受”）。
若多個傳輸-代碼都是可接受的，則可接受傳輸-代碼中qvalue值最高者優先。 “成塊”傳輸-代碼的qvalue值總是1。
若TE報頭域爲空，或沒有TE報頭域，則僅有的傳輸-代碼是“成塊”。 無傳輸-代碼的報文總是可接受的。


14．40 追蹤者（Trailer）
Trailer常規域值指示在trailer消息中有給定的頭域設置，此消息用成塊傳輸編碼編碼的。

                  Trailer  = "Trailer" ":" 1#field-name

一個http/1.1消息使用成塊傳輸編碼時要包括一個trailer頭域，且其不能爲空。這樣才能讓接收者知道trailer中期望得到哪個頭域。
  如果沒有trailer頭域存在，trailer不能包括任何頭域。在成塊傳輸編碼中用到的trailer域的限制看3。6。1節。
  Trailer頭域中列出的消息頭域必須不能包括下面的頭域：

   傳輸編碼
   內容長度
   Trailer

14．41 傳輸-編碼

   傳輸-編碼常規頭域指出爲了在發送者和接收者之間安全的傳輸而應用了什麼樣類型的轉換。它不同於內容代碼，傳輸代碼是消息而不是實體的屬性。

       Transfer-Encoding       = "Transfer-Encoding" ":" 1#transfer-coding

  傳輸代碼在3。6節中被定義了。一個例子是：

         Transfer-Encoding: chunked

   如果一個實體應用了多種編碼，傳輸代碼必須順序列出應用的編碼。關於代碼參數的額外信息有其他的實體頭域指定。許多舊的http/1.0應用程序不懂傳輸編碼頭。

14．42 升級(Upgrade)

   升級頭域允許客戶端指定它支持什麼樣的附加傳輸協議並想使用如果服務器發現選擇這種協議是恰當的話。服務器必須用101（選擇協議）升級頭域來指示要選擇那個協議。

   Upgrade        = "Upgrade" ":" 1#product

舉個例子：

   Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
升級頭域被用來規定一種簡單的機制從http/q.q過渡到其他不同性質的協議。它允許客戶發出它期望使用另一個協議，比如說稍後的更高版本的http協議，甚至當前的請求已經使用了http/1.1協議。通過允許客戶端發出一個用更普通的協議的請求來指示服務器它想用更好的協議（這兒得更好的由服務器決定，可能是按照方法的自然性或被請求的資源）它減輕了兩個不同性質的協議之間傳輸的困難。

  升級頭域只被用來從存在的傳輸層協議之上選擇應用層協議。升級不能被用來強迫一個協議的改變；它的接受和使用是由服務器自由決定的。協議變換後應用層的通訊的性能和本性是由新選擇的協議決定的，雖然改變協議以後的第一個動作是包含升級頭域的原來http請求的應答。

  升級頭域只應用於直接連接，因此無論升級出現在http/1.1消息的是什麼時候，升級的關鍵字都必須應用於連接的頭域中。

  升級頭域不能被用來指示選擇不同連接中的協議。爲這個目的，使用301，302，303重定位應答更合適。

  這個規範着定義了http協議的名字，它被在3。1節的http版本規則中定義的超文本傳輸協議家族使用。任何一個記號都可被用來做協議名字，然而，只有當客戶端和服務器用同一個協議關聯時纔有用。

14．43 用戶代理
  用戶代理請求頭包括髮出請求的用戶代理的信息。這是爲了統計學的目的，跟蹤違反協議，爲了因特定用戶代理的限制製作對應響應而自動識別用戶代理。用戶代理必須在請求中包括這個域。這個域包括多個指明代理和構成代理的重要組件的產品標記和元素。按慣例，這些產品標記按指明應用程序的重要性的順序排列。

      User-Agent     = "User-Agent" ":" 1*( product | comment )

例子:

       User-Agent: CERN-LineMode/2.15 libwww/2.17b3

14．44 更正(Vary)
  更正頭域是在響應開始的時候變更完全接收的請求頭域設置，而不管高速緩存是否允許用響應回覆後續的請求。對於非高速緩存或者舊的響應，更正頭域值建議用戶代理用來選擇請求的標準。

  一個爲“*”的更正域意味着高速緩存不能根據後來的請求的請求頭判斷而不管這個請求是否是恰當請求。高速緩存對更正頭域的用法間13。6節。

   Vary  = "Vary" ":" ( "*" | 1#field-name )

  一個HTTP/1.1的服務器的任何能緩存的響應必須包括一個更正頭域，這是服務器驅動商議的科目。這樣做高速緩存呢能恰當的解釋下一個關於那個資源的請求同時通知用戶代理需要對那個資源商議。一個服務器可以在非緩存的響應中包括更正頭域，這是服務器驅動商議的科目，既然這可以提供用戶代理在響應的時候響應的變化的有用信息。

  一個更正頭域由一張頭域的表組成，響應按一個選擇的法則從其中選出，這個法則在選擇最恰當的響應的時候只考慮列出的請求頭域。一個高速緩存會假定下一個請求的選擇會和列出的頭域的值一樣。

  此給定頭域的名字不受這個說明書定義的標準請求頭域的規範所限制。域名是對緩存不敏感的。

  一個值爲沒有定義的“*”表明對請求頭沒有限制（例如，網絡客戶端的地址），作爲選擇響應表述的規則。“*”值一定不能由代理服務器產生；它只可以由源服務器產生。

14．45 路由（Via）

  路有常規頭域必須被網關和代理服務起來指示中間的協議和關於請求的使用者和服務器之間的接收者及應答的原服務器和
客戶端的接收者。它類似於RFC 822[9]的接收域，被用來跟蹤消息的去向，避免請求循環，及識別沿請求/應答鏈個發送者協議的性能。

      Via =  "Via" ":" 1#( received-protocol received-by [ comment ] )
      received-protocol = [ protocol-name "/" ] protocol-version
      protocol-name     = token
      protocol-version  = token
      received-by       = ( host [ ":" port ] ) | pseudonym
      pseudonym         = token

  接收協議指出沿請求/應答鏈的每一段後被服務器或客戶端接收到的消息的版本。接收協議的版本被加到路由域值中，因此對於所有的接收者來說以前的所有應用程序的協議能力的信息都保留了。

  協議的名字是可以選擇的，只要也只有它是HTTP。接收到的域一般是通常的主機和接收服務器或客戶端的可選擇的端口，然而，如果真實的主機考慮信息的敏感性，它可能會用假名代替，如果沒有指明端口，它被假設成接收協議的默認端口。
多重路由域值應答傳遞消息中的每一個代理或網關。每一個接收者必須添加上自己的信息，這樣結果依照傳遞的應用程序的順序範圍。

  路由頭域可能會使用註釋來識別接收的代理或網關的軟件，用戶代理和服務器頭域也是如此。然而，所有的路由頭域中的註釋是可選的，它可以被任何接收的代理服務器刪掉。

  舉個例子，一個http/1.0的用戶代理髮送一個叫fred的請求消息給國內的代理，它使用http/1.1來傳遞請求給在nowhere.com的公共代理，它把這個請求傳遞給在wwwlics.uci.edu的原服務器。這個請求被www.ics.uci.edu收到的時候應該有以下的路由頭域：

  Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

  代理和網關被作爲一個通過防火牆的入口，在默認情況下，它不能傳遞防火牆內的主機的名字和端口。這個信息只有在明確允許下才能傳播。如果不允許的話，任何在防火牆後面的主機將被用假名代替。

  對於那些要求很強的隱藏內部結構的需求的機構，一個代理可以把有順序的路由頭域和同樣的接收協議值組合在單個的條目中。舉個例子：

       Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
        可能退化爲
       Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

  應用程序不能把多個實體組合在一起除非他們都在同一個組織的控制之下同時主機已經用假名代替了。應用程序不能把不同接收協議值的實體組合在一起。

14．46 警告(Warning)

  警告常規頭域被用來傳遞沒有被回覆的消息的狀態或轉變的信息。這個消息典型的應用是來警告一個消息實體正文的緩存操作或轉換缺乏語義的透明性。

  應答時警告頭域按以下格式發送：
       Warning    = "Warning" ":" 1#warning-value

       warning-value = warn-code SP warn-agent SP warn-text
                                             [SP warn-date]

       warn-code  = 3DIGIT
       warn-agent = ( host [ ":" port ] ) | pseudonym
                       ; the name or pseudonym of the server adding
                       ; the Warning header, for use in debugging
       warn-text  = quoted-string
       warn-date  = <"> HTTP-date <">

  警告文本必須使用自然語言，對於接收應答的使用人來說它基本上時可理解的。這個決定可以基於任何可利用的知識，比如說緩存或使用者的位置，請求中的接收語言域，應答中的內容語言域，等等。默認的語言是英語，默認的屬性設置是ISO-8859-1。

  如果屬性設置不是使用ISO-8859-1，它必須按RFC 2047[14]中描述的在警告文本中指明。

  警告頭一般能被應用於任何的消息，然而一些特殊的警告代碼對於高速緩存是特殊的，只能應用於應答消息。新的警告頭必須加到任何存在的警告頭的後面。一個高速緩存一定不能刪掉它接收到的消息的警告頭域。然而，如果高速緩存成功的使高速緩存條目有效，它能把符合條目的警告頭都刪掉除了那些特殊的警告代碼。它必須馬上把它接收到的警告頭域加到確認應答中。用其他華說，警告頭實那些能附加於最近大多數應答的應答。

  當多個警告頭附加於一個應答，用戶代理必須按應答中顯示的順序儘可能多的通知使用者。如果不能通知所有警告的擁護，用戶代理必須按這些HEURISTICS運作：

  -出現在應答中前面的警告從那些出現在後面手中接過優先權

  -符合用戶首選性質設置的警告從其它使用相同的警告代碼和警告代理但在其他性質設置的警告手中接過優先權。

  產生多個警告頭的系統必須按用戶代理的行爲排列它們。
  對於注意警告的高速緩存的行爲的要求在13。1。2節中規定。
  這是通常定義的警告代碼的列表，每一個有推薦的英語的警告文本和它意思的描述。

  110 應答遲緩
     當回覆應答遲緩的時候應用

  111 重新連接失敗
        當試圖重新連接失敗高速緩存返回一個遲緩應答，原因是服務器不可達。

  112 分離操作
        當高速緩存要有意從其它的網絡中分離一段時間。

  113 探索終止
           高速緩存要選擇保鮮的。生存期大於24小時，應答年齡大於24小時。

  199 混合警告
          警告文本可以包括只能給使用人看的信息。一個系統收到這樣的警告必須給使用者看而不能自動處理。

  214 轉變被應用了
          如果中間高速緩存或代理的任何應答的內容編碼（如在內容編碼頭中指定的）或媒體類型（如在內容類型頭指定的）或實體正文被改變了則這個警告必須被添加上去，除非這個警告代碼已經出現在應答中。
 
  299 持久混合警告
          警告文本可以包括只能給使用人看的信息。一個系統收到這樣的警告一定不能自動處理。

  如果一個實現用http/1.0或更低的版本發送了一個又一個或多個警告頭的消息，發送者必須包括和應答中匹配的每一個警告值和警告數據。

  如果一個實現收到一條報文，在這條報文中警告值包括一個警告數據，這個警告數據和行營中的數據值不同，那麼這個警告值必須在儲藏，傳遞或使用以前從這條消息中刪掉。這可防止錯誤儲存警告頭域）如果因爲這個原因所有的警告制度被刪掉了，則這個警告頭也應該被刪掉。

14．47 WWW-認證
401（未授權的）應答報文中必須含有WWW-認證應答報頭域。 域值至少包括一個指明瞭可應用於請求-URI的認證方案與參數的挑戰（challenge）.

WWW-認證=“WWW-認證”“：”1#挑戰

HTTP訪問認證過程在“HTTP認證：基本與摘要訪問認證”[43]中有所描述。
建議用戶代理尤其謹慎地解析WWW-認證域值，因爲它可能含多個挑戰，或在有多個WWW-認證報頭域的情況下挑戰內容本身即含有由逗號隔開的認證參數列表。

15．安全考慮

    這一部分是用來提醒程序開發人員，信息提供者，和HTTP/1.1中的安全限制的用戶這篇文檔所敘述的事情。雖然這個討論爲減少安全風險確實提供了一些建議，但是它並不包括所透露問題的最終解決方案。

15．1 個人信息

    HTTP的客戶機經常對大量的個人信息是敏感的（例如用戶的名字，域，郵件地址，口令，密匙等。），並且應當（SHOULD）非常小心地防止這些信息無意識地通過HTTP泄露到其他的主機。我們非常強烈地建議應該提供給用戶一個方便的界面來控制這種信息的分發，並且設計者和使用者在這方面應該特別注意。歷史告訴我們在這方面的錯誤經常引起嚴重的安全和/或者機要問題並導致出現對使用者的公司非常不利的公開的情況。

15.1.1服務器日誌信息的濫用

    服務器是處在存儲個人數據的位置上，這些數據是關於用戶的請求的,這些請求可以識別他們的閱讀習慣或者感興趣的主題。自然這種信息明顯是機要的並且在某些國家對它的處理是受限制的。使用HTTP協議提供數據的人們有責任確保這樣的材料不會在沒有得到任何公開結果確認的人允許的情況下被散佈出去。

15.1.2敏感信息的傳輸

    就像任何種類的數據傳輸協議一樣，HTTP不能控制被傳輸數據的內容，也沒有任何一種區分的方法來決定在任何給定請求的上下文中某個特別的信息片段的敏感性。因此，應用程序應該（SHOULD）提供給發佈信息的人儘可能多的對這個信息的控制能力。四個報頭域是值得在這段文字中特別提到的：Server，Via，Referer和 From。

    暴露服務器詳細的軟件版本信息可能會導致服務器因爲已知有安全漏洞的軟件而變得更易受到攻擊。開發人員應該（SHOULD）使Server報頭域是一個可配置的選項。
  
    作爲通過一個網絡防火牆的入口的代理服務器應該（SHOULD）對關於確認防火牆後面的主機的報頭信息的傳輸採取特別的防範。特別的，它們應當移走或者用清潔的版本代替，Via域在放火牆後面產生。

    Referer報頭允許學習的閱讀模式並且可以進行反向連接。雖然它非常有用，但是如果用戶的資料沒有從Referer包括的信息中分離出來的話它的能力就可能會被濫用。甚至當信息已經被移開，Referer報頭還是可能指示出一個不適於公開的私人文檔的URI。

    在From域發送的信息可能和用戶的個人利益或者他們站點的安全政策相牴觸，因此用戶如果不能使之失效，對其授權，和修改域的內容的話，它就不應該（SHOULD NOT）被傳輸。用戶必須（MUST）能夠按用戶的選擇或者應用程序的缺省配置設置這個域的內容。

    雖然並不是必須的，我們建議向用戶提供一個可以選擇允許或者禁止From和Referer信息的發送的方便捆綁界面。

    用戶代理（14.43節）或者服務器（14.38節）的報頭域有時候會被用來判斷某個特定的客戶機或者服務器有一個可以被利用的特別的安全漏洞。不幸的是同樣的信息經常被用作其它有價值的目的因爲HTTP現在沒有更好的機制。

15.1.3 URI中敏感信息的編碼

    因爲一個連接的源地址可能是機要的信息或者可能會暴露另外一個機要的信息源，所以強烈推薦用戶能夠選擇是否發送Referer域。例如，一個瀏覽器的用戶能夠有一個捆綁的選擇是公開/匿名瀏覽，這將會分別允許/禁止Referer和From信息的發送。

    如果目標頁使用安全的協議傳輸的話，在一個（不安全）HTTP請求中客戶機不應該（SHOULD NOT）包括一個Referer報頭域。

    使用HTTP協議的服務提供者不應該（SHOULD NOT）使用基於使敏感數據屈服的形式的GET命令，因爲這將導致在Request-URI中編碼這個數據。許多現有的服務器，代理服務器，和用戶代理將把請求URI日誌記錄在某個第三方可以看見的地方。服務器可以用基於屈服形式的POST代替。

15.1.4連接到Accept報頭的機要問題

    接受request-header可能暴露關於用戶可以進入的所有服務器的信息。特別的Accept-language報頭可能暴露用戶個人的民族，因爲對特殊語言的理解對特殊的同文化的民族的成員經常有很強的相關性。提供在每個請求中配置發送的Accept-language報頭的選項的用戶代理被堅定的鼓勵讓配置過程包括讓用戶明白有關機要泄露的信息。

    對於用戶代理來說一種限制機要泄露的方法是在缺省的情況下忽略發送Accept-language包頭，並且如果通過尋找任何由服務器發出的變化的 response-header域，發現這樣的發送能夠提高服務的質量，就詢問用戶是否向服務器發送Accept-language報頭。

    在每個request中發送的爲用戶精心製作的accept報頭域，特別如果這些包括質量價值，能夠被服務器用作相關地可信賴的和長久的用戶標識符。這樣的用戶標識符將會允許內容提供者進行單擊軌跡跟蹤以及允許合作的內容提供者匹配交叉服務器單擊軌跡或者形成單個用戶的屈從。注意對於許多並不在代理服務器後面的用戶，運行用戶代理的主機的網絡地址也將作爲長久用戶的標識符。在代理服務器被用作增強保密的環境裏，用戶代理在提供給終端用戶accept報頭配置選項上應該是保守的。作爲一個保密的極端措施，代理服務器應該在轉發請求信息的時候過濾accept報頭。提供高度報頭配置能力的一般用途的用戶代理應該（SHOULD）警告用戶可能涉及的機要泄漏。

15．2 基於文件和路徑名稱的攻擊

    實現HTTP的原服務器應該（SHOULD）小心地限制由HTTP請求返回的文檔僅僅是那些服務器管理員授權設置的。如果HTTP服務器直接把HTTP URIs翻譯成文件的系統名稱，服務器必須（MUST）特別注意不要提供沒有授權發佈給HTTP客戶的文件。例如UNIX，微軟Windows，和其它操作系統使用".."作爲指示當前目錄的上一層的路徑的一部分。在這樣一個系統中，如果不允許通過HTTP服務器訪問那些除授權允許訪問以外的資源的話， HTTP服務器就必須（MUST）禁止在Request-URI中任何這樣的結構。同樣的，必須（MUST）保護認爲僅僅涉及服務器內部的文件（例如訪問控制文件，配置文件，和劇本代碼）不要被不適當的獲取，因爲它們可能包含敏感信息。經驗表明在HTTP服務器這樣的使用中次要的bug已經轉變爲威脅安全的風險。

15．3 DNS欺騙

    客戶使用HTTP嚴重依賴於域名服務，因此一般傾向基於故意不相關的IP地址和DNS名稱的安全攻擊。客戶需要在假定一個IP號/DNS名稱關聯繼續合法時謹慎。

    特別的，HTTP客戶對於一個IP號/DNS名稱關聯的確認應該（SHOULD）依靠對它們名字的解析，而不是存在高速緩存中以前主機名解析查找的結果。在適當的時候並且他們應該（SHOULD）被設置成這樣做的時候，許多論壇已經能夠在本地用高速緩存存儲主機名。只有當域名服務器報告的TTL（現在時刻）信息使高速緩存裏的信息很可能仍然是有用的時候，對這些高速緩存的查詢纔是適當的。

    如果HTTP客戶爲了達到提高性能的目的把查詢到的主機名結果存在高速緩存中，他們必須（MUST）遵守域名服務器報告的TTL信息。

    如果HTTP客戶不遵守這個規則，在一個以前訪問過的服務器的IP地址改變的時候他們就會被欺騙。在網絡重新編號被認爲變得日益普遍的時候，這種形式的攻擊的可能性將會增大。遵守這個必要條件將會因此減少這種潛在的安全隱患。

    這個必要條件也改進了客戶機對使用同樣域名的鏡像服務器的平衡加載行爲並且減少了用戶訪問使用這種策略的站點經歷失敗的可能性。

15．4 Location（位置）報頭和欺騙

    如果單個的服務器支持互不信任的多個組織，那麼它必須（MUST）檢查在自稱的某個組織控制下產生的應答信息中Location和Content-Location報頭的值以確認他們沒有企圖使他們沒有權限的資源無效。

15．5 內容傾向問題（Content-Disposition Issues）
    RFC 1806 [35]，在HTTP中經常使用的Content-Disposition（見19.5.1節)報頭就源於此，有許多非常認真的安全考慮。Content-Disposition並不是HTTP標準版本中的一部分，但自從它被廣泛應用以來，我們正在證明它對使用者的價值和風險。詳細資料見RFC 2183 [49]（對RFC 1806的升級）。

15．6 鑑定證書和空閒的客戶機

    現有的HTTP客戶機和用戶代理有代表性地不確定地保留鑑定信息。HTTP/1.1沒有提供一個從服務器到直接的客戶機的方法來丟棄這些保存在高速緩存裏的證書。這是一個重大的需要對HTTP做進一步擴展的的缺點。在高速緩存裏的證書可能干擾應用程序的安全模式的情況包括但不只限於：

    --客戶機已經空閒了很長時間，然後服務器可能希望引起客戶機再一次出示用戶的證書。

    --應用程序包括了一個進程中斷的指令（例如在一頁上有"logout"或者"commit"的按鈕），在此之後應用程序的服務器方面"知道"客戶機沒有進一步的理由保留證書。

    這是當前分散考慮的情況下。這個問題的各部分有許多的工作區，我們鼓勵在屏保程序中使用密碼保護，空閒暫停，以及其它在這個問題中減輕固有安全問題的方法。特別的，在高速緩存中保存證書的用戶代理被鼓勵提供一個在用戶控制下丟棄保存在高速緩存中的證書的可以容易訪問的機制。

15．7 代理服務器和高速緩存

    HTTP代理是中間人，並且扮演一個"中間者"攻擊的目標。代理運行系統的妥協可能導致嚴重的安全和保密問題。代理有權訪問與安全相關的信息，關於個人用戶和組織的私人信息，屬於用戶和內容提供者的所有權信息。一個不安全的代理，或者一個使用或配置沒有注意安全和保密考慮的代理，可能被用作廣泛的潛在攻擊的代理。

    代理服務器的管理員應當保護代理服務器上運行的系統就像他們保護包括或者傳遞敏感信息的任何系統一樣。特別的，在代理上聚集的日誌信息經常包括高度敏感的個人信息，和/或者關於組織的信息。日誌信息應該被小心地保護，並且對發展的和接下來的使用持適當的指導方針。(15.1.1節)

    高速緩存代理給其它潛在的攻擊提供了機會，因爲高速緩存的內容對於惡意利用是一個有吸引力的目標。因爲當一個HTTP請求完成以後高速緩存的內容仍然存在，對高速緩存的攻擊能揭示很早以前用戶就認爲已經從網絡上移走的信息。因此，高速緩存的內容應該當作敏感信息保護。

    代理服務器的設計者應當考慮他們的設計和編碼的制定，以及他們提供給代理服務器操作人員的配置選項（尤其是缺省配置）所牽涉到的保密和安全問題。

    代理服務器的用戶必須明白他們並不比管理代理服務器的人更值得信任；HTTP自己不能解決這個問題。

    在適當的時候明智的使用密碼系統可以提供足夠的保護免遭廣泛的針對安全和保密的攻擊。這種密碼系統超出了HTTP/1.1規範的範圍。

15.7.1 對代理服務器的拒絕服務攻擊

    它們是存在的。它們很難防禦。研究在繼續。當心。

16 感謝（Acknowledgment)

    這份規範大量使用了擴展BNF和David爲RFC 822 [9]定義的類的結構。同樣的，它繼續使用了很多Nathaniel Borenestein和Ned Freed爲MIME [7]提供的定義。我們希望在這份規範裏它們包含的內容有助於減少過去在HTTP和互聯網郵件消息格式關係上的混亂。

    HTTP協議在這幾年已經有了相當的發展。它受益域大量積極的開發人員的團體--許多人已經通過利用郵件列表的萬維網交談來分擔工作--並且通常就是團體對HTTP和萬維網的成功負擔了其中大多數的責任。 Marc Andreessen, Robert  Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois Groff , Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett, Tony Sanders, 和 Marc VanHeyningen因爲他們在定義協議早期方面的貢獻應該得到特別的讚譽。

    這篇文檔從所有那些分擔HTTP-WG的人員的註釋中獲得了很大的益處。除了已經提到的那些人以外，下列人士對這個規範做出了貢獻：
       Gary Adams                  Ross Patterson
       Harald Tveit Alvestrand     Albert Lunde
       Keith Ball                  John C. Mallery
       Brian Behlendorf            Jean-Philippe Martin-Flatin
       Paul Burchard               Mitra
       Maurizio Codogno            David Morris
       Mike Cowlishaw              Gavin Nicol
       Roman Czyborra              Bill Perry
       Michael A. Dolan            Jeffrey Perry
       David J. Fiander            Scott Powers
       Alan Freier                 Owen Rees
       Marc Hedlund                Luigi Rizzo
       Greg Herlihy                David Robinson
       Koen Holtman                Marc Salomon
       Alex Hopmann                Rich Salz
       Bob Jernigan                Allan M. Schiffman
       Shel Kaphan                 Jim Seidman
       Rohit Khare                 Chuck Shotton
       John Klensin                Eric W. Sink
       Martijn Koster              Simon E. Spero
       Alexei Kosut                Richard N. Taylor
       David M. Kristol            Robert S. Thau
       Daniel LaLiberte            Bill (BearHeart) Weinman
       Ben Laurie                  Francois Yergeau
       Paul J. Leach               Mary Ellen Zurko
       Daniel DuBois               Josh Cohen

    高速緩存設計的許多內容和介紹應歸於一下人士的建議和註釋：Shel Kaphan,
Paul Leach, Koen Holtman, David Morris, 和 Larry Masinter。

    大部分規範的範圍是基於Ari Luotonen和John Franks早期做的工作，以及從Steve Zilles另外加入的內容。

    感謝Palo Alto的"cave men"。你們知道你們是誰。

    Jim Gettys（這篇文檔現在的編者）特別希望感謝Roy Fielding，這篇文檔以前的編者，連同John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, 和Larry Masinter一起感謝他們的幫助。還要特別感謝Jeff Mogul和Scott Lawrence對"MUST/MAY/  SHOULD"使用的檢查。

    Apache組，Anselm Baird-Smith，Jigsaw的作者，和Henrik Frystyk在早期實現了RFC 2068，我們希望感謝他們發現了許多這篇文檔嘗試糾正的問題。

17 參考資料 (Reference)

   [1] Alvestrand, H., "Tags for the Identification of Languages", RFC
       1766, March 1995.

   [2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,
       D. and B. Alberti, "The Internet Gopher Protocol (a distributed
       document search and retrieval protocol)", RFC 1436, March 1993.

   [3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC
       1630, June 1994.

   [4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
       Locators (URL)", RFC 1738, December 1994.

   [5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
       2.0", RFC 1866, November 1995.

   [6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer
       Protocol -- HTTP/1.0", RFC 1945, May 1996.

   [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
       Extensions (MIME) Part One: Format of Internet Message Bodies",
       RFC 2045, November 1996.

   [8] Braden, R., "Requirements for Internet Hosts -- Communication
       Layers", STD 3, RFC 1123, October 1989.

   [9] Crocker, D., "Standard for The Format of ARPA Internet Text
       Messages", STD 11, RFC 822, August 1982.

   [10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
        Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype
        Functional Specification," (v1.5), Thinking Machines
        Corporation, April 1990.

   [11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808,
        June 1995.

   [12] Horton, M. and R. Adams, "Standard for Interchange of USENET
        Messages", RFC 1036, December 1987.

   [13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC
        977, February 1986.

   [14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
        Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
        November 1996.

   [15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC
        1867, November 1995.

   [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
        August 1982.

   [17] Postel, J., "Media Type Registration Procedure", RFC 1590,
        November 1996.

   [18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
        959, October 1985.

   [19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
        October 1994.

   [20] Sollins, K. and L. Masinter, "Functional Requirements for
        Uniform Resource Names", RFC 1737, December 1994.

   [21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for
        Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.

   [22] ISO-8859. International Standard -- Information Processing --
        8-bit Single-Byte Coded Graphic Character Sets --
        Part 1: Latin alphabet No. 1, ISO-8859-1:1987.
        Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.
        Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.
        Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.
        Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.
        Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.
        Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.
        Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.
        Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.

   [23] Meyers, J. and M. Rose, "The Content-MD5 Header Field", RFC
        1864, October 1995.

   [24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
        1900, February 1996.

   [25] Deutsch, P., "GZIP file format specification version 4.3", RFC
        1952, May 1996.

   [26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP
        Latency", Computer Networks and ISDN Systems, v. 28, pp. 25-35,
        Dec. 1995. Slightly revised version of paper in Proc. 2nd
        International WWW Conference '94: Mosaic and the Web, Oct. 1994,
        which is available at
        http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat
        ency.html.

   [27] Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTP
        Performance", http://www.isi.edu/touch/pubs/http-perf96/>,
        ISI Research Report ISI/RR-98-463, (original report dated Aug.
        1996), USC/Information Sciences Institute, August 1998.

   [28] Mills, D., "Network Time Protocol (Version 3) Specification,
        Implementation and Analysis", RFC 1305, March 1992.

   [29] Deutsch, P., "DEFLATE Compressed Data Format Specification
        version 1.3", RFC 1951, May 1996.

   [30] S. Spero, "Analysis of HTTP Performance Problems,"
        http://sunsite.unc.edu/mdma-release/http-prob.html.

   [31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format
        Specification version 3.3", RFC 1950, May 1996.

   [32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
        Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP:
        Digest Access Authentication", RFC 2069, January 1997.

   [33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
        Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
        2068, January 1997.

   [34] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [35] Troost, R. and Dorner, S., "Communicating Presentation
        Information in Internet Messages: The Content-Disposition
        Header", RFC 1806, June 1995.

   [36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and
        Interpretation of HTTP Version Numbers", RFC 2145, May 1997.
        [jg639]

   [37] Palme, J., "Common Internet Message Headers", RFC 2076, February
        1997. [jg640]

   [38] Yergeau, F., "UTF-8, a transformation format of Unicode and
        ISO-10646", RFC 2279, January 1998. [jg641]

   [39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E.,
        Lie, H., and C. Lilley. "Network Performance Effects of
        HTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, Cannes
        France, September 1997.[jg642]

   [40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part Two: Media Types", RFC 2046, November
        1996. [jg643]

   [41] Alvestrand, H., "IETF Policy on Character Sets and Languages",
        BCP 18, RFC 2277, January 1998. [jg644]

   [42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax and Semantics", RFC 2396,
        August 1998. [jg645]

   [43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
        Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP
        Authentication: Basic and Digest Access Authentication", RFC
        2617, June 1999. [jg646]

   [44] Luotonen, A., "Tunneling TCP based protocols through Web proxy
        servers," Work in Progress. [jg647]

   [45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of
        Aggregate Documents, such as HTML (MHTML)", RFC 2110, March
        1997.

   [46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
        9, RFC 2026, October 1996.

   [47] Masinter, L., "Hyper Text Coffee Pot Control Protocol
        (HTCPCP/1.0)", RFC 2324, 1 April 1998.

   [48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part Five: Conformance Criteria and Examples",
        RFC 2049, November 1996.

   [49] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation
        Information in Internet Messages: The Content-Disposition Header
        Field", RFC 2183, August 1997.
　Copyright  www.cnpaf.net (2007).          All Rights Reserved.


18 作者地址

   Roy T. Fielding
   Information and Computer Science
   University of California, Irvine
   Irvine, CA 92697-3425, USA

   Fax: [phone]
   EMail: [email protected]


   James Gettys
   World Wide Web Consortium
   MIT Laboratory for Computer Science
   545 Technology Square
   Cambridge, MA 02139, USA

   Fax: [phone]
   EMail: [email protected]


   Jeffrey C. Mogul
   Western Research Laboratory
   Compaq Computer Corporation
   250 University Avenue
   Palo Alto, California, 94305, USA

   EMail: [email protected]


   Henrik Frystyk Nielsen
   World Wide Web Consortium
   MIT Laboratory for Computer Science
   545 Technology Square
   Cambridge, MA 02139, USA

   Fax: [phone]
   EMail: [email protected]


   Larry Masinter
   Xerox Corporation
   3333 Coyote Hill Road
   Palo Alto, CA 94034, USA

   EMail: [email protected]


   Paul J. Leach
   Microsoft Corporation
   1 Microsoft Way
   Redmond, WA 98052, USA

   EMail: [email protected]


   Tim Berners-Lee
   Director, World Wide Web Consortium
   MIT Laboratory for Computer Science
   545 Technology Square
   Cambridge, MA 02139, USA

   Fax: [phone]
   EMail: [email protected]

19 附錄

19．1 互聯網媒介類型message/http和application/http

     這篇文檔除了定義HTTP/1.1協議外，還用作互聯網媒介類型"message/http"和"application/http"的規範。倘若message/http類型遵守MIME對所有 "message"類型關於路徑長度和編碼的限制，它就可以用來封裝單獨的HTTP請求和應答信息。application/http類型可以用來封裝一個或者更多HTTP請求或應答信息（非混合的）的傳輸路徑。下列是在IANA[17]註冊的。
      
        媒介類型名稱：    message
        媒介次類型名稱：  http
        必須參數：        無
        可選參數：        版本，信息類型
        版本：封裝信息的HTTP版本號（例如，"1.1"）。如果不存在，版本可以從報文的        第一行確定。
        信息類型：信息類型--"request"或者"response"。如果不存在，類型可以從報文的第一行確定。   
        編碼考慮：只有"7bit"，"8bit"，或者"二進制"是允許的。
        安全考慮：無

      
        媒介類型名稱：    application
        媒介次類型名稱：  http
        必須參數：        無
        可選參數：        版本，信息類型
        版本：封裝信息的HTTP版本號（例如，"1.1"）。如果不存在，版本可以從報文的第一行確定。
        信息類型：信息類型--"request"或者"response"。如果不存在，類型可以從報文的第一行確定。   
        編碼考慮：用這種類型封裝的HTTP信息是"二進制"的格式；當通過E-mail傳遞的時候一種合適的內容傳輸編碼是必須的。
        安全考慮：無       

19．2 互聯網媒介類型multipart/byteranges
     當一個HTTP206（部分內容）應答信息包括很大範圍的內容（對於大範圍非重疊的請求的應答），這些是作爲一個multipart信息報文傳的。這種用途的媒介類型被稱作"multipart/byteranges"。

    multipart/byteranges媒介類型包括兩個或者更多的部分，每一個都有自己內容類型和內容範圍的域。必需的分界參數指定了用來分開每個報文部分的分界字符串。

        媒介類型名稱：    multipart
        媒介次類型名稱：  byteranges
        必須參數：        boundary
        可選參數：        無
        編碼考慮：只有"7bit"，"8bit"，或者"二進制"是允許的。
        安全考慮：無       

    例如：
    HTTP/1.1 206部分內容
   Date: Wed, 15 Nov 1995 06:25:24 GMT
   Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
   Content-type:multipart/byteranges;boundary=THIS_STRING_SEPARATES

   --THIS_STRING_SEPARATES
   Content-type: application/pdf
   Content-range: bytes 500-999/8000

   ...第一部分...
   --THIS_STRING_SEPARATES
   Content-type: application/pdf
   Content-range: bytes 7000-7999/8000

   ...第二部分
   --THIS_STRING_SEPARATES--

   註解：
   1）附加的CRLFs在報文中可以優先於第一個分界字符串。
   2）雖然RFC 2046 [40]允許分界字符串被應用，但是一些現有的程序對引用的分界字符串會進行錯誤的處理。
   3）許多瀏覽器和服務器是按照使用multipart/x-byteranges媒介類型的byteranges規範的早期草案編碼的，這個草案總是但不完全和HTTP/1.1中描述的版本兼容。

19．3 寬容的應用程序 (Tolerent Applications)

     雖然這篇文檔列出了HTTP/1.1這一代消息所必須的元素，但是並不是所有的程序在實現的時候都是正確的。因此我們建議當偏差可以明確解釋的時候操作程序對這種偏差應該是寬容的。

    客戶機在分析狀態行的時候應該（SHOULD）是寬容的並且服務器在分析請求行的時候也是（應該）是寬容的。特別的，甚至在域之間只需要一個SP的時候，他們也應該（SHOULD）接收任意數量的SP或者HT字符。

    消息報頭域的結束行是順序CRLF。然而我們建議在解析這樣的報頭的時候，程序應該接受單個的LF作爲一行的結束並忽略第一位的CR。

    一個實體正文的特徵設置應該（SHOULD）分成基本的類並用那個報文中的特徵代碼來命名，除非無分類實體的優先級比用US-ASCII或ISO-8859-1分類的實體高。見3.7.1和3.4.1。

    對關於時間的分析和編碼以及時間編碼的其它潛在問題的需要的附加規則包括：
    --HTTP/1.1客戶機和高速緩存應該（SHOULD）假定一個似乎是50多年以後的RFC-850日期實際上是過去的（這有助於解決"2000年"問題）。

    一個HTTP/1.1的實現可以（MAY）在內部表現爲分析完成時間比正確日期更早，但是一定不要（MUST NOT）在內部表現爲分析完成時間比正確日期更晚。

    --所有與結束時間有關的計算必須（MUST）用格林尼治時間。本地市區一定不能（MUST NOT）影響年齡或完成時間的計算和比較。

    --如果一個HTTP報頭不正確的攜帶了一個格林尼治時間以外其它市區的時間，它必須（MUST）用所有可能中最保守的方法轉換成格林尼治時間。

19．4 HTTP實體和RFC 2045實體之間的區別

    HTTP/1.1使用了許多爲網際郵件（RFC 822 [9]）和多用途網際郵件擴充（MIME [7]）定義的允許在一個開放的表現多樣的環境中用擴展的機制傳輸實體的結構。不論如何，RFC 2045討論郵件，HTTP有一些功能部件和RFC 2045中描述的不同。這些不同被小心地挑選出來優化二進制連接的性能，允許使用新媒介類型有更大的靈活性，是時間比較更容易，並且承認一些早期HTTP服務器和客戶機的規則。

    這個附錄描述了HTTP和RFC 2045不同的特殊區域。在嚴格的MIME環境中的代理服務器和網關應該（SHOULD）意識到這些不同並且在必要的地方提供這種轉換。從MIME環境到HTTP的代理服務器和網管也需要意識到這些不同因爲一些轉換可能是需要的。

19.4.1 MIME版本

    HTTP不是一個遵守MIME的協議。然而HTTP/1.1消息可以（MAY）包括單個MIME版本的普通報頭域來指出構造這個消息使用的MIME協議的版本。

    MIME版本的報頭域的使用表明這個消息是完全遵守MIME協議的（RFC 2045[7]定義的）。在輸出HTTP消息到嚴格MIME環境的時候代理服務器/網關有責任確保（在可能的地方）完全匹配。

       MIME-Version   = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

    在HTTP/1.1用的缺省值是MIME1.0版本。然而，HTTP/1.1消息的分析和語義是由這篇文檔而不是MIME規範定義的。

19.4.2 轉換到規範形式

    RFC 2045 [7]需要網際通信實體在傳輸以前先轉換成規範形式，就像在RFC 2049 [48]第4部分中描述的那樣。這篇文檔的3.7.1節描述了當用HTTP傳輸時允許使用的"文本"媒介的次協議的形式。RFC 2046需要關於"文本"類型的內容就像CRLF一樣代表行間隔符並禁止在行間隔符序列以外使用CR或者LF。HTTP允許CRLF，單獨的CR，和單獨的LF來指出在一個消息用HTTP傳輸的時候文本內容裏的行間隔符。

在可能的地方，從HTTP到嚴格的MIME環境的代理服務器或者網關應該（SHOULD）把本文檔3.7.1節描述的文本媒介類型裏的所有行間隔符翻譯成RFC 2049 CRLF的規範形式。然而注意當出現內容的編碼以及HTTP允許使用一些不用八位組的13和10表示CR和LF的特殊設置的實際，就像一些多位組的特殊設置的情況，這可能是複雜的。

    使用者應該注意轉換將會破壞任何用於原內容的密碼校驗和，除非原內容已經是規範形式。因此，對任何在HTTP中使用這種校驗和的內容建議表示爲規範形式。

19.4.3 日期格式的轉換

    爲了簡化日期比較的過程HTTP/1.1使用了一種限定的日期格式設置。從其它協議過來的代理服務器河網館應該（SHOULD）確保消息裏現在的任何日期報頭域符合一種HTTP/1.1的格式，如果必要的話重寫日期。

19.4.4 內容編碼的介紹

    RFC 2045不包括任何相當於HTTP/1.1的內容編碼報頭域的概念。既然從HTTP到服從MIME協議的代理和網關作爲媒介類型的修正者，它就必須（MUST）改變內容類型報頭域的值或者在向前傳送消息以前解碼實體正文。（一些網際通信內容類型的試驗程序已經使用了媒介類型參數";conversions="來實現等效於媒介編碼的功能。不管怎樣，這個參數不是RFC 2045的一部分。）

19.4.5 無內容傳輸編碼

    HTTP不使用RFC 2045的內容傳輸編碼（CTE）。從使用MIME協議到HTTP的代理和網關必須（MUST）在把應答信息傳給HTTP客戶機之前刪除任何非實體CTE（"quoted-printable"或"base64"）編碼。

    從HTTP到使用MIME協議的代理和網關有責任確保信息對那個協議來說是用正確的格式和編碼在安全的傳輸，在那"安全傳輸"的定義是由使用的協議的限制給出的。如果分類將提高用目標協議安全傳輸的可能，代理或網關就應該（SHOULD）用合適的內容傳輸編碼對數據進行分類。

19.4.6 傳輸編碼的介紹

    HTTP/1.1介紹了傳輸編碼報頭域（14.41節）。代理/網關必須（MUST）在（經過）使用MIME協議（的網段）向前傳遞消息以前刪除任何傳輸編碼。

    一個解碼"chunked"傳輸代碼（3.6節）的程序可以用假代碼表示如下：
       length := 0
       read chunk-size, chunk-extension (if any) and CRLF
       while (chunk-size > 0) {
          read chunk-data and CRLF
          append chunk-data to entity-body
          length := length + chunk-size
          read chunk-size and CRLF
       }
       read entity-header
       while (entity-header not empty) {
          append entity-header to existing header fields
          read entity-header
       }
       Content-Length := length
       Remove "chunked" from Transfer-Encoding

19.4.7 MHTML和行長度限制

    和MHTML程序共享代碼的HTTP程序需要了解MIME行長度限制。既然HTTP沒有這個限制，HTTP並不壓縮長的行。用HTTP傳輸的MHTML消息遵守所有MHTML的規定，包括行長度的限制和壓縮，規範化等，既然HTTP傳輸所有作爲有效載荷的消息實體（見3.7.2節）並且不說明內容或任何可能包括在那的MIME報頭行。

19.5 其它特點

    RFC 1945和RFC 2068記錄了一些現有的對HTTP的實現所用到的協議原理，但是對於大多數軟件既不兼容也不正確。他們中的一些描述了計劃的實驗的特徵，一些描述了被發現缺少建立在HTTP/1.1規範基礎上的地址的實驗部署的特徵。

    許多從SMTP和MIME來的其它的報頭，例如內容處理和標題，也經常實現（見RFC 2076 [37]）。

19.5.1 內容處理

    內容處理應答報頭已經被計劃爲一種如果用戶請求把內容存成一個文件原服務器提供一個缺身文件名的方法。這種用法來自RFC 1806 [35]的定義。

        content-disposition = "Content-Disposition" ":"
                              disposition-type *( ";" disposition-parm )
        disposition-type = "attachment" | disp-extension-token
        disposition-parm = filename-parm | disp-extension-parm
        filename-parm = "filename" "=" quoted-string
        disp-extension-token = token
        disp-extension-parm = token "=" ( token | quoted-string )

    一個例子是：

      Content-Disposition: attachment; filename="fname.ext"

    接收用戶的代理不應該（SHOULD NOT）注意任何在文件名的參數中出現的文件路徑信息，這個參數被認爲僅僅是一個在這一次申請應用HTTP的參數。文件名應該（SHOULD）只被當作終端的一部分。

    如果在應答中用到的報頭有程序/八位字節流內容類型，這暗示用戶代理不應該現實應答（信息），而直接開始應答...'dialog。

    見15.5節內容處理的安全問題。

19.6 和以前版本的兼容

    要求和以前的版本的兼容超出了協議規範的範圍。然而HTTP/1.1有意設計成很容易支持以前的版本。在寫這份規範的時候，值的記錄下我們希望商業化的HTTP/1.1服務器是：

      --接受HTTP/0.9,1.0和1.1請求的請求行格式；
      --懂得HTTP/0.9,1.0或1.1格式中的任何有效請求；
      --恰當地用客戶機使用的主要版本回覆信息。

    並且我們希望HTTP/1.1的客戶機：

      --接受HTTP/1.0和1.1應答的狀態行格式；
      --懂得HTTP/0.9,1.0或1.1的格式中任何有效的應答。
  
    對大多數HTTP/1.0的實現，每一個連接的建立是通過客戶機先發出請求在服務器應答後關閉。一些實現了在RFC 2068 [33]的19.7.1節描述的Keep-Alive的牢固連接的版本。

19.6.1 對HTTP/1.0的改變

    這一部分總結HTTP/1.0和HTTP/1.1之間主要的區別。

19.6.1.1 對簡單的多主機web服務器和保留IP地址的改變

    客戶機和服務器支持主機請求報頭,如果主機的HTTP/1.1請求的請求報頭（14.23節）不存在就報告出錯，並且接受絕對的URIs（5.1.2節）是本規範定義的最重要的改變。
  
    老的HTTP/1.0客戶機假定IP地址和服務器是一對一的關係。沒有其它確定的機制區別有意對服務器的請求和直接對IP地址的請求。一旦老的HTTP客戶疾步在普遍上文概述的改變將允許互聯網支持一個IP地址多重WEB站點，極大簡化了對WEB服務器的控制，對一個主機分配多個IP地址已經導致嚴重的問題。互聯網也能從新獲得已經分配給用在頂層HTTP URLs只單獨爲了某個特殊用途的域名的IP地址。給定WEB增加的速度，已經配置的服務器的數量，所有對HTTP的實現（包括對現有HTTP/1.0的程序的升級）正確的實現這些要求是非常重要的：

    --客戶機和服務器都必須（MUST）支持主機請求報頭。
    --發送HTTP/1.1請求的客戶機必須（MUST）發送主機報頭。
    --如果HTTP/1.1請求不包括主機請求報頭服務器就必須（MUST）報告錯誤400（Bad Request）。
    --服務器必須（MUST）接受完全URIs。

19.6.2 和HTTP/1.0持續連接的兼容

    一些客戶機和服務器可能希望和一些對以前實現HTTP/1.0持續連接的客戶機和服務器兼容。單個持續連接不是缺省的行爲的時候，它就被明確的越過。 HTTP/1.0持續連接的實驗性實現是有缺陷的，在HTTP/1.1中設計新的簡單的來糾正這些問題。問題是一些現有的1.0客戶機可能發送Keep- Alive給一個不明白這種連接的代理服務器，那麼就錯誤地將它傳向下一個接收服務器，它將建立一個Keep-Alive連接並導致一個掛着的 HTTP/1.0代理等待關閉的應答。結果是HTTP/1.0客戶機必須禁止使用Keep-Alive和代理交談。

    然而，和代理交談是持續連接最重要的用處，所以禁止很明顯是無法接受的。因此，我們需要一些其它的機制來表明渴望持續連接，甚至當和一個忽略Connection的老代理交談這樣使用也是安全的。對HTTP/1. 0消息持續連接是缺省的;我們引入一個新的關鍵字(Connection: close)來申明非持續。見14.10節。
    原始的持續連接HTTP/1.0的形式（the Connection: Keep-Alive and Keep-Alive header）記錄在RFC 2068 [33]。

19.6.3 對RFC 2068的改變
    這篇規範已經被仔細的審查來糾正關鍵字的用法和消除它們的歧義；RFC 2068在遵守RFC 2119 [34] 制定的協定方面有很多問題。

    澄清哪個錯誤代碼將會使入站服務器失靈（例如DNS失靈）。（10.5.5節）

    CREATE有一個特點當一份資料第一次創建的時候他必須發送一個Etag。（10.2.2節)

    從規範中刪除了內容基：它無法廣泛的實現，並且除了精力充沛的擴展機制以外沒有簡單，安全的方法把它引入。此外它以類似但不一樣的方式在MHTML [45] 中使用。

    傳輸譯碼和消息長度以當使用chunked編碼（允許傳輸自己不劃界的編碼）需要正確匹配的方式相互影響；正確的弄清如何計算消息長度是重要的。（3.6,4.4,7.2.2,13.5.2,14.13,14.16節）


    引入"身份"的內容譯碼來解決高速緩存中發現的問題。（3.5節）

    零值的性質應該表明"我什麼都不想要"以允許客戶機拒絕請求。（3.9節）

    RFC 2145已經澄清了HTTP版本號的使用和解釋。需要代理升級他們爲了處理在實現HTTP/1.0中發現的問題而要求支持的最高協議版本。（3.1節）

    統配符字符設置的引入是爲了避免在接受報頭的性質設置名稱的激增。（14.2節）

    HTTP/1.1的高速緩存控制模式中的一種情況被遺漏了；引入s-maxage是爲了補充這種情況。（13.4，14.8，14.9，14.9.3節）

    高速緩存控制：爲了應答而定義的最大生存時間指標是不恰當的。（14.9.3節）

    有服務器（尤其是代理）不知道應答的全部長度但仍可以應答比特流請求的情況。我們因此需要一個機制允許內容範圍並不指示消息全部長度的比特流。

    如果總是回覆所有的meta-data範圍請求應答將變得非常冗長；通過允許服務器在206應答中只發送必要的報頭，這個問題能夠避免。（10.2.7,13.5.3,和14.27節）

    解決不能滿足請求範圍的問題；有兩種情況：語法問題,以及範圍在文檔中不存在。需要狀態416代碼確定這種模糊，它必須指出一個超出文檔實際內容的比特請求範圍錯誤。 (10.4.17, 14.16節)

    消息傳輸重寫的需要使得明白錯誤的事先更加困難，因爲這裏錯誤的結果對互聯網有重大的影響，要應付下列問題：

    1.把"HTTP/1.1或以後的版本"變成"HTTP/1.1"，這不適當的設置了對未來HTTP/1.x版本實現行爲的要求。

    2.一般是用戶代理而不是客戶機應該重發請求這一點要清楚。

    3.把對客戶機忽略不希望的100（以後）應答，以及對代理轉發應答100的要求變爲對應答1xx的一般要求。

    4.修改一些特殊TCP語言，使得HTTP可以用非TCP傳輸這一點更清楚。

    5.要求原服務器在發送必須的應答100(擴展)之前一定不要（MUST NOT）等待請求主體。

    6.如果服務器已經看見一些請求主體，允許，不是必須，它忽略100（擴展）。

    7.允許服務器防範拒絕服務攻擊和被控制的客戶機。

    這個變化增加了期待的報頭和狀態417代碼。消息傳輸要求的修改在8.2，, 10.4.18，8.1.2.2, 13.11, 和14.20節。

    代理應該可以在適當的時候增加內容的長度。（13.5.2節）

    整理應答403和404之間的混亂。（10.4.4, 10.4.5, 和10.4.11節）

    警告可能被錯誤的隱藏起來，或者沒有得到適當的糾正。（13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, 和14.46節）警告也需要有一個普通的報頭，因爲PUT或其它命令可能需要它。
  
    傳輸譯碼有重要的問題，特別是由於用chunked編碼的交互作用。解決的辦法是把傳輸譯碼變得和內容譯碼一樣快速。這涉及到給傳輸譯碼增加一個IANA 註冊（從內容譯碼中分離），一個新的報頭域（TE）和未來授權跟蹤報頭。傳輸編碼性能有很主要的好處，所以修改它是值得的。TE也解決其它的，不太明顯的，因爲跟蹤認證，chunked編碼和HTTP/1.0客戶機之間相互作用而出現的向下兼容的問題。（3.6, 3.6.1, 和14.39節）

    補丁，連接，解除連接的方法在這份規範以前的版本中定義過但不能一般的實現。見RFC 2068 [33]。

    變化，內容版本，源，連接，URI，公開和內容基報頭域在這份規範以前的版本中定義過，但不能一般地實現。見RFC 2068 [33]。

20 索引 (Index)

    參見這份RFC對索引的後記部分。

21 全部版權聲明

    版權所有（C）INTERNET SOCIETY（1999）。保留所有權利（All rights reserved)。

    如果所有的複製和派生工作包括上面的版權聲明和這一段，那麼這篇文檔和它的翻譯就可以拷貝並提供給其他人，就可以準備，複製，出版和發行，全部或者部分，註釋或其它的解釋或在它的實現中的幫助等派生工作，而沒有任何的限制。然而，無論如何這篇文檔本身不能被修改，例如刪除版權聲明或INTERNET SOCIETY及其它互聯網組織的參考數目，除非爲了發展互聯網標準的目的，在這種情況下互聯網標準進程定義的版權程序必須得到遵守，或者需要把它翻譯成英語之外的語言。

    上面准許的有限許可是永久的並且不會被INTERNET SOCIETY或者它的後繼組織或分支機構撤回。

    這篇文檔和裏面包含的內容是在"AS IS"的基礎上並且INTERNET SOCIETY和INTERNET ENGINEERING TASK FORCE放棄所有的理由，明確的或者暗指的，包括但不限於任何使用這裏的信息將不會破壞任何的權利理由或任何商業或適當的特殊目的的隱含的理由。