RFC 2616 Fielding, et al.

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。

　　請注意：使用“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-MD5、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 

相關推薦