メインコンテンツまでスキップ

14. ヘッダフィールドの定義

この節では、すべての標準 HTTP/1.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 ) ]

アスタリスク "" という文字は、メディアタイプを範囲にまとめるために使用される。"/" はすべてのメディアタイプを示し、"type/" はそのタイプのすべてのサブタイプを示す。media-range には、その範囲に適用可能なメディアタイプパラメータを含める MAY（してもよい）。

各 media-range の後に、1 つ以上の accept-params が続くことがあり、その最初は相対的な品質係数を示す "q" パラメータである。最初の "q" パラメータ（存在する場合）は、media-range のパラメータと accept-params を分離する。品質係数により、ユーザまたはユーザエージェントは、qvalue スケール（0 から 1、3.9 節）を用いて、その media-range に対する相対的な優先度を示すことができる。デフォルト値は q=1 である。

  Note: メディアタイプパラメータを Accept 拡張パラメータから分離するための "q" パラメータ名の使用は、過去の慣行によるものである。これにより、media-range と共に "q" という名前のメディアタイプパラメータを使用することが防止されるが、IANA メディアタイプレジストリに "q" パラメータが存在しないこと、および Accept でのメディアタイプパラメータの使用がまれであることを考えると、そのような事象は起こりそうにないと考えられる。将来のメディアタイプが "q" という名前のパラメータを登録することは推奨されない。

次の例

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

は、「audio/basic を好むが、品質を 80% 割り引いたうえで最も入手しやすい音声タイプであれば、いかなる音声タイプでも送ってよい」と解釈されるべき (SHOULD) である。

Accept ヘッダフィールドが存在しない場合、クライアントはすべてのメディアタイプを受け入れるとみなされる。Accept ヘッダフィールドが存在し、かつサーバが結合された Accept フィールド値に従って受け入れ可能なレスポンスを送信できない場合、サーバは 406（not acceptable）レスポンスを送信すべき (SHOULD) である。

より詳しい例は次のとおりである。

   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 エンティティを送る」と解釈される。

メディア範囲は、より詳細なメディア範囲や特定のメディアタイプによって上書きされることがある。1 つの型に複数のメディア範囲が適用される場合、最も詳細な参照が優先される。たとえば、

   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

  Note: ユーザエージェントには、特定のメディア範囲に対する一連のデフォルトの品質値が与えられているかもしれない。しかし、他のレンダリングエージェントとやりとりできない閉じたシステムでない限り、このデフォルトセットはユーザによって設定可能であるべき (ought to) である。

14.2 Accept-Charset​

Accept-Charset リクエストヘッダフィールドは、レスポンスとして受け入れ可能な文字セットを示すために使用できる。このフィールドにより、より包括的または特殊用途の文字セットを理解できるクライアントは、それらの文字セットで文書を表現できるサーバに対してその能力を通知できる。

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

文字セット値は 3.4 節で説明されている。各 charset には、その charset に対するユーザの優先度を表す関連する品質値が与えられる MAY（してもよい）。デフォルト値は q=1 である。例は次のとおりである。

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

Accept-Charset フィールドに存在する特殊値 "" は、Accept-Charset フィールドの他の場所で言及されていないすべての文字セット（ISO-8859-1 を含む）に一致する。Accept-Charset フィールドに "" が存在しない場合、明示的に言及されていないすべての文字セットは品質値 0 を得るが、ISO-8859-1 だけは、明示的に言及されない場合に品質値 1 を得る。

Accept-Charset ヘッダが存在しない場合、デフォルトではいかなる文字セットも受け入れ可能である。Accept-Charset ヘッダが存在し、かつサーバが Accept-Charset ヘッダに従って受け入れ可能なレスポンスを送信できない場合、サーバは 406（not acceptable）ステータスコードでエラーレスポンスを送信すべき (SHOULD) であるが、受け入れ不可能なレスポンスを送信することも許されている。

14.3 Accept-Encoding​

Accept-Encoding リクエストヘッダフィールドは Accept と類似しているが、レスポンスにおいて受け入れ可能な content-coding（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 フィールドに列挙された content-coding の 1 つである場合、それは、qvalue 0 を伴っていない限り受け入れ可能である。（3.9 節で定義されているように、qvalue 0 は「受け入れ不可能」を意味する。）

  2. Accept-Encoding フィールドの特殊記号 "*" は、ヘッダフィールドに明示的に列挙されていない利用可能な content-coding のいずれにも一致する。

  3. 複数の content-coding が受け入れ可能な場合、0 でない qvalue の中で最も高い qvalue を持つ受け入れ可能な content-coding が優先される。

  4. "identity" content-coding は、Accept-Encoding フィールドに "identity;q=0" が含まれている場合、またはフィールドに "*;q=0" が含まれていて "identity" content-coding が明示的に含まれていない場合を除き、常に受け入れ可能である。Accept-Encoding フィールド値が空の場合、受け入れ可能なのは "identity" エンコーディングのみである。

リクエストに Accept-Encoding フィールドが存在し、かつサーバが Accept-Encoding ヘッダに従って受け入れ可能なレスポンスを送信できない場合、サーバは 406（Not Acceptable）ステータスコードでエラーレスポンスを送信すべき (SHOULD) である。

リクエストに Accept-Encoding フィールドが存在しない場合、サーバはクライアントがいかなる content-coding も受け入れるとみなしてもよい (MAY)。この場合、"identity" が利用可能な content-coding の 1 つであるならば、サーバは "identity" content-coding を使用すべき (SHOULD) である。ただし、異なる content-coding がクライアントにとって意味があることを示す追加情報がある場合を除く。

  Note: リクエストに Accept-Encoding フィールドが含まれておらず、"identity" content-coding が利用できない場合、HTTP/1.0 クライアントに一般的に理解されている content-coding（すなわち "gzip" および "compress"）が優先される。一部の古いクライアントは、他の content-coding で送信されたメッセージを不正に表示する。サーバは、特定のユーザエージェントやクライアントに関する情報に基づいてこの決定を行うこともある。

  Note: ほとんどの HTTP/1.0 アプリケーションは、content-coding に関連付けられた qvalue を認識せず、従わない。これは、qvalue が機能せず、x-gzip や x-compress では qvalue が許可されないことを意味する。

14.4 Accept-Language​

Accept-Language リクエストヘッダフィールドは Accept と類似しているが、リクエストに対するレスポンスとして優先される自然言語の集合を制限する。言語タグは 3.10 節で定義されている。

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

各 language-range には、その範囲で指定された言語に対するユーザの優先度の推定量を表す関連する品質値が与えられる MAY（してもよい）。品質値のデフォルトは "q=1" である。たとえば、

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

は、「デンマーク語を好むが、イギリス英語およびその他の種類の英語も受け入れる」ことを意味する。language-range は、タグと完全に等しい場合、またはタグの接頭辞と完全に等しく、その接頭辞に続く最初のタグ文字が "-" である場合に、language-tag に一致する。Accept-Language フィールドに存在する特殊な範囲 "*" は、そのフィールドに存在する他のいかなる範囲にも一致しないタグのすべてに一致する。

  Note: この接頭辞一致規則の使用は、タグが接頭辞である言語に対して、あるユーザがその言語を理解していれば、そのタグが接頭辞であるすべての言語も理解するということが常に成り立つことを意味するものではない。接頭辞規則は、そのような場合に接頭辞タグを使用できるようにする単なる規則である。

Accept-Language フィールドによって language-tag に割り当てられる言語品質係数は、その language-tag に一致するフィールド内の最長の language-range の品質値である。フィールド内のどの language-range もタグに一致しない場合、割り当てられる言語品質係数は 0 である。リクエストに Accept-Language ヘッダが存在しない場合、サーバはすべての言語が等しく受け入れ可能であるとみなすべき (SHOULD) である。Accept-Language ヘッダが存在する場合、品質係数が 0 より大きく割り当てられたすべての言語が受け入れ可能である。

ユーザの完全な言語的選好をすべてのリクエストで送信することは、ユーザのプライバシーの期待に反するおそれがある。この問題の議論については 15.1.4 節を参照されたい。

理解可能性は個々のユーザに大きく依存するため、クライアントアプリケーションは、言語的選好の選択をユーザに利用可能にすることが推奨される。その選択が利用可能にされない場合、リクエストに Accept-Language ヘッダフィールドを含めてはならない (MUST NOT)。

  Note: 言語的選好の選択をユーザに利用可能にする際、実装者に対し、ユーザは上記の言語一致の詳細を熟知していないという事実を思い起こさせる。たとえば、ユーザは "en-gb" を選択したとき、ブリティッシュ英語が利用できない場合はいかなる種類の英語文書も提供されると想定するかもしれない。このような場合、ユーザエージェントは、最適な一致動作を得るために "en" を追加することを提案してもよい。

14.5 Accept-Ranges​

  Accept-Ranges レスポンスヘッダフィールドにより、サーバはリソースに対する範囲リクエストの受け入れを通知できる。

      Accept-Ranges     = "Accept-Ranges" ":" acceptable-ranges
      acceptable-ranges = 1#range-unit | "none"

  バイト範囲リクエストを受け入れるオリジンサーバは、

      Accept-Ranges: bytes

  を送信してもよい (MAY) が、そうする必要はない。クライアントは、関係するリソースについてこのヘッダを受信していなくても、バイト範囲リクエストを生成してもよい (MAY)。範囲単位は 3.12 節で定義されている。

  いかなる種類の範囲リクエストも受け入れないサーバは、

      Accept-Ranges: none

  を送信して、クライアントに範囲リクエストを試みないよう助言してもよい (MAY)。

14.6 Age​

  Age レスポンスヘッダフィールドは、レスポンス（またはその再検証）がオリジンサーバで生成されてからの経過時間の、送信者の推定量を伝える。キャッシュされたレスポンスは、その年齢が新鲜度寿命を超えない場合に「新鲜 (fresh)」である。年齢値は 13.2.3 節の指定に従って計算される。

       Age = "Age" ":" age-value
       age-value = delta-seconds

  年齢値は、秒単位の時間を表す非負の十進整数である。

  キャッシュが、自身が表現可能な最大の正の整数より大きな値を受信した場合、またはその年齢計算のいずれかがオーバーフローした場合、年齢ヘッダを値 2147483648 (2^31) で送信しなければならない (MUST)。自身のキャッシュから生成されたすべてのレスポンスに Age ヘッダフィールドを含めなければならない (MUST) ようなキャッシュを含む HTTP/1.1 サーバは、少なくとも 31 ビットの範囲を持つ算術型を使用すべき (SHOULD) である。

14.7 Allow​

  Allow エンティティヘッダフィールドは、Request-URI で識別されるリソースによってサポートされるメソッドの集合を列挙する。このフィールドの目的は、厳密に、リソースに関連付けられた有効なメソッドを受信者に通知することである。Allow ヘッダフィールドは、405（Method Not Allowed）レスポンスに存在していなければならない (MUST)。

      Allow   = "Allow" ":" #Method

  使用例：

      Allow: GET, HEAD, PUT

  このフィールドは、クライアントが他のメソッドを試すことを妨げるものではない。しかし、Allow ヘッダフィールド値によって与えられる指示には従うべき (SHOULD) である。許可されるメソッドの実際の集合は、各リクエストの時点でオリジンサーバによって定義される。

  Allow ヘッダフィールドは、新規または修正されたリソースによってサポートされるべきメソッドを推奨するために、PUT リクエストとともに提供してもよい (MAY)。サーバはこれらのメソッドをサポートする必要はなく、実際にサポートされるメソッドを与える Allow ヘッダをレスポンスに含めるべき (SHOULD) である。

  プロキシは、指定されたすべてのメソッドを理解していなくても、Allow ヘッダフィールドを変更してはならない (MUST NOT)。なぜなら、ユーザエージェントはオリジンサーバと通信する他の手段を持っているかもしれないからである。

14.8 Authorization​

  サーバに対して自身を認証しようとするユーザエージェントは――通常は、必ずしもそうとは限らないが、401 レスポンスを受信した後――リクエストに Authorization リクエストヘッダフィールドを含めることによってそうする。Authorization フィールド値は、要求されているリソースのレルム (realm) に対するユーザエージェントの認証情報を含む資格情報 (credentials) から成る。

14.9 Cache-Control​

Cache-Control ジェネラルヘッダフィールドは、リクエスト/レスポンスチェーンの沿線にあるすべてのキャッシュ機構が従わなければならない (MUST) 指令を指定するために使用される。これらの指令は、キャッシュがリクエストやレスポンスに悪影響を及ぼすことを防ぐことを意図した振る舞いを指定する。これらの指令は、典型的にはデフォルトのキャッシュアルゴリズムを上書きする。キャッシュ指令は一方向であり、リクエストに指令が存在することは、レスポンスに同じ指令が与えられるべきであることを意味するものではない。

  Note: HTTP/1.0 キャッシュは Cache-Control を実装せず、Pragma: no-cache のみを実装するかもしれないことに注意されたい（14.32 節参照）。

プロキシやゲートウェイアプリケーションは、そのアプリケーションに対する重要性にかかわらず、Cache-Control 指令を通過させなければならない (MUST)。なぜなら、これらの指令はリクエスト/レスポンスチェーン沿線のすべての受信者に適用される可能性があるからである。特定のキャッシュに対する cache-directive を指定することは不可能である。

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 ) ]

1#field-name パラメータを伴わずに指令が現れた場合、その指令はリクエストまたはレスポンス全体に適用される。そのような指令が 1#field-name パラメータを伴って現れた場合、それは指定されたフィールドのみに適用され、リクエストやレスポンスの残りには適用されない。この仕組みは拡張性を支援する。将来のバージョンの HTTP プロトコルの実装は、これらの指令を HTTP/1.1 で定義されていないヘッダフィールドに適用するかもしれない。

cache-control 指令は、これらの一般的なカテゴリに分類できる。

  - キャッシュ可能なものに対する制限。これらはオリジンサーバのみが課すことができる。
  - キャッシュに格納されてよいものに対する制限。これらはオリジンサーバまたはユーザエージェントのいずれかが課すことができる。
  - 基本的な有効期限メカニズムの変更。これらはオリジンサーバまたはユーザエージェントのいずれかが課すことができる。
  - キャッシュの再検証と再ロードに対する制御。これらはユーザエージェントのみが課すことができる。
  - エンティティの変換に対する制御。
  - キャッシュシステムに対する拡張。

14.9.1 何がキャッシュ可能か​

デフォルトでは、リクエストメソッド、リクエストヘッダフィールド、およびレスポンスステータスの要件がキャッシュ可能であることを示している場合、レスポンスはキャッシュ可能である。13.4 節はキャッシュ可能性に関するこれらのデフォルトを要約している。次の Cache-Control レスポンス指令により、オリジンサーバはレスポンスのデフォルトのキャッシュ可能性を上書きできる。

public レスポンスが非共有キャッシュ内でのみキャッシュ可能である場合や、通常はキャッシュ不可である場合であっても、いかなるキャッシュによってもキャッシュされてよい (MAY) ことを示す。

private レスポンスメッセージの全部または一部が単一のユーザを対象としており、共有キャッシュによってキャッシュされてはならない (MUST NOT) ことを示す。これにより、オリジンサーバは、レスポンスの指定された部分が 1 人のユーザのみを対象としており、他のユーザによるリクエストに対する有効なレスポンスではないことを宣言できる。private（非共有）キャッシュはレスポンスをキャッシュしてよい (MAY)。

   Note: この private という語の用法は、レスポンスがどこにキャッシュされるかを制御するだけであり、メッセージ内容のプライバシーを保証するものではない。

no-cache no-cache 指令が field-name を指定しない場合、キャッシュは、オリジンサーバとの再検証に成功しない限り、後続のリクエストを満たすためにレスポンスを使用してはならない (MUST NOT)。これにより、クライアントリクエストに対して古いレスポンスを返すように設定されたキャッシュであっても、オリジンサーバはキャッシュを防止できる。

  no-cache 指令が 1 つ以上の field-name を指定する場合、キャッシュは、キャッシュに対する他の制限に従って、後続のリクエストを満たすためにレスポンスを使用してよい (MAY)。しかし、指定された field-name は、オリジンサーバとの再検証に成功しない限り、後続のリクエストに対するレスポンス内に送信されてはならない (MUST NOT)。これにより、オリジンサーバは、レスポンスの残りのキャッシュを許可しつつ、レスポンス内の特定のヘッダフィールドの再利用を防ぐことができる。

   Note: ほとんどの HTTP/1.0 キャッシュは、この指令を認識せず、従わない。

14.9.2 キャッシュに格納されてよいもの​

no-store no-store 指令の目的は、機密情報の不測の放出や保持（たとえばバックアップテープ上でのもの）を防ぐことである。no-store 指令はメッセージ全体に適用され、レスポンスまたはリクエストのいずれかで送信されてよい (MAY)。リクエストで送信された場合、キャッシュはこのリクエストまたはそれに対するレスポンスのいずれの部分も格納してはならない (MUST NOT)。レスポンスで送信された場合、キャッシュはこのレスポンスまたはそれを引き起こしたリクエストのいずれの部分も格納してはならない (MUST NOT)。この指令は非共有キャッシュと共有キャッシュの両方に適用される。この文脈での「格納してはならない (MUST NOT store)」とは、キャッシュが情報を不揮発性ストレージに意図的に格納してはならず、かつそれを転送した直後に揮発性ストレージから可能な限り速やかに削除するよう最善の努力を払わなければならない (MUST) ことを意味する。

  この指令がレスポンスに関連付けられている場合でも、ユーザはキャッシュシステムの外部にそのようなレスポンスを明示的に格納するかもしれない（たとえば「名前を付けて保存」ダイアログを用いて）。履歴バッファは、通常の動作の一部としてそのようなレスポンスを格納してよい (MAY)。

  この指令の目的は、キャッシュデータ構造への予期せぬアクセスを通じた情報の不測の放出を懸念する特定のユーザおよびサービス作成者の明記された要件を満たすことである。この指令の使用は場合によってはプライバシーを改善するかもしれないが、プライバシーを確保するための信頼できる、あるいは十分なメカニズムでは決してないことに注意を促す。とくに、悪意のある、または危険にさらされたキャッシュはこの指令を認識せず、従わないかもしれず、通信ネットワークは盗聴に対して脆弱であるかもしれない。

14.9.3 基本的な有効期限メカニズムの変更​

エンティティの有効期限は、オリジンサーバが Expires ヘッダ（14.21 節参照）を用いて指定してもよい (MAY)。あるいは、レスポンス内の max-age 指令を用いて指定してもよい (MAY)。キャッシュされたレスポンスに max-age cache-control 指令が存在する場合、そのリソースに対する新しいリクエストの時点で、現在の年齢が（秒単位で）与えられた年齢値より大きいなら、レスポンスは古い (stale) である。

レスポンスに Expires ヘッダと max-age 指令の両方が含まれる場合、たとえ Expires ヘッダがより厳格であっても、max-age 指令が Expires ヘッダを上書きする。この規則により、オリジンサーバは、あるレスポンスに対して、HTTP/1.0 キャッシュよりも長い有効期限を HTTP/1.1（以降）キャッシュに与えることができる。これは、一部の HTTP/1.0 キャッシュが、おそらくクロックの同期ずれのために、年齢や有効期限を不正に計算する場合に有用かもしれない。

多くの HTTP/1.0 キャッシュ実装は、レスポンスの Date 値以下の Expires 値を、Cache-Control レスポンス指令 "no-cache" と同等とみなす。HTTP/1.1 キャッシュがそのようなレスポンスを受信し、そのレスポンスに Cache-Control ヘッダフィールドが含まれていない場合、HTTP/1.0 サーバとの互換性を維持するために、そのレスポンスを非キャッシュ可能とみなすべき (SHOULD) である。

   Note: オリジンサーバは、その機能を理解しない古いキャッシュを含むネットワーク上で、"private" 指令のような比較的新しい HTTP キャッシュ制御機能を使用したいと思うかもしれない。オリジンサーバは、新しい機能を、値が Date 値以下である Expires フィールドと組み合わせる必要がある。これにより、古いキャッシュがレスポンスを不正にキャッシュするのを防ぐことができる。

s-maxage レスポンスに s-maxage 指令が含まれる場合、共有キャッシュ（ただし非私用キャッシュではない）に対しては、この指令で指定された最大年齢が、max-age 指令または Expires ヘッダのいずれで指定された最大年齢を上書きする。s-maxage 指令はまた、proxy-revalidate 指令（14.9.4 節参照）の意味論、すなわち共有キャッシュは、それが古くなった後に、まずオリジンサーバで再検証せずに、後続のリクエストに応答するためにそのエントリを使用してはならないことを含意する。s-maxage 指令は常に非私用キャッシュによって無視される。

この仕様に準拠しないほとんどの古いキャッシュは、いかなる cache-control 指令も実装しないことに注意されたい。HTTP/1.0 準拠でないキャッシュは max-age 指令を観察しないという事実、および max-age 指令が Expires ヘッダを上書きするという要件を利用して、HTTP/1.1 準拠キャッシュによるキャッシュを制限するが防止はしない cache-control 指令を使用したいオリジンサーバは、その要件を利用してよい (MAY)。

他の指令により、ユーザエージェントは基本的な有効期限メカニズムを変更できる。これらの指令はリクエスト上で指定されてよい (MAY)。

max-age クライアントが、指定された秒数以下の年齢のレスポンスを受け入れる意志があることを示す。max-stale 指令も含まれていない限り、クライアントは古いレスポンスを受け入れる意志がない。

min-fresh クライアントが、その新鲜度寿命が、現在の年齢に指定された秒数を加えたもの以上であるレスポンスを受け入れる意志があることを示す。すなわち、クライアントは、少なくとも指定された秒数の間は新鲜であり続けるレスポンスを望んでいる。

max-stale クライアントが、有効期限を超過したレスポンスを受け入れる意志があることを示す。max-stale に値が割り当てられた場合、クライアントは、指定された秒数を超えて有効期限を超過したレスポンスを受け入れる意志がある。max-stale に値が割り当てられない場合、クライアントはいかなる年齢の古いレスポンスでも受け入れる意志がある。

キャッシュが、リクエストの max-stale 指令のため、あるいはキャッシュがレスポンスの有効期限を上書きするように設定されているために、古いレスポンスを返す場合、キャッシュは古いレスポンスに、Warning 110（Response is stale）を用いて Warning ヘッダを付加しなければならない (MUST)。

キャッシュは検証なしに古いレスポンスを返すように設定されてよい (MAY) が、キャッシュ検証に関する "MUST" レベルの要件（たとえば "must-revalidate" cache-control 指令）と矛盾しない場合に限る。

新しいリクエストとキャッシュされたエントリの両方に "max-age" 指令が含まれる場合、そのリクエストに対するキャッシュされたエントリの新鲜度の決定には、2 つの値のうち小さい方が使用される。

14.9.4 キャッシュの再検証と再ロードの制御​

ユーザエージェントが、キャッシュにそのキャッシュエントリをオリジンサーバで再検証させる（オリジンサーバへ至る経路上の次のキャッシュだけでなく）こと、あるいはオリジンサーバからキャッシュエントリを再ロードさせることを主張または必要とする場合がある。キャッシュまたはオリジンサーバがキャッシュされたレスポンスの有効期限を過大評価した場合、エンドツーエンドの再検証が必要になるかもしれない。キャッシュエントリが何らかの理由で破損した場合、エンドツーエンドの再ロードが必要になるかもしれない。

エンドツーエンドの再検証は、クライアントが自身のローカルキャッシュコピーを持たない場合（この場合「未指定のエンドツーエンド再検証」と呼ぶ）と、クライアントがローカルキャッシュコピーを持つ場合（この場合「特定のエンドツーエンド再検証」と呼ぶ）のいずれかで要求できる。

クライアントは、これら 3 種類の動作を Cache-Control リクエスト指令を用いて指定できる。

End-to-end reload（エンドツーエンド再ロード） リクエストには "no-cache" cache-control 指令、または HTTP/1.0 クライアントとの互換性のための "Pragma: no-cache" が含まれる。field-name を no-cache 指令と共にリクエストに含めてはならない (MUST NOT)。サーバは、そのようなリクエストに応答する際、キャッシュされたコピーを使用してはならない (MUST NOT)。

Specific end-to-end revalidation（特定のエンドツーエンド再検証） リクエストには "max-age=0" cache-control 指令が含まれ、オリジンサーバへ至る経路上の各キャッシュに、自身のエントリがあれば次のキャッシュまたはサーバで再検証させる。最初のリクエストには、クライアントの現在のバリデータを用いたキャッシュ検証条件が含まれる。

Unspecified end-to-end revalidation（未指定のエンドツーエンド再検証） リクエストには "max-age=0" cache-control 指令が含まれ、オリジンサーバへ至る経路上の各キャッシュに、自身のエントリがあれば次のキャッシュまたはサーバで再検証させる。最初のリクエストにはキャッシュ検証条件は含まれない。このリソースに対するキャッシュエントリを持つ経路上の最初のキャッシュ（もしあれば）は、その現在のバリデータを用いたキャッシュ検証条件を含める。

max-age 中間キャッシュが max-age=0 指令によって自身のキャッシュエントリの再検証を強いられ、かつクライアントがリクエスト内に自身のバリデータを提供した場合、提供されたバリデータはキャッシュエントリに現在格納されているバリデータと異なるかもしれない。この場合、キャッシュは、意味的透明性に影響を与えずに、自身のリクエストを行う際にいずれのバリデータでも使用してよい (MAY)。

  しかし、バリデータの選択は性能に影響するかもしれない。最良のアプローチは、中間キャッシュが自身のリクエストを行う際に自身のバリデータを使用することである。サーバが 304（Not Modified）で応答した場合、キャッシュは現在検証済みのコピーを 200（OK）レスポンスでクライアントに返せる。しかし、サーバが新しいエンティティとキャッシュバリデータで応答した場合、中間キャッシュは、強比較関数を用いて、返されたバリデータをクライアントのリクエスト内で提供されたバリデータと比較できる。クライアントのバリデータがオリジンサーバのものと等しい場合、中間キャッシュは単に 304（Not Modified）を返す。そうでない場合、新しいエンティティを 200（OK）レスポンスで返す。

  リクエストに no-cache 指令が含まれる場合、min-fresh、max-stale、または max-age を含めてはならない (SHOULD NOT)。

only-if-cached ネットワーク接続が極めて不安定な場合などのように、クライアントが、現在格納しているレスポンスのみをキャッシュに返させ、オリジンサーバで再ロードや再検証をさせたくないことがある。これを行うために、クライアントはリクエストに only-if-cached 指令を含めてよい (MAY)。この指令を受信した場合、キャッシュは、リクエストの他の制約に一致するキャッシュエントリを用いて応答するか、504（Gateway Timeout）ステータスで応答すべき (SHOULD) である。しかし、キャッシュのグループが、良好な内部接続を持つ統合システムとして運用されている場合、そのようなリクエストはそのキャッシュグループ内に転送されてよい (MAY)。

must-revalidate キャッシュはサーバが指定した有効期限を無視するように設定されてよく (MAY)、またクライアントリクエストには max-stale 指令（同様の効果を持つ）が含まれてよい (MAY) ため、プロトコルには、オリジンサーバが、以降のいかなる使用に対してもキャッシュエントリの再検証を要求する仕組みも含まれている。must-revalidate 指令がキャッシュが受信したレスポンス内に存在する場合、そのキャッシュは、それが古くなった後に、まずオリジンサーバで再検証せずに、後続のリクエストに応答するためにそのエントリを使用してはならない (MUST NOT)。

  must-revalidate 指令は、特定のプロトコル機能の信頼できる動作を支援するために必要である。あらゆる状況において、HTTP/1.1 キャッシュは must-revalidate 指令に従わなければならない (MUST)。とくに、キャッシュが何らかの理由でオリジンサーバに到達できない場合、504（Gateway Timeout）レスポンスを生成しなければならない (MUST)。

  サーバは、エンティティに対するリクエストの再検証の失敗が、たとえば暗黙のうちに実行されなかった金融取引のような、不正な動作をもたらす可能性がある場合に限り、must-revalidate 指令を送信すべき (SHOULD) である。受信者は、この指令に違反するいかなる自動的な動作も行ってはならず (MUST NOT)、再検証が失敗した場合にエンティティの未検証のコピーを自動的に提供してはならない (MUST NOT)。

  これは推奨されないが、厳しい接続制約の下で動作するユーザエージェントはこの指令に違反してよい (MAY) が、その場合、未検証のレスポンスが提供されたことをユーザに明示的に警告しなければならない (MUST)。その警告は各未検証アクセス時に提供されなければならず (MUST)、明示的なユーザの確認を要求すべき (SHOULD) である。

proxy-revalidate proxy-revalidate 指令は must-revalidate 指令と同じ意味を持つが、非共有ユーザエージェントキャッシュには適用されない点が異なる。これは、認証されたリクエストに対するレスポンスで使用でき、ユーザのキャッシュが（既にそのユーザによって 1 回認証されているため）再検証せずにレスポンスを格納し、後に返すことを許可しつつ、多くのユーザにサービスするプロキシには毎回再検証を要求する（各ユーザが認証されていることを確認するため）。そのような認証されたレスポンスは、そもそもキャッシュされることを許可するために、public cache-control 指令も必要とすることに注意されたい。

14.9.5 No-Transform 指令​

no-transform 中間キャッシュ（プロキシ）の実装者は、特定のエンティティボディのメディアタイプを変換することが有用であると気付いた。たとえば、非透明プロキシは、キャッシュ容量を節約したり、低速リンク上のトラフィック量を減らすために、画像フォーマット間で変換するかもしれない。

  しかし、これらの変換が、特定の種類のアプリケーションを対象とするエンティティボディに適用されると、重大な運用上の問題が発生する。たとえば、医療画像、科学データ解析、およびエンドツーエンド認証を使用するアプリケーションはすべて、元のエンティティボディとビット単位で同一のエンティティボディを受信することに依存している。

  したがって、メッセージに no-transform 指令が含まれる場合、中間キャッシュまたはプロキシは、no-transform 指令の対象となると 13.5.2 節に列挙されているヘッダを変更してはならない (MUST NOT)。これは、キャッシュまたはプロキシが、これらのヘッダによって指定されるエンティティボディのいかなる側面、エンティティボディ自体の値を含め、変更してはならない (MUST NOT) ことを含意する。

14.9.6 キャッシュ制御の拡張​

Cache-Control ヘッダフィールドは、1 つ以上の cache-extension トークンを使用して拡張できる。各トークンにはオプションの割り当て値がある。情報的な拡張（キャッシュの振る舞いの変更を必要としないもの）は、他の指令の意味論を変更せずに追加してよい (MAY)。振る舞いの拡張は、既存のキャッシュ指令の基底を修正する修飾子として機能するように設計されている。新しい指令と標準指令の両方が提供されるため、新しい指令を理解しないアプリケーションは標準指令で指定された振る舞いにデフォルトし、新しい指令を理解するアプリケーションはそれが標準指令に関連付けられた要件を修正するものとして認識する。このようにして、キャッシュ制御指令の拡張は、基底プロトコルの変更を必要とせずに行える。

この拡張メカニズムは、そのネイティブな HTTP バージョンに対して定義されたすべての cache-control 指令に従い、特定の拡張に従い、理解できないすべての指令を無視する HTTP キャッシュに依存している。

たとえば、private 指令の修飾子として機能する community と呼ばれる仮想的な新しいレスポンス指令を考える。この新しい指令を、非共有キャッシュに加えて、その値内に名前を付けられたコミュニティのメンバーのみで共有されるいかなるキャッシュもレスポンスをキャッシュしてよいという意味に定義する。UCI コミュニティが共有キャッシュで他方は private なレスポンスを使用することを許可したいオリジンサーバは、次を含めることでそうできる。

   Cache-Control: private, community="UCI"

このヘッダフィールドを見るキャッシュは、community cache-extension を理解しなくても正しく動作する。なぜなら、private 指令も見て理解するため、安全な振る舞いにデフォルトするからである。

認識されない cache-directive は無視されなければならない (MUST)。HTTP/1.1 キャッシュによって認識されない可能性が高い cache-directive は、キャッシュが拡張を理解しなくてもキャッシュの振る舞いが最小限正しく残るように、標準指令（またはレスポンスのデフォルトのキャッシュ可能性）と組み合わされると想定されている。

14.10 Connection​

Connection ジェネラルヘッダフィールドにより、送信者はその特定の接続に対して望まれるオプションを指定でき、それらはプロキシによってそれ以降の接続経由で通信されてはならない (MUST NOT)。

Connection ヘッダの文法は次のとおりである。

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

HTTP/1.1 プロキシは、メッセージを転送する前に Connection ヘッダフィールドを解析しなければならず (MUST)、このフィールド内の各 connection-token について、その connection-token と同じ名前のヘッダフィールドをメッセージから削除しなければならない (MUST)。接続オプションは、Connection ヘッダフィールド内の connection-token の存在によって通知され、対応する追加のヘッダフィールドによって通知されるのではない。なぜなら、その接続オプションに関連付けられたパラメータがない場合、追加のヘッダフィールドは送信されないかもしれないからである。

Connection ヘッダに列挙されたメッセージヘッダには、Cache-Control などのエンドツーエンドヘッダを含めてはならない (MUST NOT)。

HTTP/1.1 は、接続がレスポンスの完了後に閉じられることを送信者が通知するための "close" 接続オプションを定義する。たとえば、

   Connection: close

は、リクエストまたはレスポンスヘッダフィールドのいずれかにあって、現在のリクエスト/レスポンスが完了した後、その接続は「持続的 (persistent)」（8.1 節）とはみなされるべきでない (SHOULD NOT) ことを示す。

持続的接続をサポートしない HTTP/1.1 アプリケーションは、すべてのメッセージに "close" 接続オプションを含めなければならない (MUST)。

Connection ヘッダを含む HTTP/1.0（またはそれより低いバージョン）のメッセージを受信したシステムは、このフィールド内の各 connection-token について、その connection-token と同じ名前のヘッダフィールドをメッセージから削除し、無視しなければならない (MUST)。これは、そのようなヘッダフィールドが HTTP/1.1 より前のプロキシによって誤って転送されるのを防ぐ。19.6.2 節を参照されたい。

14.11 Content-Encoding​

Content-Encoding エンティティヘッダフィールドは、media-type に対する修飾子として使用される。存在する場合、その値はエンティティボディにどのような追加の content-coding が適用されたかを示し、したがって Content-Type ヘッダフィールドが参照する media-type を得るためにどのような復号メカニズムを適用しなければならないかを示す。Content-Encoding は、その基礎となるメディアタイプの同一性を失うことなく文書を圧縮できるようにするために主に使用される。

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

content-coding は 3.5 節で定義されている。使用例は次のとおりである。

   Content-Encoding: gzip

content-coding は、Request-URI によって識別されるエンティティの特性である。典型的には、エンティティボディはこのエンコーディングで格納され、レンダリングまたはそれに類する使用の前にのみ復号される。しかし、新しい coding が受信者にとって受け入れ可能であることが分かっている場合、非透明プロキシは、"no-transform" cache-control 指令がメッセージに存在しない限り、content-coding を変更してよい (MAY)。

エンティティの content-coding が "identity" でない場合、レスポンスは使用された非 identity content-coding を列挙する Content-Encoding エンティティヘッダ（14.11 節）を含まなければならない (MUST)。

リクエストメッセージ内のエンティティの content-coding がオリジンサーバに受け入れられない場合、サーバは 415（Unsupported Media Type）ステータスコードで応答すべき (SHOULD) である。

複数のエンコーディングがエンティティに適用された場合、content-coding はそれらが適用された順序で列挙されなければならない (MUST)。エンコーディングパラメータに関する追加情報は、この仕様で定義されていない他のエンティティヘッダフィールドによって提供されてよい (MAY)。

14.12 Content-Language​

Content-Language エンティティヘッダフィールドは、封入されたエンティティの対象聴衆の自然言語を記述する。これは、エンティティボディ内で使用されるすべての言語と等価ではないかもしれないことに注意されたい。

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

言語タグは 3.10 節で定義されている。Content-Language の主な目的は、ユーザが自身の好みの言語に従ってエンティティを識別し、区別できるようにすることである。したがって、ボディ内容がデンマーク語を読める聴衆のみを対象としている場合、適切なフィールドは次のとおりである。

   Content-Language: da

Content-Language が指定されない場合、デフォルトは、内容がすべての言語の聴衆を対象としていることである。これは、送信者がそれをいかなる自然言語にも特定のものとはみなしていないか、あるいはどの言語を対象としているかを送信者が知らないことを意味するかもしれない。

複数の言語を、複数の聴衆を対象とする内容に対して列挙してよい (MAY)。たとえば、原本のマオリ語と英語の両方で同時に提示される「ワイタンギ条約」の実演では、次が求められる。

   Content-Language: mi, en

しかし、エンティティ内に複数の言語が存在するだけで、それが複数の言語的聴衆を対象としているという意味ではない。例として、「ラテン語の第一課」のような初心者の言語入門書があり、これは明らかに英語を読める聴衆が使用することを意図している。この場合、Content-Language には適切には "en" のみが含まれる。

Content-Language はいかなるメディアタイプにも適用されてよく (MAY)、テキスト文書に限定されない。

14.13 Content-Length​

Content-Length エンティティヘッダフィールドは、受信者に送信されるエンティティボディのサイズを、OCTET の十進数で示す。HEAD メソッドの場合は、リクエストが GET であったならば送信されたはずのエンティティボディのサイズを示す。

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

例は次のとおりである。

   Content-Length: 3495

アプリケーションは、4.4 節の規則によって禁止されていない限り、メッセージボディの転送長を示すためにこのフィールドを使用すべき (SHOULD) である。

ゼロ以上の任意の Content-Length は有効な値である。Content-Length が与えられない場合にメッセージボディの長さを決定する方法は 4.4 節で説明されている。

このフィールドの意味は、MIME における対応する定義、すなわち "message/external-body" コンテンツタイプ内で使用されるオプションのフィールドであるという定義と大きく異なることに注意されたい。HTTP では、メッセージの長さを転送前に決定できる限り、4.4 節の規則によって禁止されていない限り、送信すべき (SHOULD) である。

14.14 Content-Location​

Content-Location エンティティヘッダフィールドは、エンティティがリクエストされたリソースの URI とは別の場所からアクセス可能である場合に、メッセージに封入されたエンティティのリソース位置を提供するために使用されてよい (MAY)。サーバは、レスポンスエンティティに対応するバリアントに対する Content-Location を提供すべき (SHOULD) である。とくに、リソースに関連付けられた複数のエンティティがあり、それらのエンティティが実際に個別にアクセス可能な別の場所を持つ場合、サーバは返される特定のバリアントに対する Content-Location を提供すべき (SHOULD) である。

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

Content-Location の値は、エンティティの基底 URI も定義する。

Content-Location の値は、元のリクエストされた URI の置換ではない。それは、リクエスト時点でこの特定のエンティティに対応するリソースの位置の単なる記述である。以降のリクエストは、その特定のエンティティのソースを識別したい場合、Content-Location URI をリクエスト URI として指定してよい (MAY)。

キャッシュは、Content-Location が、それを取得するために使用された URI と異なるエンティティを、その Content-Location URI に対する以降のリクエストに応答するために使用できると仮定してはならない (MUST NOT)。しかし、Content-Location は、13.6 節で説明されているように、単一のリクエストリソースから取得された複数のエンティティを区別するために使用してよい (MAY)。

Content-Location が相対 URI である場合、その相対 URI は Request-URI に対して相対的に解釈される。

PUT または POST リクエストにおける Content-Location ヘッダの意味は未定義である。サーバはそれらの場合にそれを無視してよい (MAY)。

14.15 Content-MD5​

RFC 1864 [23] で定義されている Content-MD5 エンティティヘッダフィールドは、エンティティボディのエンドツーエンドのメッセージ完全性検査（MIC）を提供する目的で、エンティティボディの MD5 ダイジェストである。（Note: MIC は、転送中のエンティティボディの偶発的な変更を検出するのには役立つが、悪意のある攻撃に対する証明にはならない。）

    Content-MD5   = "Content-MD5" ":" md5-digest
    md5-digest   = `<base64 of 128 bit MD5 digest as per RFC 1864>`

Content-MD5 ヘッダフィールドは、エンティティボディの完全性検査として機能するように、オリジンサーバまたはクライアントによって生成されてよい (MAY)。Content-MD5 ヘッダフィールドを生成してよい (MAY) のはオリジンサーバまたはクライアントのみである。プロキシおよびゲートウェイはそれを生成してはならない (MUST NOT)。なぜなら、それはエンドツーエンドの完全性検査としての価値を損なうからである。ゲートウェイやプロキシを含め、エンティティボディのいかなる受信者も、このヘッダフィールド内のダイジェスト値が受信したエンティティボディのそれと一致するかどうかを検査してよい (MAY)。

MD5 ダイジェストは、適用されたいかなる content-coding を含むが、メッセージボディに適用されたいかなる transfer-encoding は含まないエンティティボディの内容に基づいて計算される。メッセージが transfer-encoding 付きで受信された場合、受信したエンティティに対する Content-MD5 値を検査する前に、そのエンコーディングは削除されなければならない (MUST)。

この結果、ダイジェストは、transfer-encoding が適用されていない場合に送信されるのとまさに同じオクテット、およびその順序で計算される。

HTTP は RFC 1864 を拡張して、MIME 複合メディアタイプ（たとえば multipart/* および message/rfc822）に対するダイジェストの計算を許可するが、これは前段で定義されたダイジェストの計算方法を変更するものではない。

これにはいくつかの帰結がある。複合型のエンティティボディは多くの body-part を含んでもよく (MAY)、各 body-part は自身の MIME および HTTP ヘッダ（Content-MD5、Content-Transfer-Encoding、Content-Encoding ヘッダを含む）を持つ。body-part に Content-Transfer-Encoding または Content-Encoding ヘッダがある場合、body-part の内容にエンコーディングが適用されたとみなされ、body-part は適用後の状態のまま、すなわち Content-MD5 ダイジェストに含まれる。Transfer-Encoding ヘッダフィールドは body-part 内では許可されない。

ダイジェストを計算または検査する前に、すべての改行を CRLF に変換してはならない (MUST NOT)。実際に送信されるテキストで使用される改行規則は、ダイジェストを計算する際に変更されないまま残されなければならない (MUST)。

  Note: Content-MD5 の定義は、HTTP においても MIME エンティティボディに対する RFC 1864 とまさに同じであるが、HTTP エンティティボディへの Content-MD5 の適用が MIME エンティティボディへの適用と異なる点がいくつかある。1 つは、HTTP は MIME と異なり Content-Transfer-Encoding を使用せず、Transfer-Encoding および Content-Encoding を使用することである。もう 1 つは、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

この長さが不明または決定が困難でない限り、ヘッダは完全なエンティティボディの全長を示すべき (SHOULD) である。アスタリスク "*" という文字は、instance-length がレスポンス生成時点で不明であることを意味する。

byte-ranges-specifier 値（14.35.1 節参照）と異なり、byte-range-resp-spec は 1 つの範囲のみを指定しなければならず (MUST)、範囲の最初と最後のバイトの両方に対する絶対バイト位置を含まなければならない (MUST)。

last-byte-pos 値が first-byte-pos 値より小さい、または instance-length 値が last-byte-pos 値以下であるような byte-content-range-spec は無効である。無効な byte-content-range-spec を受信した者は、それおよびそれと共に転送されたいかなる内容も無視しなければならない (MUST)。

416（Requested range not satisfiable）ステータスコードでレスポンスを送信するサーバは、byte-range-resp-spec が "" である Content-Range フィールドを含めるべき (SHOULD) である。instance-length は、選択されたリソースの現在の長さを指定する。206（Partial Content）ステータスコードのレスポンスは、byte-range-resp-spec が "" である Content-Range フィールドを含んではならない (MUST NOT)。

エンティティが合計 1234 バイトを含むと仮定した byte-content-range-spec 値の例は次のとおりである。

  . 最初の 500 バイト：
   bytes 0-499/1234

  . 2 番目の 500 バイト：
   bytes 500-999/1234

  . 最初の 500 バイト以外のすべて：
   bytes 500-1233/1234

  . 最後の 500 バイト：
   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 メッセージが複数の範囲の内容（たとえば重ならない複数範囲のリクエストへのレスポンス）を含む場合、これらは multipart メッセージとして送信される。この目的に使用される multipart メディアタイプは、付録 19.2 で定義される "multipart/byteranges" である。互換性の問題については付録 19.6.3 を参照されたい。

単一範囲のリクエストへのレスポンスは、multipart/byteranges メディアタイプを用いて送信してはならない (MUST NOT)。結果が単一範囲となる複数範囲のリクエストへのレスポンスは、1 つの part を持つ multipart/byteranges メディアタイプとして送信されてよい (MAY)。multipart/byteranges メッセージを復号できないクライアントは、単一のリクエストで複数のバイト範囲を要求してはならない (MUST NOT)。

クライアントが 1 つのリクエストで複数のバイト範囲を要求する場合、サーバはそれらをリクエスト内に現れた順序で返すべき (SHOULD) である。

サーバが構文的に無効なため byte-range-spec を無視する場合、サーバは無効な Range ヘッダフィールドが存在しなかったかのようにリクエストを扱うべき (SHOULD) である。（通常、これは完全なエンティティを含む 200 レスポンスを返すことを意味する。）

サーバが、満たせない Range リクエストヘッダフィールド（すなわち、すべての byte-range-spec 値の first-byte-pos 値が選択されたリソースの現在の長さより大きいもの）を含むリクエスト（If-Range リクエストヘッダフィールドを含むものを除く）を受信した場合、416（Requested range not satisfiable）レスポンスコード（10.4.17 節）を返すべき (SHOULD) である。

  Note: クライアントは、満たせない 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 ジェネラルヘッダフィールドは、メッセージが生成された日付と時刻を表し、RFC 822 の orig-date と同じ意味論を持つ。フィールド値は 3.3.1 節で説明されている HTTP-date であり、RFC 1123 [8] の date 形式で送信されなければならない (MUST)。

   Date  = "Date" ":" HTTP-date

例は次のとおりである。

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

オリジンサーバは、すべてのレスポンスに Date ヘッダフィールドを含めなければならない (MUST) が、次の場合を除く。

  1. レスポンスステータスコードが 100（Continue）または 101（Switching Protocols）である場合、レスポンスはサーバの判断で Date ヘッダフィールドを含んでよい (MAY)。

  2. レスポンスステータスコードがサーバエラー、たとえば 500（Internal Server Error）または 503（Service Unavailable）を伝え、かつ有効な Date を生成することが不便または不可能である場合。

  3. サーバが現在時刻の合理的な近似を提供できるクロックを持たない場合、そのレスポンスは Date ヘッダフィールドを含んではならない (MUST NOT)。この場合、14.18.1 節の規則に従わなければならない (MUST)。

Date ヘッダフィールドを持たない受信メッセージは、そのメッセージがその受信者によってキャッシュされるか、Date を必要とするプロトコルを経由してゲートウェイされる場合、受信者によって 1 つの Date が割り当てられなければならない (MUST)。クロックを持たない HTTP 実装は、各使用時に再検証せずにレスポンスをキャッシュしてはならない (MUST NOT)。HTTP キャッシュ、とくに共有キャッシュは、NTP [28] などのメカニズムを用いてクロックを信頼できる外部標準と同期させるべき (SHOULD) である。

クライアントは、PUT および POST リクエストの場合のようにエンティティボディを含むメッセージにのみ Date ヘッダフィールドを送信すべき (SHOULD) であり、その場合でもそれはオプションである。クロックを持たないクライアントは、リクエストに Date ヘッダフィールドを送信してはならない (MUST NOT)。

Date ヘッダで送信される HTTP-date は、メッセージの生成後の日付と時刻を表すべきでない (SHOULD NOT)。それは、合理的に正確な日付と時刻を生成する手段が実装にない場合を除き、メッセージ生成の日付と時刻の最良の利用可能な近似を表すべき (SHOULD) である。理論上、その日付はエンティティが生成される直前の瞬間を表すべきである。実際には、その日付はメッセージ生成中のいかなる時点でも生成でき、その意味論的価値に影響を与えない。

14.18.1 クロックのないオリジンサーバの動作​

クロックを利用できないオリジンサーバ実装もあるかもしれない。クロックを持たないオリジンサーバは、これらの値が信頼できるクロックを持つシステムまたはユーザによってリソースに関連付けられていない限り、レスポンスに Expires または Last-Modified 値を割り当ててはならない (MUST NOT)。サーバ設定時またはそれ以前に過去であることが知られている Expires 値を割り当ててよい (MAY)（これにより、各リソースごとに別個の Expires 値を格納せずにレスポンスの「事前有効期限切れ」を許可する）。

14.19 ETag​

ETag レスポンスヘッダフィールドは、要求されたバリアントのエンティティタグの現在の値を提供する。エンティティタグと共に使用されるヘッダは 14.24、14.26、14.44 節で説明されている。エンティティタグは、同じリソースからの他のエンティティとの比較（13.3.3 節参照）に使用されてよい (MAY)。

  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 フィールド内のいかなる expectation 値も理解できない、または順守できないサーバは、適切なエラーステータスで応答しなければならない (MUST)。いずれかの expectation を満たせない場合、サーバは 417（Expectation Failed）ステータスで応答しなければならず (MUST)、リクエストに他の問題がある場合は他の 4xx ステータスで応答しなければならない (MUST)。

このヘッダフィールドは、将来の拡張のために拡張可能な文法で定義されている。サーバが、サポートしない expectation-extension を含む Expect フィールドを含むリクエストを受信した場合、417（Expectation Failed）ステータスで応答しなければならない (MUST)。

expectation 値の比較は、引用符なしトークン（100-continue トークンを含む）については大文字小文字を区別せず、引用符付き文字列の expectation-extension については大文字小文字を区別する。

Expect メカニズムはホップバイホップである。すなわち、HTTP/1.1 プロキシは、満たせない expectation を持つリクエストを受信した場合、417（Expectation Failed）ステータスを返さなければならない (MUST)。しかし、Expect リクエストヘッダ自体はエンドツーエンドであり、リクエストが転送される場合転送されなければならない (MUST)。

多くの古い HTTP/1.0 および HTTP/1.1 アプリケーションは Expect ヘッダを理解しない。

100（continue）ステータスの使用については 8.2.3 節を参照されたい。

14.21 Expires​

Expires エンティティヘッダフィールドは、その後でレスポンスが古い (stale) とみなされる日付と時刻を与える。古いキャッシュエントリは、通常、まずオリジンサーバ（またはエンティティの新鲜なコピーを持つ中間キャッシュ）で検証されない限り、キャッシュ（プロキシキャッシュでもユーザエージェントキャッシュでも）によって返されてはならない (MUST NOT)。有効期限モデルのさらなる議論については 13.2 節を参照されたい。

Expires フィールドの存在は、元のリソースがその時刻の前、その時刻、またはその時刻以後に変更されたり、存在しなくなったりすることを意味するものではない。

その形式は、3.3.1 節の HTTP-date で定義される絶対的な日付と時刻であり、RFC 1123 の date 形式でなければならない (MUST)。

  Expires = "Expires" ":" HTTP-date

使用例は次のとおりである。

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

  Note: レスポンスに max-age 指令を持つ Cache-Control フィールドが含まれる場合（14.9.3 節参照）、その指令は Expires フィールドを上書きする。

HTTP/1.1 クライアントおよびキャッシュは、とくに値 "0" を含めて、その他の無効な日付形式を過去（すなわち「既に期限切れ」）として扱わなければならない (MUST)。

レスポンスを「既に期限切れ」とマークするために、オリジンサーバは Date ヘッダ値と等しい Expires 日付を送信する。（13.2.4 節の有効期限計算の規則を参照されたい。）

レスポンスを「決して期限切れにならない」とマークするために、オリジンサーバは、レスポンスが送信された時刻から約 1 年後の Expires 日付を送信する。HTTP/1.1 サーバは、1 年より未来の Expires 日付を送信すべきでない (SHOULD NOT)。

デフォルトでは非キャッシュ可能であるレスポンスであっても、将来のある時刻の日付値を持つ Expires ヘッダフィールドが存在すれば、Cache-Control ヘッダフィールド（14.9 節）によって他に示されない限り、そのレスポンスはキャッシュ可能であることを示す。

14.22 From​

From リクエストヘッダフィールドは、与えられる場合、リクエストするユーザエージェントを制御する人間ユーザのインターネット電子メールアドレスを含むべき (SHOULD) である。そのアドレスは、RFC 822 [9]（RFC 1123 [8] によって更新）の "mailbox" で定義されるように、機械可読であるべき (SHOULD) である。

   From   = "From" ":" mailbox

例は次のとおりである。

   From: [email protected]

このヘッダフィールドは、ログ記録の目的および無効または不要なリクエストの出所を識別する手段として使用されてよい (MAY)。これは、安全でないアクセス保護の形式として使用されるべきでない (SHOULD NOT)。このフィールドの解釈は、リクエストが責任を負う人物の代わりに実行されており、その人物が実行されたメソッドに対する責任を受け入れるということである。とくに、ロボットエージェントは、受信側で問題が発生した場合にロボットの実行責任者に連絡できるように、このヘッダを含めるべき (SHOULD) である。

このフィールド内のインターネット電子メールアドレスは、リクエストを発行したインターネットホストとは別であってよい (MAY)。たとえば、リクエストがプロキシを経由して渡される場合、元の発行者のアドレスを使用すべき (SHOULD) である。

クライアントは、ユーザの承認なしに From ヘッダフィールドを送信すべきでない (SHOULD NOT)。なぜなら、ユーザのプライバシー上の利益やサイトのセキュリティポリシーと衝突するおそれがあるからである。ユーザがリクエスト前のいかなる時点でもこのフィールドの値を無効化、有効化、および変更できることが強く推奨される。

14.23 Host​

Host リクエストヘッダフィールドは、ユーザまたは参照リソース（一般的には 3.2.2 節で説明される HTTP URL）から得られた元の URI によって指定される、要求されているリソースのインターネットホストとポート番号を指定する。

Host フィールド値は、元の URL によって与えられるオリジンサーバまたはゲートウェイの命名権限を表さなければならない (MUST NOT)。これにより、オリジンサーバまたはゲートウェイは、単一の IP アドレス上の複数のホスト名を持つサーバのルート "/" URL のような、内部的に曖昧な 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 ヘッダフィールドを含めなければならない (MUST)。要求された URI が要求されたサービスのインターネットホスト名を含まない場合、Host ヘッダフィールドは空の値で与えられなければならない (MUST)。HTTP/1.1 プロキシは、転送するいかなるリクエストメッセージも、プロキシによって要求されているサービスを識別する適切な Host ヘッダフィールドを含んでいることを保証しなければならない (MUST)。インターネットベースのすべての HTTP/1.1 サーバは、Host ヘッダフィールドを欠くいかなる HTTP/1.1 リクエストメッセージに対しても 400（Bad Request）ステータスコードで応答しなければならない (MUST)。

Host に関連する他の要件については 5.2 および 19.6.1.1 節を参照されたい。

14.24 If-Match​

If-Match リクエストヘッダフィールドは、メソッドと共に使用され、それを条件的なものにする。リソースから以前に取得した 1 つ以上のエンティティを持つクライアントは、それらの関連するエンティティタグのリストを If-Match ヘッダフィールドに含めることにより、それらのエンティティの 1 つが現在のものであることを検証できる。エンティティタグは 3.11 節で定義されている。この機能の目的は、最小限のトランザクションオーバーヘッドでキャッシュされた情報の効率的な更新を許可することである。また、更新リクエストにおいて、リソースの誤ったバージョンの偶発的な変更を防ぐために使用される。特別な場合として、値 "*" はリソースのいかなる現在のエンティティとも一致する。

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

いずれかのエンティティタグが、そのリソースに対する同様の GET リクエスト（If-Match ヘッダなし）のレスポンスで返されたはずのエンティティのエンティティタグと一致する場合、または "*" が与えられそのリソースに対するいかなる現在のエンティティも存在する場合、サーバは If-Match ヘッダフィールドが存在しなかったかのようにリクエストされたメソッドを実行してよい (MAY)。

サーバは、If-Match 内のエンティティタグを比較するために強比較関数（13.3.3 節参照）を使用しなければならない (MUST)。

いずれのエンティティタグも一致せず、または "*" が与えられても現在のエンティティが存在しない場合、サーバはリクエストされたメソッドを実行してはならず (MUST NOT)、412（Precondition Failed）レスポンスを返さなければならない (MUST)。この振る舞いは、クライアントが PUT などの更新メソッドが、クライアントが最後に取得して以来に変更されたリソースを変更するのを防ぎたい場合に最も有用である。

リクエストが、If-Match ヘッダフィールドがなければ、2xx または 412 以外のステータスになる場合、If-Match ヘッダは無視されなければならない (MUST)。

"If-Match: *" の意味は、オリジンサーバ（または、おそらく Vary メカニズムを用いるキャッシュ、14.44 節参照）によって選択された表現が存在する場合、メソッドを実行すべき (SHOULD) であり、表現が存在しない場合、実行してはならない (MUST NOT) ということである。

リソースを更新することを意図したリクエスト（たとえば PUT）は、If-Match ヘッダフィールドを含めてよく (MAY)、それにより、If-Match 値（単一のエンティティタグ）に対応するエンティティがそのリソースの表現ではなくなった場合、リクエストメソッドを実行してはならない (MUST NOT) ことを通知してよい。これにより、ユーザは、リソースが自分の知らないうちに変更された場合、リクエストが成功してほしくないことを示せる。例：

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

If-Match ヘッダフィールドと、If-None-Match または If-Modified-Since ヘッダフィールドのいずれかの両方を持つリクエストの結果は、この仕様では未定義である。

14.25 If-Modified-Since​

If-Modified-Since リクエストヘッダフィールドは、メソッドと共に使用され、それを条件的なものにする。指定されたバリアントがこのフィールドで指定された時刻以降に変更されていない場合、エンティティはサーバから返されず、代わりにメッセージボディなしの 304（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（Not Modified）レスポンスを返すべき (SHOULD) である。

この機能の目的は、最小限のトランザクションオーバーヘッドでキャッシュされた情報の効率的な更新を許可することである。

  Note: Range リクエストヘッダフィールドは If-Modified-Since の意味を変更する。詳細については 14.35 節を参照されたい。

  Note: If-Modified-Since の時刻は、クロックがクライアントと同期していないかもしれないサーバによって解釈される。

  Note: If-Modified-Since ヘッダフィールドを扱う際、304（Not Modified）レスポンスを送信するかどうかを決定するために、厳密な日付比較関数を使用するサーバもある。キャッシュ検証のために If-Modified-Since ヘッダフィールドを送信する際、クライアントは、可能な限り以前の Last-Modified ヘッダフィールドで受信した厳密な日付文字列を使用することが推奨される。

  Note: クライアントが、同じリクエストの Last-Modified ヘッダから取得した日付ではなく任意の日付を If-Modified-Since ヘッダに使用する場合、クライアントは、この日付がサーバの時間理解において解釈されるという事実に留意すべきである。未同期のクロックと丸めの問題を考慮すべきである。クライアントとサーバ間の異なる時間基準に対する補正は、ネットワーク遅延によりせいぜい近似である。

If-Modified-Since ヘッダフィールドと、If-Match または If-Unmodified-Since ヘッダフィールドのいずれかの両方を持つリクエストの結果は、この仕様では未定義である。

14.26 If-None-Match​

If-None-Match リクエストヘッダフィールドは、メソッドと共に使用され、それを条件的なものにする。リソースから以前に取得した 1 つ以上のエンティティを持つクライアントは、それらの関連するエンティティタグのリストを If-None-Match ヘッダフィールドに含めることにより、いずれかの既存エンティティが現在の表現でないことを検証できる。If-None-Match の目的は、エンティティが現在の表現でない場合にのみメソッドを実行するように要求することである。すなわち、新しいリソースとして作成する場合、または既存リソースを置換（PUT）する場合に、リソースが偶然上書きされるのを防ぐ。

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

エンティティタグは 3.11 節で定義されている。リソースに対するその類似の GET リクエストのレスポンスで返されるエンティティのうち、If-None-Match フィールドのいずれかのエンティティタグと弱比較関数を用いて比較して等しいものがある場合、または "*" が与えられてリソースに対する現在のエンティティが存在する場合、その場合を除き、サーバはリクエストされたメソッドを実行してよい (MAY)。

サーバは、If-None-Match 内のエンティティタグを比較するために弱比較関数（13.3.3 節参照）を使用しなければならない (MUST)。

与えられたリクエストに対して上記のテストが真である場合、If-None-Match フィールドが存在しなかったかのようにリクエストされたメソッドを実行すべき (SHOULD) である。テストが偽である場合、サーバは 304（Not Modified）レスポンスを返さなければならない (MUST)（GET または HEAD の場合）、または 412（Precondition Failed）レスポンスを返さなければならない (MUST)（他のメソッドの場合）。ただし、2xx または 304 以外のステータスになるリクエストに対しては、If-None-Match ヘッダは無視されなければならない (MUST)。

特定のリクエストメソッドに対して If-None-Match ヘッダを受信したサーバは、そのリクエストが対応するエンティティとともに送信される場合、そのエンティティのエンティティタグとリクエストの If-None-Match ヘッダ内のエンティティタグとの間で競合が発生した場合に、処理を防ぐ警告を生成してよい (MAY)。

"If-None-Match: *" の意味は、リソースが作成されていない場合にメソッドを実行すべき (SHOULD) であり、すでに存在する場合は実行してはならない (MUST NOT) ということである。

リソースを作成または置換することを意図したリクエスト（たとえば PUT）は、If-None-Match ヘッダフィールドを含めてよく (MAY)、それにより、If-None-Match 値に対応するエンティティがすでにそのリソースの表現として存在する場合、リクエストメソッドを実行してはならない (MUST NOT) ことを通知してよい。これにより、ユーザは、リソースがすでに存在する場合、リクエストが成功してほしくないことを示せる。

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

If-None-Match ヘッダフィールドと、If-Match または If-Unmodified-Since ヘッダフィールドのいずれかの両方を持つリクエストの結果は、この仕様では未定義である。

14.27 If-Range​

If-Range リクエストヘッダフィールドを使用すると、クライアントが部分的なリクエストを発行し、そのリソースが予想される表現でない場合にのみ、完全なエンティティを要求できる。If-Range ヘッダを使用すると、クライアントがエンティティの一部を持っており、プロキシまたはキャッシュに新しいリソースを配信させたい場合、無条件に完全なエンティティを要求することなく、部分的なリクエストを発行できる。

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

If-Range ヘッダがクライアントの以前のリクエストへのレスポンスで受信されたエンティティタグまたは日付と一致する場合、サーバは Range ヘッダで指定された、適切な部分を含む 206（Partial content）レスポンスを送信しなければならない (MUST)。一致しない場合、クライアントには完全なエンティティが 200（OK）レスポンスで送信されなければならない (MUST)。

If-Range ヘッダは、If-Unmodified-Since ヘッダと同様に機能するが、値がエンティティタグまたは日付のいずれかになり得る点、および範囲要求を満たすかどうかのみを制御する点が異なる。一致しない場合、If-Range は 200 レスポンスで新しいエンティティを返すよう強制し、他の前提条件ヘッダのように 304/412 レスポンスを返すことはない。

  Note: If-Range ヘッダが日付を使用している場合、このヘッダは If-Unmodified-Since と同じ意味論（13.3.3 節参照）をもつ。

If-Range リクエストヘッダがエンティティタグを伴って送信され、かつクライアントが Range ヘッダと共に送信する場合、サーバは Range ヘッダで指定された部分のみを返すべき (SHOULD) である。サーバが範囲要求を満たせず、かつ If-Range ヘッダの値がリソースの現在のエンティティタグまたは日付と等しくない場合、サーバは 200（OK）レスポンスでリソースを返さなければならない (MUST)。

If-Range リクエストヘッダがエンティティタグを伴って送信され、かつクライアントが Range ヘッダなしで送信する場合、If-Range ヘッダは無視される。エンティティタグを伴わずに送信された If-Range リクエストヘッダは、If-Unmodified-Since ヘッダと同じように扱われなければならない (MUST)。

If-Range ヘッダは持続的キャッシュの実装者にとって重要である。

14.28 If-Unmodified-Since​

If-Unmodified-Since リクエストヘッダフィールドは、メソッドと共に使用され、それを条件的なものにする。要求されたリソースがこのフィールドで指定された時刻以降に変更されていない場合、サーバは、If-Unmodified-Since ヘッダが存在しなかったかのように要求された操作を実行すべき (SHOULD) である。

要求されたバリアントが指定された時刻以降に変更されている場合、サーバは要求された操作を実行してはならず (MUST NOT)、412（Precondition Failed）を返さなければならない (MUST)。

  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 ヘッダは無視されるべき (SHOULD) である。

指定された日付が無効な場合、そのヘッダは無視される。

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 日付を送信してはならない (MUST)。そのような場合、リソースの最終変更が将来のある時刻を示す場合、サーバはその日付をメッセージ生成日付に置き換えなければならない (MUST)。

オリジンサーバは、エンティティの Last-Modified 値を、そのレスポンスの Date 値を生成する時刻にできる限り近いものとして取得すべき (SHOULD) である。これにより、受信者は、とくにエンティティがレスポンス生成に近い時刻に変更される場合に、エンティティの変更時刻を正確に評価できる。

HTTP/1.1 サーバは、実行可能な場合は常に Last-Modified を送信すべき (SHOULD) である。

14.30 Location​

Location レスポンスヘッダフィールドは、リクエストの完了または新しいリソースの識別のために、受信者を Request-URI 以外の位置にリダイレクトするために使用される。201（Created）レスポンスの場合、Location はリクエストによって作成された新しいリソースの位置である。3xx レスポンスの場合、location は、リソースへの自動リダイレクトに対するサーバの推奨 URI を示すべき (SHOULD) である。フィールド値は単一の絶対 URI から成る。

   Location       = "Location" ":" absoluteURI

例は次のとおりである。

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

  Note: 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

Max-Forwards 値は、このリクエストメッセージが転送されてよい残り回数を示す十進整数である。

Max-Forwards ヘッダフィールドを含む TRACE または OPTIONS リクエストの各プロキシまたはゲートウェイ受信者は、リクエストを転送する前にその値を検査および更新しなければならない (MUST)。受信した値がゼロ（0）の場合、受信者はリクエストを転送してはならず (MUST NOT)、代わりに最終受信者として応答しなければならない (MUST)。受信した Max-Forwards 値がゼロより大きい場合、転送されるメッセージには、値を 1 減じた更新された Max-Forwards フィールドが含まれていなければならない (MUST)。

Max-Forwards ヘッダフィールドは、この仕様で定義された他のすべてのメソッド、およびそのメソッド定義の一部として明示的に参照されないいかなる拡張メソッドについても無視されてよい (MAY)。

14.32 Pragma​

Pragma ジェネラルヘッダフィールドは、リクエスト/レスポンスチェーンに沿ういかなる受信者にも適用されるかもしれない実装固有の指令を含めるために使用される。すべての pragma 指令は、プロトコルの観点からはオプションの振る舞いを指定する。しかし、一部のシステムは、その振る舞いが指令と一致することを要求するかもしれない。

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

no-cache 指令がリクエストメッセージに存在する場合、アプリケーションは、要求されているもののキャッシュコピーを持っていても、リクエストをオリジンサーバに向けて転送すべき (SHOULD) である。この pragma 指令は no-cache cache-directive（14.9 節参照）と同じ意味論を持ち、HTTP/1.0 との下位互換性のためにここで定義されている。クライアントは、HTTP/1.1 準拠でないことが知られているサーバに no-cache リクエストを送信する場合、両方のヘッダフィールドを含めるべき (SHOULD) である。

Pragma 指令は、そのアプリケーションに対する重要性にかかわらず、プロキシまたはゲートウェイアプリケーションによって通過させなければならない (MUST)。なぜなら、それらの指令はリクエスト/レスポンスチェーンの沿線のすべての受信者に適用される可能性があるからである。特定の受信者に対する pragma を指定することは不可能である。しかし、受信者に関係のないいかなる pragma 指令も、その受信者によって無視されるべき (SHOULD) である。

HTTP/1.1 キャッシュは、"Pragma: no-cache" を、クライアントが "Cache-Control: no-cache" を送信したかのように扱うべき (SHOULD) である。HTTP では新しい Pragma 指令は定義されない。

  Note: "Pragma: no-cache" をレスポンスヘッダフィールドとして使用した場合の意味は実際には規定されていないため、レスポンス内の "Cache-Control: no-cache" の信頼できる置換にはならない。

14.33 Proxy-Authenticate​

Proxy-Authenticate レスポンスヘッダフィールドは、407（Proxy Authentication Required）レスポンスの一部として含まれなければならない (MUST)。フィールド値は、この Request-URI に対するプロキシに適用可能な認証スキームおよびパラメータを示すチャレンジから成る。

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

HTTP アクセス認証プロセスは "HTTP Authentication: Basic and Digest Access Authentication" [43] で説明されている。WWW-Authenticate と異なり、Proxy-Authenticate ヘッダフィールドは現在の接続にのみ適用され、ダウンストリームクライアントに渡すべきでない (SHOULD NOT)。しかし、中間プロキシは、ダウンストリームクライアントから認証情報を要求することによって自身の資格情報を取得する必要があるかもしれず、これは状況によってはプロキシが Proxy-Authenticate ヘッダフィールドを転送しているように見える。

14.34 Proxy-Authorization​

Proxy-Authorization リクエストヘッダフィールドにより、認証を要求するプロキシに対して、クライアントは自身（またはそのユーザ）を識別できる。Proxy-Authorization フィールド値は、プロキシおよび/または要求されているリソースのレルムに対するユーザエージェントの認証情報を含む資格情報から成る。

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

HTTP アクセス認証プロセスは "HTTP Authentication: Basic and Digest Access Authentication" [43] で説明されている。Authorization と異なり、Proxy-Authorization ヘッダフィールドは、Proxy-Authenticate フィールドを用いて認証を要求した次のアウトバウンドプロキシにのみ適用される。チェーン内で複数のプロキシが使用される場合、Proxy-Authorization ヘッダフィールドは、資格情報の受信を期待していた最初のアウトバウンドプロキシによって消費される。プロキシは、それが特定のリクエストを協調的に認証するメカニズムである場合、クライアントリクエストから次のプロキシへ資格情報を中継してよい (MAY)。

14.35 Range​

14.35.1 Byte Ranges​

すべての HTTP エンティティは HTTP メッセージにおいてバイトの列として表現されるため、バイト範囲の概念はいかなる HTTP エンティティに対しても意味を持つ。（ただし、すべてのクライアントとサーバがバイト範囲操作をサポートする必要があるわけではない。）

HTTP のバイト範囲指定は、エンティティボディ（必ずしもメッセージボディと同じではない）内のバイトの列に適用される。

バイト範囲操作は、単一のバイト範囲、または単一エンティティ内の一連の範囲を指定してよい (MAY)。

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

byte-range-spec 内の first-byte-pos 値は、範囲内の最初のバイトのバイトオフセットを与える。last-byte-pos 値は、範囲内の最後のバイトのバイトオフセットを与える。すなわち、指定されるバイト位置は包括的である。バイトオフセットはゼロから始まる。

last-byte-pos 値が存在する場合、それはその byte-range-spec 内の first-byte-pos 以上でなければならず (MUST)、そうでない場合、byte-range-spec は構文的に無効である。1 つ以上の構文的に無効な byte-range-spec 値を含む byte-range-set を受信した者は、その byte-range-set を含むヘッダフィールドを無視しなければならない (MUST)。

last-byte-pos 値が存在しない場合、またはその値がエンティティボディの現在の長さ以上である場合、last-byte-pos はエンティティボディの現在の長さから 1 を引いた値と等しいとみなされる。

クライアントは 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 に、その first-byte-pos がエンティティボディの現在の長さより小さい byte-range-spec が少なくとも 1 つ、または non-zero の suffix-length を持つ suffix-byte-range-spec が少なくとも 1 つ含まれる場合、その byte-range-set は充足可能 (satisfiable) である。それ以外の場合、byte-range-set は充足不可能 (unsatisfiable) である。byte-range-set が充足不可能な場合、サーバは 416（Requested range not satisfiable）ステータスのレスポンスを返すべき (SHOULD) である。それ以外の場合、サーバはエンティティボディの充足可能な範囲を含む 206（Partial Content）ステータスのレスポンスを返すべき (SHOULD) である。

エンティティボディの長さが 10000 であると仮定した byte-ranges-specifier 値の例は次のとおりである。

  - 最初の 500 バイト（バイトオフセット 0-499、包括的）：  bytes=0-499

  - 2 番目の 500 バイト（バイトオフセット 500-999、包括的）：
    bytes=500-999

  - 最後の 500 バイト（バイトオフセット 9500-9999、包括的）：
    bytes=-500

  - または bytes=9500-

  - 最初と最後のバイトのみ（バイト 0 および 9999）：  bytes=0-0,-1

  - 2 番目の 500 バイトのいくつかの合法だが正準でない指定（バイトオフセット 500-999、包括的）：
     bytes=500-600,601-999
     bytes=500-700,601-999

14.35.2 Range Retrieval Requests​

条件付きまたは無条件の GET メソッドを用いた HTTP 取得リクエストは、エンティティ全体の代わりに、リクエストの結果として返されるエンティティに適用される Range リクエストヘッダを用いて、エンティティの 1 つ以上の部分範囲を要求してよい (MAY)。

  Range = "Range" ":" ranges-specifier

サーバは Range ヘッダを無視してよい (MAY)。しかし、HTTP/1.1 オリジンサーバおよび中間キャッシュは、可能な場合はバイト範囲をサポートすべき (ought to) である。なぜなら、Range は部分的に失敗した転送からの効率的な回復を支援し、大きなエンティティの効率的な部分的取得を支援するからである。

サーバが Range ヘッダをサポートし、指定された範囲がエンティティに適切である場合：

  - 無条件 GET 内の Range ヘッダの存在は、GET がそれ以外の場合に成功した場合に返されるものを変更する。すなわち、レスポンスは 200（OK）ではなく 206（Partial Content）のステータスコードを運ぶ。

  - 条件付き GET（If-Modified-Since および If-None-Match の一方または両方、または If-Unmodified-Since および If-Match の一方または両方を使用するリクエスト）内の Range ヘッダの存在は、GET がそれ以外の場合に成功し、かつ条件が真である場合に返されるものを変更する。それは、条件が偽である場合に返される 304（Not Modified）レスポンスには影響しない。

一部の場合、Range ヘッダに加えて If-Range ヘッダ（14.27 節参照）を使用する方が適切かもしれない。

範囲をサポートするプロキシが Range リクエストを受信し、それをインバウンドサーバに転送し、返答としてエンティティ全体を受信した場合、プロキシは要求された範囲のみをクライアントに返すべき (SHOULD) である。それがキャッシュ割り当てポリシーと一致する場合、受信したレスポンス全体をキャッシュに格納すべき (SHOULD) である。

14.36 Referer​

Referer[sic] リクエストヘッダフィールドにより、クライアントは、Request-URI が得られたリソースのアドレス（URI）（"referrer"、ただしヘッダフィールドは綴りが間違っている）を、サーバの利益のために指定できる。Referer リクエストヘッダにより、サーバは興味、ログ記録、最適化されたキャッシュなどのためにリソースへのバックリンクのリストを生成できる。また、廃止された、または誤って入力されたリンクを保守のために追跡できる。Referer フィールドは、Request-URI がユーザのキーボードからの入力など、独自の URI を持たないソースから得られた場合、送信されてはならない (MUST NOT)。

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

例：

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

フィールド値が相対 URI である場合、それは Request-URI に対して相対的に解釈されるべき (SHOULD) である。URI にはフラグメントを含んではならない (MUST NOT)。セキュリティ上の考慮事項については 15.1.3 節を参照されたい。

14.37 Retry-After​

Retry-After レスポンスヘッダフィールドは、503（Service Unavailable）レスポンスと共に使用され、サービスが要求クライアントに対して利用できなくなると予想される期間を示すために使用できる。このフィールドは、いかなる 3xx（Redirection）レスポンスと共に使用してもよく (MAY)、ユーザエージェントがリダイレクトされたリクエストを発行する前に待機するよう求められる最小時間を示す。このフィールドの値は、HTTP-date またはレスポンス時刻以降の秒数（十進）の整数のいずれかである。

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

使用例は次の 2 つである。

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

後者の例では、遅延は 2 分である。

14.38 Server​

Server レスポンスヘッダフィールドは、リクエストを処理するためにオリジンサーバによって使用されたソフトウェアに関する情報を含む。フィールドは、サーバおよび重要なサブプロダクトを識別する複数のプロダクトトークン（3.8 節）およびコメントを含んでもよい (MAY)。プロダクトトークンは、アプリケーションの識別に対する重要性の順に列挙される。

   Server         = "Server" ":" 1*( product | comment )

例：

   Server: CERN/3.0 libwww/2.17

レスポンスがプロキシを経由して転送される場合、プロキシアプリケーションは Server レスポンスヘッダを変更してはならない (MUST NOT)。代わりに、Via フィールド（14.45 節参照）を含めるべき (SHOULD) である。

  Note: サーバの特定のソフトウェアバージョンを公開すると、既知のセキュリティホールを含むソフトウェアに対する攻撃に対してサーバマシンがより脆弱になるおそれがある。Server の実装者は、このフィールドを設定可能なオプションにすることが推奨される。

14.39 TE​

TE リクエストヘッダフィールドは、レスポンス内で受け入れる意思のある拡張 transfer-coding、およびチャンク transfer-coding 内の trailer フィールドを受け入れる意思があるかどうかを示す。その値は、キーワード "trailers" および/またはオプションの受け入れパラメータ（3.6 節参照）を持つ拡張 transfer-coding 名のカンマ区切りリストから成る。

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

"trailers" というキーワードの存在は、クライアントが、3.6.1 節で定義されるように、チャンク transfer-coding 内の trailer フィールドを受け入れる意思があることを示す。このキーワードは、それ自体は transfer-coding を表さないが、transfer-coding 値と共に使用するために予約されている。

使用例は次のとおりである。

使用例は次のとおりである。

   TE: deflate
   TE:
   TE: trailers, deflate;q=0.5

TE ヘッダフィールドは直ちの接続にのみ適用される。したがって、HTTP/1.1 メッセージ内に TE が存在する場合は常に、キーワードは Connection ヘッダフィールド（14.10 節）内に供給されなければならない (MUST)。

サーバは、TE フィールドに従って、いかなる transfer-coding が受け入れ可能かを次の規則で検査する。

  1. "chunked" transfer-coding は常に受け入れ可能である。"trailers" というキーワードが列挙されている場合、クライアントは、自身および任意のダウンストリームクライアントに代わって、チャンクレスポンス内の trailer フィールドを受け入れる意思があることを示す。その含意は、与えられた場合、クライアントは、すべてのダウンストリームクライアントが転送されたレスポンス内の trailer フィールドを受け入れる意思があるか、またはダウンストリーム受信者に代わってレスポンスをバッファリングしようとすることのいずれかである。

     Note: HTTP/1.1 は、クライアントがレスポンス全体をバッファリングすることを保証できるようなチャンクレスポンスのサイズを制限する手段を定義しない。

  2. 検査される transfer-coding が TE フィールドに列挙された transfer-coding の 1 つである場合、それは、qvalue 0 を伴っていない限り受け入れ可能である。（3.9 節で定義されているように、qvalue 0 は「受け入れ不可能」を意味する。）

  3. 複数の transfer-coding が受け入れ可能な場合、0 でない qvalue の中で最も高い qvalue を持つ受け入れ可能な transfer-coding が優先される。"chunked" transfer-coding の qvalue は常に 1 である。

TE フィールド値が空であるか、TE フィールドが存在しない場合、唯一の transfer-coding は "chunked" である。transfer-coding を持たないメッセージは常に受け入れ可能である。

14.40 Trailer​

Trailer ジェネラルフィールド値は、チャンク transfer-coding で符号化されたメッセージの trailer 内に、与えられた一連のヘッダフィールドが存在することを示す。

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

HTTP/1.1 メッセージは、空でない trailer を持つチャンク transfer-coding を用いるメッセージに Trailer ヘッダフィールドを含めるべき (SHOULD) である。そうすることで、受信者は trailer 内にどのヘッダフィールドを期待すべきかを知ることができる。

Trailer ヘッダフィールドが存在しない場合、trailer はいかなるヘッダフィールドも含んではならない (SHOULD NOT)。"chunked" transfer-coding における trailer フィールドの使用に関する制限については 3.6.1 節を参照されたい。

Trailer ヘッダフィールドに列挙されたメッセージヘッダフィールドは、次のヘッダフィールドを含んではならない (MUST NOT)。

  . Transfer-Encoding

  . Content-Length

  . Trailer

14.41 Transfer-Encoding​

Transfer-Encoding ジェネラルヘッダフィールドは、送信者と受信者の間で安全に転送するためにメッセージボディに適用された変換の種類（ある場合）を示す。これは、transfer-coding がメッセージのプロパティであってエンティティのプロパティではないという点で、content-coding と異なる。

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

Transfer-coding は 3.6 節で定義されている。例は次のとおりである。

 Transfer-Encoding: chunked

複数の符号化がエンティティに適用された場合、transfer-coding はそれらが適用された順序で列挙されなければならない (MUST)。符号化パラメータに関する追加情報は、この仕様で定義されていない他のエンティティヘッダフィールドによって提供されてよい (MAY)。

多くの古い HTTP/1.0 アプリケーションは Transfer-Encoding ヘッダを理解しない。

14.42 Upgrade​

Upgrade ジェネラルヘッダにより、クライアントは、サーバがプロトコルを切り替えることが適切と判断した場合にサポートし、使用したい追加の通信プロトコルを指定できる。サーバは、どのプロトコル（群）に切り替えるかを示すために、101（Switching Protocols）レスポンス内で Upgrade ヘッダフィールドを使用しなければならない (MUST)。

   Upgrade        = "Upgrade" ":" 1#product

例は次のとおりである。

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

Upgrade ヘッダフィールドは、HTTP/1.1 から、互換性のない他のプロトコルへの移行のための単純なメカニズムを提供することを意図している。それは、現在のリクエストが HTTP/1.1 を用いて行われているにもかかわらず、より高いメジャーバージョン番号を持つ後のバージョンの HTTP などの別のプロトコルを使用したいというクライアントの希望を通知できるようにすることで、そうする。これは、より一般的にサポートされているプロトコルでクライアントがリクエストを開始できるようにしつつ、利用可能な場合は「より良い」プロトコル（「より良い」とは、サーバ、おそらくリクエストされているメソッドおよび/またはリソースの性質に応じて決定される）を使用したいことをサーバに示すことで、互換性のないプロトコル間の困難な移行を容易にする。

Upgrade ヘッダフィールドは、既存のトランスポート層接続上でのアプリケーション層プロトコルの切り替えにのみ適用される。Upgrade はプロトコル変更を強要するために使用できない。その受け入れと使用はサーバにとってオプションである。プロトコル変更後のアプリケーション層通信の能力と性質は、選択された新しいプロトコルに完全に依存するが、プロトコル変更後の最初の動作は、Upgrade ヘッダフィールドを含む初期の HTTP リクエストへのレスポンスでなければならない (MUST)。

Upgrade ヘッダフィールドは直ちの接続にのみ適用される。したがって、HTTP/1.1 メッセージ内に Upgrade が存在する場合は常に、upgrade キーワードは Connection ヘッダフィールド（14.10 節）内に供給されなければならない (MUST)。

Upgrade ヘッダフィールドは、異なる接続上のプロトコルへの切り替えを示すために使用できない。その目的には、301、302、303、または 305 リダイレクトレスポンスを使用する方が適切である。

この仕様は、3.1 節の HTTP バージョン規則およびこの仕様の将来の更新によって定義されるハイパーテキスト転送プロトコル群により使用されるための "HTTP" というプロトコル名のみを定義する。いかなるトークンもプロトコル名として使用できる。しかし、クライアントとサーバの両方がその名前を同じプロトコルに関連付けている場合にのみ有用である。

14.43 User-Agent​

User-Agent リクエストヘッダフィールドは、リクエストを発行したユーザエージェントに関する情報を含む。これは、統計の目的、プロトコル違反の追跡、および特定のユーザエージェントの制限を回避するためのレスポンスの調整のためのユーザエージェントの自動認識のためにある。ユーザエージェントはリクエストにこのフィールドを含めるべき (SHOULD) である。フィールドは、エージェントおよびユーザエージェントの重要な部分を形成する任意のサブプロダクトを識別する複数のプロダクトトークン（3.8 節）およびコメントを含んでもよい (MAY)。慣例により、プロダクトトークンはアプリケーションの識別に対する重要性の順に列挙される。

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

例：

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

14.44 Vary​

Vary フィールド値は、レスポンスが新鲜である間、キャッシュが再検証なしに後続のリクエストに応答するためにそのレスポンスを使用することが許可されるかどうかを完全に決定するリクエストヘッダフィールドの集合を示す。キャッシュ不可または古いレスポンスに対しては、Vary フィールド値は、表現を選択するために使用された基準についてユーザエージェントに助言する。値 "*" の Vary フィールドは、キャッシュが、このレスポンスが適切な表現であるかどうかを後続のリクエストのリクエストヘッダから決定できないことを意味する。キャッシュによる Vary ヘッダフィールドの使用については 13.6 節を参照されたい。

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

HTTP/1.1 サーバは、サーバ主導ネゴシエーションの対象となるキャッシュ可能なレスポンスに Vary ヘッダフィールドを含めるべき (SHOULD) である。そうすることで、キャッシュはそのリソースに対する将来のリクエストを適切に解釈でき、ユーザエージェントにそのリソース上のネゴシエーションの存在について通知できる。

フィールド名のリストから成る Vary フィールド値は、レスポンスに対して選択された表現が、最も適切な表現を選択する際に列挙されたリクエストヘッダフィールド値のみを考慮する選択アルゴリズムに基づくことを示す。キャッシュは、レスポンスが新鲜である期間、列挙されたフィールド名に対して同じ値を持つ将来のリクエストに対して同じ選択が行われると仮定してよい (MAY)。

与えられたフィールド名は、この仕様で定義された標準リクエストヘッダフィールドの集合に限定されない。フィールド名は大文字小文字を区別しない。

値 "" の Vary フィールド値は、リクエストヘッダ（たとえばクライアントのネットワークアドレス）に限定されない不特定のパラメータが、レスポンス表現の選択に関与することを示す。"" 値はプロキシサーバによって生成されてはならない (MUST NOT)。オリジンサーバによってのみ生成されてよい (MAY)。

14.45 Via​

Via ジェネラルヘッダフィールドは、リクエストにおいてはユーザエージェントとサーバの間、レスポンスにおいてはオリジンサーバとクライアントの間の、中間プロトコルおよび受信者を示すために、ゲートウェイおよびプロキシによって使用されなければならない (MUST)。これは 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

received-protocol は、リクエスト/レスポンスチェーンの各セグメントに沿ってサーバまたはクライアントが受信したメッセージのプロトコルバージョンを示す。received-protocol バージョンは、メッセージが転送される際に Via フィールド値に付加され、アップストリームアプリケーションのプロトコル能力に関する情報がすべての受信者に可視のままになる。

protocol-name は、それが "HTTP" である場合にのみオプションである。received-by フィールドは、通常、メッセージをその後転送した受信者サーバまたはクライアントのホストおよびオプションのポート番号である。しかし、実際のホストが機密情報とみなされる場合、それは仮名 (pseudonym) に置き換えられてよい (MAY)。ポートが与えられない場合、それは received-protocol のデフォルトポートとみなされてよい (MAY)。

複数の Via フィールド値は、メッセージを転送した各プロキシまたはゲートウェイを表す。各受信者は、結果が転送アプリケーションの順序に従って並ぶように、その情報を付加しなければならない (MUST)。

Via ヘッダフィールド内のコメントは、User-Agent および Server ヘッダフィールドと同様に、受信者プロキシまたはゲートウェイのソフトウェアを識別するために使用されてよい (MAY)。しかし、Via フィールド内のすべてのコメントはオプションであり、メッセージを転送する前に任意の受信者によって削除されてよい (MAY)。

たとえば、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)

ネットワークファイアウォールを通過するポータルとして使用されるプロキシおよびゲートウェイは、デフォルトでは、ファイアウォール領域内のホストの名前とポートを転送すべきでない (SHOULD NOT)。この情報は、明示的に有効にされた場合にのみ伝播されるべき (SHOULD) である。有効にされていない場合、ファイアウォールの背後にあるいかなるホストの received-by ホストも、そのホストの適切な仮名に置き換えられるべき (SHOULD) である。

内部構造を隠すという強いプライバシー要件を持つ組織の場合、プロキシは、同一の received-protocol 値を持つ Via ヘッダフィールドエントリの順序付き部分列を、単一のそのようなエントリに結合してよい (MAY)。たとえば、

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

    は次のように折りたたまれてよい。

   Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

アプリケーションは、それらがすべて同一の組織管理下にあり、かつホストがすでに仮名に置き換えられている場合を除き、複数のエントリを結合してはならない (SHOULD NOT)。アプリケーションは、異なる received-protocol 値を持つエントリを結合してはならない (MUST NOT)。

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
                   ; the name or pseudonym of the server adding
                   ; the Warning header, for use in debugging
   warn-text  = quoted-string
   warn-date  = `<">` HTTP-date `<">`

レスポンスは複数の Warning ヘッダを運んでもよい (MAY)。

warn-text は、レスポンスを受信する人間ユーザにとって最も理解しやすい可能性が高い自然言語および文字セットであるべき (SHOULD) である。この決定は、キャッシュまたはユーザの場所、リクエスト内の Accept-Language フィールド、レスポンス内の Content-Language フィールドなど、いかなる利用可能な知識に基づいてもよい (MAY)。デフォルト言語は英語であり、デフォルト文字セットは ISO-8859-1 である。

ISO-8859-1 以外の文字セットが使用される場合、RFC 2047 [14] で説明された方法を用いて warn-text 内で符号化されなければならない (MUST)。

Warning ヘッダは一般にいかなるメッセージにも適用できるが、一部の特定の warn-code はキャッシュに特有であり、レスポンスメッセージにのみ適用できる。新しい Warning ヘッダは、既存の Warning ヘッダの後に追加されるべき (SHOULD) である。キャッシュは、メッセージと共に受信した Warning ヘッダを削除してはならない (MUST NOT)。しかし、キャッシュがキャッシュエントリの検証に成功した場合、特定の Warning コードに対して指定されている場合を除き、そのエントリに以前付加された Warning ヘッダを削除すべき (SHOULD) である。その後、検証レスポンスで受信した Warning ヘッダを追加しなければならない (MUST)。言い換えれば、Warning ヘッダは、最も最近の関連するレスポンスに付加されるものである。

複数の Warning ヘッダがレスポンスに付加されている場合、ユーザエージェントは、それらがレスポンスに現れる順序で、できる限り多くのそれらをユーザに通知するよう心掛けるべき (ought to) である。すべての警告をユーザに通知できない場合、ユーザエージェントは次のヒューリスティクスに従うべき (SHOULD) である。

  - レスポンスの早い段階に現れる警告は、後に現れる警告よりも優先される。

  - ユーザの優先文字セットの警告は、warn-code および warn-agent が同一の他の文字セットの警告よりも優先される。

複数の Warning ヘッダを生成するシステムは、このユーザエージェントの振る舞いを念頭に置いてそれらを順序付けるべき (SHOULD) である。

Warning に対するキャッシュの振る舞いの要件は 13.1.2 節に記されている。

これは現在定義されている warn-code のリストであり、それぞれに英語での推奨 warn-text とその意味の説明が付されている。

110 Response is stale 返されたレスポンスが古い場合は常に含まれなければならない (MUST)。

111 Revalidation failed サーバに到達できないためにレスポンスの再検証の試みが失敗した結果として、キャッシュが古いレスポンスを返す場合に含まれなければならない (MUST)。

112 Disconnected operation キャッシュが意図的に一定期間ネットワークの残りから切断されている場合に含まれるべき (SHOULD) である。

113 Heuristic expiration キャッシュがヒューリスティックに 24 時間より長い新鲜さの寿命を選択し、かつレスポンスの年齢が 24 時間より大きい場合に含まれなければならない (MUST)。

199 Miscellaneous warning 警告テキストは、人間ユーザに提示される、またはログに記録されるいかなる任意の情報を含んでもよい (MAY)。この警告を受信したシステムは、警告をユーザに提示すること以外に、いかなる自動的な動作も行ってはならない (MUST NOT)。

214 Transformation applied レスポンスの content-coding（Content-Encoding ヘッダで指定される）または media-type（Content-Type ヘッダで指定される）、あるいはレスポンスのエンティティボディを変更するいかなる変換を適用する場合、この Warning コードがレスポンスにすでに現れていない限り、中間キャッシュまたはプロキシによって追加されなければならない (MUST)。

299 Miscellaneous persistent warning 警告テキストは、人間ユーザに提示される、またはログに記録されるいかなる任意の情報を含んでもよい (MAY)。この警告を受信したシステムは、いかなる自動的な動作も行ってはならない (MUST NOT)。

実装が、バージョンが HTTP/1.0 以下である 1 つ以上の Warning ヘッダを持つメッセージを送信する場合、送信者は各 warning-value に、レスポンス内の日付と一致する warn-date を含めなければならない (MUST)。

実装が、warn-date を含む warning-value を持つメッセージを受信し、その warn-date がレスポンス内の Date 値と異なる場合、その warning-value は、格納、転送、または使用する前にメッセージから削除されなければならない (MUST)。（これは、Warning ヘッダフィールドの素朴なキャッシュの悪影響を防ぐ。）

14.47 WWW-Authenticate​

WWW-Authenticate レスポンスヘッダフィールドは、401（Unauthorized）レスポンスメッセージに含まれなければならない (MUST)。フィールド値は、Request-URI に適用可能な認証スキーム（群）およびパラメータを示す少なくとも 1 つのチャレンジから成る。

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

HTTP アクセス認証プロセスは "HTTP Authentication: Basic and Digest Access Authentication" [43] で説明されている。ユーザエージェントは、WWW-Authenticate フィールド値の解析において特別な注意を払うことが推奨される。なぜなら、それは複数のチャレンジを含むかもしれず、また複数の WWW-Authenticate ヘッダフィールドが提供される場合、チャレンジ自身の内容が認証パラメータのカンマ区切りリストを含むかもしれないからである。

に最終更新