HTTP/1.1中文版

時間 2019-11-26

原文原文鏈接

http://www.cnblogs.com/cxd4321/p/3504632.htmlhtml

摘要

超文本傳輸協議（HTTP）是一種爲分佈式，合做式，多媒體信息系統服務，面向應用層的協議。它是一種通用的，不分狀態（stateless)的協議，除了諸如名稱服務和分佈對象管理系統之類的超文本用途外，還能夠經過擴展它的請求方式，錯誤代碼和報頭來完成許多任務。HTTP的一個特色是數據表示方式的典型性和可協商性容許獨立於傳輸數據而創建系統。在1990年WWW全球信息剛剛起步的時候HTTP就獲得了應用。HTTP的第一個版本叫作HTTP/0.9,是一種爲互聯網原始數據傳輸服務的簡單協議。由RFC 1945定義的HTTP/1.0進一步完善了這個協議。它容許消息以相似MIME的格式傳送，包括有關數據傳輸的維護信息和關於請求/應答的句法修正。可是，HTTP/1.0沒有充分考慮到分層代理，高速緩存的做用以及對穩定鏈接和虛擬主機的需求。而且隨着不完善的進程應用的激增，HTTP/1.0迫切須要一個新的版本,以便使兩個通訊應用程序可以肯定彼此的真實性能。前端

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

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

HTTP也是用於用戶代理之間及代理/網關到其餘網絡系統的通用通訊協議，這樣的網絡系統可能由SMTP,NNTP,FTP,Gopher和WAIS協議支持。這樣，HTTP容許不一樣的應用程序對資源進行基本的超媒體訪問。數據庫

1.3 術語

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

鏈接（Connection）
爲通訊而在兩個程序間創建的傳輸層虛擬電路。瀏覽器

消息(Message)
HTTP通訊中的基本單元。它由一個結構化的八比特字節序列組成，與第4章定義的句法相匹配，並經過鏈接獲得傳送。緩存

請求(Request)
一種HTTP請求消息，參看第5章的定義。安全

應答(Response)
一種HTTP應答消息，參看第6章的定義。服務器

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

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

表示方法(Representation)
一個應答包含的實體是由內容協商決定的,如第12章所述.一個特定的應答狀態所對應的表示方法可能有多個.

內容協商(ContentNegotiation)
爲請求服務時選擇適當表示方法的機制（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）
若是一個應答直接到來而且沒有緣於原服務器,或若干代理服務器的沒必要要的延時,那麼這個應答就是直接的.若是它的有效性已經被原服務器直接認證,那麼這個應答也一樣是第一手的.

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

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

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

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

保鮮（Fresh）
若是一個應答的年齡尚未超過保鮮壽命,它就是保鮮的.

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

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

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

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

向內/向外（inbound/outbound）
向內和向外指的是消息的請求和應答路徑:"向內"即"移向原服務器","向外"即"移向用戶代理".

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節）。

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'sasctime() format

第一種格式是做爲Internet標準提出來的,它表示一個由RFC 1123 [8](RFC 822[9]的升級版本)定義的固定長度的子集.第二種格式使用比較廣泛,可是基於廢棄的RFC850 [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 "," SPdate1 SP time SP "GMT"
       rfc850-date = weekday ","SP date2 SP time SP "GMT"
       asctime-date = wkday SP date3 SP time SP4DIGIT
      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 | ( SP1DIGIT ))
                     ; 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)---如RFC1952所描述---生成的編碼格式.這種格式是一種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 TransferCoding）

成塊編碼更改消息主體,爲的是將它以一系列大塊的形式傳送,每個連同它本身尺寸的指示器,被一個包含實體頭域的可隨意選擇的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提供了一系列"多重部分"類型---在單個消息體內一個或多個實體的包裝.全部的多重部分類型共享一個公共的序列,就像RFC2046的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語言標記的語法和註冊像RFC1766[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消息

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所指定的資源上所實現的方式,這種方式是條件敏感的

擴展方式= 標記

資源容許的方法列表能由容許(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定義的狀態碼單獨的值，和一個相應的一系列註解短語的例子，介紹以下,這兒列出的註解短語只是建議――它們能夠被至關的沒有感情色彩的協議取代．

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

HTTP狀態碼是可擴展的．HTTP應用程序不須要理解全部已註冊狀態碼的含義，儘管那樣的理解顯而易見是很合算的．可是，應用程序必須瞭解由第一位數字指定的狀態碼的類型，任何未被識別的應答應被看做是該類型的Ｘ00狀態，有一個例外就是未被識別的狀態碼不能緩存．例如，若是客戶機收到一個未被識別的狀態碼431，　則能夠安全的假定請求有錯，且其對待應答的狀況是彷彿客戶端收到的是400狀態碼．在這種狀況下，用戶代理應當把實體和應答一塊兒提交給用戶，由於實體極可能包括說明不日常狀態的人承認讀的信息．

６.2應答報頭域

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

隨着協議版本的變化,應答報頭能夠可靠的擴展．並且，若是通訊的全部組成部分都把它看成應答報頭域,新的或試驗性的應答報頭域能夠被給定應答報頭域的含義，未被認可的報頭域被看成實體報頭域．

7。實體。

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

7。1 實體報文域

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

擴展報頭=報文報頭

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

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, orIf-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節所描述的那樣服從消息傳輸的須要.

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標識一個或多個當前緩存的實體,這些實體將被拋棄.這個方法的應答是不可緩存的.

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應該給予地址區域.除非請求的方法是HEAD,相應的實體應該包含一個短的指向一個新的URI的超級鏈接的超文本提示

若是302狀態代碼在一個應答非GEI或者HEAD請求中的過程當中被接收到,那麼用戶代理嚴禁自動從新定位除非它能夠被用戶證明,由於它可能變化它的請求實現的條件.

註解: RFC1945 和 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: Basicand 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 AccessAuthentication"中有解釋.

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 codesthemselves.
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 thevalue of Age: header received by the cache with
      *             this response.
       * date_value
       *      is thevalue 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 thecurrent (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) 均未在響應中出現,且響應對緩存沒有其餘限制，緩存能夠用啓發式算法計算freshnesslifetime。緩存器必須對年齡大於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 標籤緩存確認器(EntityTag Cache Validators)

標籤響應報頭值,一個實體標籤,提供了一個"模糊"緩存確認器.這將容許在不便存儲修改信息的狀況下進行可靠的確認,包括HTTP日期數據不充足和源服務器不想因使用修改日期而帶來麻煩的狀況.

實體標籤描述見3.11節,有關其報頭的描述見14.19,14.24,14.26,14.44.

13.3.3 強,弱確認器

因爲源服務器和緩存器會比較兩個確認器來肯定他們是否表明相同的條目,因此一般但願實體發生任何變化,確認器也相應變化,這樣的確認器爲強確認器.

同時還會有這樣的狀況,服務器傾向於僅在發生重要的語義變化時才改變確認器.在資源變化時確認器未必變化的稱爲弱確認器.

實體標籤一般是強確認,但協議提供一種機制來標誌弱確認.能夠認爲,強確認在實體的每一字節變化時均變化,而弱確認僅在實體含義變化時才變化,強確認是某一特定實體的標誌,而弱確認是某一類同義實體的標誌.

注: 強確認的例子:一個整數,他隨着每次實體發生變化而定值增加.
        一個實體的修改時間(以秒計算)能夠做爲弱確認器,由於實體可能在一秒內變化兩次.
        對弱確認的支持是可選的.支持弱確承認帶來等價體的高效緩存.
        當客戶生成一個在確認報頭中包含確認器的請求或服務器進行比較時均要用到確認器.
        強確承認在任何狀況下使用,而弱確認僅在不依賴嚴格相等時纔可用.
        客戶能夠發出簡單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 聯合報頭（CombiningHeaders）

但緩存向服務器發出確認請求,若服務器回覆304或206響應,則緩存器構造響應回覆給請求客戶.

若狀態碼爲304,則緩存器使用緩存實體的報文構造響應,若狀態碼爲206且標籤和最後修改時間剛好匹配,則緩存器能夠將存儲的和剛收到的實體和並做爲新響應的報文(見 13.5.4).

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

13.5.4 聯合字節範圍

一條響應可能僅傳送一條正文的一部分，通過幾回這種傳送，一緩存器可能會
收到同一條正文的好幾部分。

若是緩存器已經收到正文的一部分，且又收到了另外一部分，緩存器能夠
將新收到的內容與已有內容合併，當全部收到的響應及緩存實體含有強確認時。

13.6 緩存談判響應

使用服務器驅動內容轉讓(見12.1),由響應中的變化報頭區說明,改變了緩存器能用響應回覆後續請求的條件和過程.(服務器使用變化報頭區見14.44)

服務器要用變化報頭區告知緩存器在衆多可緩存響應類型用什麼樣的請求
報頭區來用服務器驅動轉讓.變化區命名此類報頭區爲"選擇"請求報頭.

當緩存器收到指定一個或更多包含變化報頭區的緩存實體的後續請求,緩存器不能用這樣的緩存實體來構造新請求的響應,除非新請求中全部選中的請求報頭與初始請求相應部分匹配.

當且僅當兩個請求中的選擇請求報頭能夠從前一請求變形爲後一請求時稱爲匹配.變形指,在相應的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,可是若是在質量中€標記向下以後是最佳可利用的話,就給我發送任何音頻形式.若是當前沒有接受報頭區域,那麼能夠認爲是客戶接受了全部的媒體形式.若是當前有接受報頭區域而且若是服務器不能發送根據組合接受區域的值能夠接受的響應的話,那麼服務器應該發送一個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 toAccept, but restricts the set of natural languages that arepreferred as a response to the request. Language tags are definedin 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)實體報頭域中列出了由請求指定資源支持的幾種方法--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 哪些可被高速緩存機保存

不保存

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

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

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

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

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 緩存從新確認有效和重載控制

有時用戶代理可能但願或出於須要堅持讓緩存機與原服務器之間從新確認緩存條目的有效性（而不僅是通向原服務器的傳輸路徑中的下一高速緩存機），或是從原服務器處重載緩存條目。端到端的從新確認有效手續在緩存機或原服務器高估了緩存應答的過時時間時可能須要。端到端重載在緩存條目因爲某些緣由被侵蝕時可能須要。

若是客戶機沒有本身的本地緩存拷貝，即所謂"未指明的端到端從新確認有效"，或客戶機沒有本地的緩存拷貝，即所謂"經指明的端到端從新確認有效"，都有可能要求端到端的從新確認有效。

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

端到端重載

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

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

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

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

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

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

最大-年齡

當中轉緩存機被"最大-年齡=0"的指令迫使從新確認其緩存條目有效性，且客戶機在請求中提供了本身的有效性確認器時，所供的有效性確認器可能不一樣於緩存條目中現存的有效性確認模塊。在這一狀況下，緩存機能夠在不影響句法透明性的前提下將其中的任一有效性確認模塊用於本身的請求。
然而，對有效性確認器的選擇可能影響性能。最好的方法是讓中轉緩存機採用本身的有效性確認模塊來構造請求。若服務器應答以304（未經修改），則緩存機能夠將本身的確認後拷貝連同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

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

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

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

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

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

HTTP 將RFC1864拓寬到容許對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）是適用於機器的，就像在RFC822 [9]裏定義的「mailbox"以及在RFC 1123 [8]修訂的：

    From   = "From" ":" mailbox
    例如：
          From: webmaster@w3.org

報頭域能夠（MAY）用做記錄日誌的目的和做爲認證無效或者多餘請求源的方法。他不該該（SHOULDNOT）用做不安全形式的訪問保護。這個域的解釋是請求正在爲某個給定的人執行，它承擔這個方法執行的責任。特別的，自動控制代理應該（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: http://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值的實體（單個實體標籤）再也不是源的表示法請求方法應訂不能（MUSTNOT）獲得應用。這容許用戶代表若是源已經改變而他們不知道的話他們不但願請求成功。
例如：

   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請求時必須在轉送請求前檢查和修正它的值.若是接收到的值是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）

路有常規頭域必須被網關和代理服務起來指示中間的協議和關於請求的使用者和服務器之間的接收者及應答的原服務器和客戶端的接收者。它相似於RFC822[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的原服務器。這個請求被http://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-agentSP 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標準版本中的一部分，但自從它被普遍應用以來，咱們正在證實它對使用者的價值和風險。詳細資料見RFC2183 [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）

( 略 )

17 參考資料 (Reference)

( 略 )

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）在內部表現爲分析完成時間比正確日期更早，可是必定不要（MUSTNOT）在內部表現爲分析完成時間比正確日期更晚。

--全部與結束時間有關的計算必須（MUST）用格林尼治時間。本地市區必定不能（MUST NOT）影響年齡或完成時間的計算和比較。

--若是一個HTTP報頭不正確的攜帶了一個格林尼治時間之外其它市區的時間，它必須（MUST）用全部可能中最保守的方法轉換成格林尼治時間。

19．4 HTTP實體和RFC 2045實體之間的區別

HTTP/1.1使用了許多爲網際郵件（RFC822 [9]）和多用途網際郵件擴充（MIME [7]）定義的容許在一個開放的表現多樣的環境中用擴展的機制傳輸實體的結構。不論如何，RFC2045討論郵件，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]須要網際通訊實體在傳輸之前先轉換成規範形式，就像在RFC2049 [48]第4部分中描述的那樣。這篇文檔的3.7.1節描述了當用HTTP傳輸時容許使用的"文本"媒介的次協議的形式。RFC 2046須要關於"文本"類型的內容就像CRLF同樣表明行間隔符並禁止在行間隔符序列之外使用CR或者LF。HTTP容許CRLF，單獨的CR，和單獨的LF來指出在一個消息用HTTP傳輸的時候文本內容裏的行間隔符。

在可能的地方，從HTTP到嚴格的MIME環境的代理服務器或者網關應該（SHOULD）把本文檔3.7.1節描述的文本媒介類型裏的全部行間隔符翻譯成RFC2049 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="來實現等效於媒介編碼的功能。無論怎樣，這個參數不是RFC2045的一部分。）

19.4.5 無內容傳輸編碼

HTTP不使用RFC2045的內容傳輸編碼（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 toentity-body
          length := length +chunk-size
          read chunk-size and CRLF
       }
       read entity-header
       while (entity-header not empty) {
          append entity-header toexisting 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和RFC2068記錄了一些現有的對HTTP的實現所用到的協議原理，可是對於大多數軟件既不兼容也不正確。他們中的一些描述了計劃的實驗的特徵，一些描述了被發現缺乏創建在HTTP/1.1規範基礎上的地址的實驗部署的特徵。

許多從SMTP和MIME來的其它的報頭，例如內容處理和標題，也常常實現（見RFC 2076 [37]）。

19.5.1 內容處理

內容處理應答報頭已經被計劃爲一種若是用戶請求把內容存成一個文件原服務器提供一個缺身文件名的方法。這種用法來自RFC1806 [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的實現，每個鏈接的創建是經過客戶機先發出請求在服務器應答後關閉。一些實現了在RFC2068 [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（BadRequest）。
    --服務器必須（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 andKeep-Alive header）記錄在RFC 2068 [33]。

19.6.3 對RFC 2068的改變

這篇規範已經被仔細的審查來糾正關鍵字的用法和消除它們的歧義；RFC2068在遵照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(擴展)以前必定不要（MUSTNOT）等待請求主體。

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節）

補丁，鏈接，解除鏈接的方法在這份規範之前的版本中定義過但不能通常的實現。見RFC2068 [33]。

變化，內容版本，源，鏈接，URI，公開和內容基報頭域在這份規範之前的版本中定義過，但不能通常地實現。見RFC 2068 [33]。