part ofHypertext Transfer Protocol — HTTP/1.1

RFC 2616 Fielding, et al.

14 頭字段規(guī)定

　　該章節(jié)定義了HTTP1.1標(biāo)準(zhǔn)所包含的所有頭字段的相關(guān)語法和含義。實(shí)體頭字段是接收者或者發(fā)送者所涉及到的，并不區(qū)分是客戶端還是服務(wù)器所擁有，而是依據(jù)是誰發(fā)送或者是誰接受該實(shí)體的字段。

14.1Accept

　　Accept請求頭字段可以用來指定一個能被響應(yīng)接受的確定的媒體類型。Accept頭字段可以用來標(biāo)識那些在請求中特別指定類型的一個小范圍的集合，比如請求內(nèi)聯(lián)圖片的情況。

　　Accept = “Accept” “:” #( media-range(媒體范圍)[ accept-params (可接受的參數(shù))] )

　　media-range = ( “*/*” | ( type “/” “*” ) | ( type “/” subtype ) ) *( “;” parameter )

　　accept-params = “;” “q” “=” qvalue *( accept-extension(可接受的擴(kuò)展))

　　accept-extension = “;” token(記號)[ “=” ( token | quoted-string(引用字符串)) ]

　　星號”*”字符用來把媒體類型歸類到ranges中，”*/*” 表示所有媒體類型都可以接受，”type/*”標(biāo)明該媒體類型下的所有子類型。media-range可以包含適當(dāng)范圍內(nèi)的媒體類型參數(shù)。

　　每個media-range都可以跟隨一個或多個accept-params參數(shù)，以q參數(shù)開始，用來表明相對的權(quán)重因子。第一個q參數(shù)（如果有的話）將media-range參數(shù)從accept-params字段中分隔開。權(quán)重參數(shù)允許用戶或用戶代理指示對該媒體范圍的相對偏好程度，q的值在0到1范圍內(nèi)。默認(rèn)的值是1。

　　請注意：使用“q”參數(shù)名稱將媒體類型參數(shù)從Accept擴(kuò)展參數(shù)中分離出來是有歷史實(shí)踐性的。盡管這可能會從媒體范圍中阻止任何叫做“q”的媒體類型，但是由于IANA（因特網(wǎng)編號管理局）注冊表中缺少”q”字段的相關(guān)記錄，并且Accept中很少使用任何媒體類型的參數(shù)，因此這種事情不太可能發(fā)生。

　　一個簡單的例子：

　　Accept: audio/*; q=0.2, audio/basic

　　可以理解為我第一優(yōu)先需要“audio/basic”格式，但是在降低百分之八十的標(biāo)準(zhǔn)后給我傳送其他的audio類型也是可以的。

　　如果沒有Accept投資段，那么假設(shè)客戶端可以接受任何的媒體類型。如果存在Accept頭字段，但是服務(wù)器無法發(fā)送一個包含Accept字段中可接受的響應(yīng)，那么就會返回一個406狀態(tài)碼。

　　一個稍微復(fù)雜點(diǎn)的例子：

　　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實(shí)體，但是如果也不存在，那么就需要發(fā)送那個text/plain實(shí)體。

　　媒體范圍（Media ranges）可以被更特定的媒體范圍（Media ranges）或特定的媒體類型（media types）覆蓋。如果一個給定類型應(yīng)用了多個媒體范圍，那么最特定的會被采用。我們來看下面的例子：

　　Accept: text/*, text/html, text/html;level=1, */*

　　擁有以下的優(yōu)先級

　　1) text/html;level=1

　　2) text/html

　　3) text/*

　　4) */*

　　與給定類型關(guān)聯(lián)的媒體類型權(quán)重因子是通過找到與該類型匹配的具有最高優(yōu)先級的媒體范圍來確定的。例如,

Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5

　　將會導(dǎo)致其關(guān)聯(lián)的權(quán)重值是下面這樣：

　　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

　　注意:用戶代理可能會為某些媒體范圍提供一組默認(rèn)的權(quán)重值。但是，除非用戶代理是一個封閉的系統(tǒng)，不能與其他執(zhí)行中的代理（rendering agents）交互，否則這個默認(rèn)設(shè)置應(yīng)該由用戶配置。

14.2Accept-Charset

　　Accept-Charset 請求頭字段可以用來標(biāo)示怎樣的字符集可以在響應(yīng)中使用。該字段允許客戶端有能力去理解綜合性更強(qiáng)或者具有特殊用途的字符集，具有向能夠在這些字符集中表示文檔的服務(wù)器發(fā)出信號的能力。

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

　　在3.4小節(jié)我們解釋了有關(guān)于字符集的值的相關(guān)信息。每一個字符可以擁有一個用來表示該字符權(quán)重的相關(guān)的值。權(quán)重的默認(rèn)值是1。下面我們看一個例子：

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

　　如果存在特殊的星號“*”在Accept-Charset字段中，匹配在Accept-Charset字段中沒有提及的其他所有的字符集（包括ISO-8859-1）。如果該頭字段中不存在星號，沒有明確提及的所有字符集都獲得權(quán)重值0，除了ISO-8859-1，如果沒有明確提及，則獲得權(quán)重值1。

　　如果沒有Accept-Charset頭字段，則說明任何字符都是可以接受的。如果存在該字段，但是服務(wù)器并沒有在響應(yīng)中傳遞該字段允許的字符集，那么服務(wù)器需要返回一個406狀態(tài)碼，盡管傳送一個不符合的響應(yīng)也是被允許的。

14.3Accept-Encoding

　　Accept-Encoding請求頭字段與Accept頭字段類似，但是限制了在響應(yīng)用允許使用的內(nèi)容編碼（content-codeings，第3.5小節(jié)）。

　　Accept-Encoding = “Accept-Encoding” “:”

　　1#( codings [ “;” “q” “=” qvalue ] )

　　codings = ( content-coding | “*” )

　　使用該字段的例子：

　　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

　　服務(wù)器根據(jù)Accept-Encoding字段測試內(nèi)容編碼（content-coding）是否可以接受，規(guī)則如下：

　　1.內(nèi)容編碼（content-coding）是否是在Accept-Encoding字段中列出的，如果是則可以接受，除非它伴有的權(quán)重值是0.（就像3.9小節(jié)所描述的，權(quán)重值為0則認(rèn)為無法接受）

　　2.如果Accept-Encoding字段中存在特殊的星號“*”，那么意味著在任何在該字段中未明確說明的內(nèi)容編碼都是可以接受的。

　　3.如果有多個被允許的內(nèi)容編碼，那么權(quán)重值最高的優(yōu)先。

　　4.身份（identity）內(nèi)容編碼總是可以被接受的，除非在Accept-Encoding字段中的identity字段的權(quán)重值是0,或者在字段中包含了“*；q=0”并且沒有明確的“identity”內(nèi)容編碼。如果不存在Accept-Encoding，那么只有“identity”是被允許的。

　　如果一個請求中存在Accept-Encoding字段，但是服務(wù)器無法提供該字段范圍內(nèi)的響應(yīng)，那么服務(wù)器需要返回一個406錯誤響應(yīng)。

　　如果請求中沒有Accept-Encoding頭字段，那么服務(wù)器則假設(shè)客戶端可以接受任何類型編碼的內(nèi)容。在這種情況下，如果“identity”是被允許的內(nèi)容編碼之一，那么服務(wù)器需要使用“identity”內(nèi)容編碼，除非有額外的信息表明其他的內(nèi)容編碼對客戶端更有意義。

　　注意:如果請求不包含Accept-Encoding字段，如果”identity”內(nèi)容編碼不可用，那么HTTP/1.0客戶端會使用通用的content-codings(即，“gzip”和“compress”);一些較老的客戶端可能會不正確地顯示與其他內(nèi)容編碼一起發(fā)送的消息。服務(wù)器還可以根據(jù)特定用戶代理或客戶端的信息做出此決定。

　　注意:大多數(shù)HTTP/1.0應(yīng)用程序不識別或不遵守與內(nèi)容編碼相關(guān)的qvalue。這意味著qvalues將不能工作，x-gzip或x-compress中不允許使用qvalues。

14.4Accept-Language

　　該字段也Tm跟Accept字段類似，但是它限制了請求中需要的自然語言集合的首選范圍。語言標(biāo)識符在3.10小節(jié)中已經(jīng)詳細(xì)說明。

　　Accept-Language = “Accept-Language” “:” 1#( language-range [ “;” “q” “=” qvalue ] )

　　language-range = ( ( 1*8ALPHA *( “-” 1*8ALPHA ) ) | “*” )

　　每一個語言范圍（language-range）可以擁有一個表示預(yù)計(jì)用戶在該語言范圍內(nèi)更傾向的語言的相關(guān)聯(lián)的權(quán)重值。默認(rèn)的權(quán)重值是1。比如：

　　Accept-Language: da, en-gb;q=0.8, en;q=0.7

　　意味著：“我需要丹麥語（Danish），但是英式英語或者其他類型的英語也是可以接受的”。如果語言范圍正好等于標(biāo)記，或者正好等于標(biāo)記的前綴，則語言范圍匹配語言標(biāo)記，使得前綴后面的第一個標(biāo)記字符是“-”。如果在Accept-Language字段中存在特殊范圍“*”，則與Accept-Language字段中存在的任何其他范圍不匹配的每個標(biāo)記匹配。

　　注意：前綴匹配規(guī)則的這種使用并不意味著語言標(biāo)簽是以這樣的方式分配給語言的，即如果用戶理解具有特定標(biāo)記的語言，那么該用戶也將理解具有該標(biāo)記為前綴的所有標(biāo)記的語言。如果是這樣的話，前綴規(guī)則只允許使用前綴標(biāo)簽。

　 Accept-Language字段分配給語言標(biāo)簽的權(quán)重因子是與語言標(biāo)簽匹配的字段中最長的語言范圍的權(quán)重值。如果字段中沒有語言范圍與標(biāo)簽匹配，則分配的語言權(quán)重值為0。如果請求中不存在Accept-Language字段頭，則服務(wù)器應(yīng)假定所有語言都同樣可接受。如果存在Accept-Language字段頭，則分配大于0的權(quán)重值的所有語言都是可接受的。

　　在每次請求中發(fā)送帶有用戶完整語言首選項(xiàng)的Accept-Language報頭可能與用戶的隱私期望相反。有關(guān)這個問題的討論，請參閱第15.1.4節(jié)。

　　由于可理解性高度依賴于單個用戶，因此建議客戶端應(yīng)用程序允許用戶可以選擇語言首選項(xiàng)。如果選擇不可用，則不能在請求中給出Accept-Language頭字段。

　　注意：當(dāng)用戶能夠選擇語言偏好時，我們希望提醒開發(fā)者，用戶并不熟悉上述語言匹配的細(xì)節(jié)，并且應(yīng)該提供適當(dāng)?shù)闹笇?dǎo)。舉個例子，用戶可能會假設(shè)在選擇“en-gb”時，如果英式英語不可用，他們會得到任何類型的英語文檔。在這種情況下，用戶代理可能會建議使用“EN”以獲得最佳匹配行為。

14.5Accept-Ranges

　　Accept-Ranges響應(yīng)頭字段允許服務(wù)器表明其所接受資源的范圍：

Accept-Ranges = “Accept-Ranges” “:” acceptable-ranges

acceptable-ranges = 1#range-unit | “none”

　　接受字節(jié)范圍（byte-range）請求的源服務(wù)器可以發(fā)送

Accept-Ranges: bytes

　　但是我們并不需要這樣做。客戶端可以生成字節(jié)范圍（byte-range）請求，而不為所涉及的資源接收此報頭。范圍單元（Range units）在3.12小節(jié)中做了說明。

　　如果發(fā)送了如下的字段，那么服務(wù)器不會接受任何范圍的請求。

Accept-Ranges: none

　　建議客戶端不要嘗試范圍請求。

14.6Age

　　Age響應(yīng)頭字段傳遞發(fā)送方對該響應(yīng)（或重新驗(yàn)證）在原始服務(wù)器上生成以來的時間的大致估計(jì)，如果緩存的響應(yīng)的生命周期不超過新鮮度（fresh），那么它就是最新的。在13.2.3小節(jié)中指定了如何去計(jì)算Age的值。

Age = “Age” “:” age-value

age-value = delta-seconds

　　Age的值是非負(fù)的十進(jìn)制整數(shù)，表示時間（以秒為單位）。如果一個緩存接收到一個大于它所能表示的最大正整數(shù)的值，或者Age計(jì)算出的值溢出，那么它必須發(fā)送一個值為2147483648（2^31）的Age頭字段。包含緩存的HTTP/1.1服務(wù)器必須在其自身緩存生成的每個響應(yīng)中包含Age頭字段。緩存應(yīng)該使用至少31位的算術(shù)類型。

14.7Allow

　　Allow實(shí)體頭字段列出了由請求URI（Request-URI）所標(biāo)識的資源所支持的一組方法。此字段的目的是嚴(yán)格的告知接收方與該資源關(guān)聯(lián)的有效方法。Allow字段必須在405（Method Not Allowed）響應(yīng)中存在。

Allow = “Allow” “:” #Method

　　使用例子：

Allow: GET, HEAD, PUT

　　該字段無法阻止客戶端嘗試其他方法。

　　但是，我們應(yīng)該遵循Allow頭字段的值所給出的指示。被允許使用的方法的實(shí)際集合會在每一次請求的元服務(wù)器中明確的指定。

　　Allow頭字段可以提供一個PUT方法以使用戶提前知道一個新資源或者一個被修改的資源當(dāng)前所支持的方法。服務(wù)器無需支持這些方法，但是需要在響應(yīng)中包含一個Allow頭字段告知用戶該資源實(shí)際支持的方法有哪些。

　　一個代理不能修改Allow頭字段中的內(nèi)容既是它完全無法理解所有方法所具有的特性，因?yàn)榭赡芪覀兊目蛻舳嗽谂c服務(wù)器交流的時候有其他的用意。

14.8Authorization

　　用戶代理希望通過服務(wù)器(通常是在收到401響應(yīng)之后，但不一定是在收到401響應(yīng)之后)進(jìn)行身份驗(yàn)證，驗(yàn)證的方法是在請求中包含一個Authorization請求頭字段。Authorization字段值由憑證（credentials）組成，憑證包含所請求資源范圍的用戶代理的身份驗(yàn)證信息。

　　Authorization = “Authorization” “:” credentials

　　該（“HTTP Authentication:Basic and Digest Access Authentication”）文章介紹了HTTP如何訪問身份驗(yàn)證信息。如果某個請求通過了身份驗(yàn)證并指定了一個域，那么該域內(nèi)的所有其他請求應(yīng)該具有相同的憑證（假設(shè)身份驗(yàn)證方案本身不需要其他憑證，例如根據(jù)質(zhì)詢值變化的憑證或使用同步時鐘）。

　　當(dāng)共享緩存（參見第13.7節(jié)）接收到包含Authorization字段的請求時，它不能返回相應(yīng)的響應(yīng)作為對任何其他請求的回復(fù)，除非存在以下特定情況之一：

　　1.如果一個響應(yīng)包含了“s-maxage”緩存控制（Cache-Control）指令，該緩存可以使用該響應(yīng)回復(fù)之后的請求。但是（如果已經(jīng)超過最大的指定期限）代理緩存必須優(yōu)先與服務(wù)器進(jìn)行驗(yàn)證，使用新請求的請求頭來允許源服務(wù)器驗(yàn)證新請求。（這是s-maxage的定義行為。）如果響應(yīng)包括“s-maxage=0”，則代理必須總是在重新使用之前對其進(jìn)行重新驗(yàn)證。

　　2.如果響應(yīng)中包含“must-revalidate”緩存控制指令（cache-control directive），緩存可以在答復(fù)后續(xù)請求時使用該響應(yīng)。但是，如果響應(yīng)已經(jīng)過期，所有緩存必須首先用源服務(wù)器重新驗(yàn)證它，使用來自新請求的請求頭來允許源服務(wù)器驗(yàn)證新請求。

　　3.如果響應(yīng)包含“public”緩存控制指令，則可以回復(fù)任何后續(xù)請求。

14.9Cache-Control

　　Cache-Control通用頭字段用于指定在請求/響應(yīng)鏈上所有的緩存都必須遵守的規(guī)則。指令的指定旨在防止緩存對請求或響應(yīng)產(chǎn)生不利干擾的一些行為。這些指令通常會重寫默認(rèn)緩存算法。緩存指令是單項(xiàng)的，請求中存在指令并不意味著響應(yīng)中也將會給出相同的指令。

　　注意：HTTP/1.0協(xié)議版本下的緩存可能無法實(shí)現(xiàn)緩存控制，只能實(shí)現(xiàn)Pragma(編譯指示): no-cache (詳情請見14.32小節(jié)).

　　緩存指令必須由代理或網(wǎng)關(guān)應(yīng)用程序傳遞，無論這些指令對該程序是否有用，因?yàn)檫@些指令可能適用于請求/響應(yīng)鏈上的所有接收者。我們不可能為特定的緩存指定緩存指令。

　　Cache-Control = “Cache-Control” “:” 1#cache-directive

　　cache-directive = cache-request-directive | cache-response-directive

　　cache-request-directive =

　　“no-cache” ; Section14.9.1

　　| “no-store” ; Section14.9.2

　　| “max-age” “=” delta-seconds ; Section14.9.3,14.9.4

　　| “max-stale” [ “=” delta-seconds ] ; Section14.9.3

　　| “min-fresh” “=” delta-seconds ; Section14.9.3

　　| “no-transform” ; Section14.9.5

　　| “only-if-cached” ; Section14.9.4

　　| cache-extension ; Section14.9.6

　　cache-response-directive =

　　”public” ; Section14.9.1

| “private” [ “=” <“> 1#field-name <“> ] ; Section14.9.1

　　| “no-cache” [ “=” <“> 1#field-name <“> ]; Section14.9.1

　　| “no-store” ; Section14.9.2

　　| “no-transform” ; Section14.9.5

　　| “must-revalidate” ; Section14.9.4

　　| “proxy-revalidate” ; Section14.9.4

　　| “max-age” “=” delta-seconds ; Section14.9.3

　　| “s-maxage” “=” delta-seconds ; Section14.9.3

　　 | cache-extension ; Section14.9.6

cache-extension = token [ “=” ( token | quoted-string ) ]

　　當(dāng)指令沒有任何一個字段名參數(shù)出現(xiàn)時，該指令適用于整個請求或響應(yīng)。當(dāng)這樣的指令以符合要求的字段名參數(shù)出現(xiàn)時，它只適用于命名字段，而不適用于請求或響應(yīng)的其余部分。該機(jī)制支持可擴(kuò)展性；HTTP協(xié)議的未來版本的實(shí)現(xiàn)可能將這些指令應(yīng)用于HTTP/1.1中未定義的頭字段。

　　緩存控制指令可以分解為以下這些一般類別。

　　　　-限制什么是可緩存的；這些只能由源服務(wù)器強(qiáng)加。

　　　　-對緩存可以存儲的內(nèi)容的限制；這些可以由源服務(wù)器或用戶代理強(qiáng)制執(zhí)行。

　　　　-基本過期機(jī)制的修改；這些可以由源服務(wù)器或用戶代理強(qiáng)制執(zhí)行。

　　　　-對緩存重新驗(yàn)證和重新加載進(jìn)行控制；這些可能僅由用戶代理強(qiáng)制執(zhí)行。

　　　　-控制實(shí)體的轉(zhuǎn)換。

　　　　-緩存系統(tǒng)的擴(kuò)展。

14.9.1What is Cacheable

　　默認(rèn)情況下，如果請求方法、請求頭字段和響應(yīng)狀態(tài)的指示該響應(yīng)是可緩存的，則響應(yīng)是可緩存的。第13.4小節(jié)總結(jié)了這些可緩存性的默認(rèn)值。下面的Cache-Control響應(yīng)指令允許源服務(wù)器重寫響應(yīng)的默認(rèn)緩存性：

public

　　指示響應(yīng)可能由任何緩存來緩存資源，即使它通常不可緩存或僅在非共享緩存中緩存。（請參閱授權(quán)，第14.8小節(jié)，以了解更多細(xì)節(jié)。）

private

　　指示響應(yīng)消息的全部或部分用于單個用戶，而不能由共享緩存緩存。這允許源服務(wù)器聲明響應(yīng)的指定部分僅針對一個用戶，而不能對其他用戶的請求進(jìn)行有效響應(yīng)。私有（非共享）緩存可以緩存響應(yīng)。

　　注意：private一詞的在這里的語義只是控制響應(yīng)可以緩存在哪里，并不能確保消息內(nèi)容的隱私性。

no-cache

　　如果無緩存（no-cache）指令沒有指定字段名，則緩存不能使用該響應(yīng)來滿足后續(xù)請求，而無需與原始服務(wù)器重新驗(yàn)證成功。這允許源服務(wù)器甚至通過配置成向客戶端請求返回過期響應(yīng)的緩存來防止緩存。

　　如果非緩存指令確實(shí)指定了一個或多個字段名，則緩存可以使用響應(yīng)來滿足后續(xù)請求，但受緩存上的任何其他限制。但是，在沒有與原始服務(wù)器成功重新驗(yàn)證的情況下，在響應(yīng)后續(xù)請求時，必須不發(fā)送指定的字段名。這允許源服務(wù)器防止在響應(yīng)中重用某些頭部字段，同時仍然允許緩存響應(yīng)的其余部分。

　　注意：大部分HTTP/1.0協(xié)議下的緩存無法識別或遵守該指令

14.9.2What May be Stored by Caches

no-store

　　no-store指令存在的目的是阻止那些無意間發(fā)布或保留的敏感信息（例如，備份信息）。no-store指令為整個消息提供實(shí)用，可能會被響應(yīng)或請求發(fā)送。如果在請求中發(fā)送，緩存一定不能被請求的任何部分或響應(yīng)該請求的響應(yīng)存儲。如果在響應(yīng)中發(fā)送，則緩存不能存儲該響應(yīng)的任何部分或引發(fā)該請求的請求。該指令也適用于非共享和共享緩存。“必須不存儲”在此上下文中意味著緩存必須不故意將信息存儲在非易失性存儲器中，并且必須盡力在轉(zhuǎn)發(fā)信息之后盡可能迅速地從易失性存儲器中刪除信息。

　　即使這個指令與響應(yīng)相關(guān)聯(lián)，用戶也可以在緩存系統(tǒng)之外顯式地存儲這樣的響應(yīng)（例如，使用“另存為”對話框）。歷史緩沖區(qū)可以存儲這些響應(yīng)作為正常操作的一部分。

　　本指令的目的是滿足某些用戶和服務(wù)作者的既定要求，這些用戶和服務(wù)作者擔(dān)心通過意外訪問緩存數(shù)據(jù)結(jié)構(gòu)而泄漏信息。雖然在某些情況下，使用本指令可能改善一些隱私的保密性，但我們警告說，它絕不是確保隱私的可靠或充分的機(jī)制。特別地，惡意或受損的緩存可能無法識別或遵從這個指令，并且在這種情況下，通信網(wǎng)絡(luò)可能很容易被竊聽。

14.9.3Modificationsof the Basic Expiration Mechanism

　　源服務(wù)器可以使用Expires頭字段指定實(shí)體的過期時間(參見14.21節(jié))。或者，可以在響應(yīng)中使用max-age指令指定它。當(dāng)緩存的響應(yīng)中出現(xiàn)max-age cache-control指令時，如果當(dāng)前時間大于對該資源的新請求時給出的時間值(以秒為單位)，則響應(yīng)就失效了。響應(yīng)的max-age指令意味著響應(yīng)是可緩存的(即，“public”）除非有其他更嚴(yán)格的緩存指令。

　　如果一個響應(yīng)同時包含一個Expires頭字段和一個max-age指令，則max-age指令將覆蓋Expires頭字段，即使Expires頭字段有更多的限制。該規(guī)則允許源服務(wù)器為給定的響應(yīng)提供比HTTP/1.0緩存更長(或更高)的HTTP/1.1緩存過期時間。如果某些HTTP/1.0緩存無法正確地計(jì)算時間或過期時間，這可能是有用的，導(dǎo)致該情況的原因可能是由于時鐘不同步。

　　許多HTTP/1.0緩存實(shí)現(xiàn)會將一個小于或等于響應(yīng)日期值的Expires值視為等同于cache – control的“no-cache”響應(yīng)指令。如果HTTP/1.1緩存接收到這樣的響應(yīng)，并且響應(yīng)不包含cache – control頭字段，則應(yīng)該認(rèn)為響應(yīng)不可緩存，以保持與HTTP/1.0服務(wù)器的兼容性。

　　注意:源服務(wù)器可能希望在網(wǎng)絡(luò)上使用相對較新的HTTP緩存控制特性，比如“private”指令，其中包括不理解該特性的舊緩存。原始服務(wù)器需要將新特性與一個Expires字段合并，該字段的值小于或等于日期值。這將防止舊的緩存不正確地緩存響應(yīng)。

s-maxage

　　如果響應(yīng)包含一個s-maxage指令，那么對于共享緩存(但不是私有緩存)，該指令指定的最大使用時限將覆蓋由max-age指令或Expires頭指定的最大使用時限。s-maxage指令還包含代理重新驗(yàn)證指令的語義(參見14.9.4節(jié))，即，在實(shí)體過期后，緩存在原始服務(wù)器沒有重新驗(yàn)證它之前必須不能使用該實(shí)體來響應(yīng)后續(xù)請求。私有緩存總是忽略s-maxage指令。

　　注意，大多數(shù)舊的緩存行為，不遵循這個規(guī)范，無法實(shí)現(xiàn)任何緩存控制指令。如果源服務(wù)器希望使用該限制規(guī)范但又不防止HTTP/1.1兼容緩存的cache-control指令，那么它可能會利用max-age指令覆蓋Expires頭字段的要求，以及HTTP/1.1之前的版本兼容的緩存不遵守max-age指令的事實(shí)。

　　其他指令允許用戶代理修改基本的過期機(jī)制。這些指示可按要求指定:

max-age

　　指示客戶端愿意接受時限不大于指定時間(以秒為單位)的響應(yīng)。除非還包含了舊的指令，否則客戶端不希望接受舊的響應(yīng)。

min-fresh

　　表示客戶端愿意接受新鮮度時限不小于當(dāng)前時間加上指定時間(以秒為單位)的響應(yīng)。也就是說，客戶端希望響應(yīng)至少在指定的秒數(shù)內(nèi)仍然是有效的。

max-stale

　　指示客戶端愿意接受超過過期時間的響應(yīng)。如果賦給max-stale值，那么客戶端愿意接受超過其過期時間不超過指定秒數(shù)的響應(yīng)。如果沒有賦值給max-stale賦值，那么客戶愿意接受任何時限的陳舊響應(yīng)。

　　如果緩存返回陳舊的響應(yīng)，或者因?yàn)檎埱笊系膍ax-stale指令，或者因?yàn)榫彺姹慌渲脼楦采w響應(yīng)的過期時間，那么緩存必須使用警告110(響應(yīng)過時了)并將警告標(biāo)頭附加到過時的響應(yīng)上。

　　緩存可以配置為在不進(jìn)行驗(yàn)證的情況下返回過時的響應(yīng)，但前提是這與緩存驗(yàn)證的任何“必須”級別需求(例如，“必須重新驗(yàn)證”cache-control指令)不沖突。

　　如果新請求和緩存內(nèi)容都包含“max-age”指令，那么兩個值中的較小值將用于確定該請求緩存內(nèi)容的新鮮度。

14.9.4Cache Revalidation and Reload Controls

　　有時候，用戶代理可能希望或需要堅(jiān)持讓緩存使用原始服務(wù)器重新驗(yàn)證其緩存條目(而不僅僅是使用沿著原始服務(wù)器路徑的下一個緩存)，或者從原始服務(wù)器重新加載其緩存條目。如果緩存或原始服務(wù)器高估了緩存響應(yīng)的過期時間，那么端到端重新驗(yàn)證可能是必要的。如果緩存條目由于某種原因損壞，那么端到端的重新加載可能是必要的。

　　端到端重新驗(yàn)證可以在客戶端沒有自己的本地緩存副本時請求，在這種情況下，我們將其稱為“未指定的端到端重新驗(yàn)證”，或者當(dāng)客戶端有本地緩存副本時，在這種情況下，我們將其稱為“特定的端到端重新驗(yàn)證”。

　　客戶端可以使用Cache-Control請求指令指定這三種操作:

End-to-end reload（端到端重新加載）

　　這個請求包括一個“無緩存（no-cache）”cache-control指令，或者為了與HTTP/1.0客戶端兼容，使用“Pragma: no-cache”。在請求中，字段名不能包含在無緩存指令中。服務(wù)器在響應(yīng)此類請求時不能使用緩存副本。

Specific end-to-end revalidation（特定的端到端重新生效）

　　該請求包括一個“max-age=0”cache-control指令，該指令強(qiáng)制沿著到原始服務(wù)器的路徑中的每個緩存與下一個緩存或服務(wù)器一起重新驗(yàn)證自己的條目(如果有的話)。最初的請求包括一個緩存驗(yàn)證條件和客戶端的當(dāng)前驗(yàn)證器。

Unspecified end-to-end revalidation（未指定的端到端再校驗(yàn)）

　　該請求包括“max-age=0”緩存控制指令，該指令強(qiáng)制沿著到源服務(wù)器的路徑的每個緩存使用下一個緩存或服務(wù)器重新驗(yàn)證其自己的條目（如果有的話）。初始請求不包括緩存驗(yàn)證條件，沿著保存該資源的緩存條目的路徑（如果有的話）的具有其當(dāng)前驗(yàn)證器的緩存驗(yàn)證條件的第一個緩存。

max-age

　　當(dāng)通過max-age=0指令強(qiáng)制中間緩存重新驗(yàn)證其自己的緩存條目，并且客戶端在請求中提供了自己的驗(yàn)證器時，所提供的驗(yàn)證器可能與當(dāng)前存儲在緩存條目中的驗(yàn)證器不同。在這種情況下，緩存可以使用驗(yàn)證器來進(jìn)行自己的請求，而不影響語義透明性。

　　但是，驗(yàn)證器的選擇可能會影響性能。最好的方法是中間緩存使用它自己的驗(yàn)證器來進(jìn)行請求。如果服務(wù)器用304（Not Modified.）進(jìn)行響應(yīng)，則緩存可以向客戶端返回其現(xiàn)在已驗(yàn)證的副本，并帶有200（OK）響應(yīng)。但是，如果服務(wù)器用新的實(shí)體和緩存驗(yàn)證器進(jìn)行響應(yīng)，則中間緩存可以使用強(qiáng)比較函數(shù)將返回的驗(yàn)證器與客戶端請求中提供的驗(yàn)證器進(jìn)行比較。如果客戶端的驗(yàn)證器等于源服務(wù)器，則中間緩存只返回304（NotModified.）。否則，它返回具有200（OK）響應(yīng)的新實(shí)體。

　　如果請求包含no-cache指令，則不應(yīng)包括min-fresh、max-stale或max-age。

only-if-cached

　　在某些情況下，比如網(wǎng)絡(luò)連接性非常差的時候，客戶端可能希望緩存只返回它當(dāng)前存儲的響應(yīng)，而不是使用原始服務(wù)器重新加載或重新驗(yàn)證。要做到這一點(diǎn)，客戶端可以在請求中包含noly-if-cached指令。如果它接收到這個指令，緩存應(yīng)該使用與請求的其他約束一致的緩存條目進(jìn)行響應(yīng)，或者使用504(網(wǎng)關(guān)超時-Gateway Timeout)狀態(tài)進(jìn)行響應(yīng)。但是，如果一組緩存作為一個統(tǒng)一的系統(tǒng)進(jìn)行操作，并且具有良好的內(nèi)部連接，則該請求可以在該組緩存中轉(zhuǎn)發(fā)。

must-revalidate（必須重新驗(yàn)證）

　　因?yàn)榫彺婵赡芎雎苑?wù)器配置的指定過期時間,因?yàn)榭蛻舳苏埱罂赡馨╩ax-stale指令(也有類似的效果),該協(xié)議還包括一個源服務(wù)器的機(jī)制需要重新驗(yàn)證緩存條目的任何后續(xù)使用。當(dāng)必須重新驗(yàn)證指令出現(xiàn)在緩存接收到的響應(yīng)中時，該緩存必須在條目過期后使用該條目來響應(yīng)后續(xù)請求，而不優(yōu)先使用原始服務(wù)器重新驗(yàn)證該條目。(即。如果僅基于原始服務(wù)器的Expires或max-age值，緩存的響應(yīng)就過時了，那么每次緩存都必須執(zhí)行端到端重新驗(yàn)證。）

　　must-revalidate指令對于支持某些協(xié)議特性的可靠操作是必要的。在任何情況下，HTTP/1.1緩存必須遵守“must-revalidate”指令;特別是，如果緩存由于任何原因無法到達(dá)原始服務(wù)器，它必須生成504(網(wǎng)關(guān)超時)響應(yīng)。

　　服務(wù)器應(yīng)該發(fā)送“must-revalidate”指令，當(dāng)且僅當(dāng)在實(shí)體上重新驗(yàn)證請求失敗可能導(dǎo)致錯誤操作(如未執(zhí)行的財務(wù)事務(wù))時才發(fā)送該指令。接收方不得采取任何違反此指令的自動操作，也不得在重新驗(yàn)證失敗時自動提供實(shí)體的未驗(yàn)證副本。

　　盡管不建議這樣做，但是在嚴(yán)格的連接約束下操作的用戶代理可能違反此指令，但如果是這樣，則必須明確警告用戶已經(jīng)提供了未經(jīng)驗(yàn)證的響應(yīng)。每個未經(jīng)驗(yàn)證的訪問都必須提供警告，并且需要明確的用戶確認(rèn)。

proxy-revalidate（代理重新驗(yàn)證）

　　proxy-reavalidate指令的含義與must-revalidate指令相同，只是它不適用于非共享的用戶代理緩存。提供每次重新驗(yàn)證的服務(wù)(為了確保每個用戶已經(jīng)通過身份驗(yàn)證)。

它可以使用在回應(yīng)一個身份驗(yàn)證請求,允許用戶的緩存來存儲和后來返回響應(yīng),而不需要重新驗(yàn)證(因?yàn)樗呀?jīng)被該用戶身份驗(yàn)證一次),同時還要求代理服務(wù)許多用戶重新驗(yàn)證每一次(為了確保每個用戶已經(jīng)通過身份驗(yàn)證)。注意，這種經(jīng)過身份驗(yàn)證的響應(yīng)還需要“public”緩存控制指令，以便能夠完全緩存它們。

14.9.5No-Transform Directive

no-transform

　　中間緩存（代理）的實(shí)現(xiàn)者發(fā)現(xiàn)轉(zhuǎn)換某些實(shí)體的媒體類型是有用的。例如，非透明代理可以在圖像格式之間進(jìn)行轉(zhuǎn)換，以便節(jié)省緩存空間或減少慢速鏈路上的通信量。

　　然而，當(dāng)這些轉(zhuǎn)換應(yīng)用于特定類型的應(yīng)用程序?qū)嶓w時，會出現(xiàn)嚴(yán)重的操作問題。例如，用于醫(yī)學(xué)成像、科學(xué)數(shù)據(jù)分析以及使用端到端認(rèn)證的應(yīng)用都依賴于接收與原始實(shí)體-主體逐位相同（bit for bit identical——也就是每一字節(jié)都與原實(shí)體一樣）的實(shí)體主體。

　　因此，如果消息包括no-transform指令，則中間緩存或代理必須不改變那些在第13.5.2節(jié)中列出的、受no-transform指令制約的報頭。這意味著緩存或代理必須不改變由這些頭字段指定的實(shí)體主體的任何方面，包括實(shí)體主體本身的值。　　

14.9.6Cache Control Extensions

　　可以通過使用一個或多個緩存擴(kuò)展令牌來擴(kuò)展Cache-Control頭字段，每個令牌具有可選的分配值。可以在不改變其他指令的語義的情況下添加信息擴(kuò)展（不需要改變緩存行為的擴(kuò)展）。行為擴(kuò)展被設(shè)計(jì)為通過對緩存指令的現(xiàn)有基礎(chǔ)作為修飾符來工作。提供新的指令和標(biāo)準(zhǔn)指令，使得不理解新指令的應(yīng)用程序?qū)⒛J(rèn)執(zhí)行標(biāo)準(zhǔn)指令指定的行為，而理解新指令的應(yīng)用程序?qū)⒄J(rèn)識到它修改了與標(biāo)準(zhǔn)指令相關(guān)的需求。這樣，可以在不修改基礎(chǔ)協(xié)議的情況下，對緩存控制指令進(jìn)行擴(kuò)展。

　　這種擴(kuò)展機(jī)制依賴于HTTP緩存，它遵守為其原生HTTP版本定義的所有緩存控制指令，遵守某些擴(kuò)展，并忽略它不理解的所有指令。

　　例如，假設(shè)有一個名為community的新響應(yīng)指令，它充當(dāng)私有指令的修飾符。我們定義這個新指令是為了表示，除了任何非共享緩存之外，任何僅由值中指定的社區(qū)成員共享的緩存都可以緩存響應(yīng)。希望允許UCI社區(qū)在其共享緩存中使用私有響應(yīng)的源服務(wù)器可以通過包括下面的字段來實(shí)現(xiàn)這一點(diǎn)

Cache-Control: private, community=”UCI”

　　即使緩存不理解community cache-extension，看到這個header字段的緩存也會正常工作，因?yàn)樗矔吹讲⒗斫馑接兄噶睿虼四J(rèn)為安全行為。

　　不能識別的緩存指令必須被忽略;假設(shè)任何緩存指令可能無法被HTTP/1.1緩存識別，將與標(biāo)準(zhǔn)指令結(jié)合使用(或者響應(yīng)的默認(rèn)緩存能力，即使緩存不理解擴(kuò)展，緩存行為也將保持最低限度的正確性)。

14.10Connection

　　Connection通用頭字段允許發(fā)送方指定特定鏈接所需的選項(xiàng)，并且代理不能通過其他鏈接進(jìn)行通信。

　　Connection頭字段的語法如下：

　　Connection = “Connection” “:” 1#(connection-token)

　　connection-token = token

　　在Connection字段中列出的Message頭字段不能包含端到端類型的頭字段，比如Cache-Control。　　

　　HTTP/1.1為發(fā)送方定義了“close”連接選項(xiàng)，以表示連接將在響應(yīng)完成后關(guān)閉。比如：

　　Connection: close

　　無論在響應(yīng)還是請求中都表示在響應(yīng)或請求完成后，該鏈接不能被當(dāng)作持久鏈接。

　　不支持持久鏈接的HTTP／1.1應(yīng)用程序必須在每一個消息（message）中包含close鏈接選項(xiàng)。

　　接收包含Connection頭字段的HTTP/1.0(或較低版本)消息的系統(tǒng)，對于該字段中的每個連接令牌（coonection-token），必須從與連接令牌同名的消息中刪除和忽略任何頭字段。這可以防止這些頭字段被http /1.1代理錯誤轉(zhuǎn)發(fā)。（詳情見19.6.2小節(jié)）

14.11Content-Encoding

　　Content-Encoding實(shí)體頭字段被用來當(dāng)作media-type的調(diào)節(jié)器。當(dāng)存在時，它的值指示哪些附加的內(nèi)容編碼已經(jīng)應(yīng)用到實(shí)體主體，因此我們要知道在Content-Type頭字段中使用的media-type需要使用怎么樣的解碼機(jī)制。Content-Type主要用于允許文檔被壓縮而不丟失其底層媒體類型的特征。

Content-Encoding = “Content-Encoding” “:” 1#content-coding

　　內(nèi)容編碼在3.5中被定義。一個使用的例子：

Content-Encoding: gzip

　　內(nèi)容編碼是由請求URI標(biāo)識的實(shí)體的特性。典型地，實(shí)體用這樣的編碼方式存儲，并且只有在渲染內(nèi)容或類似的情況下使用之前才被解碼。然而，除非消息中存在“no-transform”緩存控制指令，否則，如果已知接收方可以接受新編碼，則非透明代理可以修改內(nèi)容編碼。

　　如果一個實(shí)體的內(nèi)容編碼不是“identity”，然后，響應(yīng)必須包含內(nèi)容編碼實(shí)體頭(14.11節(jié))，其中列出了使用的非標(biāo)識內(nèi)容編碼。

　　如果原始服務(wù)器無法接受請求消息中實(shí)體的內(nèi)容編碼，則服務(wù)器應(yīng)以狀態(tài)碼415(Unsupported Media Type)進(jìn)行響應(yīng)。

　　如果多個編碼被應(yīng)用到一個實(shí)體中，內(nèi)容編碼必須按照應(yīng)用它們的順序列出。有關(guān)編碼參數(shù)的其他信息可以由本規(guī)范未定義的其他實(shí)體頭字段提供。

14.12Content-Language

　　Content-Language 實(shí)體頭字段描述了封閉實(shí)體的預(yù)期受眾的自然語言。注意，這可能不等于實(shí)體主體（entity-body）中使用的所有語言。

　　Content-Language = “Content-Language” “:” 1#language-tag

　　語言標(biāo)識在3.10節(jié)中做了定義。內(nèi)容語言的主要目的是允許用戶根據(jù)自己的首選語言識別和區(qū)分實(shí)體。因此，如果正文內(nèi)容僅針對具有丹麥語文化的讀者，則適當(dāng)?shù)姆秶?/p>

　　Content-Language: da

　　如果沒有指定內(nèi)容語言，默認(rèn)情況下內(nèi)容是針對所有語言受眾的。這可能意味著發(fā)送方不認(rèn)為它是特定于任何自然語言的，或者發(fā)送方不知道它是針對哪種語言的。

　　可以為多個受眾列出多個語言的內(nèi)容。例如，同時在原始毛利語和英語版本中出現(xiàn)的《瓦伊坦吉條約》的譯本就需要

　　Content-Language: mi, en

　　然而，僅僅因?yàn)槎鄠€語言存在于一個實(shí)體中并不意味著它是針對多個語言受眾的。舉個例子，初學(xué)者的語言入門，比如“拉丁語第一課”，很明顯是用來讓有英語基礎(chǔ)的觀眾使用的。在這種情況下，內(nèi)容語言將只包括“EN”。

　　Content-Language可以應(yīng)用于任何媒體類型——它不限于文本文檔。

14.13Content-Length

　　Content-Length實(shí)體頭字段表示實(shí)體內(nèi)容的大小，發(fā)送給接收者的是一個十進(jìn)制八位字節(jié)的數(shù)字，在HEAD方法中，如果請求是GET，那么將發(fā)送的實(shí)體主體的大小。

　　Content-Length = “Content-Length” “:” 1*DIGIT

　　下面是一個例子

　　Content-Length: 3495

　　應(yīng)用程序應(yīng)該使用此字段來指示消息體的傳輸長度（transfer-length），除非第4.4節(jié)中的規(guī)則禁止這一點(diǎn)。

　　任何大于或等于0的內(nèi)容長度都是一個有效值。第4.4節(jié)描述了如果沒有提供內(nèi)容長度，如何確定消息體的長度。

　　注意，這個字段的含義與MIME中相應(yīng)的定義有很大的不同，MIME是“消息/外部體”（”message/external-body”）內(nèi)容類型中使用的可選字段。在HTTP中，只要消息的長度可以在傳輸之前確定，就應(yīng)該發(fā)送它，除非第4.4節(jié)中的規(guī)則禁止這一點(diǎn)。

14.14Content-Location

　　當(dāng)從與請求資源的URI分離的位置訪問該實(shí)體時，可以使用Content-Location實(shí)體頭字段為消息中包含的實(shí)體提供資源位置。服務(wù)器應(yīng)該為響應(yīng)實(shí)體對應(yīng)的變體提供內(nèi)容位置;特別是當(dāng)一個資源有多個與它相關(guān)聯(lián)的實(shí)體，并且這些實(shí)體實(shí)際上有單獨(dú)的位置，通過這些位置可以單獨(dú)訪問它們，服務(wù)器應(yīng)該為返回的特定變體提供一個內(nèi)容位置。

　　Content-Location = “Content-Location” “:”( absoluteURI | relativeURI )

　　Content-Location的值也定義了基本實(shí)體的URI。

　　Content-Location的值不是原始請求URI的代替;它只是請求時對應(yīng)于此特定實(shí)體的資源位置的聲明。如果希望標(biāo)識特定實(shí)體的源，將來的請求可以指定Content-LocationURI作為請求URI。

　　緩存不能假設(shè)具有與用于檢索它的URI不同的內(nèi)容位置的實(shí)體可以用于響應(yīng)該內(nèi)容位置URI上的稍后請求。然而，Content-Location可用于區(qū)分從單個請求資源檢索的多個實(shí)體，如第13.6節(jié)所述。

　　如果Content-Location是一個相對的URI標(biāo)識，相對URI是相對于請求URI解釋的。

　　在PUT或Post請求中Content-Location頭字段是未定意的。服務(wù)器在這種情況下會忽略這些內(nèi)容。

14.15Content-MD5

　　RFC 1864中定義的Content-MD5實(shí)體頭字段是實(shí)體主體的MD5摘要，用于提供實(shí)體主體的端到端消息完整性檢查（MIC）。（注意：MIC用于檢測傳輸中的實(shí)體主體的意外修改，但不能防止惡意攻擊。）

　　Content-MD5 = “Content-MD5” “:” md5-digest

　　md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>

　　Content-MD5頭字段可以由源服務(wù)器或客戶端生成，以作為實(shí)體主體的完整性檢查。只有原始服務(wù)器或客戶端可能生成Content-MD5頭字段；代理和網(wǎng)關(guān)不能生成，因?yàn)檫@將破壞其作為端到端完整性檢查的價值。任何實(shí)體主體的接收者，包括網(wǎng)關(guān)和代理，都可以檢查這個頭字段中的摘要值是否與接收到的實(shí)體主體的摘要值匹配。

　　MD5摘要是基于實(shí)體主體的內(nèi)容計(jì)算的，包括已經(jīng)應(yīng)用的任何內(nèi)容編碼，但不包括應(yīng)用到消息主體的任何傳輸編碼。如果用傳輸編碼接收到消息，則必須在根據(jù)接收到的實(shí)體檢查Content-MD5值之前刪除該編碼。

　　這樣做的結(jié)果是，在實(shí)體主體的八位字節(jié)上精確地計(jì)算摘要，并且如果沒有應(yīng)用傳輸編碼，則按照這樣的順序發(fā)送摘要。

　　HTTP擴(kuò)展了RFC 1864，允許為MIME復(fù)合媒體類型（例如，multipart/*和message/rfc822）計(jì)算摘要，但這并不改變?nèi)缜岸嗡x的摘要的計(jì)算方式。

　　這有幾個后果。復(fù)合類型的實(shí)體主體可能包含許多主體部分，每個部分都有自己的MIME和HTTP頭(包括Content-MD5、Content-Transfer-Encoding和Content-Encoding頭)。如果body-part具有content – transfer – encoding頭字段，則假設(shè)body-part的內(nèi)容已經(jīng)應(yīng)用了編碼，并且body-part包含在content – md5摘要中，如下所示:之后的運(yùn)行中。在主體部分中不允許使用Transfer-Encoding頭字段。

　　在計(jì)算或檢查摘要之前，不能將所有換行符轉(zhuǎn)換為CRLF:實(shí)際傳輸?shù)奈谋局惺褂玫膿Q行約定在計(jì)算摘要時必須保持不變。

　　注意：盡管Content-MD5的定義對于HTTP與RFC 1864對于MIME實(shí)體主體的定義完全相同，但是在幾種情況下，Content-MD5對于HTTP實(shí)體主體的應(yīng)用不同于其對于MIME實(shí)體主體的應(yīng)用。一種是HTTP不同于MIME，它不使用內(nèi)容傳輸編碼，但使用傳輸編碼和內(nèi)容編碼。另一個原因是HTTP比MIME更頻繁地使用二進(jìn)制內(nèi)容類型，因此值得注意的是，在這種情況下，用于計(jì)算摘要的字節(jié)順序是為該類型定義的傳輸字節(jié)順序。最后，HTTP允許使用幾種換行規(guī)則中的任何一種來傳輸文本類型，而不僅僅是使用CRLF的規(guī)范形式。

14.16Content-Range

　　Content-Range實(shí)體頭字段與部分實(shí)體主體一起發(fā)送，以指定在完整實(shí)體主體中應(yīng)該在何處應(yīng)用部分主體。范圍單元在3.12節(jié)中定義。

　　Content-Range = “Content-Range” “:” content-range-spec

　　content-range-spec = byte-content-range-spec

　　byte-content-range-spec = bytes-unit SP

　　　　　 　　byte-range-resp-spec “/” ( instance-length | “*” )

　　byte-range-resp-spec 　= (first-byte-pos “-” last-byte-pos) | “*”

　　instance-length = 1*DIGIT

　　報頭應(yīng)該指示完整實(shí)體的總長度，除非這個長度是未知的或難以確定的。星號“*”字符表示在生成響應(yīng)時，實(shí)例長度未知。

　　與byte-ranges-specifier的值（參見14.35.1節(jié)）不同，byte-range-resp-spec必須只指定一個范圍，并且必須包含該范圍的第一個和最后一個字節(jié)的絕對字節(jié)位置。

　　當(dāng)一個byte-range-resp-spec存在一個byte-content-range-spec值，并且該值的最后一位（last-byte-pos）小于它的第一位（first-byte-po），或者它的實(shí)際長度（instance-length）小于或等于它最后一位（last-byte-pos），這樣是不允許的。接收者應(yīng)該忽略一個未通過驗(yàn)證的byte-content-range-spec，以及隨其傳輸?shù)娜魏纹渌麅?nèi)容。

　　發(fā)送具有狀態(tài)代碼416（請求范圍不可滿足）的響應(yīng)的服務(wù)器應(yīng)該包括具有byte-range-resp-spec的值為“*”的Content-Range字段。實(shí)例長度指定所選資源的當(dāng)前長度。使用狀態(tài)代碼206（部分內(nèi)容）的響應(yīng)不能包含具有“*”字節(jié)的byte-range- resp-spec字段。　　

　　下面是一個字節(jié)內(nèi)容范圍規(guī)則值(byte-content-range-spec)的例子，假設(shè)實(shí)體總共包含了1234字節(jié)：

　　. 最開始的500個字節(jié): bytes 0-499/1234

　　. 第二個五百個字節(jié): bytes 500-999/1234

　　. 除了前五百個字節(jié): bytes 500-1233/1234

　　. 最后五百個字節(jié)：bytes 734-1233/1234

　　當(dāng)一個HTTP消息包含一個單一范圍的內(nèi)容(例如,一個響應(yīng)請求一個單一的范圍,或者請求一組沒有任何漏洞的重疊范圍),該內(nèi)容與Content-Range頭字段一起傳遞,并且Content-Length頭字段應(yīng)該顯示實(shí)際傳輸?shù)淖止?jié)數(shù)。例如,

　　HTTP/1.1 206 Partial content

　　Date: Wed, 15 Nov 1995 06:25:24 GMT

　　Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT

　　Content-Range: bytes 21010-47021/47022

　　Content-Length: 26012

　　Content-Type: image/gif

　　當(dāng)HTTP消息包含多個范圍(例如，對多個非重疊范圍的請求的響應(yīng))的內(nèi)容時，這些內(nèi)容作為多部分消息進(jìn)行傳輸。用于此目的的大部分媒體類型是附錄19.2中定義的“多multipart/byteranges”。兼容性問題見附錄19.6.3。

　　對于單個范圍的請求的響應(yīng)不能使用multipart/byteranges媒體類型來發(fā)送。對多個范圍的請求的響應(yīng)，如果其結(jié)果是單個范圍，可能作為帶有一個部分的multipart/byteranges媒體類型發(fā)送。不能解碼multipart/byteranges消息的客戶端不能在單個請求中請求多個byte-ranges。

　　當(dāng)客戶端在一個請求中請求多個byte-ranges時，服務(wù)器應(yīng)該按照它們在請求中出現(xiàn)的順序返回它們。

　　如果服務(wù)器由于語法無效而忽略了byte-range-spec，則服務(wù)器應(yīng)將請求視為不存在無效Range頭字段。（通常，這意味著返回包含完整實(shí)體的200響應(yīng)）。

　　如果服務(wù)器收到一個請求(除了一個包括If-Range請求頭字段)和一個請求頭字段不可滿足的范圍(即所有的byte-range-spec值first-byte-pos值大于當(dāng)前選中的資源的長度）,它應(yīng)該返回一個416響應(yīng)代碼(請求的范圍不可以滿足的)(10.4.17小節(jié))。

　　注意:對于不可滿足Range請求頭字段情況，客戶端不能依賴服務(wù)器發(fā)送416(Requested range not satisfiable)響應(yīng)來代替200 (OK)響應(yīng)，因?yàn)椴皇撬蟹?wù)器都支持這個請求頭。

14.17Content-Type

　　Content-Type實(shí)體字段表示發(fā)送給接收方的實(shí)體主體的媒體類型，對于HEAD方法，則表示如果請求是GET，應(yīng)該發(fā)送的媒體類型。

　　Content-Type = “Content-Type” “:” media-type

　 媒體類型已經(jīng)在3.7小節(jié)中定義，下面是該字段的一個例子

　　Content-Type: text/html; charset=ISO-8859-4

　　第7.2.1節(jié)進(jìn)一步討論了確定實(shí)體的媒體類型的方法。

14.18Date

　　Date通用頭字段表示消息產(chǎn)生的日期和時間，跟RFC822中的orig-date一樣。該字段的值是一個HTTP—DATE，它的詳細(xì)描述在3.3.1小節(jié)，它在傳輸?shù)臅r候必須被格式化。

　　Date = “Date” “:” HTTP-date

　　下面是一個例子：

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

　　源服務(wù)器必須在所有的響應(yīng)中包含一個Date頭字段，除了以下的情況：

　　　　1.如果響應(yīng)的狀態(tài)碼是100或者101，在服務(wù)器的配置中，響應(yīng)中可以包含Date頭字段。

　　　　2.如果響應(yīng)狀態(tài)代碼傳遞了一個服務(wù)器錯誤，例如500(內(nèi)部服務(wù)器錯誤)或503(服務(wù)不可用)，并且不方便或不可能生成一個有效的日期。

　　　　3.如果服務(wù)器沒有一個可以提供合理的接近當(dāng)前時間的值，那么它的響應(yīng)一定不能包含一個Date頭字段，我們必須遵守14.18.1小節(jié)中的相關(guān)規(guī)則。

　　如果消息將通過需要Date的協(xié)議被接收方或網(wǎng)關(guān)緩存，則接收到的沒有日期標(biāo)頭字段的消息必須由接收方分配一個Date頭字段。沒有時鐘的HTTP實(shí)現(xiàn)不能緩存響應(yīng)，并且不必在每次使用時重新驗(yàn)證它們。HTTP緩存，尤其是共享緩存，應(yīng)該使用NTP等機(jī)制來使其時鐘與可靠的外部標(biāo)準(zhǔn)同步。

　　客戶端應(yīng)該只在包含entity-body的消息中發(fā)送Date頭字段，就像PUT和POST請求那樣，即使這樣，它也是可選的。沒有時鐘的客戶端不能在請求中發(fā)送Date頭字段。

　　在日期標(biāo)頭中發(fā)送的HTTP-date不應(yīng)該表示消息生成之后的日期和時間。它應(yīng)該表示消息生成時日期和時間的最佳近似值，除非實(shí)現(xiàn)無法生成合理準(zhǔn)確的日期和時間。理論上，日期應(yīng)該表示實(shí)體生成之前的時刻。在實(shí)踐中，日期可以在不影響其語義值的情況下，消息發(fā)起期間的任何時候生成。

14.18.1Clockless Origin Server Operation

　　一些原始服務(wù)器實(shí)現(xiàn)可能沒有可用的時鐘。沒有時鐘的原始服務(wù)器不能給響應(yīng)分配Expires或Last-Modified值，除非Date值是由與資源相關(guān)聯(lián)的、具有可靠時鐘的系統(tǒng)或用戶產(chǎn)生的。它可能分配一個Expires值，該值在服務(wù)器配置時或之前是已知的（這使得“pre-expiration”的響應(yīng)無需單獨(dú)的存儲每個資源的Expires值）。

14.19ETag

　　ETAG響應(yīng)頭字段為所請求的變體提供實(shí)體標(biāo)簽的當(dāng)前值。在14.24,14.26和14.44小節(jié)中描述了與實(shí)體標(biāo)簽一起使用的頭字段。實(shí)體標(biāo)簽可用于與來自同一資源的其他實(shí)體進(jìn)行比較（參見第13.3.3節(jié)）。

　　ETag = “ETag” “:” entity-tag

　　例子:

　　ETag: “xyzzy”

　　ETag: W/”xyzzy”

　　ETag: “”

14.20Expect

　　Expect請求頭字段被用來描述客戶端需要的特定的服務(wù)器行為。

　　Expect = “Expect” “:” 1#expectation

　　expectation = “100-continue” | expectation-extension

　　expectation-extension = token [ “=” ( token | quoted-string ) *expect-params ]

　　expect-params = “;” token [ “=” ( token | quoted-string ) ]

　　服務(wù)器如果無法理解或者遵守任何請求中Expect頭字段中的任何存在的預(yù)期值，那么應(yīng)該返回適當(dāng)?shù)腻e誤狀態(tài)。服務(wù)器必須返回417錯誤，如果任何的“期望”都無法滿足，或者有其他的客戶端請求錯誤，一些4XX錯誤。

　　該頭字段被定義為可擴(kuò)展的語法，以用在未來可能的擴(kuò)展中。如果一個服務(wù)器接收到了它不支持的Expect頭字段中所包含的拓展詞（expectation-extension），那么它必須返回一個417錯誤（Expectation Failed）。

　　“期望”值的比較對于未引用的tokens（包括100-continue）不區(qū)分大小寫，并且對于引用字符串的期望擴(kuò)展區(qū)分大小寫。

　　Expect機(jī)制是逐跳（hop-by-hop）的：也就是說，如果HTTP/1.1代理接收到了預(yù)期無法滿足的請求，則必須返回417（Expectation Failed）狀態(tài)。但是，預(yù)期請求頭本身是端到端的；如果轉(zhuǎn)發(fā)請求，則必須轉(zhuǎn)發(fā)它。

　　許多較老的HTTP/1和HTTP/1.1應(yīng)用程序不理解Expect頭字段。

　　100（continue）狀態(tài)碼的使用方法請查閱8.2.3小節(jié)。

14.21Expires

　　Expires實(shí)體頭字段給出響應(yīng)過期的日期/時間。過期的緩存內(nèi)容通常不會返回緩存機(jī)制所緩存的內(nèi)容(包括代理緩存或用戶代理緩存)，除非它首先通過原始服務(wù)器(或具有實(shí)體的新副本的中間緩存)進(jìn)行驗(yàn)證。有關(guān)到期模型的進(jìn)一步討論，請參閱第13.2節(jié)。

　　Expires字段的存在并不意味著原始資源將在該時間節(jié)點(diǎn)點(diǎn)之前或之后改變或不再存在。

　　該字段值的格式是由3.3.1節(jié)中的HTTP日期定義的絕對日期和時間；它必須是RFC 1123日期格式：

　　Expires = “Expires” “:” HTTP-date

　　下面是一個使用案例

　　Expires: Thu, 01 Dec 1994 16:00:00 GMT

　　注意:如果響應(yīng)包含一個Cache-Control字段和max-age指令(參見14.9.3節(jié))，該指令將覆蓋Expires字段。

　　HTTP/1.1客戶端和緩存必須處理其他無效的日期格式，特別是包含“0”的值(例如“已過期”)。

　　如果想要將響應(yīng)標(biāo)記為“已過期”，那么源服務(wù)器需要發(fā)送一個等于日期標(biāo)頭值的過期日期。(詳情請參閱第13.2.4節(jié)中的過期計(jì)算規(guī)則。)

　　為了將響應(yīng)標(biāo)記為“永不過期”，源服務(wù)器發(fā)送的Expires日期的值為該響應(yīng)發(fā)送時起的一年后，那么HTTP/ 1.1服務(wù)器不應(yīng)在未來發(fā)送超過一年的過期日期。

　　如果Expires頭字段的日期值在將來的某個時間出現(xiàn)在默認(rèn)為不可緩存的響應(yīng)上，那么表示響應(yīng)是可緩存的，除非Cache-Control頭字段(14.9小節(jié))另有指示。

14.22From

　　From請求頭字段，如果存在，需要包含一個客戶端使用者的互聯(lián)網(wǎng)郵箱地址。該地址應(yīng)該是可以被機(jī)器識別的“machine-usable”，具體的規(guī)則在RFC 822[9]并在RFC 1123[8]中做了一些升級：

　　From = “From” “:” mailbox

　　下面是一個例子：

　　From: webmaster@w3.org

　　該頭字段可用于日志記錄，并可用于標(biāo)識無效或不想要請求的資源。它不應(yīng)該用作不安全的訪問保護(hù)形式。該字段的解釋是，請求是代表指定的人所發(fā)出的，該人對執(zhí)行方法負(fù)有責(zé)任。特別是，機(jī)器人代理應(yīng)該包括這個頭，以便在接收端出現(xiàn)問題時可以聯(lián)系負(fù)責(zé)運(yùn)行機(jī)器人的人。

　　此字段中的Internet電子郵件地址可能與發(fā)出請求的Internet主機(jī)分開。例如，當(dāng)請求通過代理傳遞時，應(yīng)該使用原始發(fā)布者的地址。

　　客戶端不應(yīng)該在未經(jīng)用戶批準(zhǔn)的情況下發(fā)送From頭字段，因?yàn)檫@可能會與用戶的隱私利益或其站點(diǎn)的安全策略發(fā)生沖突。強(qiáng)烈建議用戶能夠在請求之前的任何時候禁用、啟用和修改此字段的值。

14.23Host

　　Host 請求頭字段指定了從用戶給出的原始URI或引用資源（通常是HTTP URL，如3.2.2節(jié)所述）中所獲得的被請求資源的網(wǎng)絡(luò)主機(jī)和端口號。HOST字段值必須代表原始URL給出的源服務(wù)器或網(wǎng)關(guān)的命名權(quán)限。這允許原始服務(wù)器或網(wǎng)關(guān)區(qū)分內(nèi)部模糊的（內(nèi)部歧義）URL，例如，用于單個IP地址上的多個主機(jī)名的服務(wù)器URL的根名稱“/”。

　　Host = “Host” “:” host [ “:” port ] ; Section 3.2.2

　　如果一個host尾部并沒有跟隨端口號信息，那么就是默認(rèn)的端口號（比如，HTTP URl的默認(rèn)端口號是80）。舉個例子。向“http://www.w3.org/pub/WWW”所發(fā)出的請求會包含以下信息：

　　GET /pub/WWW/ HTTP/1.1

　　Host: www.w3.org

　　在HTTP/1.1的客戶端請求信息中必須包含HOST頭字段。如果所請求的URI不包括所請求服務(wù)的Internet主機(jī)名，則必須給Host頭字段一個空值。HTTP/1.1代理必須確保它轉(zhuǎn)發(fā)的任何請求信息中都包含適當(dāng)?shù)腍OST頭字段，該字段標(biāo)識代理請求的服務(wù)。所有基于HTTP/1.1的互聯(lián)網(wǎng)請求的服務(wù)器必須對任何缺少主機(jī)頭字段的HTTP/1.1請求消息使用400（Bad Request）狀態(tài)碼進(jìn)行響應(yīng)。

　　有關(guān)HOST字段的其他要求見第5.2和19.6.1.1節(jié)。

14.24If-Match

　　If-Match請求頭字段需要與一個使其成為“條件”的方法一起使用。擁有一個或多個之前從資源中獲得的實(shí)體的客戶端可以通過在If-Match頭字段中包含相關(guān)實(shí)體標(biāo)記的列表來驗(yàn)證這些實(shí)體中的一個是否是當(dāng)前匹配的。實(shí)體標(biāo)記在3.11節(jié)中有詳細(xì)說明。這個特性的目的是允許以最少的開銷，高效地更新緩存的信息。在更新請求時，它還用于防止無意中修改錯誤版本的資源。作為一種特殊情況，“*”值匹配資源的任何當(dāng)前實(shí)體。

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

　　如果任何實(shí)體標(biāo)記與在響應(yīng)該資源上的類似GET請求（沒有if-Match頭字段）時返回的實(shí)體的實(shí)體標(biāo)記相匹配，或者如果“*”值在IF-Matc中被給出并且任何當(dāng)前的實(shí)體都存在該資源中，則服務(wù)器可以執(zhí)行所請求的方法就像if-Match頭字段不存在一樣。

　　服務(wù)器必須使用強(qiáng)比較函數(shù)（參見第13.3.3節(jié)）來比較If-Match中的實(shí)體標(biāo)簽。

　　如果沒有匹配的實(shí)體標(biāo)記，或者給定了“*”值，且不存在當(dāng)前實(shí)體，服務(wù)器就不能執(zhí)行請求的方法，必須返回412(Precondition Failed)響應(yīng)。當(dāng)客戶端希望阻止一個更新類型的方法(如PUT)修改自客戶端上次檢索后已更改的資源時，這種行為最有用。

　　如果請求在沒有if-Match頭字段的情況下會導(dǎo)致除了2xx或412狀態(tài)之外的任何結(jié)果，則必須忽略if-Match頭字段。

　　“if-Match：*”的含義是，如果源服務(wù)器(或緩存，可能使用變體機(jī)制，請參見14.44節(jié))選擇的內(nèi)容存在，則應(yīng)該執(zhí)行該方法，如果內(nèi)容不存在，則必須不執(zhí)行該方法。

　　更新資源(例如PUT)的請求可能包含if-match頭字段，以表示如果與if-match值(單個實(shí)體標(biāo)記)對應(yīng)的實(shí)體不再是該資源的表示，則不得應(yīng)用請求方法。這允許用戶表示，如果資源在他們不知情的情況下被更改，他們不希望請求成功。

　　例如：

　　If-Match: “xyzzy”

　　If-Match: “xyzzy”, “r2d2xxxx”, “c3piozzzz”

　　If-Match: *

　　一個請求中是否可以同時存在If-Match字段和If-None-Match或If-Modified-Since頭字段在本規(guī)范中并未定義。

14.25If-Modified-Since

　　If-Modified-Since請求頭字段需要與一個使其成為“條件”的方法一起使用：如果請求變量在該字段給出的時間范圍內(nèi)沒有被修改，那么服務(wù)器則不能返回實(shí)體內(nèi)容。替代的，一個沒有任何信息體的304（Not Modified）響應(yīng)會被返回。

　　If-Modified-Since = “If-Modified-Since” “:” HTTP-date

　　下面是該字段的一個例子：

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

　　一個帶有If-Modified-Since頭字段且沒有Range頭字段的GET方法只要求標(biāo)識的實(shí)體在If-Modified-Since頭字段給出的日期之后被修改，才會被傳遞。確定這一點(diǎn)的算法包括下列情況:　　

　　a) 如果請求通常不會導(dǎo)致200 (OK)狀態(tài)，或者傳遞的If-Modified-Since日期無效，則響應(yīng)與普通GET完全相同。晚于服務(wù)器當(dāng)前時間的日期無效。

　　b) 如果該變體自If-Modified-Since所攜帶的日期以來進(jìn)行了修改，則響應(yīng)與普通GET完全相同。

　　c)如果該變體在有效的If-Modified-Since日期之后沒有被修改，服務(wù)器應(yīng)該返回304(沒有修改)響應(yīng)。

　　這個特性的目的是允許以最少的事務(wù)開銷來更高效地更新緩存的信息。

　　　　注意：Range請求頭字段會修改If-Modified-Since的含義。詳情請見14.35小節(jié)。

　　注意:因?yàn)闀r間是由服務(wù)器確定的，服務(wù)器的時間可能與客戶端的時間不同步。

　　　　注意：在處理If-Modified-Since頭字段時，一些服務(wù)器將使用精確的日期比較函數(shù)而不是小于函數(shù)來決定是否發(fā)送304(未修改)響應(yīng)。為了獲得最好的結(jié)果，當(dāng)發(fā)送一個If-Modified-Since頭字段來進(jìn)行緩存驗(yàn)證時，建議客戶端盡可能使用在上一個Last-Modified頭字段中收到的確切日期字符串。

　　　　注意：如果客戶端在If-Modified-Since頭字段中使用任意日期，而不是使用從同一個請求的Last-Modified頭字段中提取的日期，那么客戶端應(yīng)該知道這個日期是用服務(wù)器中的時間來做為解釋的。由于客戶端和服務(wù)器之間的時間并不相同，客戶端需要考慮不同步時鐘和舍入問題。這包括，如果文檔在第一次請求的時間和后續(xù)請求中存在If-Modified-Sinc日期之間發(fā)生了更改，那么可能存在競態(tài)條件;如果If-Modified-Since日期來自客戶端的時鐘，且并沒有修改服務(wù)器的時鐘，則可能存在時鐘偏移相關(guān)的問題。由于網(wǎng)絡(luò)延遲，客戶端和服務(wù)器之間的不同時間間隔即使在修正后也不可能完全一樣。

　　一個請求中是否可以同時存在If-Match字段和If-None-Match或If-Modified-Since頭字段在本規(guī)范中并未定義。

14.26If-None-Match

　　If-None-Match請求頭字段需要與一個使其成為“條件”的方法一起使用。擁有一個或多個先前從資源中獲得的實(shí)體的客戶端可以通過在If-None-Match頭字段中包含相關(guān)實(shí)體標(biāo)記的列表來驗(yàn)證這些實(shí)體都不是當(dāng)前的。這個特性的目的是允許以最少的事務(wù)開銷來高效地更新緩存的信息。它還用于防止客戶端認(rèn)為資源不存在時在無意中使用一些方法修改現(xiàn)有資源(例如PUT)。

作為一種特殊情況，“*”值匹配資源的任何當(dāng)前實(shí)體。

If-None-Match = “If-None-Match” “:” ( “*” | 1#entity-tag )

　　如果任何實(shí)體標(biāo)記匹配該實(shí)體標(biāo)記，那么將會導(dǎo)致在使用一個類似GET請求(不具有If-None-Match請求頭)下的資源被返回，或者給出的If-None-Match請求頭字段的值時*號并且當(dāng)前存在任何屬于該資源的實(shí)體，除非必要否則服務(wù)器一定不能執(zhí)行所請求的方法，因?yàn)樵贗f-Modified-Since請求頭字段中資源的修改日期是不匹配的。。相反，如果請求方法是GET或HEAD，服務(wù)器應(yīng)該使用304(未修改)響應(yīng)進(jìn)行響應(yīng)，包括與緩存相關(guān)的頭字段(特別是與ETag匹配的一個實(shí)體)。對于所有其他請求方法，服務(wù)器必須以412狀態(tài)響應(yīng)(Precondition Failed)。

　　有關(guān)如何確定兩個實(shí)體標(biāo)記是否匹配的規(guī)則，請參閱第13.3.3節(jié)。弱比較函數(shù)只能用于GET或HEAD請求。

　　如果實(shí)體標(biāo)記都不匹配，那么服務(wù)器可以執(zhí)行請求的方法，就好像If-None-Match頭字段不存在一樣，但是必須忽略請求中存在的任何If-Modified-Since頭字段。也就是說，如果沒有實(shí)體標(biāo)記匹配，服務(wù)器就不能返回304(Not Modified)響應(yīng)。

　　如果請求在沒有If-None-Match頭字段的情況下，結(jié)果不是2xx或304狀態(tài)，則必須忽略If-None-Match標(biāo)頭。(請參閱第13.3.4節(jié)，了解在同一請求中同時出現(xiàn)If-Modified-Since和If-None-Match時的服務(wù)器行為。)

　　“If-None-Match: *”的意思是，如果原始服務(wù)器(或緩存可能使用變體機(jī)制，請參見14.44節(jié))選擇的表示存在，則不能執(zhí)行該方法，如果表示不存在，則應(yīng)該執(zhí)行該方法。這個特性用于防止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-Match字段和If-None-Match或If-Modified-Since頭字段在本規(guī)范中并未定義。

14.27If-Range

　　如果客戶端在其緩存中有一個實(shí)體的部分副本，并且希望在其緩存中有整個實(shí)體的最新副本，那么它可以使用Range 請求頭和一個有條件的GET(使用If-Unmodified-Since和If-Match)。但是，如果由于實(shí)體被修改而導(dǎo)致條件失敗，那么客戶端將不得不發(fā)出第二次請求以獲得整個當(dāng)前實(shí)體主體。

　　If-Range報頭允許客戶端“短路（short-circuit）”第二個請求。非正式地說，它的意思是“如果實(shí)體沒有改變，就把我缺少的部分發(fā)給我;否則，將整個新實(shí)體發(fā)送給我”。

If-Range = “If-Range” “:” ( entity-tag | HTTP-date )

　　如果客戶端沒有實(shí)體的實(shí)體標(biāo)記，但是有最后修改日期，它可以在If-Range頭字段中使用該日期。(服務(wù)器可以通過檢查不超過兩個字符來區(qū)分有效的HTTP-date和任何形式的實(shí)體標(biāo)記。)If-Range頭字段應(yīng)該只與Range頭字段一起使用，如果請求不包含Range頭字段，或者服務(wù)器不支持子范圍操作，則必須忽略該報頭。

If the entity tag given in the If-Range header matches the current entity tag for the entity, then the server SHOULD provide the specified sub-range of the entity using a 206 (Partial content) response. If the entity tag does not match, then the server SHOULD return the entire entity using a 200 (OK) response.

　　如果If-Range頭字段中的實(shí)體標(biāo)記與實(shí)體的當(dāng)前實(shí)體標(biāo)記匹配，那么服務(wù)器應(yīng)該使用206(Partial content)響應(yīng)提供實(shí)體的指定子范圍。如果實(shí)體標(biāo)記不匹配，那么服務(wù)器應(yīng)該使用200 (OK)響應(yīng)返回整個實(shí)體。

14.28If-Unmodified-Since

　　If-Unmodified-Since請求頭字段需要與一個使其成為“條件”的方法一起使用。如果請求的資源在此字段中指定的時間之后沒有被修改，服務(wù)器應(yīng)該執(zhí)行請求的操作，就像If-Unmodified-Sincee頭文件不存在一樣。

　　如果請求的變體自指定時間以來已經(jīng)被修改，服務(wù)器必須不執(zhí)行請求的操作，并且必須返回412(Precondition Failed)狀態(tài)。

　　If-Unmodified-Since = “If-Unmodified-Since” “:” HTTP-date

　　下面是該字段的一個例子:

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

　　如果在請求正常(例如，請求中沒有If-Unmodified-Since報頭)的情況下，，可能會產(chǎn)生除了2xx或412狀態(tài)外的其他任何狀態(tài)，那么If-Unmodified-Since報頭應(yīng)該被忽略。

　　如果指定的日期無效，則忽略該頭字段。

　　此規(guī)范未定義具有If-Unmodified-Since標(biāo)頭字段和If-None-Match或If-Modified-Since標(biāo)頭字段的請求的結(jié)果。

14.29Last-Modified

　　Last-Modified實(shí)體頭字段指示原始服務(wù)器認(rèn)為該變體最后被修改的日期和時間。

　　Last-Modified = “Last-Modified” “:” HTTP-date

下面是該字段的是個用法例子：

　　Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

　　這個頭字段的確切含義取決于原始服務(wù)器的實(shí)現(xiàn)和原始資源的性質(zhì)。對于文件，可能只是文件系統(tǒng)最后一次修改的時間。對于包含動態(tài)部件的實(shí)體，它可能是其組件部件的最后一次修改時間集的最近一次修改時間集。對于數(shù)據(jù)庫網(wǎng)關(guān)，它可能是記錄的最后更新時間戳。對于虛擬對象，可能是最后一次更改的內(nèi)部狀態(tài)。

　　源服務(wù)器不能發(fā)送晚于服務(wù)器發(fā)出消息時間的Last-Modified日期。在這種情況下，如果資源的最后一次修改將指示將來的某個時間，則服務(wù)器必須將該日期替換為消息發(fā)起日期。

　　原始服務(wù)器應(yīng)該包含盡可能接近于實(shí)體生成響應(yīng)的時間的日期值的Last-Modified值。這允許接收方準(zhǔn)確評估實(shí)體的修改時間，特別是當(dāng)實(shí)體在生成響應(yīng)時發(fā)生更改。

　　HTTP/1.1服務(wù)器應(yīng)該在可行的情況下發(fā)送Last-Modified。

14.30Location

　　Location 響應(yīng)頭字段用于將收件人重定向到請求uri以外的位置，以完成請求或標(biāo)識新資源。對于201(Created)響應(yīng)，Location是由請求創(chuàng)建的新資源的位置。對于3xx響應(yīng)，Location應(yīng)該指示服務(wù)器自動重定向到資源的首選URI。字段值由單個絕對URI組成。

　　Location = “Location” “:” absoluteURI

　　例子:

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

　　注意:Content-Location頭字段(14.14節(jié))與Location不同，因?yàn)镃ontent-Location標(biāo)識了請求中包含的實(shí)體的原始位置。因此，響應(yīng)可以包含Location和Content-Location的頭字段。某些方法的緩存要求參見第13.10節(jié)。

14.31Max-Forwards

　　Max-Forwards請求頭字段為TRACE(9.8節(jié))和OPTIONS(9.2節(jié))方法提供了一種機(jī)制，用于限制可以將請求轉(zhuǎn)發(fā)到下一個入站服務(wù)器的代理或網(wǎng)關(guān)的數(shù)量。當(dāng)客戶端試圖跟蹤請求鏈時，如果請求鏈在中間鏈中出現(xiàn)故障或循環(huán)，這可能非常有用。

　　Max-Forwards = “Max-Forwards” “:” 1*DIGIT

　　最大轉(zhuǎn)發(fā)值是一個十進(jìn)制整數(shù)，指示此請求消息可能被轉(zhuǎn)發(fā)的剩余次數(shù)。

　　TRACE或OPTIONS請求的每個代理或網(wǎng)關(guān)接收者(包含Max-Forwards頭字段)必須在轉(zhuǎn)發(fā)請求之前檢查并更新其值。如果接收到的值為0，接收方不得轉(zhuǎn)發(fā)請求;相反，它必須作為最終接收者做出回應(yīng)。如果接收到的Max-Foewards值大于零，那么轉(zhuǎn)發(fā)的消息必須包含一個更新的Max-Foewards字段，其值遞減為1。

　　對于本規(guī)范中定義的所有其他方法和那些沒有明確地將其作為該方法定義的一部分的擴(kuò)展方法來說，Max-Forwards頭字段都可能被忽略。

14.32Pragma

　　Pragma通用頭字段用于包含可能應(yīng)用于請求/響應(yīng)鏈上任何接收者的特別的指令。所有實(shí)用程序指令從協(xié)議的角度指定可選行為;然而，一些系統(tǒng)可能要求行為與指令一致。

　　Pragma = “Pragma” “:” 1#pragma-directive

　　pragma-directive = “no-cache” | extension-pragma

　　extension-pragma = token [ “=” ( token | quoted-string ) ]

　　當(dāng)請求消息中出現(xiàn)no-cache指令時，應(yīng)用程序應(yīng)該將請求轉(zhuǎn)發(fā)到原始服務(wù)器，即使它有被請求內(nèi)容的緩存副本。這個pragma指令具有與no-cache緩存指令相同的語義(參見14.9節(jié))，它的定義是為了向后兼容HTTP/1.0。當(dāng)一個沒有緩存的請求被發(fā)送到一個不知道是否兼容HTTP/1.1的服務(wù)器時，客戶端應(yīng)該包含這兩個頭字段。

　　Pragma指令必須通過代理或網(wǎng)關(guān)應(yīng)用程序傳遞，而不管它們對應(yīng)用程序的重要性如何，因?yàn)檫@些指令可能適用于請求/響應(yīng)鏈上的所有接收者。不可能為特定的接收者指定一個實(shí)用程序;然而，任何與接收者無關(guān)的Pragma指令都應(yīng)該被接收者忽略。

　　HTTP/1.1緩存應(yīng)該將“Pragma: no-cache”視為客戶端發(fā)送的“Cache-Control: no-cache”。HTTP中不會定義新的Pragma指令。

　　注意:因?yàn)椤癙ragma: no-cache”作為響應(yīng)頭字段的含義實(shí)際上沒有指定，所以它不能替換響應(yīng)中的“Cache-Control: no-cache”頭字段。

14.33Proxy-Authenticate

　　Proxy Authenticate 響應(yīng)頭字段必須被包含在一個407（Proxy Authentication Required）響應(yīng)中。字段值包含一個“詢問”，該“詢問”指示這個請求URI的代理適用的身份驗(yàn)證方案及參數(shù)。

　　Proxy-Authenticate = “Proxy-Authenticate” “:” 1#challenge

　　HTTP訪問身份驗(yàn)證過程被描述為“HTTP身份驗(yàn)證:基本和摘要訪問身份驗(yàn)證”[43]。與WWW-Authenticate不同，代理身份驗(yàn)證頭字段僅應(yīng)用于當(dāng)前連接，不應(yīng)傳遞到下游客戶端。但是，中間代理可能需要通過從下游客戶端請求它們來獲得自己的憑證，在某些情況下，這看起來就好像代理在轉(zhuǎn)發(fā)Proxy-Authenticate頭字段一樣。

14.34Proxy-Authorization

　　Proxy-Authorization請求頭字段允許客戶端將自己(或其用戶)標(biāo)識給需要身份驗(yàn)證的代理。Proxy-Authorization字段值由憑證組成，該憑證包含用戶代理的身份驗(yàn)證信息，用于請求的資源和/或領(lǐng)域。

　　Proxy-Authorization = “Proxy-Authorization” “:” credentials

　　HTTP訪問身份驗(yàn)證過程在“HTTP Authentication:基本和摘要訪問身份驗(yàn)證”[43]中有更詳細(xì)的描述。與Authorization不同，Proxy-Authorization頭字段僅適用于使用Proxy- Authenticate字段要求進(jìn)行身份驗(yàn)證的下一個出站代理。當(dāng)在一個鏈中使用多個代理時，Proxy-Authorization頭字段將由第一個期望接收憑證的出站代理使用。代理可以將憑證從客戶端請求中繼到下一個代理，如果這是代理合作驗(yàn)證給定請求的機(jī)制的話。

14.35Range

14.35.1Byte Ranges(字節(jié)范圍)

　　由于所有HTTP實(shí)體在HTTP消息中都表示為字節(jié)序列，因此字節(jié)范圍的概念對任何HTTP實(shí)體都有意義。(不過，并非所有客戶端和服務(wù)器都需要支持字節(jié)范圍操作。)

　　HTTP中的字節(jié)范圍規(guī)范適用于實(shí)體主體中的字節(jié)序列（不一定與消息主體相同）。

　　字節(jié)范圍操作可以指定單個范圍的字節(jié)，或者指定單個實(shí)體中的一組范圍。

　　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值是第一個字節(jié)范圍。last-byte-pos給定的是最后一個字節(jié)的范圍。也就是說，指定的字節(jié)位置包括在內(nèi)。字節(jié)的范圍從0開始。

　　如果last-byte-pos存在，在byte-range-spec中必須大于或等于first-byte-pos，否則byte-range-spec規(guī)范在語法上是無效的。包含一個或多個語法無效的byte-range-spec值的byte-range-set的接收者必須忽略包含該byte-range-set的標(biāo)頭字段。

　　如果不存在last-byte-pos值，或者如果該值大于或等于實(shí)體主體的當(dāng)前長度，則last-byte-pos的值被取為小于實(shí)體主體的當(dāng)前長度的字節(jié)。

　　通過選擇last-byte-pos，客戶端可以在不知道實(shí)體大小的情況下限制檢索的字節(jié)數(shù)。

　　suffix-byte-range-spec = “-” suffix-length

　　suffix-length = 1*DIGIT

　　suffix-byte-range-spec被用來用于指定實(shí)體主體的后綴，其長度由suffix-length值給出。(也就是說，該結(jié)構(gòu)指定實(shí)體主體的最后N字節(jié)。)如果實(shí)體短于指定的suffix-length，則使用整個實(shí)體主體。

　　如果一個語法有效的byte-range-set包含至少一個byte-range-spec，其first-byte-pos小于實(shí)體主體的當(dāng)前長度，或者至少一個非零的suffix-byte-range-spec，那么byte-range-set是可滿足的。否則，byte-range-se是無法滿足的。如果byte-range-set無法滿足，服務(wù)器應(yīng)該返回狀態(tài)為416的響應(yīng)(Requested range not satisfiable)。否則，服務(wù)器應(yīng)該返回狀態(tài)為206(Partial Content)的響應(yīng)，其中包含實(shí)體主體的可滿足范圍。　　

　　下面是一個指定字節(jié)范圍值的例子（假定實(shí)體主體的長度是10000）:

　　– 最開始的500個字節(jié) (字節(jié)范圍是 0-499, 包含開始和結(jié)束的值): bytes=0-499

　　- 第二部分500個字節(jié) (字節(jié)范圍是 500-999, 包含開始和結(jié)束的值):bytes=500-999

　　- 最后500個字節(jié) (字節(jié)范圍是 9500-9999, 包含開始和結(jié)束的值):bytes=-500

　　- 或者 bytes=9500-

　　- 只有第一個和最后一個字節(jié) (字節(jié) 0 和 9999): bytes=0-0,-1

　　– (字節(jié)范圍 500-999, 包含開始和結(jié)束的值)下面是幾個合法但不規(guī)范的第二部分字節(jié)的表示方法:

　　 　　　　bytes=500-600,601-999

　　　　bytes=500-700,601-999

14.35.2Range Retrieval Requests（范圍檢索請求）

　　使用條件或無條件GET方法的HTTP檢索請求可以使用Range請求頭請求實(shí)體的一個或多個子范圍，而不是整個實(shí)體，它適用于作為請求結(jié)果返回的實(shí)體:

　　Range = “Range” “:” ranges-specifier

　　服務(wù)器可能忽略Range頭字段。然而，HTTP/1.1源服務(wù)器和中間緩存應(yīng)該盡可能支持字節(jié)范圍，因?yàn)镽ange頭字段支持對部分失敗傳輸?shù)母咝Щ謴?fù)，并且支持對大型實(shí)體的高效部分檢索。

　　如果服務(wù)器支持Range頭字段，并且指定的范圍適合實(shí)體:

　　　　-無條件GET中出現(xiàn)的Range頭字段會修改GET請求成功返回的內(nèi)容。換句話說，響應(yīng)的狀態(tài)代碼是206(Partial Content)，而不是200 (OK)。

　　　　- 有條件的GET請求(使用If-Modifify-Since或者If-None-Match中一個或兩個的請求，或者If-Unmodify-Since和If-Match中一個或兩個的請求)中存在的Range頭字段可以修改如果GET成功且條件為true時返回的內(nèi)容。如果條件為false，則不影響返回的304(Not Modified)響應(yīng)。

　　在某些情況下，除了Range頭字段之外，使用If-Range頭字段(參見14.27節(jié))可能更合適。

　　如果支持范圍的代理接收范圍請求，將請求轉(zhuǎn)發(fā)到入站服務(wù)器，并接收整個實(shí)體作為響應(yīng)，那么它應(yīng)該只將請求范圍返回給客戶端。如果響應(yīng)與緩存分配策略一致，則應(yīng)該將整個接收到的響應(yīng)存儲在緩存中。

14.36Referer

　　Referer[sic]請求頭字段允許客戶端為服務(wù)器的著想的角度指定獲取請求URI的資源的地址(“referrer”，盡管頭字段拼錯了)。Referer請求頭允許服務(wù)器為感興趣的資源生成返回鏈接列表，日志記錄，優(yōu)化緩存等等。它也允許對過時的或輸入錯誤的鏈接進(jìn)行跟蹤以進(jìn)行維護(hù)。如果從沒有自己的URI(例如從用戶鍵盤輸入)的源獲取請求URI，則不能發(fā)送Referer字段。

　　Referer = “Referer” “:” ( absoluteURI | relativeURI )

　　例子：

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

　　如果字段值是一個相對URI，則應(yīng)該將其解釋為相對于請求URI。URI不能包含片段。有關(guān)安全方面的參考，請查看第15.1.3小節(jié)。

14.37Retry-After

　　Retry-After 響應(yīng)頭字段可與503(Service Unavailable)響應(yīng)一起使用，以指示請求客戶端預(yù)期服務(wù)不可用的時間。此字段還可以與任何3xx(Redirection)響應(yīng)一起使用，以指示用戶代理在發(fā)出重定向請求之前等待的最短時間。該字段的值可以是HTTP-date值，也可以是響應(yīng)時間之后的整數(shù)秒數(shù)(十進(jìn)制)。

　　Retry-After = “Retry-After” “:” ( HTTP-date | delta-seconds )

　　下面是該字段用法的兩個例子

　　Retry-After: Fri, 31 Dec 1999 23:59:59 GMT

　　Retry-After: 120

　　第二個例子，需要延遲兩分鐘

14.38Server

The Server response-header field contains information about the software used by the origin server to handle(操作，操控;) the request. The field can contain multiple product tokens (section3.8) and comments identifying(確認(rèn);辨認(rèn);認(rèn)出) the server and any significant subproducts(子積;子乘積;[). The product tokens are listed in order of their significance(意義;重要性;意思) for identifying the application.

　　Server = “Server” “:” 1*( product | comment )

　　例子:

　　Server: CERN/3.0 libwww/2.17

If the response is being forwarded through a proxy, the proxy application MUST NOT modify the Server response-header. Instead, it SHOULD include a Via field (as described in section14.45).

Note: Revealing(泄露;顯示，展示;揭示，揭露) the specific software version of the server might allow the server machine to become more vulnerable(易受攻擊的;易受傷的;易受批評的;[橋牌]已成局的) to attacks against software that is known to contain security holes. Server implementors(實(shí)現(xiàn)者) are encouraged(鼓動;鼓勵) to make this field a configurable(結(jié)構(gòu)的，可配置的) option.

14.39TE

　　TE請求頭字段指示它愿意在響應(yīng)中接受哪些擴(kuò)展傳輸編碼，以及是否愿意接受分組傳輸編碼中的trailer字段。它的值可能包括關(guān)鍵字“trailers”和（或）帶有可選接收參數(shù)的以逗號分隔的擴(kuò)展傳遞編碼名稱列表(如3.6節(jié)所述)。

　　TE = “TE” “:” #( t-codings )

　　t-codings = “trailers” | ( transfer-extension [ accept-params ] )

　　關(guān)鍵字“trailers”的出現(xiàn)表明客戶愿意接受分段轉(zhuǎn)換編碼中的trailer字段，如3.6.1節(jié)中定義的那樣。這個關(guān)鍵字保留用于傳輸編碼值，即使它本身并不表示傳輸編碼。

　　它的用法:

　　TE: deflate

　　TE:

　　TE: trailers, deflate;q=0.5

　　TE頭字段僅適用于短連接（immediate connection）。因此，當(dāng)HTTP/1.1消息中出現(xiàn)TE時，必須在連接標(biāo)頭字段(14.10小節(jié))中提供關(guān)鍵字。

　　根據(jù)TE字段，服務(wù)器使用以下規(guī)則測試傳輸編碼是否可接受:

　　1. “chunked”的轉(zhuǎn)換編碼總是可以接受的。如果列出了關(guān)鍵字“trailers”，則客戶端表示它愿意代表自己和任何下游客戶接受chunked響應(yīng)中的trailer字段。這意味著，如果給定，客戶端將聲明，要么所有下游客戶端都愿意接受轉(zhuǎn)發(fā)響應(yīng)中的trailers字段，要么它將嘗試代表下游接收者緩沖響應(yīng)。

　　　　注意:HTTP/1.1沒有定義任何方法來限制chunked響應(yīng)的大小，從而確保客戶端能夠緩沖整個響應(yīng)。

　　2.如果正在測試的傳輸編碼是TE字段中列出的傳輸編碼之一，那么它是可以接受的，除非qvalue的值為0。(在3.9節(jié)中定義，0的qvalue值表示“不可接受”。)

　　3.如果多個傳輸編碼是可接受的，則首選具有最高非零qvalue值的可接受傳輸編碼。“chunked”轉(zhuǎn)換編碼的qvalue值總是為1。

　　如果TE字段值為空或不存在TE字段，則唯一的傳輸編碼是“chunked”。沒有傳輸編碼的消息總是可以接受的。

14.40Trailer

　　Trailer通用頭字段值用來表示給定的頭字段集存在于用分塊“傳輸編碼”編碼的消息的trailer中。

　　Trailer = “Trailer” “:” 1#field-name

　　HTTP/1.1消息應(yīng)該包含消息中的Trailer頭字段，該字段使用非空Trailer的分組傳輸編碼。這樣做可以讓接收者知道Trailer中期望的是哪個頭字段。

If no Trailer header field is present, the trailer SHOULD NOT include any header fields. See section 3.6.1 for restrictions on the use of trailer fields in a “chunked” transfer-coding.

　　如果不存在Trailer頭字段，那么trailer不應(yīng)該包含任何頭字段。請參閱第3.6.1節(jié)，了解在“chunked”傳輸編碼中使用trailer字段的限制。

　　在Trailer頭字段中列出的消息頭字段不能包含以下頭字段:

. Transfer-Encoding

. Content-Length

. Trailer

14.41Transfer-Encoding

　　Transfer-Encoding 通用頭字段指示向消息體應(yīng)用了什么（如果有的話）類型的轉(zhuǎn)換，以便在發(fā)送方和接收方之間安全地傳輸它。這與內(nèi)容編碼不同，因?yàn)閭鬏斁幋a是消息的屬性，而不是實(shí)體的屬性。

　　Transfer-Encoding = “Transfer-Encoding” “:” 1#transfer-coding

　　Transfer-codings在3.6小節(jié)中有詳細(xì)的定義。下面是一個例子：

　　Transfer-Encoding: chunked

　　如果多個編碼被應(yīng)用到一個實(shí)體，那么傳輸編碼必須按照應(yīng)用它們的順序列出。有關(guān)編碼參數(shù)的其他信息可以由本規(guī)范未定義的其他實(shí)體頭字段提供。

　　大多數(shù)應(yīng)用HTTP/1.0的協(xié)議無法理解Transfer-Encoding頭字段。

14.42Upgrade

　　Upgrade通用頭字段允許客戶端指定它支持哪些附加通信協(xié)議，如果服務(wù)器發(fā)現(xiàn)它適合交換協(xié)議，則允許客戶端使用哪些附加通信協(xié)議。服務(wù)器必須在101（Switching Protocols）響應(yīng)中使用Upgrade頭字段來指示正在交換哪些協(xié)議。

　　Upgrade = “Upgrade” “:” 1#product

　　例如,

　　Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

　　Upgrade頭字段旨在提供一個簡單的機(jī)制，用于從HTTP/1.1轉(zhuǎn)換到其他不兼容的協(xié)議。它通過允許客戶端聲明它想要使用另一種協(xié)議來實(shí)現(xiàn)這一點(diǎn)，比如使用更高主版本號的HTTP的后期版本，即使當(dāng)前的請求是使用HTTP/1.1發(fā)出的。這通過允許客戶端在更普遍支持的協(xié)議中發(fā)起請求，同時向服務(wù)器指示如果可用，它希望使用“更好”的協(xié)議（“更好”由服務(wù)器決定，可能根據(jù)所請求的方法和/或資源的性質(zhì)不同而不同。），從而減輕了不兼容協(xié)議之間轉(zhuǎn)換困難的問題。

　　Upgrade頭字段僅適用于現(xiàn)有傳輸層連接上的交換應(yīng)用層協(xié)議。Upgrade不能用于堅(jiān)持更改協(xié)議；服務(wù)器的接受和使用是可選的。協(xié)議改變后的應(yīng)用層通信的能力和性質(zhì)完全取決于所選擇的新協(xié)議，盡管改變協(xié)議之后的第一動作必須是對包含Upgrade頭字段的初始HTTP請求的響應(yīng)。

　　Upgrade頭字段僅適用于立即連接。因此，每當(dāng)在HTTP/1.1消息中存在Upgrade時，必須在Connection頭字段（部分14.10）中提供upgrade關(guān)鍵字。

　　Upgrade頭字段不能用于指示在不同連接上切換協(xié)議。為此，使用301, 302, 303或305等重定向響應(yīng)更合適。

　　本規(guī)范只定義了供超文本傳輸協(xié)議族使用的協(xié)議名稱“HTTP”，如3.1節(jié)的HTTP版本規(guī)則和本規(guī)范的未來更新所定義。任何令牌都可以用作協(xié)議名稱；但是，只有當(dāng)客戶端和服務(wù)器都把該名稱與相同的協(xié)議關(guān)聯(lián)時才有用。

14.43User-Agent

　　User-Agent請求頭字段包含關(guān)于發(fā)起請求的用戶代理的信息。這是為了統(tǒng)計(jì)請求的意圖、跟蹤違反協(xié)議的情況以及自動識別用戶代理，以便調(diào)整響應(yīng)以避免特定的用戶代理限制。用戶代理應(yīng)該將此字段包含在請求中。字段可以包含多個產(chǎn)品標(biāo)記(第3.8節(jié))和標(biāo)識代理和構(gòu)成用戶代理重要部分的任何子產(chǎn)品的注釋。按照慣例，產(chǎn)品令牌是按照它們對識別應(yīng)用程序的重要性列出的。

　　User-Agent = “User-Agent” “:” 1*( product | comment )

　　例子:

　　User-Agent: CERN-LineMode/2.15 libwww/2.17b3

14.44Vary

　　Vary字段值表示請求頭字段集，該字段集在響應(yīng)是“新鮮”的情況下完全確定是否允許緩存使用響應(yīng)來響應(yīng)后續(xù)請求，而無需重新驗(yàn)證。對于無法緩存或過時的響應(yīng)，Vary字段值向用戶代理提供用于選擇表示的標(biāo)準(zhǔn)。值“*”表示緩存無法從后續(xù)請求的請求頭中確定此響應(yīng)是否合適。請參閱第13.6節(jié)，了解緩存對Vary頭字段的使用。

　　Vary = “Vary” “:” ( “*” | 1#field-name )

　　HTTP/1.1服務(wù)器應(yīng)該包含一個Vary頭字段，其中包含任何可緩存的響應(yīng)，該響應(yīng)受服務(wù)器驅(qū)動協(xié)商的影響。這樣做允許緩存正確地解釋對該資源的未來請求，并告知用戶代理該資源上是否存在協(xié)商。服務(wù)器可能包含一個Vary標(biāo)頭字段，其中不可緩存的響應(yīng)受服務(wù)器驅(qū)動協(xié)商的影響，因?yàn)檫@可能為用戶代理提供關(guān)于“響應(yīng)”在響應(yīng)時變化的維度的有用信息。

　　一個Vary字段值，由一組字段名稱信號組成，所選的響應(yīng)表示是基于選擇算法的，該算法在選擇最合適的表示時只考慮列出的請求頭字段。緩存可能假設(shè)在響應(yīng)新鮮的時間段內(nèi)，對于將來具有相同值的請求，將進(jìn)行相同的選擇。

　　給出的字段名不限于此規(guī)范定義的標(biāo)準(zhǔn)請求頭字段集。且字段名不區(qū)分大小寫。

　　如果Vary的字段值是“*”，則表明未指定的參數(shù)不限于請求頭(例如，客戶端的網(wǎng)絡(luò)地址)，在響應(yīng)表示的選擇中起作用。“*”值不能由代理服務(wù)器生成;它可能僅由原始服務(wù)器生成。

14.45Via

　　Via通用頭字段必須被網(wǎng)關(guān)和代理使用，以用來在請求中指示用戶代理和服務(wù)器之間的中間協(xié)議和接收者，在響應(yīng)上指示源服務(wù)器和客戶端之間的中間協(xié)議和接收者。它類似于RFC 822[9]的“Received”字段，用于跟蹤消息轉(zhuǎn)發(fā)，避免請求循環(huán)，以及識別請求/響應(yīng)鏈上所有發(fā)送者的協(xié)議功能。

　　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

　　接收協(xié)議指示服務(wù)器或客戶端沿著請求/響應(yīng)鏈的每個環(huán)節(jié)所接收的消息相關(guān)的協(xié)議版本。當(dāng)消息被轉(zhuǎn)發(fā)時，接收的協(xié)議版本被附加到Via字段的值上，以便關(guān)于上游應(yīng)用程序的協(xié)議能力的信息對所有接收者保持可見。

　　協(xié)議名稱是可選的，當(dāng)且僅當(dāng)它是“HTTP”時。接收方字段通常是隨后轉(zhuǎn)發(fā)消息的接收方服務(wù)器或客戶端的主機(jī)和可選端口號。然而，如果真實(shí)主機(jī)被認(rèn)為是敏感信息，它可以被化名取代。如果沒有給出端口，則可以假定它是接收到的協(xié)議的默認(rèn)端口。

　　多個Via字段值表示轉(zhuǎn)發(fā)消息的每個代理或網(wǎng)關(guān)。每個接收方必須附加其信息，以便根據(jù)轉(zhuǎn)發(fā)應(yīng)用程序的序列對最終結(jié)果進(jìn)行排序。

　　注釋可以在Via頭字段中使用，以標(biāo)識接收方代理或網(wǎng)關(guān)的軟件，類似于User-Agent和Server標(biāo)頭字段。但是，在傳遞字段中的所有注釋都是可選的，并且可以在轉(zhuǎn)發(fā)消息之前由任何接收者刪除。

　　例如，可以將請求消息從HTTP/1.0用戶代理發(fā)送到名為“fred”的內(nèi)部代理，該代理使用HTTP/1.1將請求轉(zhuǎn)發(fā)到nowhere.com的公共代理，該公共代理通過將請求轉(zhuǎn)發(fā)到位于www.ics.uci.edu的源服務(wù)器來完成請求。由www.ics.uci.edu接收的請求將具有以下的Via頭字段：

　　Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

　　默認(rèn)情況下，代理和網(wǎng)關(guān)作為通過網(wǎng)絡(luò)防火墻的門戶不應(yīng)該轉(zhuǎn)發(fā)防火墻區(qū)域內(nèi)的主機(jī)的名稱和端口。只有顯式啟用該信息才能傳播。如果沒有啟用，防火墻后面的任何主機(jī)的主機(jī)所接收的主機(jī)都應(yīng)該用適當(dāng)?shù)幕鎿Q。

　　對于對隱藏內(nèi)部結(jié)構(gòu)具有很強(qiáng)隱私要求的組織，代理可以將具有相同接收協(xié)議值的Via頭字段條目的有序子序列組合到一個這樣的條目中。例如，

　　Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy

　　可以縮減為

　　Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

　　應(yīng)用程序不應(yīng)該組合多個條目，除非它們都在相同的組織控制之下，并且主機(jī)已經(jīng)被假名取代。應(yīng)用程序不能組合具有不同接收的協(xié)議值的條目。

14.46Warning

　　Warning通用頭字段用于承載關(guān)于消息中可能未反映的消息的狀態(tài)或轉(zhuǎn)換的附加信息。此信息用于警告實(shí)體主體信息在緩存配置或轉(zhuǎn)換中缺乏語義的透明度。

　　Warning頭字段通過以下方式發(fā)送:

　　Warning = “Warning” “:” 1#warning-value

　　warning-value = warn-code SP warn-agent SP warn-text

　　[SP warn-date]

　　warn-code = 3DIGIT

　　warn-agent = ( host [ “:” port ] ) | pseudonym

　　;服務(wù)器添加的名稱或別名

　　; Warning頭字段，用于調(diào)試

　　warn-text = quoted-string

　　warn-date = <“> HTTP-date <“>

　　響應(yīng)可能包含多個Warning頭字段。

　　警告文本應(yīng)該使用自然語言和字符集，對于接收響應(yīng)的人類用戶來說，這些語言和字符集最容易理解。此決策可以基于任何可用的知識，例如緩存或用戶的位置、請求中的Accept-Language字段、響應(yīng)中的Content-Language字段等。默認(rèn)語言為英語，默認(rèn)字符集為ISO-8859-1。

　　如果使用的字符集不是ISO-859-1，則必須使用RFC 2047（14）中描述的方法在警告文本中進(jìn)行編碼。

　　Warning頭通常可以應(yīng)用于任何消息，但是一些特定的警告代碼對于緩存來說是特殊的，并且只能應(yīng)用于響應(yīng)消息。在任何現(xiàn)有的Warning標(biāo)頭之后都應(yīng)該添加新的警告標(biāo)題。緩存不能刪除它收到的任何消息頭。但是，如果緩存成功驗(yàn)證緩存條目，則應(yīng)刪除以前附加到該條目的任何Warning標(biāo)頭，除非為特定Warning代碼指定。然后，必須在驗(yàn)證響應(yīng)中添加任何Warning標(biāo)頭。換句話說，Warning標(biāo)頭是那些附加到最近的相關(guān)響應(yīng)的標(biāo)題。

　　當(dāng)多個Warning頭附加到響應(yīng)時，用戶代理應(yīng)該盡可能多地通知用戶，以使它們出現(xiàn)在響應(yīng)中。如果無法將所有警告通知用戶，用戶代理應(yīng)遵循以下啟發(fā)式方法:

　　–出現(xiàn)在響應(yīng)中較早的警告優(yōu)先于出現(xiàn)在響應(yīng)中較晚的警告。

　　-用戶首選字符集中的警告優(yōu)先于其他字符集中的警告，但是警告代碼和警告代理是相同的。

　　生成多個Warning標(biāo)頭的系統(tǒng)應(yīng)該根據(jù)用戶代理行為對其進(jìn)行排序。

　　有關(guān)警告的緩存行為的需求在第13.1.2節(jié)中說明。

　　這是當(dāng)前定義的警告代碼的列表，每個警告代碼都帶有英文推薦的警告文本，并描述了其含義。

　　　　110–當(dāng)響應(yīng)過期時，則必須被包含。

　　　　111–如果由于無法連接到服務(wù)器而引起的重校驗(yàn)失敗導(dǎo)致了緩存返回了一個陳舊的響應(yīng)，則“重新校驗(yàn)失敗”必須被包含。

　　　　112–如果緩存有意從網(wǎng)絡(luò)的其余部分?jǐn)嚅_一段時間，則應(yīng)該包含“斷開連接操作”。

　　　　113–如果緩存從啟發(fā)意義上選擇的新鮮度范圍大于24小時，響應(yīng)的范圍大于24小時。則“探索性過期”必須被包含。

　　　　199 –雜項(xiàng)警告，警告文本可以包括要呈現(xiàn)給人類用戶或登錄的任意信息。接受此警告的系統(tǒng)除了向用戶發(fā)出警告外，不得采取任何自動化行動。

　　　　214 –應(yīng)用轉(zhuǎn)換必須由中間緩存或代理添加，如果它應(yīng)用任何轉(zhuǎn)換來更改響應(yīng)的內(nèi)容編碼（如Content-Encoding標(biāo)頭中指定的）或媒體類型（如Content-Type標(biāo)頭中指定的）或響應(yīng)的實(shí)體主體，除非該Warning字段已經(jīng)出現(xiàn)在響應(yīng)中。

　　　　299 –雜項(xiàng)持久警告，警告文本可以包括要呈現(xiàn)給人類用戶或登錄的任意信息。接收此警告的系統(tǒng)不能采取任何自動化操作。

　　如果實(shí)現(xiàn)發(fā)送的消息具有一個或多個警告標(biāo)頭，其版本為HTTP/1.0或更低，那么發(fā)送方必須在每個警告值中包含一個與響應(yīng)中的日期匹配的警告日期。

　　如果一個實(shí)現(xiàn)接收到包含警告日期的警告值的消息，并且該警告日期與響應(yīng)中的日期值不同，那么在存儲、轉(zhuǎn)發(fā)或使用消息之前，該警告值必須從消息中刪除。(這可以防止警告標(biāo)頭字段初始緩存的不良后果。)如果出于這個原因刪除了所有警告值，那么警告頭也必須被刪除。

14.47WWW-Authenticate

　　WWW-Authenticate響應(yīng)頭字段必須包含在401(Unauthorized)響應(yīng)消息中。字段值由至少一個詢問組成，該詢問指示身份驗(yàn)證方案和適用于Request-URI的參數(shù)。

　　WWW-Authenticate = “WWW-Authenticate” “:” 1#challenge

　　HTTP訪問身份驗(yàn)證過程描述為“HTTP身份驗(yàn)證:基本和摘要訪問身份驗(yàn)證”[43]。建議用戶代理在解析WWW-Authenticate字段值時特別小心，因?yàn)樗赡馨鄠€質(zhì)詢，或者如果提供了多個WWW-Authenticate頭字段，則質(zhì)詢本身的內(nèi)容可以包含一個逗號分隔的身份驗(yàn)證參數(shù)列表。

總結(jié)

以上是生活随笔為你收集整理的RFC2616-HTTP1.1-Header Field Definitions(头字段规定部分—译文)「建议收藏」的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。