RFC2616-HTTP1.1-Header Field Definitions(頭字段規定部分—譯文)

時間 2019-11-26

標籤 rfc2616 rfc http1.1 http header field definitions 字段規定部分譯文欄目 HTTP/TCP 简体版

原文原文鏈接

part of Hypertext Transfer Protocol -- HTTP/1.1html

RFC 2616 Fielding, et al.web

14 頭字段規定

　　該章節定義了HTTP1.1標準所包含的全部頭字段的相關語法和含義。實體頭字段是接收者或者發送者所涉及到的，並不區分是客戶端仍是服務器所擁有，而是依據是誰發送或者是誰接受該實體的字段。算法

14.1 Accept

　　Accept請求頭字段能夠用來指定一個能被響應接受的肯定的媒體類型。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(引用字符串) ) ]網絡

　　星號"*"字符用來把媒體類型歸類到ranges中，"*/*" 表示全部媒體類型均可以接受，"type/*"標明該媒體類型下的全部子類型。media-range能夠包含適當範圍內的媒體類型參數。數據結構

　　每一個media-range均可以跟隨一個或多個accept-params參數，以q參數開始，用來代表相對的權重因子。第一個q參數（若是有的話）將media-range參數從accept-params字段中分隔開。權重參數容許用戶或用戶代理指示對該媒體範圍的相對偏好程度，q的值在0到1範圍內。默認的值是1。app

　　請注意：使用「q」參數名稱將媒體類型參數從Accept擴展參數中分離出來是有歷史實踐性的。儘管這可能會從媒體範圍中阻止任何叫作「q」的媒體類型，可是因爲IANA（因特網編號管理局）註冊表中缺乏"q"字段的相關記錄，而且Accept中不多使用任何媒體類型的參數，所以這種事情不太可能發生。

　　一個簡單的例子：

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

　　能夠理解爲我第一優先須要「audio/basic」格式，可是在下降百分之八十的標準後給我傳送其餘的audio類型也是能夠的。

　　若是沒有Accept投資段，那麼假設客戶端能夠接受任何的媒體類型。若是存在Accept頭字段，可是服務器沒法發送一個包含Accept字段中可接受的響應，那麼就會返回一個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實體。

　　媒體範圍（Media ranges）能夠被更特定的媒體範圍（Media ranges）或特定的媒體類型（media types）覆蓋。若是一個給定類型應用了多個媒體範圍，那麼最特定的會被採用。咱們來看下面的例子：

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

　　擁有如下的優先級

　　 1) text/html;level=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

　　注意:用戶代理可能會爲某些媒體範圍提供一組默認的權重值。可是，除非用戶代理是一個封閉的系統，不能與其餘執行中的代理（rendering agents）交互，不然這個默認設置應該由用戶配置。

14.2 Accept-Charset

　　Accept-Charset 請求頭字段能夠用來標示怎樣的字符集能夠在響應中使用。該字段容許客戶端有能力去理解綜合性更強或者具備特殊用途的字符集，具備向可以在這些字符集中表示文檔的服務器發出信號的能力。

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

　　在3.4小節咱們解釋了有關於字符集的值的相關信息。每個字符能夠擁有一個用來表示該字符權重的相關的值。權重的默認值是1。下面咱們看一個例子：

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

　　若是存在特殊的星號「*」在Accept-Charset字段中，匹配在Accept-Charset字段中沒有說起的其餘全部的字符集（包括ISO-8859-1）。若是該頭字段中不存在星號，沒有明確說起的全部字符集都得到權重值0，除了ISO-8859-1，若是沒有明確說起，則得到權重值1。

　　若是沒有Accept-Charset頭字段，則說明任何字符都是能夠接受的。若是存在該字段，可是服務器並無在響應中傳遞該字段容許的字符集，那麼服務器須要返回一個406狀態碼，儘管傳送一個不符合的響應也是被容許的。

14.3 Accept-Encoding

　　Accept-Encoding請求頭字段與Accept頭字段相似，可是限制了在響應用容許使用的內容編碼（content-codeings，第3.5小節）。

　　 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

　　服務器根據Accept-Encoding字段測試內容編碼（content-coding）是否能夠接受，規則以下：

　　1.內容編碼（content-coding）是不是在Accept-Encoding字段中列出的，若是是則能夠接受，除非它伴有的權重值是0.（就像3.9小節所描述的，權重值爲0則認爲沒法接受）

　　2.若是Accept-Encoding字段中存在特殊的星號「*」，那麼意味着在任何在該字段中未明確說明的內容編碼都是能夠接受的。

　　3.若是有多個被容許的內容編碼，那麼權重值最高的優先。

　　4.身份（identity）內容編碼老是能夠被接受的，除非在Accept-Encoding字段中的identity字段的權重值是0,或者在字段中包含了「*；q=0」而且沒有明確的「identity」內容編碼。若是不存在Accept-Encoding，那麼只有「identity」是被容許的。

　　若是一個請求中存在Accept-Encoding字段，可是服務器沒法提供該字段範圍內的響應，那麼服務器須要返回一個406錯誤響應。

　　若是請求中沒有Accept-Encoding頭字段，那麼服務器則假設客戶端能夠接受任何類型編碼的內容。在這種狀況下，若是「identity」是被容許的內容編碼之一，那麼服務器須要使用「identity」內容編碼，除非有額外的信息代表其餘的內容編碼對客戶端更有意義。

　　注意:若是請求不包含Accept-Encoding字段，若是"identity"內容編碼不可用，那麼HTTP/1.0客戶端會使用通用的content-codings(即，「gzip」和「compress」);一些較老的客戶端可能會不正確地顯示與其餘內容編碼一塊兒發送的消息。服務器還能夠根據特定用戶代理或客戶端的信息作出此決定。

　　注意:大多數HTTP/1.0應用程序不識別或不遵照與內容編碼相關的qvalue。這意味着qvalues將不能工做，x-gzip或x-compress中不容許使用qvalues。

14.4 Accept-Language

　　該字段也Tm跟Accept字段相似，可是它限制了請求中須要的天然語言集合的首選範圍。語言標識符在3.10小節中已經詳細說明。

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

　　language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )

　　每個語言範圍（language-range）能夠擁有一個表示預計用戶在該語言範圍內更傾向的語言的相關聯的權重值。默認的權重值是1。好比：

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

　　意味着：「我須要丹麥語（Danish），可是英式英語或者其餘類型的英語也是能夠接受的」。若是語言範圍正好等於標記，或者正好等於標記的前綴，則語言範圍匹配語言標記，使得前綴後面的第一個標記字符是「-」。若是在Accept-Language字段中存在特殊範圍「*」，則與Accept-Language字段中存在的任何其餘範圍不匹配的每一個標記匹配。

　　注意：前綴匹配規則的這種使用並不意味着語言標籤是以這樣的方式分配給語言的，即若是用戶理解具備特定標記的語言，那麼該用戶也將理解具備該標記爲前綴的全部標記的語言。若是是這樣的話，前綴規則只容許使用前綴標籤。

　 Accept-Language字段分配給語言標籤的權重因子是與語言標籤匹配的字段中最長的語言範圍的權重值。若是字段中沒有語言範圍與標籤匹配，則分配的語言權重值爲0。若是請求中不存在Accept-Language字段頭，則服務器應假定全部語言都一樣可接受。若是存在Accept-Language字段頭，則分配大於0的權重值的全部語言都是可接受的。

　　在每次請求中發送帶有用戶完整語言首選項的Accept-Language報頭可能與用戶的隱私指望相反。有關這個問題的討論，請參閱第15.1.4節。

　　因爲可理解性高度依賴於單個用戶，所以建議客戶端應用程序容許用戶能夠選擇語言首選項。若是選擇不可用，則不能在請求中給出 Accept-Language頭字段。

　　注意：當用戶可以選擇語言偏好時，咱們但願提醒開發者，用戶並不熟悉上述語言匹配的細節，而且應該提供適當的指導。舉個例子，用戶可能會假設在選擇「en-gb」時，若是英式英語不可用，他們會獲得任何類型的英語文檔。在這種狀況下，用戶代理可能會建議使用「EN」以得到最佳匹配行爲。

14.5 Accept-Ranges

　　Accept-Ranges響應頭字段容許服務器代表其所接受資源的範圍：

Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges

acceptable-ranges = 1#range-unit | "none"

　　接受字節範圍（byte-range）請求的源服務器能夠發送

Accept-Ranges: bytes

　　可是咱們並不須要這樣作。客戶端能夠生成字節範圍（byte-range）請求，而不爲所涉及的資源接收此報頭。範圍單元（Range units）在3.12小節中作了說明。

　　若是發送了以下的字段，那麼服務器不會接受任何範圍的請求。

Accept-Ranges: none

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

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（Request-URI）所標識的資源所支持的一組方法。此字段的目的是嚴格的告知接收方與該資源關聯的有效方法。Allow字段必須在405（Method Not Allowed）響應中存在。

Allow = "Allow" ":" #Method

　　使用例子：

Allow: GET, HEAD, PUT

　　該字段沒法阻止客戶端嘗試其餘方法。

　　可是，咱們應該遵循Allow頭字段的值所給出的指示。被容許使用的方法的實際集合會在每一次請求的元服務器中明確的指定。

　　Allow頭字段能夠提供一個PUT方法以使用戶提早知道一個新資源或者一個被修改的資源當前所支持的方法。服務器無需支持這些方法，可是須要在響應中包含一個Allow頭字段告知用戶該資源實際支持的方法有哪些。

　　一個代理不能修改Allow頭字段中的內容既是它徹底沒法理解全部方法所具備的特性，由於可能咱們的客戶端在與服務器交流的時候有其餘的用意。

14.8 Authorization

　　用戶代理但願經過服務器(一般是在收到401響應以後，但不必定是在收到401響應以後)進行身份驗證，驗證的方法是在請求中包含一個Authorization請求頭字段。Authorization字段值由憑證（credentials）組成，憑證包含所請求資源範圍的用戶代理的身份驗證信息。

　　Authorization = "Authorization" ":" credentials

　　該（"HTTP Authentication:Basic and Digest Access Authentication"）文章介紹了HTTP如何訪問身份驗證信息。若是某個請求經過了身份驗證並指定了一個域，那麼該域內的全部其餘請求應該具備相同的憑證（假設身份驗證方案自己不須要其餘憑證，例如根據質詢值變化的憑證或使用同步時鐘）。

　　當共享緩存（參見第13.7節）接收到包含Authorization字段的請求時，它不能返回相應的響應做爲對任何其餘請求的回覆，除非存在如下特定狀況之一：

　　1.若是一個響應包含了「s-maxage」緩存控制（Cache-Control）指令，該緩存可使用該響應回覆以後的請求。可是（若是已經超過最大的指按期限）代理緩存必須優先與服務器進行驗證，使用新請求的請求頭來容許源服務器驗證新請求。（這是s-maxage的定義行爲。）若是響應包括「s-maxage=0」，則代理必須老是在從新使用以前對其進行從新驗證。

　　2.若是響應中包含「must-revalidate」緩存控制指令（ cache-control directive），緩存能夠在答覆後續請求時使用該響應。可是，若是響應已通過期，全部緩存必須首先用源服務器從新驗證它，使用來自新請求的請求頭來容許源服務器驗證新請求。

　　3.若是響應包含「public」緩存控制指令，則能夠回覆任何後續請求。

14.9 Cache-Control

　　Cache-Control通用頭字段用於指定在請求/響應鏈上全部的緩存都必須遵照的規則。指令的指定旨在防止緩存對請求或響應產生不利干擾的一些行爲。這些指令一般會重寫默認緩存算法。緩存指令是單項的，請求中存在指令並不意味着響應中也將會給出相同的指令。

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

　　緩存指令必須由代理或網關應用程序傳遞，不管這些指令對該程序是否有用，由於這些指令可能適用於請求/響應鏈上的全部接收者。咱們不可能爲特定的緩存指定緩存指令。

　　Cache-Control = "Cache-Control" ":" 1#cache-directive

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

　　cache-request-directive =

　　 "no-cache" ; Section 14.9.1

　　 | "no-store" ; Section 14.9.2

　　 | "max-age" "=" delta-seconds ; Section 14.9.3, 14.9.4

　　| "max-stale" [ "=" delta-seconds ] ; Section 14.9.3

　　| "min-fresh" "=" delta-seconds ; Section 14.9.3

　　| "no-transform" ; Section 14.9.5

　　| "only-if-cached" ; Section 14.9.4

　　 | cache-extension ; Section 14.9.6

　　cache-response-directive =

　　"public" ; Section 14.9.1

| "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1

　　| "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1

　　 | "no-store" ; Section 14.9.2

　　| "no-transform" ; Section 14.9.5

　　| "must-revalidate" ; Section 14.9.4

　　 | "proxy-revalidate" ; Section 14.9.4

　　 | "max-age" "=" delta-seconds ; Section 14.9.3

　　 | "s-maxage" "=" delta-seconds ; Section 14.9.3

　　 | cache-extension ; Section 14.9.6

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

　　當指令沒有任何一個字段名參數出現時，該指令適用於整個請求或響應。當這樣的指令以符合要求的字段名參數出現時，它只適用於命名字段，而不適用於請求或響應的其他部分。該機制支持可擴展性；HTTP協議的將來版本的實現可能將這些指令應用於HTTP/1.1中未定義的頭字段。

　　緩存控制指令能夠分解爲如下這些通常類別。

　　　　-限制什麼是可緩存的；這些只能由源服務器強加。

　　　　-對緩存能夠存儲的內容的限制；這些能夠由源服務器或用戶代理強制執行。

　　　　-基本過時機制的修改；這些能夠由源服務器或用戶代理強制執行。

　　　　-對緩存從新驗證和從新加載進行控制；這些可能僅由用戶代理強制執行。

　　　　-控制實體的轉換。

　　　　-緩存系統的擴展。

14.9.1 What is Cacheable

　　默認狀況下，若是請求方法、請求頭字段和響應狀態的指示該響應是可緩存的，則響應是可緩存的。第13.4小節總結了這些可緩存性的默認值。下面的Cache-Control響應指令容許源服務器重寫響應的默認緩存性：

public

　　指示響應可能由任何緩存來緩存資源，即便它一般不可緩存或僅在非共享緩存中緩存。（請參閱受權，第14.8小節，以瞭解更多細節。）

private

　　指示響應消息的所有或部分用於單個用戶，而不能由共享緩存緩存。這容許源服務器聲明響應的指定部分僅針對一個用戶，而不能對其餘用戶的請求進行有效響應。私有（非共享）緩存能夠緩存響應。

　　注意： private一詞的在這裏的語義只是控制響應能夠緩存在哪裏，並不能確保消息內容的隱私性。

no-cache

　　若是無緩存（no-cache）指令沒有指定字段名，則緩存不能使用該響應來知足後續請求，而無需與原始服務器從新驗證成功。這容許源服務器甚至經過配置成向客戶端請求返回過時響應的緩存來防止緩存。

　　若是非緩存指令確實指定了一個或多個字段名，則緩存可使用響應來知足後續請求，但受緩存上的任何其餘限制。可是，在沒有與原始服務器成功從新驗證的狀況下，在響應後續請求時，必須不發送指定的字段名。這容許源服務器防止在響應中重用某些頭部字段，同時仍然容許緩存響應的其他部分。

　　注意：大部分HTTP/1.0協議下的緩存沒法識別或遵照該指令

14.9.2 What May be Stored by Caches

no-store

　　no-store指令存在的目的是阻止那些無心間發佈或保留的敏感信息（例如，備份信息）。no-store指令爲整個消息提供實用，可能會被響應或請求發送。若是在請求中發送，緩存必定不能被請求的任何部分或響應該請求的響應存儲。若是在響應中發送，則緩存不能存儲該響應的任何部分或引起該請求的請求。該指令也適用於非共享和共享緩存。「必須不存儲」在此上下文中意味着緩存必須不故意將信息存儲在非易失性存儲器中，而且必須盡力在轉發信息以後儘量迅速地從易失性存儲器中刪除信息。

　　即便這個指令與響應相關聯，用戶也能夠在緩存系統以外顯式地存儲這樣的響應（例如，使用「另存爲」對話框）。歷史緩衝區能夠存儲這些響應做爲正常操做的一部分。

　　本指令的目的是知足某些用戶和服務做者的既定要求，這些用戶和服務做者擔憂經過意外訪問緩存數據結構而泄漏信息。雖然在某些狀況下，使用本指令可能改善一些隱私的保密性，但咱們警告說，它毫不是確保隱私的可靠或充分的機制。特別地，惡意或受損的緩存可能沒法識別或聽從這個指令，而且在這種狀況下，通訊網絡可能很容易被竊聽。

14.9.3 Modifications of the Basic Expiration Mechanism

　　源服務器可使用Expires頭字段指定實體的過時時間(參見14.21節)。或者，能夠在響應中使用max-age指令指定它。當緩存的響應中出現max-age cache-control指令時，若是當前時間大於對該資源的新請求時給出的時間值(以秒爲單位)，則響應就失效了。響應的max-age指令意味着響應是可緩存的(即，「public」）除非有其餘更嚴格的緩存指令。

　　若是一個響應同時包含一個Expires頭字段和一個max-age指令，則max-age指令將覆蓋Expires頭字段，即便Expires頭字段有更多的限制。該規則容許源服務器爲給定的響應提供比HTTP/1.0緩存更長(或更高)的HTTP/1.1緩存過時時間。若是某些HTTP/1.0緩存沒法正確地計算時間或過時時間，這多是有用的，致使該狀況的緣由多是因爲時鐘不一樣步。

　　許多HTTP/1.0緩存實現會將一個小於或等於響應日期值的Expires值視爲等同於cache - control的「no-cache」響應指令。若是HTTP/1.1緩存接收到這樣的響應，而且響應不包含cache - control頭字段，則應該認爲響應不可緩存，以保持與HTTP/1.0服務器的兼容性。

　　注意:源服務器可能但願在網絡上使用相對較新的HTTP緩存控制特性，好比「private」指令，其中包括不理解該特性的舊緩存。原始服務器須要將新特性與一個Expires字段合併，該字段的值小於或等於日期值。這將防止舊的緩存不正確地緩存響應。

s-maxage

　　若是響應包含一個s-maxage指令，那麼對於共享緩存(但不是私有緩存)，該指令指定的最大使用時限將覆蓋由max-age指令或Expires頭指定的最大使用時限。s-maxage指令還包含代理從新驗證指令的語義(參見14.9.4節)，即，在實體過時後，緩存在原始服務器沒有從新驗證它以前必須不能使用該實體來響應後續請求。私有緩存老是忽略s-maxage指令。

　　注意，大多數舊的緩存行爲，不遵循這個規範，沒法實現任何緩存控制指令。若是源服務器但願使用該限制規範但又不防止HTTP/1.1兼容緩存的cache-control指令，那麼它可能會利用max-age指令覆蓋Expires頭字段的要求，以及HTTP/1.1以前的版本兼容的緩存不遵照max-age指令的事實。

　　其餘指令容許用戶代理修改基本的過時機制。這些指示可按要求指定:

max-age

　　指示客戶端願意接受時限不大於指定時間(以秒爲單位)的響應。除非還包含了舊的指令，不然客戶端不但願接受舊的響應。

min-fresh

　　表示客戶端願意接受新鮮度時限不小於當前時間加上指定時間(以秒爲單位)的響應。也就是說，客戶端但願響應至少在指定的秒數內仍然是有效的。

max-stale

　　指示客戶端願意接受超過過時時間的響應。若是賦給max-stale值，那麼客戶端願意接受超過其過時時間不超過指定秒數的響應。若是沒有賦值給max-stale賦值，那麼客戶願意接受任什麼時候限的陳舊響應。

　　若是緩存返回陳舊的響應，或者由於請求上的max-stale指令，或者由於緩存被配置爲覆蓋響應的過時時間，那麼緩存必須使用警告110(響應過期了)並將警告標頭附加到過期的響應上。

　　緩存能夠配置爲在不進行驗證的狀況下返回過期的響應，但前提是這與緩存驗證的任何「必須」級別需求(例如，「必須從新驗證」cache-control指令)不衝突。

　　若是新請求和緩存內容都包含「max-age」指令，那麼兩個值中的較小值將用於肯定該請求緩存內容的新鮮度。

14.9.4 Cache Revalidation and Reload Controls

　　有時候，用戶代理可能但願或須要堅持讓緩存使用原始服務器從新驗證其緩存條目(而不只僅是使用沿着原始服務器路徑的下一個緩存)，或者從原始服務器從新加載其緩存條目。若是緩存或原始服務器高估了緩存響應的過時時間，那麼端到端從新驗證多是必要的。若是緩存條目因爲某種緣由損壞，那麼端到端的從新加載多是必要的。

　　端到端從新驗證能夠在客戶端沒有本身的本地緩存副本時請求，在這種狀況下，咱們將其稱爲「未指定的端到端從新驗證」，或者當客戶端有本地緩存副本時，在這種狀況下，咱們將其稱爲「特定的端到端從新驗證」。

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

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

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

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

　　該請求包括一個「max-age=0」cache-control指令，該指令強制沿着到原始服務器的路徑中的每一個緩存與下一個緩存或服務器一塊兒從新驗證本身的條目(若是有的話)。最初的請求包括一個緩存驗證條件和客戶端的當前驗證器。

Unspecified end-to-end revalidation（未指定的端到端再校驗）

　　該請求包括「max-age=0」緩存控制指令，該指令強制沿着到源服務器的路徑的每一個緩存使用下一個緩存或服務器從新驗證其本身的條目（若是有的話）。初始請求不包括緩存驗證條件，沿着保存該資源的緩存條目的路徑（若是有的話）的具備其當前驗證器的緩存驗證條件的第一個緩存。

max-age

　　當經過max-age=0指令強制中間緩存從新驗證其本身的緩存條目，而且客戶端在請求中提供了本身的驗證器時，所提供的驗證器可能與當前存儲在緩存條目中的驗證器不一樣。在這種狀況下，緩存可使用驗證器來進行本身的請求，而不影響語義透明性。

　　可是，驗證器的選擇可能會影響性能。最好的方法是中間緩存使用它本身的驗證器來進行請求。若是服務器用304（Not Modified.）進行響應，則緩存能夠向客戶端返回其如今已驗證的副本，並帶有200（OK）響應。可是，若是服務器用新的實體和緩存驗證器進行響應，則中間緩存可使用強比較函數將返回的驗證器與客戶端請求中提供的驗證器進行比較。若是客戶端的驗證器等於源服務器，則中間緩存只返回304（Not Modified.）。不然，它返回具備200（OK）響應的新實體。

　　若是請求包含no-cache指令，則不該包括min-fresh、max-stale或max-age。

only-if-cached

　　在某些狀況下，好比網絡鏈接性很是差的時候，客戶端可能但願緩存只返回它當前存儲的響應，而不是使用原始服務器從新加載或從新驗證。要作到這一點，客戶端能夠在請求中包含noly-if-cached指令。若是它接收到這個指令，緩存應該使用與請求的其餘約束一致的緩存條目進行響應，或者使用504(網關超時-Gateway Timeout)狀態進行響應。可是，若是一組緩存做爲一個統一的系統進行操做，而且具備良好的內部鏈接，則該請求能夠在該組緩存中轉發。

must-revalidate（必須從新驗證）

　　由於緩存可能忽略服務器配置的指定過時時間,由於客戶端請求可能包括max-stale指令(也有相似的效果),該協議還包括一個源服務器的機制須要從新驗證緩存條目的任何後續使用。當必須從新驗證指令出如今緩存接收到的響應中時，該緩存必須在條目過時後使用該條目來響應後續請求，而不優先使用原始服務器從新驗證該條目。(即。若是僅基於原始服務器的Expires或max-age值，緩存的響應就過期了，那麼每次緩存都必須執行端到端從新驗證。）

　　must-revalidate指令對於支持某些協議特性的可靠操做是必要的。在任何狀況下，HTTP/1.1緩存必須遵照「must-revalidate」指令;特別是，若是緩存因爲任何緣由沒法到達原始服務器，它必須生成504(網關超時)響應。

　　服務器應該發送「must-revalidate」指令，當且僅當在實體上從新驗證請求失敗可能致使錯誤操做(如未執行的財務事務)時才發送該指令。接收方不得采起任何違反此指令的自動操做，也不得在從新驗證失敗時自動提供實體的未驗證副本。

　　儘管不建議這樣作，可是在嚴格的鏈接約束下操做的用戶代理可能違反此指令，但若是是這樣，則必須明確警告用戶已經提供了未經驗證的響應。每一個未經驗證的訪問都必須提供警告，而且須要明確的用戶確認。

proxy-revalidate（代理從新驗證）

　　proxy-reavalidate指令的含義與must-revalidate指令相同，只是它不適用於非共享的用戶代理緩存。提供每次從新驗證的服務(爲了確保每一個用戶已經經過身份驗證)。

它可使用在迴應一個身份驗證請求,容許用戶的緩存來存儲和後來返回響應,而不須要從新驗證(由於它已經被該用戶身份驗證一次),同時還要求代理服務許多用戶從新驗證每一次(爲了確保每一個用戶已經經過身份驗證)。注意，這種通過身份驗證的響應還須要「public」緩存控制指令，以便可以徹底緩存它們。

14.9.5 No-Transform Directive

no-transform

　　中間緩存（代理）的實現者發現轉換某些實體的媒體類型是有用的。例如，非透明代理能夠在圖像格式之間進行轉換，以便節省緩存空間或減小慢速鏈路上的通訊量。

　　然而，當這些轉換應用於特定類型的應用程序實體時，會出現嚴重的操做問題。例如，用於醫學成像、科學數據分析以及使用端到端認證的應用都依賴於接收與原始實體-主體逐位相同（bit for bit identical——也就是每一字節都與原實體同樣）的實體主體。

　　所以，若是消息包括no-transform指令，則中間緩存或代理必須不改變那些在第13.5.2節中列出的、受no-transform指令制約的報頭。這意味着緩存或代理必須不改變由這些頭字段指定的實體主體的任何方面，包括實體主體自己的值。　　

14.9.6 Cache Control Extensions

　　能夠經過使用一個或多個緩存擴展令牌來擴展Cache-Control頭字段，每一個令牌具備可選的分配值。能夠在不改變其餘指令的語義的狀況下添加信息擴展（不須要改變緩存行爲的擴展）。行爲擴展被設計爲經過對緩存指令的現有基礎做爲修飾符來工做。提供新的指令和標準指令，使得不理解新指令的應用程序將默認執行標準指令指定的行爲，而理解新指令的應用程序將認識到它修改了與標準指令相關的需求。這樣，能夠在不修改基礎協議的狀況下，對緩存控制指令進行擴展。

　　這種擴展機制依賴於HTTP緩存，它遵照爲其原生HTTP版本定義的全部緩存控制指令，遵照某些擴展，並忽略它不理解的全部指令。

　　例如，假設有一個名爲community的新響應指令，它充當私有指令的修飾符。咱們定義這個新指令是爲了表示，除了任何非共享緩存以外，任何僅由值中指定的社區成員共享的緩存均可以緩存響應。但願容許UCI社區在其共享緩存中使用私有響應的源服務器能夠經過包括下面的字段來實現這一點

Cache-Control: private, community="UCI"

　　即便緩存不理解community cache-extension，看到這個header字段的緩存也會正常工做，由於它也會看到並理解私有指令，所以默認爲安全行爲。

　　不能識別的緩存指令必須被忽略;假設任何緩存指令可能沒法被HTTP/1.1緩存識別，將與標準指令結合使用(或者響應的默認緩存能力，即便緩存不理解擴展，緩存行爲也將保持最低限度的正確性)。

14.10 Connection

　　Connection通用頭字段容許發送方指定特定連接所需的選項，而且代理不能經過其餘連接進行通訊。

　　Connection頭字段的語法以下：

　　 Connection = "Connection" ":" 1#(connection-token)

　　connection-token = token

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

　　HTTP/1.1爲發送方定義了「close」鏈接選項，以表示鏈接將在響應完成後關閉。好比：

　　Connection: close

　　不管在響應仍是請求中都表示在響應或請求完成後，該連接不能被看成持久連接。

　　不支持持久連接的HTTP／1.1應用程序必須在每個消息（message）中包含close連接選項。

　　接收包含Connection頭字段的HTTP/1.0(或較低版本)消息的系統，對於該字段中的每一個鏈接令牌（coonection-token），必須從與鏈接令牌同名的消息中刪除和忽略任何頭字段。這能夠防止這些頭字段被http /1.1代理錯誤轉發。（詳情見19.6.2小節）

14.11 Content-Encoding

　　Content-Encoding實體頭字段被用來看成media-type的調節器。當存在時，它的值指示哪些附加的內容編碼已經應用到實體主體，所以咱們要知道在Content-Type頭字段中使用的media-type須要使用怎麼樣的解碼機制。Content-Type主要用於容許文檔被壓縮而不丟失其底層媒體類型的特徵。

Content-Encoding = "Content-Encoding" ":" 1#content-coding

　　內容編碼在 3.5中被定義。一個使用的例子：

Content-Encoding: gzip

　　內容編碼是由請求URI標識的實體的特性。典型地，實體用這樣的編碼方式存儲，而且只有在渲染內容或相似的狀況下使用以前才被解碼。然而，除非消息中存在「no-transform」緩存控制指令，不然，若是已知接收方能夠接受新編碼，則非透明代理能夠修改內容編碼。

　　若是一個實體的內容編碼不是「identity」，而後，響應必須包含內容編碼實體頭(14.11節)，其中列出了使用的非標識內容編碼。

　　若是原始服務器沒法接受請求消息中實體的內容編碼，則服務器應以狀態碼415(Unsupported Media Type)進行響應。

　　若是多個編碼被應用到一個實體中，內容編碼必須按照應用它們的順序列出。有關編碼參數的其餘信息能夠由本規範未定義的其餘實體頭字段提供。

14.12 Content-Language

　　Content-Language 實體頭字段描述了封閉實體的預期受衆的天然語言。注意，這可能不等於實體主體（entity-body）中使用的全部語言。

　　Content-Language = "Content-Language" ":" 1#language-tag

　　語言標識在 3.10節中作了定義。內容語言的主要目的是容許用戶根據本身的首選語言識別和區分實體。所以，若是正文內容僅針對具備丹麥語文化的讀者，則適當的範圍是

　　 Content-Language: da

　　若是沒有指定內容語言，默認狀況下內容是針對全部語言受衆的。這可能意味着發送方不認爲它是特定於任何天然語言的，或者發送方不知道它是針對哪一種語言的。

　　能夠爲多個受衆列出多個語言的內容。例如，同時在原始毛利語和英語版本中出現的《瓦伊坦吉條約》的譯本就須要

　　 Content-Language: mi, en

　　然而，僅僅由於多個語言存在於一個實體中並不意味着它是針對多個語言受衆的。舉個例子，初學者的語言入門，好比「拉丁語第一課」，很明顯是用來讓有英語基礎的觀衆使用的。在這種狀況下，內容語言將只包括「EN」。

　　Content-Language能夠應用於任何媒體類型——它不限於文本文檔。

14.13 Content-Length

　　Content-Length實體頭字段表示實體內容的大小，發送給接收者的是一個十進制八位字節的數字，在HEAD方法中，若是請求是GET，那麼將發送的實體主體的大小。

　　Content-Length = "Content-Length" ":" 1*DIGIT

　　下面是一個例子

　　Content-Length: 3495

　　應用程序應該使用此字段來指示消息體的傳輸長度（transfer-length），除非第4.4節中的規則禁止這一點。

　　任何大於或等於0的內容長度都是一個有效值。第4.4節描述了若是沒有提供內容長度，如何肯定消息體的長度。

　　注意，這個字段的含義與MIME中相應的定義有很大的不一樣，MIME是「消息/外部體」（"message/external-body"）內容類型中使用的可選字段。在HTTP中，只要消息的長度能夠在傳輸以前肯定，就應該發送它，除非第4.4節中的規則禁止這一點。

14.14 Content-Location

　　當從與請求資源的URI分離的位置訪問該實體時，可使用Content-Location實體頭字段爲消息中包含的實體提供資源位置。服務器應該爲響應實體對應的變體提供內容位置;特別是當一個資源有多個與它相關聯的實體，而且這些實體實際上有單獨的位置，經過這些位置能夠單獨訪問它們，服務器應該爲返回的特定變體提供一個內容位置。

　　Content-Location = "Content-Location" ":"( absoluteURI | relativeURI )

　　Content-Location的值也定義了基本實體的URI。

　　Content-Location的值不是原始請求URI的代替;它只是請求時對應於此特定實體的資源位置的聲明。若是但願標識特定實體的源，未來的請求能夠指定Content-Location URI做爲請求URI。

　　緩存不能假設具備與用於檢索它的URI不一樣的內容位置的實體能夠用於響應該內容位置URI上的稍後請求。然而，Content-Location可用於區分從單個請求資源檢索的多個實體，如第13.6節所述。

　　若是Content-Location是一個相對的URI標識，相對URI是相對於請求URI解釋的。

　　在PUT或Post請求中Content-Location頭字段是未定意的。服務器在這種狀況下會忽略這些內容。

14.15 Content-MD5

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

　　Content-MD5 = "Content-MD5" ":" md5-digest

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

　　Content-MD5頭字段能夠由源服務器或客戶端生成，以做爲實體主體的完整性檢查。只有原始服務器或客戶端可能生成Content-MD5頭字段；代理和網關不能生成，由於這將破壞其做爲端到端完整性檢查的價值。任何實體主體的接收者，包括網關和代理，均可以檢查這個頭字段中的摘要值是否與接收到的實體主體的摘要值匹配。

　　MD5摘要是基於實體主體的內容計算的，包括已經應用的任何內容編碼，但不包括應用到消息主體的任何傳輸編碼。若是用傳輸編碼接收到消息，則必須在根據接收到的實體檢查Content-MD5值以前刪除該編碼。

　　這樣作的結果是，在實體主體的八位字節上精確地計算摘要，而且若是沒有應用傳輸編碼，則按照這樣的順序發送摘要。

　　HTTP擴展了RFC 1864，容許爲MIME複合媒體類型（例如，multipart/*和message/rfc822）計算摘要，但這並不改變如前段所定義的摘要的計算方式。

　　這有幾個後果。複合類型的實體主體可能包含許多主體部分，每一個部分都有本身的MIME和HTTP頭(包括Content-MD五、Content-Transfer-Encoding和Content-Encoding頭)。若是body-part具備content - transfer - encoding頭字段，則假設body-part的內容已經應用了編碼，而且body-part包含在content - md5摘要中，以下所示:以後的運行中。在主體部分中不容許使用Transfer-Encoding頭字段。

　　在計算或檢查摘要以前，不能將全部換行符轉換爲CRLF:實際傳輸的文本中使用的換行約定在計算摘要時必須保持不變。

　　注意：儘管Content-MD5的定義對於HTTP與RFC 1864對於MIME實體主體的定義徹底相同，可是在幾種狀況下，Content-MD5對於HTTP實體主體的應用不一樣於其對於MIME實體主體的應用。一種是HTTP不一樣於MIME，它不使用內容傳輸編碼，但使用傳輸編碼和內容編碼。另外一個緣由是HTTP比MIME更頻繁地使用二進制內容類型，所以值得注意的是，在這種狀況下，用於計算摘要的字節順序是爲該類型定義的傳輸字節順序。最後，HTTP容許使用幾種換行規則中的任何一種來傳輸文本類型，而不只僅是使用CRLF的規範形式。

14.16 Content-Range

　　Content-Range實體頭字段與部分實體主體一塊兒發送，以指定在完整實體主體中應該在何處應用部分主體。範圍單元在3.12節中定義。

　　 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

　　報頭應該指示完整實體的總長度，除非這個長度是未知的或難以肯定的。星號「*」字符表示在生成響應時，實例長度未知。

　　與byte-ranges-specifier的值（參見14.35.1節）不一樣，byte-range-resp-spec必須只指定一個範圍，而且必須包含該範圍的第一個和最後一個字節的絕對字節位置。

　　當一個byte-range-resp-spec存在一個byte-content-range-spec值，而且該值的最後一位（last-byte-pos）小於它的第一位（first-byte-po），或者它的實際長度（instance-length）小於或等於它最後一位（last-byte-pos），這樣是不容許的。接收者應該忽略一個未經過驗證的byte-content-range-spec，以及隨其傳輸的任何其餘內容。

　　發送具備狀態代碼416（請求範圍不可知足）的響應的服務器應該包括具備byte-range-resp-spec的值爲「*」的Content-Range字段。實例長度指定所選資源的當前長度。使用狀態代碼206（部份內容）的響應不能包含具備「*」字節的 byte-range- resp-spec字段。　　

　　下面是一個字節內容範圍規則值(byte-content-range-spec)的例子，假設實體總共包含了1234字節：

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

　　 . 第二個五百個字節: bytes 500-999/1234

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

　　. 最後五百個字節： bytes 734-1233/1234

　　當一個HTTP消息包含一個單一範圍的內容(例如,一個響應請求一個單一的範圍,或者請求一組沒有任何漏洞的重疊範圍),該內容與Content-Range頭字段一塊兒傳遞,而且Content-Length頭字段應該顯示實際傳輸的字節數。例如,

　　 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

　　當HTTP消息包含多個範圍(例如，對多個非重疊範圍的請求的響應)的內容時，這些內容做爲多部分消息進行傳輸。用於此目的的大部分媒體類型是附錄19.2中定義的「多multipart/byteranges」。兼容性問題見附錄19.6.3。

　　對於單個範圍的請求的響應不能使用multipart/byteranges媒體類型來發送。對多個範圍的請求的響應，若是其結果是單個範圍，可能做爲帶有一個部分的multipart/byteranges媒體類型發送。不能解碼multipart/byteranges消息的客戶端不能在單個請求中請求多個byte-ranges。

　　當客戶端在一個請求中請求多個byte-ranges時，服務器應該按照它們在請求中出現的順序返回它們。

　　若是服務器因爲語法無效而忽略了 byte-range-spec，則服務器應將請求視爲不存在無效Range頭字段。（一般，這意味着返回包含完整實體的200響應）。

　　若是服務器收到一個請求(除了一個包括If-Range請求頭字段)和一個請求頭字段不可知足的範圍(即全部的byte-range-spec值first-byte-pos值大於當前選中的資源的長度）,它應該返回一個416響應代碼(請求的範圍不能夠知足的)( 10.4.17小節)。

　　注意:對於不可知足Range請求頭字段狀況，客戶端不能依賴服務器發送416(Requested range not satisfiable)響應來代替200 (OK)響應，由於不是全部服務器都支持這個請求頭。

14.17 Content-Type

　　Content-Type實體字段表示發送給接收方的實體主體的媒體類型，對於HEAD方法，則表示若是請求是GET，應該發送的媒體類型。

　　Content-Type = "Content-Type" ":" media-type

　媒體類型已經在 3.7小節中定義，下面是該字段的一個例子

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

　　第7.2.1節進一步討論了肯定實體的媒體類型的方法。

14.18 Date

　　Date通用頭字段表示消息產生的日期和時間，跟RFC822中的orig-date同樣。該字段的值是一個HTTP—DATE，它的詳細描述在 3.3.1小節，它在傳輸的時候必須被格式化。

　　 Date = "Date" ":" HTTP-date

　　下面是一個例子：

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

　　源服務器必須在全部的響應中包含一個Date頭字段，除了如下的狀況：

　　　　1.若是響應的狀態碼是100或者101，在服務器的配置中，響應中能夠包含Date頭字段。

　　　　2.若是響應狀態代碼傳遞了一個服務器錯誤，例如500(內部服務器錯誤)或503(服務不可用)，而且不方便或不可能生成一個有效的日期。

　　　　3.若是服務器沒有一個能夠提供合理的接近當前時間的值，那麼它的響應必定不能包含一個Date頭字段，咱們必須遵照 14.18.1小節中的相關規則。

　　若是消息將經過須要Date的協議被接收方或網關緩存，則接收到的沒有日期標頭字段的消息必須由接收方分配一個Date頭字段。沒有時鐘的HTTP實現不能緩存響應，而且沒必要在每次使用時從新驗證它們。HTTP緩存，尤爲是共享緩存，應該使用NTP等機制來使其時鐘與可靠的外部標準同步。

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

　　在日期標頭中發送的HTTP-date不該該表示消息生成以後的日期和時間。它應該表示消息生成時日期和時間的最佳近似值，除非實現沒法生成合理準確的日期和時間。理論上，日期應該表示實體生成以前的時刻。在實踐中，日期能夠在不影響其語義值的狀況下，消息發起期間的任什麼時候候生成。

14.18.1 Clockless Origin Server Operation

　　一些原始服務器實現可能沒有可用的時鐘。沒有時鐘的原始服務器不能給響應分配Expires或Last-Modified值，除非Date值是由與資源相關聯的、具備可靠時鐘的系統或用戶產生的。它可能分配一個Expires值，該值在服務器配置時或以前是已知的（這使得「pre-expiration」的響應無需單獨的存儲每一個資源的Expires值）。

14.19 ETag

　　ETAG響應頭字段爲所請求的變體提供實體標籤的當前值。在 14.24, 14.26和 14.44小節中描述了與實體標籤一塊兒使用的頭字段。實體標籤可用於與來自同一資源的其餘實體進行比較（參見第13.3.3節）。

　　ETag = "ETag" ":" entity-tag

　　例子:

　　ETag: "xyzzy"

　　ETag: W/"xyzzy"

　　 ETag: ""

14.20 Expect

　　Expect請求頭字段被用來描述客戶端須要的特定的服務器行爲。

　　 Expect = "Expect" ":" 1#expectation

　　 expectation = "100-continue" | expectation-extension

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

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

　　服務器若是沒法理解或者遵照任何請求中Expect頭字段中的任何存在的預期值，那麼應該返回適當的錯誤狀態。服務器必須返回417錯誤，若是任何的「指望」都沒法知足，或者有其餘的客戶端請求錯誤，一些4XX錯誤。

　　該頭字段被定義爲可擴展的語法，以用在將來可能的擴展中。若是一個服務器接收到了它不支持的Expect頭字段中所包含的拓展詞（expectation-extension），那麼它必須返回一個417錯誤（Expectation Failed）。

　　「指望」值的比較對於未引用的tokens（包括100-continue）不區分大小寫，而且對於引用字符串的指望擴展區分大小寫。

　　Expect機制是逐跳（hop-by-hop）的：也就是說，若是HTTP/1.1代理接收到了預期沒法知足的請求，則必須返回417（Expectation Failed）狀態。可是，預期請求頭自己是端到端的；若是轉發請求，則必須轉發它。

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

　　100（continue）狀態碼的使用方法請查閱8.2.3小節。

14.21 Expires

　　Expires實體頭字段給出響應過時的日期/時間。過時的緩存內容一般不會返回緩存機制所緩存的內容(包括代理緩存或用戶代理緩存)，除非它首先經過原始服務器(或具備實體的新副本的中間緩存)進行驗證。有關到期模型的進一步討論，請參閱第 13.2節。

　　Expires字段的存在並不意味着原始資源將在該時間節點點以前或以後改變或再也不存在。

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

　　 Expires = "Expires" ":" HTTP-date

　　下面是一個使用案例

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

　　注意:若是響應包含一個Cache-Control字段和max-age指令(參見14.9.3節)，該指令將覆蓋Expires字段。

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

　　若是想要將響應標記爲「已過時」，那麼源服務器須要發送一個等於日期標頭值的過時日期。(詳情請參閱第 13.2.4節中的過時計算規則。)

　　爲了將響應標記爲「永不過時」，源服務器發送的Expires日期的值爲該響應發送時起的一年後，那麼HTTP/ 1.1服務器不該在將來發送超過一年的過時日期。

　　若是Expires頭字段的日期值在未來的某個時間出如今默認爲不可緩存的響應上，那麼表示響應是可緩存的，除非Cache-Control頭字段( 14.9小節)另有指示。

14.22 From

　　From請求頭字段，若是存在，須要包含一個客戶端使用者的互聯網郵箱地址。該地址應該是能夠被機器識別的「machine-usable」，具體的規則在 RFC 822 [9]並在 RFC 1123 [8]中作了一些升級：

　　 From = "From" ":" mailbox

　　下面是一個例子：

　　 From: webmaster@w3.org

　　該頭字段可用於日誌記錄，並可用於標識無效或不想要請求的資源。它不該該用做不安全的訪問保護形式。該字段的解釋是，請求是表明指定的人所發出的，該人對執行方法負有責任。特別是，機器人代理應該包括這個頭，以便在接收端出現問題時能夠聯繫負責運行機器人的人。

　　此字段中的Internet電子郵件地址可能與發出請求的Internet主機分開。例如，當請求經過代理傳遞時，應該使用原始發佈者的地址。

　　客戶端不該該在未經用戶批准的狀況下發送From頭字段，由於這可能會與用戶的隱私利益或其站點的安全策略發生衝突。強烈建議用戶可以在請求以前的任什麼時候候禁用、啓用和修改此字段的值。

14.23 Host

　　Host 請求頭字段指定了從用戶給出的原始URI或引用資源（一般是HTTP URL，如3.2.2節所述）中所得到的被請求資源的網絡主機和端口號。HOST字段值必須表明原始URL給出的源服務器或網關的命名權限。這容許原始服務器或網關區份內部模糊的（內部歧義）URL，例如，用於單個IP地址上的多個主機名的服務器URL的根名稱「/」。

　　 Host = "Host" ":" host [ ":" port ] ; Section 3.2.2

　　若是一個host尾部並無跟隨端口號信息，那麼就是默認的端口號（好比，HTTP URl的默認端口號是80）。舉個例子。向「http://www.w3.org/pub/WWW」所發出的請求會包含如下信息：

　　GET /pub/WWW/ HTTP/1.1

　　Host: www.w3.org

　　在HTTP/1.1的客戶端請求信息中必須包含HOST頭字段。若是所請求的URI不包括所請求服務的Internet主機名，則必須給Host頭字段一個空值。HTTP/1.1代理必須確保它轉發的任何請求信息中都包含適當的HOST頭字段，該字段標識代理請求的服務。全部基於HTTP/1.1的互聯網請求的服務器必須對任何缺乏主機頭字段的HTTP/1.1請求消息使用400（Bad Request）狀態碼進行響應。

　　有關HOST字段的其餘要求見第5.2和19.6.1.1 節。

14.24 If-Match

　　If-Match請求頭字段須要與一個使其成爲「條件」的方法一塊兒使用。擁有一個或多個以前從資源中得到的實體的客戶端能夠經過在If-Match頭字段中包含相關實體標記的列表來驗證這些實體中的一個是不是當前匹配的。實體標記在 3.11節中有詳細說明。這個特性的目的是容許以最少的開銷，高效地更新緩存的信息。在更新請求時，它還用於防止無心中修改錯誤版本的資源。做爲一種特殊狀況，「*」值匹配資源的任何當前實體。

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

　　若是任何實體標記與在響應該資源上的相似GET請求（沒有if-Match頭字段）時返回的實體的實體標記相匹配，或者若是「*」值在IF-Matc中被給出而且任何當前的實體都存在該資源中，則服務器能夠執行所請求的方法就像if-Match頭字段不存在同樣。

　　服務器必須使用強比較函數（參見第 13.3.3節）來比較If-Match中的實體標籤。

　　若是沒有匹配的實體標記，或者給定了「*」值，且不存在當前實體，服務器就不能執行請求的方法，必須返回412(Precondition Failed)響應。當客戶端但願阻止一個更新類型的方法(如PUT)修改自客戶端上次檢索後已更改的資源時，這種行爲最有用。

　　若是請求在沒有if-Match頭字段的狀況下會致使除了2xx或412狀態以外的任何結果，則必須忽略if-Match頭字段。

　　「if-Match：*」的含義是，若是源服務器(或緩存，可能使用變體機制，請參見14.44節)選擇的內容存在，則應該執行該方法，若是內容不存在，則必須不執行該方法。

　　更新資源(例如PUT)的請求可能包含if-match頭字段，以表示若是與if-match值(單個實體標記)對應的實體再也不是該資源的表示，則不得應用請求方法。這容許用戶表示，若是資源在他們不知情的狀況下被更改，他們不但願請求成功。

　　例如：

　　 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（Not Modified）響應會被返回。

　　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 (OK)狀態，或者傳遞的If-Modified-Since日期無效，則響應與普通GET徹底相同。晚於服務器當前時間的日期無效。

　　 b) 若是該變體自If-Modified-Since所攜帶的日期以來進行了修改，則響應與普通GET徹底相同。

　　 c)若是該變體在有效的If-Modified-Since日期以後沒有被修改，服務器應該返回304(沒有修改)響應。

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

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

　　注意:由於時間是由服務器肯定的，服務器的時間可能與客戶端的時間不一樣步。

　　　　注意：在處理If-Modified-Since頭字段時，一些服務器將使用精確的日期比較函數而不是小於函數來決定是否發送304(未修改)響應。爲了得到最好的結果，當發送一個If-Modified-Since頭字段來進行緩存驗證時，建議客戶端儘量使用在上一個Last-Modified頭字段中收到的確切日期字符串。

　　　　注意：若是客戶端在If-Modified-Since頭字段中使用任意日期，而不是使用從同一個請求的Last-Modified頭字段中提取的日期，那麼客戶端應該知道這個日期是用服務器中的時間來作爲解釋的。因爲客戶端和服務器之間的時間並不相同，客戶端須要考慮不一樣步時鐘和舍入問題。這包括，若是文檔在第一次請求的時間和後續請求中存在If-Modified-Sinc日期之間發生了更改，那麼可能存在競態條件;若是If-Modified-Since日期來自客戶端的時鐘，且並無修改服務器的時鐘，則可能存在時鐘偏移相關的問題。因爲網絡延遲，客戶端和服務器之間的不一樣時間間隔即便在修正後也不可能徹底同樣。

　　一個請求中是否能夠同時存在If-Match字段和If-None-Match或If-Modified-Since頭字段在本規範中並未定義。

14.26 If-None-Match

　　If-None-Match請求頭字段須要與一個使其成爲「條件」的方法一塊兒使用。擁有一個或多個先前從資源中得到的實體的客戶端能夠經過在If-None-Match頭字段中包含相關實體標記的列表來驗證這些實體都不是當前的。這個特性的目的是容許以最少的事務開銷來高效地更新緩存的信息。它還用於防止客戶端認爲資源不存在時在無心中使用一些方法修改現有資源(例如PUT)。

做爲一種特殊狀況，「*」值匹配資源的任何當前實體。

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

　　若是任何實體標記匹配該實體標記，那麼將會致使在使用一個相似GET請求(不具備If-None-Match請求頭)下的資源被返回，或者給出的If-None-Match請求頭字段的值時*號而且當前存在任何屬於該資源的實體，除非必要不然服務器必定不能執行所請求的方法，由於在If-Modified-Since請求頭字段中資源的修改日期是不匹配的。。相反，若是請求方法是GET或HEAD，服務器應該使用304(未修改)響應進行響應，包括與緩存相關的頭字段(特別是與ETag匹配的一個實體)。對於全部其餘請求方法，服務器必須以412狀態響應(Precondition Failed)。

　　有關如何肯定兩個實體標記是否匹配的規則，請參閱第13.3.3節。弱比較函數只能用於GET或HEAD請求。

　　若是實體標記都不匹配，那麼服務器能夠執行請求的方法，就好像If-None-Match頭字段不存在同樣，可是必須忽略請求中存在的任何If-Modified-Since頭字段。也就是說，若是沒有實體標記匹配，服務器就不能返回304(Not Modified)響應。

　　若是請求在沒有If-None-Match頭字段的狀況下，結果不是2xx或304狀態，則必須忽略If-None-Match標頭。(請參閱第13.3.4節，瞭解在同一請求中同時出現If-Modified-Since和If-None-Match時的服務器行爲。)

　　「If-None-Match: *」的意思是，若是原始服務器(或緩存可能使用變體機制，請參見14.44節)選擇的表示存在，則不能執行該方法，若是表示不存在，則應該執行該方法。這個特性用於防止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頭字段在本規範中並未定義。

14.27 If-Range

　　若是客戶端在其緩存中有一個實體的部分副本，而且但願在其緩存中有整個實體的最新副本，那麼它可使用Range 請求頭和一個有條件的GET(使用If-Unmodified-Since和If-Match)。可是，若是因爲實體被修改而致使條件失敗，那麼客戶端將不得不發出第二次請求以得到整個當前實體主體。

　　If-Range報頭容許客戶端「短路（short-circuit）」第二個請求。非正式地說，它的意思是「若是實體沒有改變，就把我缺乏的部分發給我;不然，將整個新實體發送給我」。

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

　　若是客戶端沒有實體的實體標記，可是有最後修改日期，它能夠在If-Range頭字段中使用該日期。(服務器能夠經過檢查不超過兩個字符來區分有效的HTTP-date和任何形式的實體標記。)If-Range頭字段應該只與Range頭字段一塊兒使用，若是請求不包含Range頭字段，或者服務器不支持子範圍操做，則必須忽略該報頭。

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頭字段中的實體標記與實體的當前實體標記匹配，那麼服務器應該使用206(Partial content)響應提供實體的指定子範圍。若是實體標記不匹配，那麼服務器應該使用200 (OK)響應返回整個實體。

14.28 If-Unmodified-Since

　　If-Unmodified-Since請求頭字段須要與一個使其成爲「條件」的方法一塊兒使用。若是請求的資源在此字段中指定的時間以後沒有被修改，服務器應該執行請求的操做，就像If-Unmodified-Sincee頭文件不存在同樣。

　　若是請求的變體自指定時間以來已經被修改，服務器必須不執行請求的操做，而且必須返回412(Precondition Failed)狀態。

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

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

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

　　若是在請求正常(例如，請求中沒有If-Unmodified-Since報頭)的狀況下，，可能會產生除了2xx或412狀態外的其餘任何狀態，那麼If-Unmodified-Since報頭應該被忽略。

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

　　此規範未定義具備If-Unmodified-Since標頭字段和If-None-Match或If-Modified-Since標頭字段的請求的結果。

14.29 Last-Modified

　　Last-Modified實體頭字段指示原始服務器認爲該變體最後被修改的日期和時間。

　　Last-Modified = "Last-Modified" ":" HTTP-date

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

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

　　這個頭字段的確切含義取決於原始服務器的實現和原始資源的性質。對於文件，可能只是文件系統最後一次修改的時間。對於包含動態部件的實體，它多是其組件部件的最後一次修改時間集的最近一次修改時間集。對於數據庫網關，它多是記錄的最後更新時間戳。對於虛擬對象，多是最後一次更改的內部狀態。

　　源服務器不能發送晚於服務器發出消息時間的Last-Modified日期。在這種狀況下，若是資源的最後一次修改將指示未來的某個時間，則服務器必須將該日期替換爲消息發起日期。

　　原始服務器應該包含儘量接近於實體生成響應的時間的日期值的Last-Modified值。這容許接收方準確評估實體的修改時間，特別是當實體在生成響應時發生更改。

　　HTTP/1.1服務器應該在可行的狀況下發送Last-Modified。

14.30 Location

　　Location 響應頭字段用於將收件人重定向到請求uri之外的位置，以完成請求或標識新資源。對於201(Created)響應，Location是由請求建立的新資源的位置。對於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

　　Max-Forwards請求頭字段爲TRACE(9.8節)和OPTIONS(9.2節)方法提供了一種機制，用於限制能夠將請求轉發到下一個入站服務器的代理或網關的數量。當客戶端試圖跟蹤請求鏈時，若是請求鏈在中間鏈中出現故障或循環，這可能很是有用。

　　 Max-Forwards = "Max-Forwards" ":" 1*DIGIT

　　最大轉發值是一個十進制整數，指示此請求消息可能被轉發的剩餘次數。

　　TRACE或OPTIONS請求的每一個代理或網關接收者(包含Max-Forwards頭字段)必須在轉發請求以前檢查並更新其值。若是接收到的值爲0，接收方不得轉發請求;相反，它必須做爲最終接收者作出迴應。若是接收到的Max-Foewards值大於零，那麼轉發的消息必須包含一個更新的Max-Foewards字段，其值遞減爲1。

　　對於本規範中定義的全部其餘方法和那些沒有明確地將其做爲該方法定義的一部分的擴展方法來講，Max-Forwards頭字段均可能被忽略。

14.32 Pragma

　　Pragma通用頭字段用於包含可能應用於請求/響應鏈上任何接收者的特別的指令。全部實用程序指令從協議的角度指定可選行爲;然而，一些系統可能要求行爲與指令一致。

　　 Pragma = "Pragma" ":" 1#pragma-directive

　　 pragma-directive = "no-cache" | extension-pragma

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

　　當請求消息中出現no-cache指令時，應用程序應該將請求轉發到原始服務器，即便它有被請求內容的緩存副本。這個pragma指令具備與no-cache緩存指令相同的語義(參見14.9節)，它的定義是爲了向後兼容HTTP/1.0。當一個沒有緩存的請求被髮送到一個不知道是否兼容HTTP/1.1的服務器時，客戶端應該包含這兩個頭字段。

　　Pragma指令必須經過代理或網關應用程序傳遞，而無論它們對應用程序的重要性如何，由於這些指令可能適用於請求/響應鏈上的全部接收者。不可能爲特定的接收者指定一個實用程序;然而，任何與接收者無關的Pragma指令都應該被接收者忽略。

　　HTTP/1.1緩存應該將「Pragma: no-cache」視爲客戶端發送的「Cache-Control: no-cache」。HTTP中不會定義新的Pragma指令。

　　注意:由於「Pragma: no-cache」做爲響應頭字段的含義實際上沒有指定，因此它不能替換響應中的「Cache-Control: no-cache」頭字段。

14.33 Proxy-Authenticate

　　Proxy Authenticate 響應頭字段必須被包含在一個407（Proxy Authentication Required）響應中。字段值包含一個「詢問」，該「詢問」指示這個請求URI的代理適用的身份驗證方案及參數。

　　Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge

　　HTTP訪問身份驗證過程被描述爲「HTTP身份驗證:基本和摘要訪問身份驗證」[43]。與WWW-Authenticate不一樣，代理身份驗證頭字段僅應用於當前鏈接，不該傳遞到下游客戶端。可是，中間代理可能須要經過從下游客戶端請求它們來得到本身的憑證，在某些狀況下，這看起來就好像代理在轉發Proxy-Authenticate頭字段同樣。

14.34 Proxy-Authorization

　　Proxy-Authorization請求頭字段容許客戶端將本身(或其用戶)標識給須要身份驗證的代理。Proxy-Authorization字段值由憑證組成，該憑證包含用戶代理的身份驗證信息，用於請求的資源和/或領域。

　　 Proxy-Authorization = "Proxy-Authorization" ":" credentials

　　HTTP訪問身份驗證過程在「HTTP Authentication:基本和摘要訪問身份驗證」[43]中有更詳細的描述。與Authorization不一樣，Proxy-Authorization頭字段僅適用於使用Proxy- Authenticate字段要求進行身份驗證的下一個出站代理。當在一個鏈中使用多個代理時，Proxy-Authorization頭字段將由第一個指望接收憑證的出站代理使用。代理能夠將憑證從客戶端請求中繼到下一個代理，若是這是代理合做驗證給定請求的機制的話。

14.35 Range

14.35.1 Byte Ranges(字節範圍)

　　因爲全部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給定的是最後一個字節的範圍。也就是說，指定的字節位置包括在內。字節的範圍從0開始。

　　若是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，客戶端能夠在不知道實體大小的狀況下限制檢索的字節數。

　　 suffix-byte-range-spec = "-" suffix-length

　　suffix-length = 1*DIGIT

　　suffix-byte-range-spec被用來用於指定實體主體的後綴，其長度由suffix-length值給出。(也就是說，該結構指定實體主體的最後N字節。)若是實體短於指定的suffix-length，則使用整個實體主體。

　　若是一個語法有效的byte-range-set包含至少一個byte-range-spec，其first-byte-pos小於實體主體的當前長度，或者至少一個非零的suffix-byte-range-spec，那麼byte-range-set是可知足的。不然， byte-range-se是沒法知足的。若是byte-range-set沒法知足，服務器應該返回狀態爲416的響應(Requested range not satisfiable)。不然，服務器應該返回狀態爲206(Partial Content)的響應，其中包含實體主體的可知足範圍。　　

　　下面是一個指定字節範圍值的例子（假定實體主體的長度是10000）:

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

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

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

　　- 或者 bytes=9500-

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

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

　　　　　　bytes=500-600,601-999

　　　　bytes=500-700,601-999

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

　　使用條件或無條件GET方法的HTTP檢索請求可使用Range請求頭請求實體的一個或多個子範圍，而不是整個實體，它適用於做爲請求結果返回的實體:

　　Range = "Range" ":" ranges-specifier

　　服務器可能忽略Range頭字段。然而，HTTP/1.1源服務器和中間緩存應該儘量支持字節範圍，由於Range頭字段支持對部分失敗傳輸的高效恢復，而且支持對大型實體的高效部分檢索。

　　若是服務器支持Range頭字段，而且指定的範圍適合實體:

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

　　　　- 有條件的GET請求(使用If-Modifify-Since或者If-None-Match中一個或兩個的請求，或者If-Unmodify-Since和If-Match中一個或兩個的請求)中存在的Range頭字段能夠修改若是GET成功且條件爲true時返回的內容。若是條件爲false，則不影響返回的304(Not Modified)響應。

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

　　若是支持範圍的代理接收範圍請求，將請求轉發到入站服務器，並接收整個實體做爲響應，那麼它應該只將請求範圍返回給客戶端。若是響應與緩存分配策略一致，則應該將整個接收到的響應存儲在緩存中。

14.36 Referer

　　Referer[sic]請求頭字段容許客戶端爲服務器的着想的角度指定獲取請求URI的資源的地址(「referrer」，儘管頭字段拼錯了)。Referer請求頭容許服務器爲感興趣的資源生成返回連接列表，日誌記錄，優化緩存等等。它也容許對過期的或輸入錯誤的連接進行跟蹤以進行維護。若是從沒有本身的URI(例如從用戶鍵盤輸入)的源獲取請求URI，則不能發送Referer字段。

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

　　例子：

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

　　若是字段值是一個相對URI，則應該將其解釋爲相對於請求URI。URI不能包含片斷。有關安全方面的參考，請查看第15.1.3小節。

14.37 Retry-After

　　Retry-After 響應頭字段可與503(Service Unavailable)響應一塊兒使用，以指示請求客戶端預期服務不可用的時間。此字段還能夠與任何3xx(Redirection)響應一塊兒使用，以指示用戶代理在發出重定向請求以前等待的最短期。該字段的值能夠是HTTP-date值，也能夠是響應時間以後的整數秒數(十進制)。

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

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

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

　　 Retry-After: 120

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

14.38 Server

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(確認;辨認;認出) 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 section 14.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(實現者) are encouraged(鼓動;鼓勵) to make this field a configurable(結構的，可配置的) option.

14.39 TE

　　TE請求頭字段指示它願意在響應中接受哪些擴展傳輸編碼，以及是否願意接受分組傳輸編碼中的trailer字段。它的值可能包括關鍵字「trailers」和（或）帶有可選接收參數的以逗號分隔的擴展傳遞編碼名稱列表(如3.6節所述)。

　　TE = "TE" ":" #( t-codings )

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

　　關鍵字「trailers」的出現代表客戶願意接受分段轉換編碼中的trailer字段，如 3.6.1節中定義的那樣。這個關鍵字保留用於傳輸編碼值，即便它自己並不表示傳輸編碼。

　　它的用法:

　　 TE: deflate

　　 TE:

　　 TE: trailers, deflate;q=0.5

　　TE頭字段僅適用於短鏈接（immediate connection）。所以，當HTTP/1.1消息中出現TE時，必須在鏈接標頭字段(14.10小節)中提供關鍵字。

　　根據TE字段，服務器使用如下規則測試傳輸編碼是否可接受:

　　1. 「chunked」的轉換編碼老是能夠接受的。若是列出了關鍵字「trailers」，則客戶端表示它願意表明本身和任何下游客戶接受chunked響應中的trailer字段。這意味着，若是給定，客戶端將聲明，要麼全部下游客戶端都願意接受轉發響應中的trailers字段，要麼它將嘗試表明下游接收者緩衝響應。

　　　　注意:HTTP/1.1沒有定義任何方法來限制chunked響應的大小，從而確保客戶端可以緩衝整個響應。

　　2.若是正在測試的傳輸編碼是TE字段中列出的傳輸編碼之一，那麼它是能夠接受的，除非qvalue的值爲0。(在3.9節中定義，0的qvalue值表示「不可接受」。)

　　 3. 若是多個傳輸編碼是可接受的，則首選具備最高非零qvalue值的可接受傳輸編碼。「chunked」轉換編碼的qvalue值老是爲1。

　　若是TE字段值爲空或不存在TE字段，則惟一的傳輸編碼是「chunked」。沒有傳輸編碼的消息老是能夠接受的。

14.40 Trailer

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

　　Trailer = "Trailer" ":" 1#field-name

　　HTTP/1.1消息應該包含消息中的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不該該包含任何頭字段。請參閱第3.6.1節，瞭解在「chunked」傳輸編碼中使用trailer字段的限制。

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

. Transfer-Encoding

. Content-Length

. Trailer

14.41 Transfer-Encoding

　　Transfer-Encoding 通用頭字段指示向消息體應用了什麼（若是有的話）類型的轉換，以便在發送方和接收方之間安全地傳輸它。這與內容編碼不一樣，由於傳輸編碼是消息的屬性，而不是實體的屬性。

　　Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding

　　Transfer-codings在 3.6小節中有詳細的定義。下面是一個例子：

　　Transfer-Encoding: chunked

　　若是多個編碼被應用到一個實體，那麼傳輸編碼必須按照應用它們的順序列出。有關編碼參數的其餘信息能夠由本規範未定義的其餘實體頭字段提供。

　　大多數應用HTTP/1.0的協議沒法理解Transfer-Encoding頭字段。

14.42 Upgrade

　　Upgrade通用頭字段容許客戶端指定它支持哪些附加通訊協議，若是服務器發現它適合交換協議，則容許客戶端使用哪些附加通訊協議。服務器必須在101（Switching Protocols）響應中使用Upgrade頭字段來指示正在交換哪些協議。

　　 Upgrade = "Upgrade" ":" 1#product

　　例如,

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

　　Upgrade頭字段旨在提供一個簡單的機制，用於從HTTP/1.1轉換到其餘不兼容的協議。它經過容許客戶端聲明它想要使用另外一種協議來實現這一點，好比使用更高主版本號的HTTP的後期版本，即便當前的請求是使用HTTP/1.1發出的。這經過容許客戶端在更廣泛支持的協議中發起請求，同時向服務器指示若是可用，它但願使用「更好」的協議（「更好」由服務器決定，可能根據所請求的方法和/或資源的性質不一樣而不一樣。），從而減輕了不兼容協議之間轉換困難的問題。

　　Upgrade頭字段僅適用於現有傳輸層鏈接上的交換應用層協議。Upgrade不能用於堅持更改協議；服務器的接受和使用是可選的。協議改變後的應用層通訊的能力和性質徹底取決於所選擇的新協議，儘管改變協議以後的第一動做必須是對包含Upgrade頭字段的初始HTTP請求的響應。

　　Upgrade頭字段僅適用於當即鏈接。所以，每當在HTTP/1.1消息中存在Upgrade時，必須在Connection頭字段（部分14.10）中提供upgrade關鍵字。

　　Upgrade頭字段不能用於指示在不一樣鏈接上切換協議。爲此，使用301, 302, 303或305等重定向響應更合適。

　　本規範只定義了供超文本傳輸協議族使用的協議名稱「HTTP」，如3.1節的HTTP版本規則和本規範的將來更新所定義。任何令牌均可以用做協議名稱；可是，只有當客戶端和服務器都把該名稱與相同的協議關聯時纔有用。

14.43 User-Agent

　　User-Agent請求頭字段包含關於發起請求的用戶代理的信息。這是爲了統計請求的意圖、跟蹤違反協議的狀況以及自動識別用戶代理，以便調整響應以免特定的用戶代理限制。用戶代理應該將此字段包含在請求中。字段能夠包含多個產品標記(第3.8節)和標識代理和構成用戶代理重要部分的任何子產品的註釋。按照慣例，產品令牌是按照它們對識別應用程序的重要性列出的。

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

　　例子:

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

14.44 Vary

　　Vary字段值表示請求頭字段集，該字段集在響應是「新鮮」的狀況下徹底肯定是否容許緩存使用響應來響應後續請求，而無需從新驗證。對於沒法緩存或過期的響應，Vary字段值向用戶代理提供用於選擇表示的標準。值「*」表示緩存沒法從後續請求的請求頭中肯定此響應是否合適。請參閱第 13.6節，瞭解緩存對Vary頭字段的使用。

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

　　HTTP/1.1服務器應該包含一個Vary頭字段，其中包含任何可緩存的響應，該響應受服務器驅動協商的影響。這樣作容許緩存正確地解釋對該資源的將來請求，並告知用戶代理該資源上是否存在協商。服務器可能包含一個Vary標頭字段，其中不可緩存的響應受服務器驅動協商的影響，由於這可能爲用戶代理提供關於「響應」在響應時變化的維度的有用信息。

　　一個Vary字段值，由一組字段名稱信號組成，所選的響應表示是基於選擇算法的，該算法在選擇最合適的表示時只考慮列出的請求頭字段。緩存可能假設在響應新鮮的時間段內，對於未來具備相同值的請求，將進行相同的選擇。

　　給出的字段名不限於此規範定義的標準請求頭字段集。且字段名不區分大小寫。

　　若是Vary的字段值是「*」，則代表未指定的參數不限於請求頭(例如，客戶端的網絡地址)，在響應表示的選擇中起做用。「*」值不能由代理服務器生成;它可能僅由原始服務器生成。

14.45 Via

　　Via通用頭字段必須被網關和代理使用，以用來在請求中指示用戶代理和服務器之間的中間協議和接收者，在響應上指示源服務器和客戶端之間的中間協議和接收者。它相似於RFC 822[9]的「Received」字段，用於跟蹤消息轉發，避免請求循環，以及識別請求/響應鏈上全部發送者的協議功能。

　　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

　　接收協議指示服務器或客戶端沿着請求/響應鏈的每一個環節所接收的消息相關的協議版本。當消息被轉發時，接收的協議版本被附加到Via字段的值上，以便關於上游應用程序的協議能力的信息對全部接收者保持可見。

　　協議名稱是可選的，當且僅當它是「HTTP」時。接收方字段一般是隨後轉發消息的接收方服務器或客戶端的主機和可選端口號。然而，若是真實主機被認爲是敏感信息，它能夠被化名取代。若是沒有給出端口，則能夠假定它是接收到的協議的默認端口。

　　多個Via字段值表示轉發消息的每一個代理或網關。每一個接收方必須附加其信息，以便根據轉發應用程序的序列對最終結果進行排序。

　　註釋能夠在Via頭字段中使用，以標識接收方代理或網關的軟件，相似於User-Agent和Server標頭字段。可是，在傳遞字段中的全部註釋都是可選的，而且能夠在轉發消息以前由任何接收者刪除。

　　例如，能夠將請求消息從HTTP/1.0用戶代理髮送到名爲「fred」的內部代理，該代理使用HTTP/1.1將請求轉發到nowhere.com的公共代理，該公共代理經過將請求轉發到位於www.ics.uci.edu的源服務器來完成請求。由www.ics.uci.edu接收的請求將具備如下的Via頭字段：

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

　　默認狀況下，代理和網關做爲經過網絡防火牆的門戶不該該轉發防火牆區域內的主機的名稱和端口。只有顯式啓用該信息才能傳播。若是沒有啓用，防火牆後面的任何主機的主機所接收的主機都應該用適當的化名替換。

　　對於對隱藏內部結構具備很強隱私要求的組織，代理能夠將具備相同接收協議值的Via頭字段條目的有序子序列組合到一個這樣的條目中。例如，

　　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頭字段經過如下方式發送:

　　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

　　 ; 服務器添加的名稱或別名

　　 ; Warning頭字段，用於調試

　　warn-text = quoted-string

　　warn-date = <"> HTTP-date <">

　　響應可能包含多個Warning頭字段。

　　警告文本應該使用天然語言和字符集，對於接收響應的人類用戶來講，這些語言和字符集最容易理解。此決策能夠基於任何可用的知識，例如緩存或用戶的位置、請求中的Accept-Language字段、響應中的Content-Language字段等。默認語言爲英語，默認字符集爲ISO-8859-1。

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

　　Warning頭一般能夠應用於任何消息，可是一些特定的警告代碼對於緩存來講是特殊的，而且只能應用於響應消息。在任何現有的Warning標頭以後都應該添加新的警告標題。緩存不能刪除它收到的任何消息頭。可是，若是緩存成功驗證緩存條目，則應刪除之前附加到該條目的任何Warning標頭，除非爲特定Warning代碼指定。而後，必須在驗證響應中添加任何Warning標頭。換句話說，Warning標頭是那些附加到最近的相關響應的標題。

　　當多個Warning頭附加到響應時，用戶代理應該儘量多地通知用戶，以使它們出如今響應中。若是沒法將全部警告通知用戶，用戶代理應遵循如下啓發式方法:

　　 - 出如今響應中較早的警告優先於出如今響應中較晚的警告。

　　- 用戶首選字符集中的警告優先於其餘字符集中的警告，可是警告代碼和警告代理是相同的。

　　生成多個Warning標頭的系統應該根據用戶代理行爲對其進行排序。

　　有關警告的緩存行爲的需求在第13.1.2節中說明。

　　這是當前定義的警告代碼的列表，每一個警告代碼都帶有英文推薦的警告文本，並描述了其含義。

　　　　110 - 當響應過時時，則必須被包含。

　　　　111 - 若是因爲沒法鏈接到服務器而引發的重校驗失敗致使了緩存返回了一個陳舊的響應，則「從新校驗失敗」必須被包含。

　　　　112 - 若是緩存有意從網絡的其他部分斷開一段時間，則應該包含「斷開鏈接操做」。

　　　　113 - 若是緩存從啓發意義上選擇的新鮮度範圍大於24小時，響應的範圍大於24小時。則「探索性過時」必須被包含。

　　　　199 - 雜項警告，警告文本能夠包括要呈現給人類用戶或登陸的任意信息。接受此警告的系統除了向用戶發出警告外，不得采起任何自動化行動。

　　　　214 - 應用轉換必須由中間緩存或代理添加，若是它應用任何轉換來更改響應的內容編碼（如Content-Encoding標頭中指定的）或媒體類型（如Content-Type標頭中指定的）或響應的實體主體，除非該Warning字段已經出如今響應中。