標準仕様書(TS)   　　　　　　　　　 TS X 0085:2004

序文

この標準仕様書(TS)は，1997年1月にInternet Engineering Task Force (IETF)から公表された Hypertext Transfer Protocol HTTP/1.1 (RFC 2068)を翻訳し，技術的内容を変更することなく作成した標準 仕様書(TS)である。

0. 適用範囲

この標準仕様書(TS)は，分散協調ハイパメディア情報システムのためのアプリケーションレベルプロトコルであるハイパテキスト転送プロトコル(Hypertext Transfer Protocol，HTTP)を規定する。それは，要求メソッドの拡張によって，名前サーバ及び分散オブジェクト管理システムといった多くの作業に利用できる，共通的な状態のないオブジェクト指向プロトコルとする。HTTPの特徴は，データ表現の型付け及び折衝であって，それが，転送されるデータとは独立にシステムを構築可能にする。

HTTPは，WWW大域情報イニシアティブ(World-Wide Web global information initiative)によって，1990年から利用されてきた。この標準 仕様書(TS)は，HTTP/1.1と呼ばれるプロトコルを規定する。

1. 導入

1.1 目的

ハイパテキスト転送プロトコル(HTTP)は，分散協調ハイパメディア情報システムのためのアプリケーションレベルプロトコルであって，ウェブ大域情報イニシアティブ(World-Wide Web global information initiative)によって，1990年から利用されてきた。HTTP/0.9と呼ばれるHTTPの最初の版は，インターネット上の生データ転送のための簡単なプロトコルであった。 RFC 1945 [6]が規定するHTTP/1.0は，そのプロトコルを改良して，メッセージをMIMEに類似したメッセージのフォーマットにすることを可能にし，転送されたデータに関するメタ情報を含め，要求及び応答のセマンティクスの修飾子を含めた。しかし，HTTP/1.0は，階層プロキシ，キャッシュ化，永続的コネクションの必要性，及び仮想ホストの効果を充分に考慮していない。しかも，"HTTP/1.0"と称する不完全に実装されたアプリケーションの急増は，二つの通信アプリケーションが互いの真の能力を決定するために，プロトコルの版変更を必要とした。

この標準仕様書(TS)は，HTTP/1.1と呼ぶプロトコルを規定する。このプロトコルは，その機能をもつ信頼性のある実装を確実なものとするために，HTTP/1.0よりも厳密な要件を含む。

実際の情報システムは，探索，フロントエンド更新，及び注記を含む, 簡単な検索よりも多くの機能を必要とする。HTTPは，ある要求の目的を示すメソッドの拡張可能な集合を許容する。それは，メソッドが適用される資源を表すために，位置(URL) [4]又は名前(URN)として，統一資源識別子(URI) [3][20]が提供する参照の規律を基礎とする。メッセージは，多目的インターネットメール拡張(MIME)が定義するとおりの，インターネットメールが用いるフォーマットに類似するフォーマットで渡される。

HTTPは，利用者エージェントと，(SMTP [16]，NNTP [13]，FTP [18], Gopher [2]，及びWAIS [10]のプロトコルによってサポートされるものを含む)他のインターネットシステムに対するプロキシ及びゲートウェイとの間の通信のための共通プロトコルとしても利用される。このようにHTTPは，多様なアプリケーションから利用可能な資源への基本的なハイパメディアアクセスを可能にする。

1.2 要件

この規定は，それぞれの特定な要件の重要性を定義するために，RFC 1123 [8]と同じ用語遣いを用いる。それを次に示す。

…(し)なければならない，…する (MUST)

この用語遣い又は形容詞の"必須の(required)"は，その項目が規定の絶対的な要件であることを意味する。

…することが望ましい，…するのがよい (SHOULD)

この用語遣い又は形容詞の"推奨の(recommended)"は，特定環境ではこの項目を無視する妥当な理由があり得ることを意味する。しかし，完全な実装は，対応済みであることが望ましく，別のやり方を選択する前に慎重に考慮されることが望ましい。

…(し)てもよい，…差し支えない (MAY)

この用語遣い又は形容詞の"オプションの(optional)"は，この項目が真に任意選択可能であることを意味する。例えば，あるベンダは，特定の業界がそれを必要とするので，又はそれがその製品を高めるので，その項目を含むことを選択してよい。他のベンダは，同じ項目を省いてもよい。

実装されたプロトコルに関する一つ以上の必須要件を満たすことに失敗した場合，その実装は非適合とする。プロトコルに関するすべての必須要件及び推奨要件を満たす実装は，"無条件適合"であるという。プロトコルに関するすべての必須要件を満たすが，必ずしもすべての推奨要件を満たさない実装は，"条件付き適合"であるという。

1.3 定義

この規定は，HTTP通信の参加者及びHTTP通信のオブジェクトが行う役割を参照するために多くの用語を使用する。

コネクション(connection)

通信のために二つのプログラムの間に確立されるトランスポート層の仮想回線。

メッセージ(message)

HTTP通信の基本単位。4.に定義する構文に一致し，コネクションを介して伝送される構造化オクテット列から成る。

要求(request)

5.に定義するHTTP要求メッセージ。

応答(response)

6.に定義するHTTP応答メッセージ。

資源(resource)

URIによって識別できるネットワークデータのオブジェクト又はサービスであって，3.2に定義する。資源は，幾つもの表現(例えば，幾つもの言語，データフォーマット，サイズ，解像度など)で利用できてよく，又は他の方法で変形できてもよい。

実体(entity)

要求又は応答のペイロードとして運ばれる情報。実体は, 7.に示すとおり，実体ヘッダ(entity-header)フィールドの形式でのメタ情報，及び実体本体(entity-body)の形式での内容から成る。

表現(representation)

内容折衝に従う応答と共に含まれる実体であって，12.に示される。特定の応答状態と関連する幾つもの表現が存在してよい。

内容折衝(content negotiation)

12.に示すとおり，要求をサービスする際に，適切な表現を選別する機構。(エラー応答を含む)どんな応答における実体の表現も，折衝できる。

変形(variant)

資源は，与えられたどんな瞬間においても，それと関連する一つ又は複数の表現をもってよい。これらの表現のそれぞれは，'変形'と呼ばれる。'変形'という用語の使用は，必ずしも，資源が内容折衝に従うことを意味しない。

クライアント(client)

要求を送るためにコネクションを確立するプログラム。

利用者エージェント(user agent)

要求を開始するクライアント。これらは，ブラウザ，編集装置，スパイダ(ウェブ辿りロボット)，又は他の末端利用者ツールであることが多い。

サーバ(server)

応答を返送することによって要求にサービスするために，コネクションを受諾するアプリケーションプログラム。与えられたどんなプログラムも，クライアント及びサーバのどちらにもなり得る。これらの用語の利用は，一般的にプログラムの機能を参照するのではなく，特定なコネクションに関してプログラムが実行している役割だけを参照する。同様に，どんなサーバも，各要求の性質に基づく振る舞いを切り替えて，原サーバ、プロキシ，ゲートウェイ又はトンネルとして動作してよい。

原サーバ(origin server)

与えられた資源が存在しているか，又は生成される予定であるサーバ。

プロキシ(proxy)

他のクライアントのために要求を生成することを目的として，サーバ及びクライアントの両方として動作する仲介プログラム。要求は，内部的に，又はその要求を可能な翻訳を伴って他のサーバに受け渡すことによって，サービスされる。プロキシは，この規定に示すクライアント及びサーバの両方の要求を実装しなければならない。

ゲートウェイ(gateway)

他のサーバへの仲介として動作するサーバ。プロキシと異なり，ゲートウェイは，それが，要求された資源に関する原サーバであるかのように，要求を受信する。要求するクライアントは，それがゲートウェイと通信していることを知らなくてよい。

トンネル(tunnel)

二つのコネクションの間で意識しない中継として動作する仲介プログラム。トンネルは，HTTP要求によっ起動されてもよいが，ひとたび活性化すると，HTTP通信に参加するものとしては扱われない。中継されたコネクションの両端が閉じるとき，トンネルはその存在を停止する。

キャッシュ(cache)

応答メッセージのプログラム局所記憶，並びにそのメッセージの記憶，検索及び削除を制御するサブシステム。キャッシュは，将来の等価な要求に関する応答時間及びネットワーク帯域幅消費を削減するために，キャッシュ可能な応答を記憶する。トンネルとして動作しているサーバはキャッシュを使用できないが，どんなクライアント又はサーバも，キャッシュを含んでよい。

キャッシュ可能な(cachable)

キャッシュが，後続の要求に応える際に使うために，応答メッセージのコピーを記憶することを許可される場合に，応答は，キャッシュ可能とする。HTTP応答のキャッシュ可能性を決定する規則は,13.に定義する。たとえ応答がキャッシュ可能であっても，キャッシュが特定の要求についてキャッシュしたコピーを使用できるかどうかに関する付加的な制約が存在してもよい。

直接(first-hand)

応答が，一つ以上のプロキシは経由するかもしれないが，原サーバから直に不必要な遅延なしに到達する場合，応答は，直接とする。応答は，その有効性が原サーバで直にチェックされたばかりであっても，直接とする。

明示的な有効期限(explicit expiration time)

原サーバが，それ以上の有効性検証なしに，キャッシュはもはや実体を返さないほうがよい，と意図する時間。

発見的な有効期限(heuristic expiration time)

明示的な有効期限が利用可能ではない場合に，キャッシュによって割り当てられる有効期限。

経過時間(age)

応答の経過時間は，応答が，原サーバによって送られてからの時間，又は原サーバにによる有効性検証に成功してからの時間とする。

新鮮保持期間(freshness lifetime)

応答の生成とその有効期限との間の時間。

新鮮な(fresh)

応答の経過時間がまだその新鮮保持期間を超えていない場合，応答は，新鮮とする。

新鮮でない(stale)

応答の経過時間がその新鮮保持期間を超えた場合，応答は，新鮮でないとする。

意味的に透過な(semantically transparent)

キャッシュは，その使用が，性能向上以外に，要求側クライアントにも原サーバにも影響を与えない場合，特定な応答に関しては"意味的に透過な"方法で振る舞う。キャッシュが意味的に透過である場合，クライアントは，その要求が原サーバによって直に扱われた場合にクライアントが受け取ったものと(hop-by-hopヘッダを除き)ちょうど同じ応答を受け取る。

有効性検証子(validator)

キャッシュのエントリが実体の等価なコピーであるかどうかを見つけるために用いるプロトコル要素。例えば，実体タグ又はLast-Modified(最終修正)時間など。

1.4 動作概要

HTTPプロトコルは，要求及び応答のプロトコルとする。クライアントは，要求メソッド，URI及びプロトコル版，さらにそれらに，要求修飾子，クライアント情報，及びサーバとのコネクションの上で可能な本体内容を含むMIMEに似たメッセージを続けた形式でサーバに要求を送信する。サーバは，メッセージのプロトコル版，及び成功又はエラーのコードを含む状態行を用い，さらにそれに，サーバ情報，実体メタ情報，及び可能な実体本体内容を含むMIMEに似たメッセージが続けて，応答する。HTTPとMIMEとの関係は, 19.4に示す。

大部分のHTTP通信は，利用者エージェントによって開始され，原サーバの資源に適用される要求から成る。最も単純な場合，これは，利用者エージェント(UA)と原サーバ(O)との間の単一のコネクション(v)によって達成できる。

             要求連鎖 ------------------------>
          UA -------------------v------------------- O
             <----------------------- 応答連鎖

要求連鎖及び応答連鎖に一つ以上の仲介が存在する場合，もっと複雑な状況が生じる。仲介には，三つの共通的な形式，すなわち，プロキシ，ゲートウェイ及びトンネルがある。プロキシは, 回送エージェントであって，絶対形式でのURIへの要求を受信し，メッセージの全部又は一部を書き直し，URIが識別するサーバに向けて再フォーマットされた要求を回送する。ゲートウェイは，受信エージェントであって，他のサーバ上のある一つの階層として動作し，必要に応じて, 下位のサーバプロトコルへの要求を翻訳する。トンネルは，メッセージを変えることなしに，二つのコネクション間の中継点として動作する。トンネルは，通信が(ファイアウォールなどの)仲介を通過する必要があるときに，仲介がメッセージの内容を理解できなくとも，用いられる。

             要求連鎖 -------------------------------------->
          UA -----v----- A -----v----- B -----v----- C -----v----- O
             <------------------------------------- 応答連鎖

この図は，利用者エージェント及び原サーバの間の三つの仲介(A，B及びC)を示す。連鎖全体を伝わる要求メッセージ及び応答メッセージは，四つの分離したコネクションを通過する。HTTPコネクションのオプションには，直近の非トンネルの隣接だけに適用されたり，連鎖の端点だけに適用されたり，連鎖をわたる全コネクションに適用されたりするものがあるので，この区別は重要となる。図は直線的であるが，各参加者は，複数の同時的な通信に関与してもよい。例えば，Bは，Aの要求を扱うと同時に，A以外の多くのクライアントから要求を受信していてもよいし，C以外のサーバに要求を回送してもよい。

通信へのトンネルとして動作していないいかなる参加者も，要求を扱うために内部キャッシュを用いてよい。キャッシュは次の効果をもつ。すなわち，連鎖への参加者の一つが要求に適用できるキャッシュされた応答をもつ場合，要求連鎖及び応答連鎖が短縮される。Bが，UA又はAによってキャッシュされなかった要求に関して, Oから(Cを介して)の以前の応答のキャッシュされたコピーをもつ場合に生じる連鎖を次に図示する。

                 要求連鎖 ---------->
          UA -----v----- A -----v----- B - - - - - - C - - - - - - O
             <--------- 応答連鎖

すべての応答が，都合よくキャッシュ可能であるわけではない。キャッシュの振る舞いに特別な要件をおく修飾子を含む要求があってもよい。キャッシュの振る舞い及びキャッシュ可能な応答に関するHTTP要件は，13.に定義する。

実際，現在，ウェブを用いて実験されたり，ウェブ上に配備されたりしているキャッシュ及びプロキシにはさまざまな体系及び構成がある。これらのシステムは，海底ケーブルの帯域幅を節減するプロキシキャッシュの国レベルの階層，キャッシュされたエントリを同報通信又は多重通信するシステム，キャッシュされたデータのサブセットをCD-ROMによって配布する組織などを含む。 HTTPシステムは，広帯域幅リンク上での社内イントラネットにおいて利用され，低電力無線リンク及び断続的な接続性を用いてPDAを介してアクセスするために利用される。HTTP/1.1は，高い信頼性を，それがだめな場合には，少なくとも失敗の信頼できる表示を必要とするウェブアプリケーションを構築する者の要求を満たすプロトコル構成要素を導入しながら，既に配備されている構成の大きな多様性をサポートすることを目標とする。

HTTPの通信は，通常，TCP/IPのコネクションの上で行われる。デフォルトのポートは，TCP 80とするが，他のポートも利用できる。これは，HTTPが，インターネット上の他のどのようなプロトコルの上でも，又は他のネットワーク上でも，実装されることを妨げるものではない。HTTPは，信頼できるトランスポートだけを仮定する。それを保証するどんなプロトコルも利用できる。HTTP/1.1の要求構造及び応答構造を着目するプロトコルのトランスポートデータ単位へ対応付けることは，この規定の適用範囲外とする。

HTTP/1.0においては，ほとんどの実装は，要求及び応答の交換ごとに新しいコネクションを用いていた。HTTP/1.1においては，コネクションはいろいろな理由で閉じられてもよい(8.1を参照)が，一つのコネクションを1回以上の要求及び応答の交換に対して使ってもよい。

2. 記法の規約及び共通文法

2.1 強化BNF

この標準仕様書(TS)で規定するすべての機構は，通常の(自然言語による)記述及び強化BNF(BNFは，Backus-Naur Form，バッカスナウア記法のこと。)の両方で記述される。強化BNFは，RFC 822 [9]が用いるものに類似している。実装者は，この規定を理解するためには，その記法に習熟している必要がある。強化BNFは，次の構成子を含む。

name = definition

規則の名前(name)は，単に(囲み"<"及び">"をもたない)名前それ自体とし，その定義(definition)とは等号文字"="によって分離される。空白は，連続行の字下げが複数行にわたる規則定義を表すために使われる場合だけに意味がある。SP，LWS，HT，CRLF，DIGIT，ALPHAなどの基本規則は，大文字で表す。山括弧("<"及び">")は，それが規則名の使用を分かりやすくするときに定義の中で使われる。

"literal"

リテラル(literal)テキストは，引用符によって囲まれる。特記しない限り，テキストは大文字・小文字を区別しない。

rule1 | rule2

縦線("|")によって分離された要素は，代替選択肢とする。例えば，"yes | no"は，yes又はnoを受諾する。

(rule1 rule2)

括弧で囲まれた要素は，単一の要素として扱う。したがって，"(elem (foo | bar) elem)" は，トークン列，"elem foo elem"及び"elem bar elem"を許容する。

*rule

要素の前の文字"*"は，繰返しを表す。省略のない形式は"<n>*<m>element"であって，最小<n>個及び最大<m>個の要素(element)の出現を表す。デフォルト値は，0及び無限大とするので，"*(element)"は，0を含む任意の個数を許容する。"1*element"は，少なくとも1個は必要とし，"1*2element"は, 1個又は2個を許容する。

[rule]

オプション要素は，角括弧によって囲まれる。"[foo bar]"は，"*1(foo bar)"と等価とする。

N rule

特定の繰返しを表す。"<n>(element)"は，"<n>*<n>(element)"と等価とする。つまり，厳密に<n>個の(element)の出現とする。したがって，2DIGITは，2桁の数とし，3ALPHAは，三つのアルファベット文字の文字列とする。

#rule

構成子"#"は，"*"と似たように定義され，要素のリストを与える。省略のない形式は"<n>#<m>element"であって，各々が1個以上のコンマ(",")及びオプションである連続する空白(linear whitespace, LWS)によって分離された，最小<n>個及び最大<m>個の要素(element)を表す。これは，リストの通常の形式を極めて容易にする。"( *LWS element *( *LWS "," *LWS element ))"などの規則は，"1#element"として示される。 この構成子が使われるところでは，ヌル要素は，許容されるが，存在する要素の数には入らない。つまり，"(element), , (element)"は許容されるが，二つの要素だけとして数えられる。したがって，少なくとも一つの要素が必要なところでは，少なくとも一つの非ヌル要素が存在しなければならない。デフォルト値は，0及び無限大とするので，"#(element)"は，0を含む任意の個数を許容する。"1#element"は，少なくとも1個は必要とし，"1#2element"は，1個又は2個を許容する。

; comment

規則テキストの右に，ある距離を隔てて置かれた一つのセミコロンは，注釈(comment)を開始し，それは行末まで続く。これは，有用な備考を規定に並んで含める簡単な方法を与える。

implied *LWS

この規定によって記述される文法は，語に基づく。特記する場合を除き, 連続する空白(linear whitespace, LWS)は，どのような二つの隣接する語(トークン又は引用文字列)の間，並びに隣接するトークン及び区切り子(tspecials)の間にも，フィールドの解釈を変更することなく，含まれることができる。少なくとも一つの区切り子(tspecials)が，どのような二つのトークンの間にも存在しなければならない。それは，そうでない場合には，二つのトークンが単一のトークンとして解釈されるてしまうことによる。

2.2 基本規則

参考　この規定における逆スラッシュ文字は，日本語環境では，しばしば"円記号(\)"として表示されることがある点に注意すること。

次の規則は，この標準仕様書(TS)の中で基本構文解析構成子を記述するために使用する。US-ASCII符号化文字集合は，ANSI X3.4-1986 [21]によって定義される。

          OCTET          = <データの任意の8ビット列>
          CHAR           = <任意のUS-ASCII文字(オクテット 0 - 127)>
          UPALPHA        = <任意のUS-ASCIIの大文字の字 "A".."Z">
          LOALPHA        = <任意のUS-ASCIIの小文字の字 "a".."z">
          ALPHA          = UPALPHA | LOALPHA
          DIGIT          = <任意のUS-ASCIIの数字 "0".."9">
          CTL            = <任意のUS-ASCIIの制御文字
                           (オクテット 0 - 31) 及び DEL (127)>
          CR             = <US-ASCII CR，復帰 (13)>
          LF             = <US-ASCII LF，改行 (10)>
          SP             = <US-ASCII SP，スペース (32)>
          HT             = <US-ASCII HT，水平タブ (9)>
          <">            = <US-ASCII 2重引用符 (34)>

HTTP/1.1は，entity-bodyを除くすべてのプロトコル要素のための行末マーカとして，文字列CR LFを定義する(耐障害アプリケーションについては19.3参照)。entity-body内での行末マーカは，3.7に示すとおり，その関連するメディア型によって定義される。

          CRLF           = CR LF

HTTP/1.1ヘッダが複数行に折返し可能なのは，その連続する行がスペース又は水平タブで始まる場合とする。折返しを含むすべての連続する空白は，SPと同じセマンティクスをもつ。

          LWS            = [CRLF] 1*( SP | HT )

TEXT規則は，メッセージパーサによって解釈されることを意図しない記述としてのフィールドの内容及び値だけに用いる。*TEXTの語は，RFC 1522の規則に従って符号化される場合だけは，ISO 8859-1 [22]以外の文字集合の文字を含んでよい。

          TEXT           = <任意のOCTET，ただし，CTLは除きLWSは含む。>

          HEX            = "A" | "B" | "C" | "D" | "E" | "F"
                         | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT

多くのHTTP/1.1ヘッダフィールド値は，LWS又は特殊文字によって分離された語から成る。これらの特殊文字は，パラメタ値内で使われるためには引用文字列で表さなければならない。

          token          = 1*<CTL又はtspecials以外の任意のCHAR>

          tspecials      = "(" | ")" | "<" | ">" | "@"
                         | "," | ";" | ":" | "\" | <">
                         | "/" | "[" | "]" | "?" | "="
                         | "{" | "}" | SP | HT

注釈は，注釈テキストを括弧で囲むことによって，幾つかのHTTPヘッダフィールドの中に含めることができる。注釈は，フィールド値定義の部分として"comment"を含むフィールドの中だけに許可される。他のすべてのフィールドにおいては，括弧は，フィールド値の部分と考える。

          comment        = "(" *( ctext | comment ) ")"
          ctext          = <"("及び")"を除く任意のTEXT>

テキストの列は，それが2重引用符を用いて引用される場合，単一の語として構文解析される。

          quoted-string  = ( <"> *(qdtext) <"> )

          qdtext         = <<">以外の任意のTEXT>

逆スラッシュ文字("\")は，引用文字列及び注釈構成子の中だけで単一文字の引用機構として用いてよい。

          quoted-pair    = "\" CHAR

3. プロトコルパラメタ

3.1 HTTPの版

HTTPは，プロトコルの版を示すために"<major>.<minor>"(主版番号．副版番号)という番号付け方式を用いる。プロトコル版付け方針は，送り手が，メッセージのフォーマットと，通信を通して得られる機能以上のHTTP通信を理解するための能力とを示すのが可能になることを意図している。通信の振る舞いに影響を与えない，又は拡張フィールド値への追加だけを行うメッセージ要素の追加については，版番号に変更は行われない。<minor>番号は，一般的なメッセージ構文解析アルゴリズムを変えないが，メッセージのセマンティクスに追加を行い，送り手の追加能力を暗示してもよいプロトコルの追加機能に変更があるときに，増加する。<major>番号は，プロトコル内のメッセージのフォーマットが変わるときに，増加する。

HTTPメッセージの版は，メッセージの最初の行のHTTP-Versionフィールドによって示される。

          HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT

主版番号及び副版番号は, 別々の整数として扱われなければならず，それぞれは，1桁よりも大きく増加してもよいことに注意すること。したがって，HTTP/2.4はHTTP/2.13より前の版であって，さらにHTTP/2.13はHTTP/12.3よりも前の版になる。先行するゼロは，受け手によって無視されなければならず，送られてはならない。

この規定が定義するとおりに，要求及び応答のメッセージを送るアプリケーションは，"HTTP/1.1"のHTTP-Versionを含まなければならない。この版番号の使用は，送信アプリケーションがこの規定に少なくとも条件付き適合することを示す。

アプリケーションのHTTP版は，そのアプリケーションが少なくとも条件付き適合する最大のHTTP版とする。

プロキシ及びゲートウェイのアプリケーションは，アプリケーションのプロトコル版と異なるプロトコル版でメッセージを回送する場合，注意しなければならない。プロトコル版は，送り手のプロトコル能力を示すので，プロキシ及びゲートウェイは，その実際の版よりも大きい版表示子をもつメッセージを送ってはならない。より後の版の要求が受信される場合，プロキシ及びゲートウェイは，要求の版を格下げするか，エラーで応答するか，又はトンネルの振る舞いに切り替えるかのいずれかをしなければならない。プロキシ及びゲートウェイの版のそれより前の版をもつ要求は，回送される前に格上げされてもよい。その要求に対するプロキシ及びゲートウェイの応答は，要求と同じ主版でなければならない。

備考　HTTPの版の間の変換は，変換対象のその版によって要求される又は禁止されるヘッダフィールドの修正を行ってもよい。

3.2 統一資源識別子

URIは，多くの名前, WWWアドレス(WWW address)，普遍文書識別子(Universal Document Identifier)，普遍資源識別子(Universal Resource Identifiers)，最終的には，統一資源位置指定子(Uniform Resource Locator，URL)及び統一資源名(Uniform Resource Name，URN)の組合せによって，知られてきた。HTTPに関する限り，統一資源識別子(Uniform Resource Identifier)は，名前, 位置又は他の特質によって資源を識別する，簡潔にフォーマット化された文字列とする。

3.2.1 一般構文

HTTPにおけるURIは，URI利用の文脈に依存して，絶対形式又はある既知の基底URIに対する相対形式で表現できる。その二つの形式は，絶対形式が常にコロンが後にある方式名で始まることによって，区別される。

          URI            = ( absoluteURI | relativeURI ) [ "#" fragment ]

          absoluteURI    = scheme ":" *( uchar | reserved )

          relativeURI    = net_path | abs_path | rel_path

          net_path       = "//" net_loc [ abs_path ]
          abs_path       = "/" rel_path
          rel_path       = [ path ] [ ";" params ] [ "?" query ]

          path           = fsegment *( "/" segment )
          fsegment       = 1*pchar
          segment        = *pchar

          params         = param *( ";" param )
          param          = *( pchar | "/" )

          scheme         = 1*( ALPHA | DIGIT | "+" | "-" | "." )
          net_loc        = *( pchar | ";" | "?" )

          query          = *( uchar | reserved )
          fragment       = *( uchar | reserved )

          pchar          = uchar | ":" | "@" | "&" | "=" | "+"
          uchar          = unreserved | escape
          unreserved     = ALPHA | DIGIT | safe | extra | national

          escape         = "%" HEX HEX
          reserved       = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
          extra          = "!" | "*" | "'" | "(" | ")" | ","
          safe           = "$" | "-" | "_" | "."
          unsafe         = CTL | SP | <"> | "#" | "%" | "<" | ">"
          national       = <ALPHA，DIGIT，reserved，extra，safe，及びunsafeanyを除くOCTET>

URLの構文及び意味に関する確定的な情報については，RFC 1738 [4]及びRFC 1808 [11]を参照すること。前述のBNFは，RFC 1738が規定するとおりの有効なURLには使えないnational(国内)文字を含む。これは，HTTPサーバがアドレスのrel_path部分を表現するのに使える予約済みでない文字の集合には制限されないこと，及びHTTPプロキシはRFC 1738によって定義されないURIのための要求を受けてもよいことによる。

HTTPプロトコルでは，URIの長さには予めの制限がない。サーバは，それが扱うどんな資源のURIも処理できなければならず，長さに制約のないURIを生成できるGETに基づく形式をサーバが提供する場合には，その長さに制約のないURIを扱えることが望ましい。URIがサーバの扱えるものよりも長い場合，サーバは，414(Request-URI Too Long)状態を返すことが望ましい(10.4.15参照)。

備考　サーバは，255バイトを超えるURIの長さに応じることに注意することが望ましい。それは，古いクライアント又はプロキシの実装は，これらの長さを適切にサポートしないことがあることによる。

3.2.2 http URL

"http"方式は，HTTPプロトコルによって，ネットワーク資源を位置決めするために用いられる。3.2.2は，http URLに関するこの方式固有の構文及び意味を定義する。

          http_URL       = "http:" "//" host [ ":" port ] [ abs_path ]

          host           = <RFC 1123の2.1によって定義されるとおりの
                            文法に合ったインターネットホストドメイン名
                            又は(ドット10進形式での)IPアドレス>

          port           = *DIGIT

ポートが空であるか，与えられない場合，ポート80を仮定する。そのセマンティクスは，次のとおりとする。すなわち，識別された資源はそのホストのそのポート上でTCPコネクションを待ち受けているサーバに位置決めされ，その資源のRequest-URI(要求URI)はabs_pathとする。URLにおけるIPアドレスの使用は，可能であるときは必ず避けることが望ましい(RFC 1900 [24]参照)。abs_pathがそのURLの中に存在しない場合であって，資源のためのRequest-URIとして使われるときには，abs_pathは，"/"として与えられなければならない(5.1.2参照)。

3.2.3 URIの比較

二つのURIを比較してそれらが一致するかどうかを決定する場合，クライアントは，URI全体を大文字・小文字を区別するオクテット毎の比較を用いることが望ましい。ただし，次の例外がある。

• 空であるか又は与えられていないポートは，そのURIのためのデフォルトのポートに等価とする。
• ホスト名の比較は，大文字・小文字を区別してはならない。
• 方式名の比較は，大文字・小文字を区別してはならない。
• 空のabs_pathは，"/"のabs_pathと等価とする。

"reserved"集合及び"unsafe"集合(3.2参照)における以外の文字は，その""%" HEX HEX"符号化に等価とする。

例えば，次の三つのURIは等価とする。

         http://abc.com:80/~smith/home.html
         http://ABC.com/%7Esmith/home.html
         http://ABC.com:/%7esmith/home.html

3.3 日時フォーマット

3.3.1 省略なし日付

HTTPアプリケーションは，日時スタンプの表現のために三つの異なるフォーマットを歴史的に許容してきた。

• Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822。RFC 822は，RFC 1123によって更新された。
• Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850。RFC 850は，RFC 1036によって廃棄された。
• Sun Nov 6 08:49:37 1994 ; ANSI Cのasctime()フォーマット。

最初のフォーマットは，インターネット規定として望ましく，RFC 1123(RFC 822の更新版)によって定義される固定長の部分集合を表す。第2のフォーマットは，共通利用されているが，古いRFC 850 [12]の日付フォーマットに基づき，4桁の年をもっていない。日付の値を構文解析するHTTP/1.1のクライアント及びサーバは，ヘッダフィールドにおいてHTTP日付値を表現するためにRFC 1123フォーマットだけを生成しなければならないが，(HTTP/1.0との互換性のために)三つのフォーマットのすべてを受諾しなければならない。

備考　日付値の受け手は，日付値の受諾において強靭であることが望まれる。その日付値は，非HTTPアプリケーションによって送られた可能性もある。これは，SMTP又はNMTPへのプロキシ又はケートウェイを介して，メッセージを取得したり送付したりする場合があることによる。

すべてのHTTP日時スタンプは，例外なしにグリニッチ標準時で表現されなければならない。これは，最初の二つのフォーマットでは，タイムゾーンの3字短縮形として"GMT"を含むことによって表示され，asctimeフォーマットを読むときには仮定されなければならない。

          HTTP-date    = rfc1123-date | rfc850-date | asctime-date

          rfc1123-date = wkday "," SP date1 SP time SP "GMT"
          rfc850-date  = weekday "," SP date2 SP time SP "GMT"
          asctime-date = wkday SP date3 SP time SP 4DIGIT

          date1        = 2DIGIT SP month SP 4DIGIT
                         ; 日 月 年 (例えば，02 Jun 1982)
          date2        = 2DIGIT "-" month "-" 2DIGIT
                         ; 日-月-年 (例えば，02-Jun-82)
          date3        = month SP ( 2DIGIT | ( SP 1DIGIT ))
                         ; 月 日 (例えば，Jun  2)

          time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT
                         ; 00:00:00 - 23:59:59

          wkday        = "Mon" | "Tue" | "Wed"
                       | "Thu" | "Fri" | "Sat" | "Sun"


          weekday      = "Monday" | "Tuesday" | "Wednesday"
                       | "Thursday" | "Friday" | "Saturday" | "Sunday"

          month        = "Jan" | "Feb" | "Mar" | "Apr"
                       | "May" | "Jun" | "Jul" | "Aug"
                       | "Sep" | "Oct" | "Nov" | "Dec"

備考　日時スタンプフォーマットに関するHTTP要件は，プロトコルストリーム内でのその利用だけに適用される。クライアント及びサーバは，利用者への表示，ログ取得要求などのために，これらのフォーマットを用いることを要求されない。

3.3.2 差分秒(delta-seconds)

HTTPヘッダフィールドには，メッセージが受信された後の時間値を10進で表した秒の整数として指定できるものがある。

          delta-seconds  = 1*DIGIT

3.4 文字集合

HTTPは，MIMEのために示されるのと同じである用語"文字集合"の定義を用いる。

用語"文字集合"は，この標準仕様書(TS)では，オクテット列を文字列に変換する一つ以上の表を使う手法を参照するために用いる。他の方向(文字列をオクテット列に変換する方向)における無条件変換は要求されないことに注意すること。すなわち，必ずしもすべての文字が，与えられる文字集合で利用可能でなくともよく，一つの文字集合が，特定文字を表現するのに一つより多くのオクテット列を提供してもよい。この定義は，US-ASCIIなどの簡単な単一表対応付けから，ISO 2022の技法を用いるなどの複雑な表切替え手法に至る，さまざまな種類の文字符号化を許容することを意図している。しかし，MIME文字集合名と関連する定義は，オクテットから文字へと実行される対応付けを十分に指定しなければならない。特に，正確な対応付けを決定するために外部のプロファイル化情報を使用することは，許されない。

備考　用語"文字集合"のこの使用は，"文字符号化"として参照されることがより普通である。しかし，HTTP及びMIMEは同じレジストリを共有するので，用語も共有することが重要になる。

HTTP文字集合は，大文字・小文字を区別しないトークンによって識別される。トークンの完全な集合は，IANA文字集合レジストリ[19]によって定義される。

          charset = token

HTTPは，任意のトークンがcharset値として用いられることを許容するが，IANA文字集合レジストリ内で予め定義された値をもつどんなトークンも，そのレジストリによって定義される文字集合を表現しなければならない。アプリケーションは，文字集合のその利用をIANAレジストリによって定義される集合に制限することが望ましい。

3.5 内容符号化(content-coding)

内容符号化値は，実体に適用された又は適用できる符号化変換を示す。内容符号化は，基本的には，文書が，その基本のメディア型の同一性を失わず，情報の欠損なしに，圧縮されるか，又は別の方法で有効に変換されることを可能にするために用いられる。多くの場合，実体は，符号化された形式で記憶され，直接に伝送され，受け手だけによって復号される。

          content-coding   = token

すべての内容符号化値は，大文字・小文字を区別しない。HTTP/1.1は，Accept-Encoding(14.3参照)及びContent-Encoding(14.12参照)のヘッダフィールドにおいて，内容符号化値を用いる。その値は，内容符号化を示すが，より重要なことは，符号化を取り除くためにはどんな復号機構が必要になるかをそれが示すこととする。

インターネット割当て番号機関(Internet Assigned Numbers Authority，IANA)は，内容符号化値のトークンのための登録組織として働く。最初，そのレジストリは，次のトークンを含む。

gzip

RFC 1952 [25]に示されるとおりの，ファイル圧縮プログラム"gzip"(GNU zip)によって生成される符号化フォーマット。このフォーマットは，32ビットのCRCをもつLempel-Ziv符号化(LZ77)とする。

compress

共通のUNIXファイル圧縮プログラム"compress"によって生成される符号化フォーマット。このフォーマットは，適応Lempel-Ziv-Welch符号化(LZW)とする。

備考　符号化フォーマットの識別のためにプログラム名を使用することは，望ましくなく，将来の符号化には推奨できない。ここでのその使用は，歴史的事実を代表するのであって，良い設計ではない。HTTPの以前の実装との互換性のために，アプリケーションは，"x-gzip"及び"x-compress"をそれぞれ"gzip"及び"compress"と等価であると考えることが望ましい。

deflate

RFC 1951 [29]に示される"deflate"圧縮機構と組み合わされる，RFC 1950 [31]に定義する"zlib"フォーマット

新しい内容符号化値のトークンは，登録されることが望ましい。クライアントとサーバとの間の相互運用性を可能にするために，新しい値を実装するのに必要な内容符号化アルゴリズムの規定は，広く利用可能で独立した実装に適していることが望ましく，ここで定義される内容符号化の目的に適合する。

3.6 転送符号化(transfer-coding)

転送符号化の値は，ネットワークを通して"安全な転送"を確実にするために，実体本体に適用された，適用可能な，又は適用される必要があってもよい符号化変換を示すのに使われる。これは，転送符号化はメッセージの特性であって元の実体の特性ではないという点で，内容符号化とは異なる。

          transfer-coding         = "chunked" | transfer-extension

          transfer-extension      = token

すべての転送符号化の値は，大文字・小文字を区別しない。HTTP/1.1は，Transfer-Encodingのヘッダフィールド(14.40参照)において，転送符号化の値を用いる。

転送符号化は，MIMEのContent-Transfer-Encodingの値に類似している。Content-Transfer-Encodingの値は，7ビットトランスポートサービスの上でバイナリデータの安全な転送を可能にするために設計された。しかし，安全なトランスポートは，8ビットトランスポートプロトコルに関して異なる焦点を当てている。HTTPでは，メッセージ本体の安全でない特質だけが，厳密な本体長(7.2.2参照)を決定する際の困難となっていたり，共有トランスポート上でデータを暗号化する要望になっていたりする。

かたまり(chunked)符号化は，一連のかたまりとして転送するためにメッセージ本体を修正する。各かたまりは，それ自体の大きさの表示子をもち，その後に，実体ヘッダフィールドを含むオプションのフッタが続く。これは，動的に生成される内容が，受け手が全メッセージを受信したことを検証するために必要な情報と共に転送されることを可能にする。

       Chunked-Body   = *chunk
                        "0" CRLF
                        footer
                        CRLF

       chunk          = chunk-size [ chunk-ext ] CRLF
                        chunk-data CRLF

       hex-no-zero    = 

       chunk-size     = hex-no-zero *HEX
       chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )
       chunk-ext-name = token
       chunk-ext-val  = token | quoted-string
       chunk-data     = chunk-size(OCTET)

       footer         = *entity-header

かたまり符号化は，フッタが後にくる大きさ0のかたまりによって終了する。フッタは，空行によって終端する。フッタの目的は，動的に生成される実体に関する情報を供給する効率的な方法を提供することにある。アプリケーションは，ディジタル署名又は他の機能のためにHTTPになされるContent-MD5又は将来の拡張といった，フッタのために適切であると明示的には定義されていないヘッダフィールドをフッタの中に入れて送ってはならない。

Chunked-Bodyを復号するための処理例を，19.4.6に示す。

すべてのHTTP/1.1アプリケーションは，"chunked"転送符号化を受信し復号することができなければならず，アプリケーションが理解できない転送符号化拡張を無視しなければならない。理解できない転送符号化をもつ実体本体を受信するサーバは，501(Unimplemented)を返して，コネクションを閉じることが望ましい。サーバは，HTTP/1.0クライアントに転送符号化を送ってはならない。

3.7 メディア型(media-type)

HTTPは, 開放型で拡張可能なデータ型付け及び型折衝を与えるために，Content-Type(14.18参照)及びAccept(14.1参照)のヘッダフィールドにおいてインターネットメディア型を用いる。

          media-type     = type "/" subtype *( ";" parameter )
          type           = token
          subtype        = token

パラメタは，属性及び値の対の形式における型/下位型に従ってよい。

          parameter      = attribute "=" value
          attribute      = token
          value          = token | quoted-string

型，下位型及びパラメタ属性名は，大文字・小文字の区別しない。パラメタの値は，パラメタ名のセマンティクスに依存して，大文字・小文字を区別してもしなくてもよい。連続する空白(LWS)は，型と下位型との間に用いてはならず，属性と属性値との間にも用いてはならない。メディア型を認識する利用者エージェントは，発見された問題を利用者に通知するためにその型/下位型の定義によって記述されるとおりのそのMIME型に対するパラメタを処理(又は利用者エージェントによってその型/下位型を処理するのに使われる外部アプリケーションが処理するための準備)をしなければならない。

備考　より古いHTTPアプリケーションには，メディア型パラメタを認識しないものがある。より古いHTTPアプリケーションにデータを送る場合，実装は，メディア型パラメタがその 型/下位型 の定義によって要求されるとき，メディア型パラメタだけを使うことが望ましい。

メディア型の値は，インターネット割当て番号機関(Internet Assigned Number Authority，IANA)で登録される。メディア型の登録は，RFC 2048 [17]においてその概要が示される。登録されていないメディア型の利用は，推奨されない。

3.7.1 正準化及びテキストのデフォルト

インターネットメディア型は，正準形式で登録される。一般に，HTTPメッセージを介して転送される実体本体は，その伝送に先立って適切な正準形式で表現されなければならない。例外は，次の段落に定義する"text"型とする。

正準形式では，"text"型のメディア下位型は，テキストの行区切りにCRLFを用いる。HTTPは，この要求を緩和して，行区切りを表現するために簡潔なCR又はLFだけをもつテキストメディアの転送を, 実体本体の全体に関して首尾一貫してそれがなされる場合には，許容する。HTTPアプリケーションは，CRLF，CRだけ，及びLFだけを，HTTPを介して受け取ったテキストメディアにおける行区切りの表現として受理しなければならない。 さらに，テキストが，ある多バイト文字集合に対する場合のように，CRに対するオクテット13及びLFに対するオクテット10を用いない文字集合において表現される場合，HTTPは，行区切りに対してCR及びLFに等価なものを表現するために，その文字集合によって，どんなオクテット列が定義されてもその使用を許容する。 行区切りに関するこの柔軟性は，実体本体におけるテキストメディアだけに適用される。単なるCRだけ又はLFだけは，(ヘッダフィールド及びマルチパート境界といった)いかなるHTTP制御構造内でも，CRLFの代わりに置き換えられてはならない。

実体本体がContent-Encodingで符号化される場合，基礎となるデータは，符号化されるのに先立ち，前述の定義の形式になっていなければならない。

"charset"パラメタは， データの文字集合(3.4参照)を定義するために，幾つかのメディア型と共に用いられる。明示的なcharsetパラメタが送り手によって与えられない場合，"text"型のメディア下位型は，HTTPを介しての受信に際して，"ISO-8859-1"のデフォルトcharset値をもつと定義される。"ISO-8859-1"以外の文字集合又は"ISO-8859-1"の部分集合におけるデータは，適切なcharset値でラベル付けされなければならない。

HTTP/1.0ソフトウェアには，charsetパラメタなしのContent-Typeヘッダを，"受け手は推測することが望ましい。"を意味すると間違って解釈するものがある。この振る舞いをしないようにしたい送り手は，charsetがISO-8859-1である場合でもcharsetパラメタを含めてもよく，それが受け手を混乱させないと分かっている場合にはそうすることが望ましい。

残念ながら，より古いHTTP/1.0クライアントには，明示的なcharsetパラメタを適切に扱えないものがあった。HTTP/1.1の受け手は，送り手によって与えられるcharsetラベルを尊重しなければならない。charsetを"推測"するための規定をもつそれらの利用者エージェントは，最初に文書を表示する際に，受け手が希望するものではなくて，content-typeフィールドからのcharsetをサポートしている場合には，content-typeフィールドからのcharsetを用いなければならない。

3.7.2 マルチパート型

MIMEは，多くの"マルチパート"型，つまり単一のメッセージ本体内の一つ以上の実体のカプセル化，を提供する。すべてのマルチパート型は，MIME [7]に規定されるとおりに，共通構文を共有し，メディア型の値の一部として境界パラメタを含まなければならない。メッセージ本体は，それ自体プロトコル要素であって，したがって，本体部分の間の行区切りを表現するためには，CRLFだけを使用しなければならない。MIMEにおける場合と異なり，どのマルチパートメッセージのエピローグも空でなければならない。HTTPアプリケーションは，(たとえ元のマルチパートがエピローグを含んでいても)エピローグを伝送してはならない。

HTTPにおいては，マルチパートの本体部分は，その部分の意味にとって重要であるヘッダフィールドを含んでもよい。Content-Locationヘッダフィールド(14.15)は，URLによって識別可能な各同封実体の本体部分の中に含まれることが望ましい。

一般に，HTTP利用者は，MIME利用者エージェントがマルチパート型の受領に際して従うのと同一又は類似の振る舞いに従うことが望ましい。アプリケーションが認識しないマルチパート下位型を受信する場合，アプリケーションは，"multipart/mixed"と等価であるとして，それを扱わなければならない。

備考　"multipart/form-data"型は、RFC 1867 [15]に示されるとおり，POST要求メソッドによって処理に適するフォームデータを運ぶために特に定義された。

3.8 製品(product)トークン

製品トークンは，通信アプリケーションが，ソフトウェアの名前及び版によってそれ自体を識別するのを可能にする。製品トークンを用いる大部分のフィールドは，アプリケーションの重要な部分を形成する部分製品を空白によって分離したリストとすることも可能にする。慣例として，製品は，アプリケーションを識別するためにその重要さの順序でリストにされる。

          product         = token ["/" product-version]
          product-version = token

例を次に示す。

          User-Agent: CERN-LineMode/2.15 libwww/2.17b3
          Server: Apache/0.8.4

製品トークンは，短くて要領を得たものとすることが望ましく，宣伝のため又は他の本質的でない情報のためにそれらを使用することは，明示的に禁止される。どんなトークン文字もproduct-versionにおいて現れてよいが，このトークンは，版識別子だけのために使用されることが望ましい。(すなわち，同一製品の連続する版は，製品値のproduct-versionの部分だけで異なることが望ましい。)

3.9 品質値(qvalue)

HTTP内容折衝(12.参照)は，さまざまな折衝パラメタの相対的な重要性("重み")を示すために短い"浮動小数点"数を使う。重みは，0から1までの範囲の実数に正規化される。ここで，0が最小値，1が最大値とする。HTTP/1.1アプリケーションは，小数点の後に3桁より多くを生成してはならない。これらの値の利用者構成も，この制限を受けることが望ましい。

          qvalue         = ( "0" [ "." 0*3DIGIT ] )
                         | ( "1" [ "." 0*3("0") ] )

"品質値"は，その値が望ましい品質における相対的な低下を表現するだけなので, 適切な表現ではない。

3.10 言語タグ(language-tag)

言語タグは，情報の通信のために，人によって他の人に対して話され，書かれ，又は他の方法で運ばれる自然言語を識別する。コンピュータ言語は，明らかにそこには含まれない。HTTPは，Accept-Languageフィールド及びContent Languageフィールドの中で言語タグを使う。

HTTP言語タグの構文及びレジストリは，RFC 1766 [1]が定義するものと同じとする。要するに，言語タグは，一つ以上の部分，すなわち，主言語タグ及び空であってよい一連の下位タグ，から構成される。

           language-tag  = primary-tag *( "-" subtag )

           primary-tag   = 1*8ALPHA
           subtag        = 1*8ALPHA

タグ内では空白は許されず，すべてのタグは大文字・小文字を区別しない。言語タグの名前空間は，IANAによって管理される。次にタグの例を示す。

          en, en-US, en-cockney, i-cherokee, x-pig-latin

ここで，どの2字の主タグもISO 639の言語短縮形であって，どの2字の初期下位タグもISO 3166の国コードとする。(最後の三つのタグは，登録済みタグではないが，一番最後以外のすべては，将来登録される可能性のあるタグの例になっている。)

3.11 実体タグ(entity-tag)

実体タグは，同じ要求された資源からの二つ以上の実体を比較するのに使用する。HTTP/1.1は，ETag(14.20参照)，If-Match(14.25参照)，If-None-Match(14.26参照)及びIf-Range(14.27参照)のヘッダフィールドにおいて実体タグを用いる。それらがどのようにして用いられ，キャッシュ有効性検証子として比較されるかの定義は，13.3.3に示す。実体タグは，弱さ表示子を前置することがある不透明な引用文字列から成る。

         entity-tag = [ weak ] opaque-tag

         weak       = "W/"
         opaque-tag = quoted-string

"強実体タグ"は，資源の二つの実体がオクテット等価性によって等価となる場合だけに，資源の二つの実体によって共有されてよい。

接頭辞"W/"によって示される"弱実体タグ"は，資源の二つの実体が等価であって，セマンティクスにおける大きな変更なしに互いに置換可能な場合だけに，資源の二つの実体によって共有されてよい。弱実体タグは，弱い比較のためだけに用いられる。

実体タグは，特定資源に関連するすべての実体のすべての版に関して一意でなければならない。与えられた実体タグの値は，異なるURIに関する要求によって得られる実体に対して，その実体の等価性について何も暗黙に示すことなく用いてよい。

3.12 範囲単位(range-unit)

HTTP/1.1は，応答実体(の範囲)の部分だけが応答の中に含まれることをクライアントが要求することを可能にする。HTTP/1.1は，Range(14.36参照)及びContent-Range(14.17参照)のヘッダフィールドの中の範囲単位を用いる。実体は，様々な構造単位に応じて補助範囲に分割されてよい。

         range-unit       = bytes-unit | other-range-unit

         bytes-unit       = "bytes"
         other-range-unit = token

HTTP/1.1によって定義される範囲単位は，"バイト"だけとする。HTTP/1.1の実装は，他の単位を用いて指定される範囲を無視してもよい。HTTP/1.1は，範囲の知識に依存しないアプリケーションの実装を可能にするために設計された。

4. HTTPメッセージ

4.1 メッセージ型

HTTPメッセージは，クライアントからサーバへの要求と，サーバからクライアントへの応答とから成る。

          HTTP-message   = Request | Response     ; HTTP/1.1メッセージ

要求メッセージ(5.参照)及び応答メッセージ(6.参照)は，実体(メッセージのペイロード)の転送のために，RFC 822 [9]の共通メッセージフォーマットを用いる。どちらの型のメッセージも，開始行，一つ以上のヘッダフィールド("ヘッダ"としても知られる。)，ヘッダフィールドの末尾を示す空行(すなわち，CRLFの前に何もない行)，及びオプションのメッセージ本体から成る。

           generic-message = start-line
                             *message-header
                             CRLF
                             [ message-body ]

           start-line      = Request-Line | Status-Line

頑健性のために，サーバは，Request-Lineが期待されるところで受信したいかなる空行も無視することが望ましい。換言すると，サーバは，メッセージの開始に際してプロトコルのストリームを読んでいき最初にCRLFを受信した場合，そのCRLFを無視することが望ましい。

備考　バグのあるHTTP/1.0の実装では，POST要求の後に余分なCRLFを生成することがある。BNFによって明示的に禁止されることを再度示すために，HTTP/1.1クライアントは，余分なCRLFを要求の前に付けたり後ろに付けたりしてはならない。

4.2 メッセージヘッダ(message-header)

一般ヘッダ(general-header，4.5参照)，要求ヘッダ(request-header，5.3参照)，応答ヘッダ(response-header，6.2参照)及び実体ヘッダ(entity-header，7.1参照)のフィールドを含むHTTPヘッダフィールドは，RFC 822 [9]の3.1に与えられるものと同じ共通フォーマットに従う。各ヘッダフィールドは，名前，それに続くコロン(":")及びそのフィールド値から成る。 フィールド名は，大文字・小文字を区別しない。フィールド値の前には，SPを一つ置くことが望ましいが，LWSを幾つ置いてもよい。ヘッダフィールドは，少なくとも一つのSP又はHTをもつ各々の余分な行を前置することによって，複数行に拡張できる。アプリケーションは，HTTPの構成要素を生成する場合には"共通形式"に従うことが望ましい。これは，共通形式以外のものの受理に失敗する実装が存在するかもしれないことによる。

          message-header = field-name ":" [ field-value ] CRLF

          field-name     = token
          field-value    = *( field-content | LWS )

          field-content  = <field-valueを形成するOCTET列であって
                           *TEXT，又はtoken，tspecials及びquoted-stringの
                           組合せから構成される。>

異なるフィールド名をもつヘッダフィールドが受信される順序は，重要ではない。しかし，一般ヘッダフィールドを最初に送り，それに要求ヘッダ又は応答ヘッダのフィールドが続き，実体ヘッダのフィールドで終わることは，"良い習慣"とする。

同じフィールド名をもつ多くのメッセージヘッダフィールドは，そのヘッダフィールドに対するフィールド値全体がコンマで分離されたリスト[すなわち，#(values)]として定義される場合及びその場合に限り，一つのメッセージの中に存在してよい。メッセージのセマンティクスを変えることなしに，後続の各フィールド値をそれぞれコンマで分離して最初に付加することによって，複数のヘッダフィールドを一つの"フィールド名:フィールド値"の対に結合できなければならない。 したがって，同じフィールド名をもつヘッダフィールドが受信される順番は，結合されたフィールド値の解釈にとって重要になり，そこでプロキシは，メッセージを回送するときに，これらのフィールド値の順番を変えてはならない。

4.3 メッセージ本体(message-body)

HTTPメッセージのメッセージ本体は，それが存在する場合には，要求又は応答と関連する実体本体を運ぶのに使われる。メッセージ本体は，Transfer-Encodingヘッダフィールド(14.40参照)によって示されるとおりに，転送符号化が適用された場合だけ，実体本体と異なる。

          message-body = entity-body
                       | <Transfer-Encodingごとに符号化されたentity-body>

Transfer-Encodingは，メッセージの安全で適切な転送を確実にするためにアプリケーションによって適用されるどんな転送符号化をも示すために使われなければならない。Transfer-Encodingは，メッセージの特性であって，実体の特性ではなく，したがって，要求及び応答の連鎖に沿うあらゆるアプリケーションによって，追加されたり削除されたりすることができる。

メッセージ本体がメッセージの中で許容されるときの規則は，要求及び応答に対して異なる。

要求の中でのメッセージ本体の存在は，要求のメッセージヘッダの中にContent-Length又はTransfer-Encodingのヘッダフィールドを含むことによって通知される。メッセージ本体は，要求メソッド(5.1.1参照)が実体本体を許容する場合だけ，要求の中に含まれてよい。

応答メッセージについては，メッセージ本体がメッセージと共に含まれるかどうかは，要求メソッド及び応答状態コード(6.1.1参照)の両方に依存する。HEAD要求メソッドへのすべての応答は，たとえ実体ヘッダフィールドの存在がメッセージ本体を含めることを信じさせるかもしれなくとも，メッセージ本体を含んではならない。すべての1xx(参考)，204(内容なし)及び304(修正なし)の応答は，メッセージ本体を含んではならない。他のすべての応答は，メッセージ本体を含む。ただし，その長さは0であってもよい。

4.4 メッセージ長

メッセージ本体がメッセージと共に含まれる場合，その本体の長さは，(優先度の順に)次の一つによって決定される。

a)	メッセージ本体を含んではならないあらゆる応答メッセージ(1xx，204，304の応答，HEAD要求への応答など)は，メッセージの中にある実体ヘッダフィールドにかかわらず，ヘッダフィールドの後の最初の空行によって常に終端される。
b)	Transfer-Encodingヘッダフィールド(14.40参照)が存在して，それが"chunked"転送符号化が適用されたことを示す場合，その長さは，かたまり符号化(3.6参照)によって定義される。
c)	Content-Lengthヘッダフィールド(14.14参照)が存在する場合，そのバイト単位の値は，メッセージ本体の長さを表現する。
d)	メッセージがそれ自体を区切るメディア型"multipart/byteranges"を使用している場合，それが長さを定義する。このメディア型は，受け手がそれを構文解析できることを送り手が知らない場合には，用いてはならない。複数のバイト範囲指定子をもつRangeヘッダの要求の中にそれがあることは，クライアントがmultipart/byterangesの応答を構文解析できることを意味する。
e)	コネクションを閉じるサーバによる。(コネクションを閉じることは，サーバが応答を返送する可能性を残さないので，要求本体の末尾を示すためには使用できない。)

HTTP/1.0アプリケーションとの互換性のために，メッセージ本体を含むHTTP/1.1要求は，サーバがHTTP/1.1準拠であると知られていない場合には，有効なContent-Lengthヘッダフィールドを含まなければならない。要求がメッセージ本体を含み，Content-Lengthが与えられない場合，サーバは，メッセージの長さを決定できないならば，400(悪い要求)を伴って応答するのがよく，有効なContent-Lengthを受信することを強く主張したいならば，411(長さの要求)を伴って応答するのがよい。

実体を受信するすべてのHTTP/1.1アプリケーションは，"chunked"転送符号化(3.6参照)を受理しなければならないので，メッセージ長を前もって決定できない場合には，この機構をメッセージに対して用いることを可能にする。

メッセージは，Content-Lengthヘッダフィールド及び"chunked"転送符号化の両方を含んではならない。これらの両方が受信された場合には，Content-Lengthtが，無視されなければならない。

Content-Lengthが，メッセージ本体が許容されるメッセージの中に与えられる場合，そのフィールドの値は，メッセージ本体の中のオクテット(OCTET)の個数と正確に一致しなければならない。HTTP/1.1の利用者エージェントは，有効でない長さが受信され検出された場合には，利用者に通知しなければならない。

4.5 一般ヘッダ(general-header)フィールド

要求メッセージ及び応答メッセージの両方に対して一般的な適用可能性をもつが，転送される実体には適用されないヘッダフィールドが少しはある。これらのヘッダフィールドは，伝送されているメッセージだけに適用される。

          general-header = Cache-Control            ; 14.9
                         | Connection               ; 14.10
                         | Date                     ; 14.19
                         | Pragma                   ; 14.32
                         | Transfer-Encoding        ; 14.40
                         | Upgrade                  ; 14.41
                         | Via                      ; 14.44

一般ヘッダフィールドの名前は，プロトコル版の変更と結合した場合にだけ，信頼性のある拡張が可能になる。しかし，新しい又は実験的なヘッダフィールドは，通信の関係者すべてがそれらを一般ヘッダフィールドと認識する場合に，一般ヘッダフィールドのセマンティクスを与えられてよい。認識されないヘッダフィールドは，実体ヘッダフィールドとして扱われる。

5. 要求

クライアントからサーバへの要求メッセージは，そのメッセージの最初の行内に，資源に適用されるメソッド，資源の識別子及び使用しているプロトコル版を含む。

           Request       = Request-Line              ; 5.1
                           *( general-header         ; 4.5
                            | request-header         ; 5.3
                            | entity-header )        ; 7.1
                           CRLF
                           [ message-body ]          ; 7.2

5.1 Request-Line(要求行)

Request-Lineは，メソッドトークンで開始し，その後にRequest-URI及びプロトコル版が続き，CRLFで終了する。要素は，SP文字によって分離される。CR及びLFは，最終のCRLFシーケンス以外では禁止される。

          Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

5.1.1 Method(メソッド)

Methodトークンは，Request-URIによって識別される資源に関して実行されるメソッドを示す。メソッドは，大文字・小文字を区別する。

          Method         = "OPTIONS"                ; 9.2
                         | "GET"                    ; 9.3
                         | "HEAD"                   ; 9.4
                         | "POST"                   ; 9.5
                         | "PUT"                    ; 9.6
                         | "DELETE"                 ; 9.7
                         | "TRACE"                  ; 9.8
                         | extension-method

          extension-method = token

資源によって許容されるメソッドのリストは，Allowヘッダフィールド(14.7参照)の中に指定できる。応答の返却コードは，メソッドが資源に関して現在許容されているかどうかをクライアントに常に通知する。これは，許容されるメソッドの集合が，動的に変化可能なことによる。 サーバは，メソッドがサーバによって知られているが要求された資源に対して許容されない場合，状態コード405(Method Not Allowed)を返すことが望ましく，メソッドがサーバによって認知されない又は実装されていない場合，状態コード501(Not Implemented)を返すことが望ましい。サーバによって知られているメソッドのリストは，Public応答ヘッダフィールド(14.35参照)の中にリストとして示すことができる。

メソッドGET及びメソッドHEADは，すべての一般目的のサーバによってサポートされなければならない。他のすべてのメソッドは，オプションとする。しかし，前述のメソッドが実装される場合には，それらは，9.に規定するセマンティクスと同じセマンティクスをもって実装されなければならない。

5.1.2 Request-URI(要求URI)

Request-URIは，統一資源識別子(3.2参照)であって，その要求を適用する資源を識別する。

          Request-URI    = "*" | absoluteURI | abs_path

Request-URIに対する三つのオプションは，要求の性質に依存する。アスタリスク"*"は，要求が特定の資源には適用されないがサーバ自体には適用されることを意味して，使用するメソッドが必ずしも資源に適用されない場合だけに許容される。一例を次に示す。

          OPTIONS * HTTP/1.1

要求がプロキシに対して行われているとき，absoluteURI(絶対URI)の形式が要求される。プロキシは，その要求を回送するか，又は有効なキャッシュからそれをサービスすることを要求され，その応答を返すことを要求される。 プロキシは，要求を他のプロキシに，又はabsoluteURIによって指定されるサーバに直接に，要求を回送してもよいことに注意すること。要求のループを避けるために，プロキシは，別名，局所的な変形及び数値IP番地を含むそのサーバの名前のすべてを認識できなければならない。Request-Lineの例を次に示す。

          GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

HTTPの将来版のすべての要求におけるabsoluteURIへの移行を考慮して，すべてのHTTP/1.1サーバは，たとえ，HTTP/1.1クライアントがプロキシへの要求においてそれらを生成するだけであっても，要求におけるabsoluteURI形式を受け入れなければならない。

Request-URIの最も共通の形式は，原サーバ又はゲートウェイの上の資源を識別するために使うものとする。この場合，そのURIの絶対経路は，Request-URIとして伝送されなければならず(3.2.1のabs_pathを参照)，URIのネットーク位置(net_loc)は，Hostヘッダフィールドの中で伝送されなければならない。例えば，前述の資源を原サーバから直接に取得しようとするクライアントは，ホスト"www.w3.org"のポート80へのTCPコネクションを生成し，次の行を送る。

          GET /pub/WWW/TheProject.html HTTP/1.1
          Host: www.w3.org

この後に要求の残りが続く。絶対経路は空ではあり得ないことに注意すること。元のURIの中に何も存在しない場合，それは，"/"(サーバのルート)として与えられなければならない。

プロキシがRequest-URIの中に経路をもたない要求を受信し，指定されたメソッドが要求のアスタリスク形式をサポートできる場合，要求連鎖上の最後のプロキシは，最終のRequest-URIとして"*"をもつ要求を回送しなければならない。次に例を示す。

          OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1

この要求は，次のとおりプロキシによって回送される。

          OPTIONS * HTTP/1.1
          Host: www.ics.uci.edu:8001

この回送は，ホスト"www.ics.uci.edu"のポート8001への接続の後に行われる。

Request-URIは，3.2.1に規定されるフォーマットで伝送される。原サーバは，要求を適切に解釈するために，Request-URIを復号しなければならない。サーバは，有効でないRequest-URIに対して，適切な状態コードで応答することが望ましい。

プロキシが回送する要求において，プロキシは，たとえプロキシがその内部実装において何をしようとも，ヌルabs_pathを"*"で置換するために前述したことを除いたどのような方法でも，Request-URIの"abs_path"部分を書き換えてはならない。

備考　"書換えなし"規則は，原サーバが予約済みの目的のために予約済みではないURL文字を不適切に用いている場合に，プロキシが要求の意味を変えることを阻止する。実装者は，Request-URIを書き換えることが知られているpre-HTTP/1.1プロキシが存在することに，気付いていることが望ましい。

5.2 要求によって識別される資源

HTTP/1.1原サーバは，インターネット要求によって識別されるその資源が，Request-URI及びHostヘッダフィールドの両方を調査することによって決定されることを知っていることが望ましい。

資源が要求されたホストによって異なることを許容しない原サーバは，Hostヘッダフィールドの値を無視してもよい。(しかし，HTTP/1.1でのHostのサポートに関する他の要件については，19.5.1を参照すること。)

要求されるホストに基づいて(仮想ホスト又は虚構ホスト名と呼ばれることもある)資源を区別する原サーバは，HTTP/1.1要求に関して要求される資源を決定するための次の規則を用いなければならない。

a)	Request-URIがabsoluteURIである場合，ホストは，Request-URIの一部とする。要求におけるどんなHostヘッダフィールドの値も，無視されなければならない。
b)	Request-URIがabsoluteURIではなく，要求がHostヘッダフィールドを含む場合，ホストは，Hostヘッダフィールドの値によって決定される。
c)	規則a)又はb)によって決定されるホストがサーバ上で有効なホストでない場合，応答は，400(Bad Request)のエラーメッセージでなければならない。

HostヘッダフィールドのないHTTP/1.0要求の受け手は，どの資源が要求されているのかを決定するために，発見的手法(例えば，特定のホストに対して一意であるものについてのURI経路の調査)を用いようとしてもよい。

5.3 要求ヘッダ(request-header)フィールド

要求ヘッダフィールドは，クライアントが要求及びクライアント自体に関する追加情報をサーバに受け渡すことを可能にする。これらのフィールドは，要求修飾子として動作し，プログラム言語のメソッド呼出しにおけるパラメタと等価なセマンティクスをもつ。

          request-header = Accept                   ; 14.1
                         | Accept-Charset           ; 14.2
                         | Accept-Encoding          ; 14.3
                         | Accept-Language          ; 14.4
                         | Authorization            ; 14.8
                         | From                     ; 14.22
                         | Host                     ; 14.23
                         | If-Modified-Since        ; 14.24
                         | If-Match                 ; 14.25
                         | If-None-Match            ; 14.26
                         | If-Range                 ; 14.27
                         | If-Unmodified-Since      ; 14.28
                         | Max-Forwards             ; 14.31
                         | Proxy-Authorization      ; 14.34
                         | Range                    ; 14.36
                         | Referer                  ; 14.37
                         | User-Agent               ; 14.42

要求ヘッダフィールド名は，プロトコル版における変更との組合せだけにおいて，信頼性のある拡張が可能となる。しかし，新しい又は実験的なヘッダフィールドは，通信のすべての関係者がそれらを要求ヘッダフィールドであると認識する場合，要求ヘッダフィールドのセマンティクスを与えられてもよい。認識されないヘッダフィールドは，実体ヘッダフィールドとして扱われる。

6. 応答

要求メッセージを受信し解釈した後，サーバは，HTTP応答メッセージを用いて応答する。

       Response      = Status-Line               ; 6.1
                       *( general-header         ; 4.5
                        | response-header        ; 6.2
                        | entity-header )        ; 7.1
                       CRLF
                       [ message-body ]          ; 7.2

6.1 Status-Line(状態行)

応答メッセージの最初の行は，Status-Lineであって，プロトコル版，それに続いて数値の状態コード及びその関連するテキストの句から成る。最終のCRLF列の中を除き，CR及びLFは許されない。

       Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

6.1.1 Status-Code(状態コード)及びReason-Phrase(理由句)

Status-Code要素は，要求を理解し満足する企ての，3桁整数の結果コードとする。これらのコードは，10.において完全に定義される。Reason-Phraseは，Status-Codeの短いテキスト記述を与えることを意図している。Status-Codeは機械による利用を意図しており，Reason-Phraseは人の利用者のためを意図している。クライアントが，Reason-Phraseを調査したり表示することは要求されない。

Status-Codeの最初の桁は，応答のクラスを定義する。最後の2桁は，いかなる分類の役割をももっていない。最初の桁については，次の五つの値がある。

• 1xx: 参考 - 要求が受信されて，処理を継続中。

• 2xx: 成功 - 動作が成功裏に受信され，理解され，受諾された。

• 3xx: 宛先切替え - 要求を完了するために，更なる動作が行われなければならない。

• 4xx: クライアントエラー - 要求が，悪い構文を含むか，果たすことができない。

• 5xx: サーバエラー - サーバが，見た目は有効な要求を果たせなかった。

HTTP/1.1のために定義された数値状態コードの個々の値，及び対応するReason-Phraseの例示集を次に示す。ここにリストとして示す理由句だけが, 推奨される。それらは，プロトコルに影響を与えることなく，局所的に(又は地域的に)等価なものによって置き換えられてよい。

          Status-Code    = "100"   ; Continue
                         | "101"   ; Switching Protocols
                         | "200"   ; OK
                         | "201"   ; Created
                         | "202"   ; Accepted
                         | "203"   ; Non-Authoritative Information
                         | "204"   ; No Content
                         | "205"   ; Reset Content
                         | "206"   ; Partial Content
                         | "300"   ; Multiple Choices
                         | "301"   ; Moved Permanently
                         | "302"   ; Moved Temporarily
                         | "303"   ; See Other
                         | "304"   ; Not Modified
                         | "305"   ; Use Proxy
                         | "400"   ; Bad Request
                         | "401"   ; Unauthorized
                         | "402"   ; Payment Required
                         | "403"   ; Forbidden
                         | "404"   ; Not Found
                         | "405"   ; Method Not Allowed
                         | "406"   ; Not Acceptable
                         | "407"   ; Proxy Authentication Required
                         | "408"   ; Request Time-out
                         | "409"   ; Conflict
                         | "410"   ; Gone
                         | "411"   ; Length Required
                         | "412"   ; Precondition Failed
                         | "413"   ; Request Entity Too Large
                         | "414"   ; Request-URI Too Large
                         | "415"   ; Unsupported Media Type
                         | "500"   ; Internal Server Error
                         | "501"   ; Not Implemented
                         | "502"   ; Bad Gateway
                         | "503"   ; Service Unavailable
                         | "504"   ; Gateway Time-out
                         | "505"   ; HTTP Version not supported
                         | extension-code

          extension-code = 3DIGIT

          Reason-Phrase  = *<CR及びLFを除くTEXT>

HTTP状態コードは，拡張可能とする。HTTPアプリケーションは，すべての登録済み状態コードの意味を理解する必要はない。ただし，それらの理解は，明らかに望ましい。しかし，アプリケーションは，どんな状態コードのクラスも，最初の桁によって示されるとおりに理解しなければならず，どんな認識されない応答も，そのクラスのx00状態コードに等価になるとして扱わなければならない。ただし，認識されない応答は，キャッシュされてはならない。 例えば，認識されない状態コードの431がクライアントによって受信された場合，クライアントは，その要求に何か間違いがあった仮定してよく，状態コード400を受信したものとして応答を扱うことができる。それらの場合，利用者エージェントは，利用者に対して応答と共に返却される実体を提示することが望ましい。これは，その実体が，異常な状態を説明する人間可読情報を含むことが多いことによる。

6.2 応答ヘッダ(response-header)フィールド

応答ヘッダ(response-header)フィールドは，Status-Lineの中におくことができない応答に関する追加情報をサーバが受け渡すことを許容する。これらのヘッダフィールドは，サーバに関する情報，及びRequest-URIによって識別される資源への追加アクセスに関する情報を与える。

          response-header = Age                     ; 14.6
                          | Location                ; 14.30
                          | Proxy-Authenticate      ; 14.33
                          | Public                  ; 14.35
                          | Retry-After             ; 14.38
                          | Server                  ; 14.39
                          | Vary                    ; 14.43
                          | Warning                 ; 14.45
                          | WWW-Authenticate        ; 14.46

応答ヘッダ(response-header)フィールド名は，プロトコル版における変更との組合せだけにおいて，信頼性のある拡張が可能となる。しかし，新しい又は実験的なヘッダフィールドは，通信のすべての関係者がそれらを応答ヘッダフィールドであると認識する場合，応答ヘッダフィールドのセマンティクスを与えられてもよい。認識されないヘッダフィールドは，実体ヘッダフィールドとして扱われる。

7. 実体

要求メッセージ及び応答メッセージは，要求メソッド又は応答状態コードによって他に制限されない場合には，実体を転送してよい。応答には，実体ヘッダだけを含むものもあるが，実体は，実体ヘッダフィールド及び実体本体から成る。

7.では，送り手及び受け手の両方は，誰がその実体を送信し誰がその実体を受信するかに応じて，クライアント又はサーバのどちらかを指すこととする。

7.1 実体ヘッダ(entity-header)フィールド

実体ヘッダ(entity-header)フィールドは，実体本体に関するオプションのメタ情報を定義するか，本体が存在しない場合には，要求によって識別される資源に関するオプションのメタ情報を定義する。

          entity-header  = Allow                    ; 14.7
                         | Content-Base             ; 14.11
                         | Content-Encoding         ; 14.12
                         | Content-Language         ; 14.13
                         | Content-Length           ; 14.14
                         | Content-Location         ; 14.15
                         | Content-MD5              ; 14.16
                         | Content-Range            ; 14.17
                         | Content-Type             ; 14.18
                         | ETag                     ; 14.20
                         | Expires                  ; 14.21
                         | Last-Modified            ; 14.29
                         | extension-header

          extension-header = message-header

拡張ヘッダ(extension-header)の機構は，追加の実体ヘッダフィールドがプロトコルを変更することなく定義されることを許容する。しかし，これらのフィールドは，受け手によって認識可能とは期待できない。認識されないヘッダフィールドは，受け手によって無視され，プロキシによって回送されることが望ましい。

7.2 実体本体(entity-body)

HTTP要求又はHTTP応答と共に送られる実体本体は，それが存在する場合には，実体ヘッダフィールドによって定義されるフォーマット及び符号化になっている。

          entity-body    = *OCTET

4.3に示すとおり，実体本体は，メッセージ本体が存在する場合だけに，メッセージの中に存在する。実体本体は，メッセージの安全で適切な転送を確実にするために適用されてもよかったTransfer-Encoding(転送符号化)を復号することによってメッセージ本体から得られる。

7.2.1 型

実体本体がメッセージと共に含まれるとき，その本体のデータ型は，ヘッダフィールドであるContent-Type及びContent-Encodingを介して決定される。これらは，次に示す2層の順序付き符号化モデルを定義する。

          entity-body := Content-Encoding( Content-Type( data ) )

Content-Typeは，基礎となるデータのメディア型を指定する。Content-Encodingは，要求される資源の特性であるデータに適用する，通常はデータ圧縮のための，追加の内容符号化を示すために使ってよい。デフォルトの符号化は存在しない。

実体本体を含むどんなHTTP/1.1メッセージも，その実体のメディア型を定義するContent-Typeヘッダフィールドを含むことが望ましい。メディア型がContent-Typeフィールドによって与えられない場合及びその場合だけは，受け手は，その内容の検査，及び/又は資源を識別するのに用いるURLの名前拡張の検査によってメディア型を推定しようとしてよい。メディア型がわからないままである場合，受け手は，型"application/octet-stream"としてそれを扱うことが望ましい。

7.2.2 長さ

実体本体の長さは，どの転送符号化も取り除かれた後のメッセージ本体の長さとする。4.4は，メッセージ本体の長さを決定する方法を定義する。

8. コネクション

8.1 永続的コネクション

8.1.1 目的

永続的コネクション(の使用)に先立って，各URLを取得するために別個のTCPコネクションが確立されてきたが，これが，HTTPサーバの負荷を増加し，インターネット上の輻輳を引き起こした。行内画像及び他の関連データの使用は，クライアントに対して，短時間に同一サーバへの複数の要求を出すことを必要とすることが多い。これらの性能問題の解析は，[30]及び[27]にあり，プロトタイプ実装の解析及び結果は，[26]にある。

永続性HTTPコネクションは，次の多くの利点をもつ。

• より少ないTCPコネクションを開き閉じることによって，CPU時間が節約され，TCPプロトコル制御ブロック用のメモリも節約される。

• HTTPの要求及び応答は，一つのコネクション上でパイプライン化可能になる。パイプライン化は，クライアントが，複数の要求をそれぞれの応答を待つことなしに出すことを可能にし，単一のTCPコネクションがより効率的により少ない経過時間で用いられることを可能にする。

• TCP(コネクション)を開くことが引き起こすパケットの個数を減らすことによって，及びTCPに対してネットワークの輻輳状態を決定するのに充分な時間を許容することによって，ネットワークの輻輳が，減らされる。

• TCPコネクションを閉じるという罰則なしにエラーを報告できるので，HTTPは，より上品に進化できる。HTTPの将来版を用いるクライアントは，新機能を楽観的に試みてもよいが，より古いサーバとの通信に際して，エラーが報告された後は，古いセマンティクスを使って再び試みるのがよい。

HTTPの実装は，永続的コネクションを実装することが望ましい。

8.1.2 動作概要

HTTP/1.1とHTTPの以前の版との大きな相違は，永続的コネクションがあらゆるHTTPコネクションのデフォルトの振る舞いになることとする。すなわち，特記しない限り，クライアントは，サーバが永続的コネクションを維持することを仮定してよい。

永続的コネクションは，クライアント及びサーバがTCPコネクションの閉じを通知できる機構を提供する。この通知は，Connectionヘッダフィールドを用いて行われる。ひとたび閉じが通知されてしまうと，クライアントは，そのコネクション上ではそれ以上の要求を送ってはならない。

8.1.2.1 折衝

HTTP/1.1サーバは，コネクショントークン"close"を含むConnectionヘッダが，要求の中で送られなかった場合に，HTTP/1.1クライアントが永続的コネクションを維持するつもりであると仮定してよい。サーバは，応答を送った直後にコネクションを閉じることを選択した場合，コネクショントークンcloseを含むConnectionヘッダを送ることが望ましい。

HTTP/1.1クライアントは，コネクションは開いたままであることを期待してよいが，サーバからの応答がコネクショントークンcloseをもつConnectionヘッダを含むかどうかに基づいて，そのコネクションを開いたままにすることを決定する。クライアントが，その要求より多くの要求に対してコネクションを維持することを望まない場合，コネクショントークンcloseを含むConnectionヘッダを送ることが望ましい。

クライアント又はサーバのどちらかがConnectionヘッダの中でcloseトークンを送る場合には，その要求は，そのコネクションに対する最後のものとなる。

クライアント及びサーバは，1.1より前のHTTPの版に対しては，明示的に通知されない場合には，永続的コネクションが維持されることを仮定しないことが望ましい。HTTP/1.0クライアントとの後方互換性に関するより詳しい情報については，19.7.1を参照すること。

(コネクションが)永続的であり続けるためには，コネクション上の全メッセージは，4.4に示すとおりに，自己定義されたメッセージ長(すなわち，コネクションの閉じによって定義されないもの)をもたなければならない。

8.1.2.2 パイプライン化

永続的コネクションをサポートするクライアントは，その要求を"パイプライン化"してよい。すなわち，各応答を待つことなしに複数の要求を送ってよい。サーバは，要求が受け取られたのと同じ順番に，それらの要求に対する応答を送らなければならない。

永続的コネクションとコネクション設立直後のパイプラインとを仮定するクライアントは，最初のパイプライン化の試行に失敗した場合には，そのコネクションを再試行する準備を整えていることが望ましい。クライアントは，再試行をしない場合，コネクションが永続的であることを知る前にパイプライン化をしてはならない。サーバが対応する応答のすべてを送る前にコネクションを閉じる場合には，クライアントは，その要求を再送する準備も整っていなければならない。

8.1.3 プロキシサーバ

プロキシが，Connectionヘッダフィールドの特性を，14.2.1に規定されるとおりに正しく実装することは，特に重要とする。

プロキシサーバは，そのクライアント及びそれが接続する原サーバ(又は他のプロキシサーバ)との永続的コネクションを別々に通知しなければならない。各永続的コネクションは，一つのトランスポートリンクだけに適用される。

プロキシサーバは，HTTP/1.0クライアントとの永続的コネクションを確立してはならない。

8.1.4 実際上の考慮

サーバは，通常，サーバが非活性コネクションをそれ以上維持しないあるタイムアウト値をもつ。クライアントは同じサーバを通してより多くのコネクションを作ることが多いので，プロキシサーバは，このタイムアウト値をより大きな値にするかもしれない。永続的コネクションの使用は，クライアント又はサーバのどちらかに対するこのタイムアウトの長さについての要件を提起しない。

クライアント又はサーバがタイムアウトを望む場合，トランスポートコネクション上で相手のことを配慮した閉じを発行することが望ましい。クライアント及びサーバは，トランスポートの閉じの他の側を常に待ち受けることが望ましく，適切なものとしてそれに応答することが望ましい。クライアント又はサーバが他の側の閉じを直ちに検出しない場合には，ネットワーク上で不必要な資源の消耗を引き起こす可能性がある。

クライアント，サーバ又はプロキシは，いつでもトランスポートコネクションを閉じてよい。例えば，サーバが"未使用の"コネクションを閉じることを決めたときと同時に，クライアントが，新しい要求を送ることを開始したとする。サーバの観点からは，コネクションは，それが未使用であった間に閉じられようとしているのだが，クライアントの観点からは，要求が進行中となる。

これは，クライアント，サーバ及びプロキシは，非同期の閉じイベントから回復できなければならないことを意味する。クライアントソフトウェアは，トランスポートコネクションを再び開き，要求メソッドが多重呼出し不変(9.1.2参照)な場合に限っては，異常終了された要求を再び伝送することが望ましい。それ以外のメソッドは，自動的に再試行してはならない。ただし，利用者エージェントは，人間の操作員に要求の再試行の選択を提供してもよい。

しかし，2回目の要求が失敗した場合には，この自動再試行を繰り返さないほうがよい。

サーバは，可能な場合には，コネクション毎に少なくとも一つの要求に対して常に応答することが望ましい。サーバは，ネットワーク又はクライアントの失敗の可能性がない場合には，応答の伝送の最中に，コネクションを閉じないことが望ましい。

永続的コネクションを用いるクライアントは，それが与えられたサーバに対して維持する同時コネクションの数を制限することが望ましい。一つの利用者クライアントは，サーバ又はプロキシとの多くとも2個のコネクションを維持するのが望ましい。一つのプロキシは，他のサーバ又はプロキシに対する2*N個までのコネクションを使用することが望ましい。ここで，Nは，同時に有効な利用者の数とする。これらの指針は，HTTPの応答時間を改善し，インターネット又は他のネットワークの輻輳を避けることを意図している。

8.2 メッセージ転送要件

一般的な要件を次に示す。

• HTTP/1.1サーバは，永続的コネクションを維持し，一時的な過負荷を解決するためにTCPのフロー制御機構を利用することが望ましい。一時的な過負荷解決のために，クライアントが再試行することを期待するコネクションの閉じは行わないほうがよい。後者の技術は，ネットワークの輻輳を悪化さる可能性がある。

• メッセージ本体を送るHTTP/1.1(又はそれ以降の版)のクライアントは，それが要求を伝送している間，エラー状態のためにネットワークコネクションを監視することが望ましい。クライアントがエラー状態を検知した場合，クライアントは，直ちに本体の伝送を止めることが望ましい。本体が"chunked"(かたまり)符号化(3.6参照)を使って送られている場合，長さ0のかたまり及び空のフッタを用いて，メッセージの終わりを早めにマークしてもよい。本体の前にContent-Lengthヘッダがくる場合には，クライアントは，そのコネクションを閉じなければならない。

• HTTP/1.1(又はそれ以降の版)のクライアントは，通常の応答が後に続く100(Continue)状態を受諾する準備ができていなければならない。

• HTTP/1.0(又はそれ以前の版)のクライアントからの要求を受けるHTTP/1.1(又はそれ以降の版)のサーバは，100(Continue)応答を伝送してはならない。サーバは，要求が正常に完了されるまで待つ(このようにして，割込み要求を避ける。)か，又は早めにコネクションを閉じるかのどちらかを行うことが望ましい。

HTTP/1.1(又はそれ以降の版)のクライアントからのこれら要件に従うメソッドを受ける際，HTTP/1.1(又はそれ以降の版)のサーバは，100(Continue)状態で応答して入力ストリームからの読取りを継続するか，又はエラー状態で応答するかのどちらかを行わなければならない。エラー状態で応答する場合には，トランスポート(TCP)コネクションを閉じてもよいし，読取りを継続して要求の残りを廃棄してもよい。サーバは，エラー状態を返す場合には，要求されたメソッドを実行してはならない。

クライアントは，少なくとも一番最近に用いたサーバの版数を記憶していることが望ましい。HTTP/1.1クライアントがサーバからのHTTP/1.1又はそれ以降の版の応答を検知した場合であって，それがサーバからいかなる状態も受ける前にコネクションの閉じを検知した場合，クライアントは，要求メソッドが多重呼出し不変(9.1.2参照)である場合に限って，利用者との相互作用なしに要求を再試行することが望ましい。それ以外のメソッドは，自動的に再試行してはならない。ただし，利用者エージェントは，人間の操作員に要求の再試行の選択を提供してもよい。クライアントが要求を再試行する場合には，クライアントの動作は，次のとおりとする。

• まず，要求ヘッダフィールドを送らなければならない。

• 次に，サーバが100(Continue)応答又はエラー状態のどちらかで応答するのを待たなければならない。前者は，クライアントが継続することが望ましい場合とする。

HTTP/1.1クライアントがサーバからのHTTP/1.1又はそれ以降の版の応答を検知しなかった場合，クライアントは，サーバがHTTP/1.0又はそれ以前の版を実装していて，100(Continue)応答を用いないと仮定することが望ましい。この場合であって，クライアントがサーバからのいかなる状態も受ける前にコネクションの閉じを検知した場合，クライアントは，要求を再試行することが望ましい。クライアントがこのHTTP/1.0サーバへの要求を再試行する場合には，それは，次の"binary exponential backoff"アルゴリズムを用いて，信頼性のある応答を得ることを確実にすることが望ましい。

a)	サーバへの新しいコネクションを開始する。
b)	要求ヘッダを伝送する。
c)	変数Rを，サーバに対する評価済みラウンドトリップ時間(例えば，コネクションを確立するのにかかる時間に基づくもの)に初期化するか，又はラウンドトリップ時間が利用可能でない場合には，定数値5秒に初期化する。
d)	T = R * (2**N) を計算する。ここで，Nは，この要求の以前の再試行の回数とする。
e)	サーバからのエラー応答を待つか，又はT秒間待つかのどちらかとする。どちらにするかは，早いほうにする。
f)	エラー応答が受け取られない場合，T秒後に要求の本体を伝送する。
g)	クライアントがコネクションが早めに閉じられたのを検知した場合には，要求が受諾されるまでステップa)からをを繰り返すか，誤り応答が受け取られるか，又は利用者が待ちきれずに再試行処理を終える。

サーバの版数が何であっても，エラー状態が受け取られる場合には，クライアントの動作は次のとおりとする。

• 継続してはならない。

• メッセージを送ることを完了していなかった場合には，コネクションを閉じなければならない。

100(Continue)を受けた後だがその他の状態を受ける前にコネクションの閉じを検知するHTTP/1.1又はそれ以降の版のクライアントは，要求を再試行することが望ましく，100(Continue)応答を待つ必要はない。ただし，それが実装を簡素化する場合には，100(Continue)応答を待ってもよい。

9. メソッド定義

HTTP/1.1のための共通メソッドの集合を，以降に定義する。この集合は，拡張可能だが，追加のメソッドが，別々に拡張されたクライアント及びサーバに対して同じセマンティクスを共有することを仮定することはできない。

Host要求ヘッダフィールド(14.23参照)は，すべてのHTTP/1.1要求になければならない。

9.1 安全メソッド及び多重呼出し不変なメソッド

9.1.1 安全メソッド

実装者は，ソフトウェアがインターネット上での相互作用において利用者を表現していることに気付いていることが望ましく，利用者が，行ってもよいが自分にも他にも予期しない重要性をもつ可能性がある動作に気付くことを可能にするように注意することが望ましい。

特に，GETメソッド及びHEADメソッドが取得以外の動作を行うという重要性を決してもたないことが望ましいという規約が，既に確立されている。これらのメソッドは，"安全"と考えられることが望ましい。これは，利用者エージェントに対して，特別な方法でPOST，PUT，DELETEなどの他のメソッドを表現することを許容する。その結果，利用者は，安全でない可能性のある動作が要求されている事実に気付かされる。

当然，サーバが，GET要求の実行の結果として副作用を生成しないことを確実にすることは可能ではない。実際，動的資源の中には，それを機能と考えるものがある。ここで重要な点は，利用者は副作用を要求しなかったことであって，したがってそれに関して責任があるとはできないことである。

9.1.2 多重呼出し不変なメソッド

メソッドは，(エラー又は期限切れは除いて) N個(N > 0)の等しい要求の副作用が単一の要求に対するものと同じという点で，"多重呼出し不変"な特性をもってもよい。メソッドのGET，HEAD，PUT及びDELETEは，この特性を共有する。

9.2 OPTIONS

OPTIONSメソッドは，Request-URIによって識別される要求連鎖及び応答連鎖の上で利用可能な通信オプションに関する情報のための要求を表現する。このメソッドは，クライアントが，資源動作を暗示したり資源取得を開始したりせずに，資源に関連するオプション及び/又は要件を決定したり，サーバの能力を決定することを可能にする。

サーバの応答がエラーでない場合，その応答は，通信オプション(例えば，Allowは適切だが，Content-Typeは適切ではない，など)と考えられるもの以外の実体情報を含んではならない。このメソッドへの応答は，キャッシュ可能ではない。

Request-URIがアスタリスク("*")である場合，OPTIONS要求は，全体としてサーバに適用されることを意図している。200応答は，適用可能な一般フィールド又は応答ヘッダフィールドに加えて，この規定によって定義されない拡張を含む，(Publicなどの)サーバによって実装されるオプション機能を示すヘッダフィールドを含むことが望ましい。5.1.2に示すとおり，"OPTIONS *"要求は，経路情報なしにRequest-URIの中に宛先サーバを指定することによって，プロキシを通して適用できる。

Request-URIがアスタリスク("*")でない場合，OPTIONS要求は，その資源と通信する際に利用可能なオプションだけに適用される。200応答は，適用可能な一般フィールド又は応答ヘッダフィールドに加えて，この規定によって定義されない拡張を含む，(Allowなどの)サーバによって実装されその資源に適用できるオプション機能を示すどんなヘッダフィールドも含むことが望ましい。OPTIONS要求がプロキシを通過する場合，そのプロキシは，応答を編集して，プロキシの能力に適用され，そのプロキシを通しては利用不可能なことが知られているオプションを取り除かなければならない。

9.3 GET

GETメソッドは，(実体の形式の)Request-URIによって識別されるいかなる情報も取得することを意味する。Request-URIがデータ生成プロセスを参照する場合，応答において実体として返却されなければならないのは，生成データであって，プロセスのソーステキストではない。ただし，そのテキストがプロセスの出力になる場合は除く。

要求メッセージがIf-Modified-Since，If-Unmodified-Since，If-Match，If-None-Match，又はIf-Rangeのヘッダフィールドを含む場合，GETメソッドのセマンティクスは, "条件付きGET"に変化する。条件付きGETメソッドは，実体が条件付きヘッダフィールドによって記述される状況下だけで転送されることを要求する。条件付きGETメソッドは，複数要求を要求したり既にクライアントによって保持されているデータを転送したりせずに，キャッシュされた実体が更新されることを可能にすることによって，不必要なネットワーク利用を削減することを意図している。

要求メッセージがRangeヘッダフィールドを含む場合，GETメソッドのセマンティクスは，"部分的GET"に変化する。部分的GETは，14.36に示すとおり，実体の部分だけが転送されることを要求する。部分的GETメソッドは，部分的に取得された実体が，既にクライアントによって保持されているデータを転送せずに完了されることを可能にすることによって，不必要なネットワーク利用を削減することを意図している。

GET要求への応答は，キャッシュできるが，それは，その応答が13.に示すHTTPキャッシュ化の要件に合う場合に限る。

9.4 HEAD

HEADメソッドは，サーバが応答においてメッセージ本体を返却してはならないことを除き，GETと同じとする。HEAD要求への応答におけるHTTPヘッダに含まれるメタ情報は，GET要求への応答において送られる情報と同じになることが望ましい。このメソッドは，実体本体それ自体を転送することなく，要求によって暗示される実体に関するメタ情報を得るために使用できる。このメソッドは，ハイパテキストのリンクを，有効性，アクセス可能性及び最近の修正について試験するのに使用されることが多い。

HEAD要求への応答は，応答に含まれる情報が資源からの以前にキャッシュされた実体を更新するのに使用されてもよいという意味でキャッシュ可能としてよい。新しいフィールドの値が，(Content-Length，Content-MD5，ETag又はLast-Modifiedでの変化によって示されるとおりに，)キャッシュされた実体が現在の実体と異なることを示す場合，キャッシュは，キャッシュ実体を新鮮ではないとして扱わなければならない。

9.5 POST

POSTメソッドは，宛先サーバが，Request-Lineの中のRequest-URIによって識別される資源の新しい下位要素として，要求の中に入れられた実体を受理することを要求するのに用いられる。POSTは，一つのメソッドが次の機能を網羅できるように設計されている。

• 既存資源の注記。

• 掲示板，ニュースグループ，メーリングリスト又は類似の議論グループへのメッセージの投稿。

• フォーム提出の結果といったデータブロックのデータ処理プロセスへの提供。

• 付加演算によるデータベースの拡張。

POSTメソッドによって実行される実際の機能は，サーバによって決定され，通常はRequest-URIに依存する。ポストされる実体は，ファイルがそれを含むディレクトリの下位要素であり，ニュース記事がそれが投稿されるニュースグループの下位要素であり，又はレコードがデータベースの下位要素であるのと同じ方法で，URIの下位要素とする。

POSTメソッドによって実行される動作は，URIによって識別できる資源には帰結しないかもしれない。この場合，200(OK)又は204(No Content)のどちらかを，応答が結果を記述する実体を含むかどうかに依存して，適切な状態とする。

資源が既に原サーバ上に生成されている場合，応答は，201(Created)であって，要求の状態を示し新しい資源を参照する実体及びLocationヘッダを含むことが望ましい(14.30参照)。

このメソッドへの応答は，応答が適切なCache-Control又はExpiresのヘッダフィールドを含まない場合には，キャッシュ可能ではない。しかし，303(See Other)の応答は，利用者エージェントにキャッシュ可能な資源を検索するように指示するのに用いることができる。

POST要求は，8.2に示すメッセージ伝送要件に従わなければならない。

9.6 PUT

PUTメソッドは，そのメソッドに含まれる実体が，供給されるRequest-URIのもとに格納されることを要求する。Request-URIが既存の資源を参照する場合，その含まれる実体は，原サーバ上にあるものの修正版と見なされることが望ましい。Request-URIが既存の資源を指し示さず，そのURIが要求している利用者エージェントによって新しい資源として定義されることが可能な場合，原サーバは，そのURIをもつ資源を生成できる。 新しい資源が生成される場合，原サーバは，201(Created)応答によって利用者エージェントに通知しなければならない。既存の資源が修正される場合，200(OK)又は204(No Content)の応答コードどちらかが，要求の成功完了を示すために送られることが望ましい。応答がRequest-URIを用いて生成されたり修正されたりできない場合，問題の性質を反映する適切なエラー応答が与えられることが望ましい。実体の受け手は，それが理解しない又は実装しないContent-*(例えば，Content-Range)ヘッダを無視してはならず，その場合には501(Not Implemented)応答を返却しなければならない。

POST要求とPUT要求との基本的な違いが，Request-URIの異なる意味に反映される。POST要求の中のURIは，含まれる実体を扱うことになる資源を識別する。その資源は，データ受理プロセス，他のプロトコルへのゲートウェイ又は注記を受理する別の実体であってよい。 それとは反対に，PUT要求におけるURIは，要求とともに含まれる実体を識別する。利用者エージェントはどのURIが意図されるかを知り，サーバはその要求を他の資源へ適用しようとしてはならない。要求が異なるURIに適用されることをサーバが望む場合，サーバは，301(Moved Permanently)応答を送らなければならない。そのとき，利用者エージェントは，宛先を切り替えて要求を送るかどうかに関して，それ自体の決定を行ってもよい。

一つの資源が，多くの異なるURIによって識別されてよい。例えば，一つの(ニュースの)記事は，各々の特定な版を識別するURIとは別の"現版"を識別するためのURIをもってよい。この場合，一般的な一つのURIに関するPUT要求が，原サーバによって定義されている幾つかの他のURIに帰結してもよい。

HTTP/1.1は，PUTメソッドが原サーバの状態にどのように影響するかを定義しない。

PUT要求は，8.2に示すメッセージ伝送要件に従わなければならない。

9.7 DELETE

DELETEメソッドは，原サーバがRequest-URIによって識別される資源を削除することを要求する。このメソッドは，原サーバ上での人の介入(又は他の手段)によって上書きされてもよい。クライアントは，たとえ原サーバから返される状態コードが動作が成功完了したことを示す場合であっても，操作が実行されたことを保証されるわけではない。しかし，サーバは，応答が与えられるときに，資源を削除したり，それをアクセス可能ではない位置に移動したりすることを意図しない場合には，成功を示すことは望ましくない。

成功応答は，応答が状態を示す実体を含む場合は200(OK)とし，動作がまだ行われていない場合は202(Accepted)とし，応答はOKだが実体を含まない場合は204(No Content)とすることが望ましい。

要求がキャッシュを通過し，Request-URIが一つ以上の現在のキャッシュされた実体を識別する場合，それらの実体は，新鮮でないとして扱われることが望ましい。このメソッドへの応答は，キャッシュ可能ではない。

9.8 TRACE

TRACEメソッドは，要求メッセージに関する遠隔のアプリケーション層ループバックを呼び出すのに使われる。要求の最終の受け手は，200(OK)応答の実体本体として，クライアントへ受け戻されるメッセージを反映することが望ましい。最終の受け手は，要求においてゼロ(0)のMax-Forwards値を受け取る原サーバ，最初のプロキシ又はゲートウェイのいずれかとする(14.31参照)。TRACE要求は，実体を含んではならない。

TRACEは，クライアントが，要求連鎖の他の端で何が受け取られているかを知り，検査情報又は診断情報のためにそのデータを使用することを可能にする。Viaヘッダフィールド(14.44参照)の値は，それが要求連鎖のトレースとして動作するので，特に重要になる。Max-Forwardsヘッダフィールドの使用は，クライアントが，メッセージを無限ループで回送するプロキシの連鎖を試験するために有用な要求連鎖の長さを制限することを可能にする。

成功した場合，応答は，"message/http"のContent-Typeをもつ実体本体の中に全要求メッセージを含むことが望ましい。このメソッドへの応答は，キャッシュされてはならない。

各状態コード(Status-Code)を次に示す。これには，それに続くことが可能なメソッド及び応答で要求されるメタ情報の記述が含まれる。

状態コードのこのクラスは，Status-Line及びオプションのヘッダだけから成る暫定的な応答を示し，空行で終端される。HTTP/1.0は1xx状態コードを定義しないので，サーバは，実験的な状況下以外では，HTTP/1.0クライアントに1xx応答を送信してはならない。

クライアントは，その要求を継続してもよい。この暫定的な応答は，クライアントに，サーバが要求の最初の部分を受信しまだ拒否はしていないことを知らせる。クライアントは，要求の残りを送信することによって継続するか，要求が既に完了している場合には，この応答を無視することが望ましい。サーバは，要求が完了した後で最終的な応答を送信しなければならない。

サーバは，クライアント要求を理解し，このコネクション上で使用されるアプリケーションプロトコルの変更に対し，Upgradeメッセージヘッダフィールド(14.41参照)によって，その要求に従う準備がある。サーバは，101応答を終端する空行のすぐ後にある応答のUpgradeヘッダフィールドが定義するものに，プロトコルを切り替える。

プロトコルは，切替えを行うことに利点がある場合にだけ切り替えられる。例えば，HTTPのより新しい版への切替えは，古い版よりも利点があり，実時間の同期型プロトコルへの切替えは，それら機能を使用する資源を配布する場合に，利点がある。

状態コードのこのクラスは，クライアントの要求が成功的に受信され，理解され，受諾されたことを示す。

要求は成功した。応答と共に返却される情報は，要求で使用されたメソッドに依存する。例えば，幾つかのメソッドに対するものを次に示す。

GET

要求された資源に対応する実体は，応答の中で送信される。

HEAD

要求された資源に対応す実体ヘッダフィールドは，いかなるメッセージ本体も伴わない応答の中で送信される。

POST

動作の結果を記述する又は含む実体。

TRACE

末端サーバが受信するとおりの要求メッセージを含む実体。

要求は果され，新しい資源の生成が行われる。新しく生成された資源は，応答の実体で返却されるURIで参照できる。応答は，Locationヘッダフィールドが与える資源に対して最も的確なURLをもっている。原サーバは，201状態コードを返却する前に資源を生成しなければならない。その動作をすぐに実行できない場合には，サーバは，代わりに，202(Accepted)応答を使って応答することが望ましい。

要求は処理のために受諾されたが，その処理は完了していない。要求は，実際に処理が行われるときに許可されなくてもよいので，実際には実行されてもされなくてもよい。これらの非同期操作から生じる状態コードを再送信するための機能は存在しない。

202応答は，意図的に，確定的でないとする。この目的は，サーバが，(恐らく1日に1回だけ実行されるバッチ指向の処理などの)他の処理の要求を，処理が完了するまで利用者エージェントのサーバへのコネクションの継続を要求することなしに，受諾できるようにすることにある。この応答と共に返却される実体は，要求の現在の状態への指示と，状態モニタへのポインタ，又は利用者が要求が果されると期待できる時の見積もり，とを含むことが望ましい。

実体ヘッダで返却されるメタ情報は，原サーバからの利用可能とされる確定的な集合ではなく，局所的な又は第3者的なコピーから集められている。与えられる集合は，原版の部分集合又は原版を含む集合であってもよい。例えば，資源についての局所的な注記情報を含む場合は，原サーバが知っているメタ情報を含む集合となる。この応答コードの使用は必須ではなく，使用しない場合に応答が200(OK)となるときにだけ適切とする。

サーバは要求を果したが，送り返す情報が存在しない。クライアントが利用者エージェントの場合は，要求の送信を引き起こした文書ビューをを変更しないほうがよい。この応答は，第一義的には，利用者エージェントの活動的な文書ビューを変更することなしに入力が動作を起こせることを意図している。応答は，実体ヘッダの形式に新しいメタ情報を含んでもよい。ただし，利用者エージェントの活動的なビューにおける現時点で文書に適用することが望ましい。

204応答は，メッセージ本体を含んではならない。そこで，この応答は，ヘッダフィールドの後の最初の空行によって，常に終端される。

サーバは要求を果したが，利用者エージェントは，要求の送信を引き起こした文書ビューをリセットすることが望ましい。この応答は，第一義的には，入力が利用者入力経由で動作を起こすことを可能にし，それに続けて，利用者が他の入力動作を容易に開始できるように入力を与えるフォームをクリアすることを意図している。応答は，実体を含んではならない。

サーバは，資源に対する部分的なGET要求を果した。要求は，望まれる範囲を示すRangeヘッダフィールド(14.36参照)を含んでいなければならない。応答は，この応答で含まれる範囲を示すContent-Rangeヘッダフィールド(14.17参照)、又は各パートのためのContent-Rangeフィールドを含むmultipart/byteranges Content-Typeのいずれかを含まなければならない。multipart/byterangesを使用しない場合には，応答におけるContent-Lengthヘッダフィールドは，メッセージ本体で伝送されるオクテットの実際の数に一致しなければならない。

Range及びContent-Rangeのヘッダをサポートしないキャッシュは，206(Partial)応答をキャッシュしてはならない。

状態コードのこのクラスは，要求を果すために利用者エージェントが更なる動作を行う必要があることを示す。要求される動作は，2番目の要求で使用されるメソッドがGET又はHEADの場合に限り，利用者との相互作用なしに利用者エージェントが実行してもよい。利用者エージェントは，要求を5回を超えて自動的に要求を宛先切替えしない方がよい。これは，こうした宛先切替えが通常は無限ループを示すことによる。

要求された資源は，それぞれがそれ自体固有の位置をもつ表現の集合におけるいずれか一つに対応し，利用者(又は利用者エージェント)が好ましい表現を選別しその要求をその位置に宛先切替えできるように，エージェント駆動の折衝情報(12参照)が提供中になっている。

それがHEAD要求でなかった場合には，応答は，利用者又は利用者エージェントが最も適切な一つを選択できる資源の特徴及び位置のリストを包含する実体を含むことが望ましい。実体フォーマットは，Content-Typeヘッダフィールドで与えられるメディア型によって指定される。フォーマット及び利用者エージェントの能力に依存して，最も適切な選択の選別が，自動的に実行されてもよい。しかし，この規定は，それら自動選別の標準を定義しない。

サーバが表現の好ましい選択をもっている場合，サーバは，Locationフィールドにその表現に対する特定のURLを含むことが望ましい。利用者エージェントは，自動宛先切替のためにLocationフィールド値を使用してもよい。この応答は，特に断らない場合には，キャッシュ可能とする。

要求された資源は，新しい永久的なURIを割り当てられており，この資源への今後の参照は，返却されたURI群の一つを使用して行われることが望ましい。リンク編集能力をもつクライアントは，可能な場合には，自動的に，Request-URIへの参照をサーバが返却する新しい参照の一つ以上に再リンクすることが望ましい。この応答は，特に断らない場合には，キャッシュ可能とする。

新しいURIが位置の場合，そのURLは，応答におけるLocationフィールドによって与えられることが望ましい。要求メソッドがHEADではなかった場合には，応答の実体は，新しいURIへのハイパリンクをもつ短いハイパテキストの備考を含むことが望ましい。

301状態コードがGET又はHEAD以外の要求への応答で受信される場合，利用者エージェントは，利用者が確認できないときに，自動的に要求を宛先切替えしてはならない。これは，宛先切替えが，要求が発行された際の条件を変更するかもしれないことによる。

備考　 301状態コードを受信した後でPOST要求を自動的に宛先切替えする場合，既存のHTTP/1.0利用者エージェントの中には，間違ってそれをGET要求に変更するものがある。

要求された資源は，一時的に，異なるURIの下に存在する。この宛先切替えは変更されてよいときもあるので，クライアントは，今後の要求に対して，Request-URIを使用し続けることが望ましい。この応答は，Cache-Controlヘッダフィールド又はExpiresヘッダフィールドによって示される場合にだけ，キャッシュ可能とする。

新しいURIが位置の場合，そのURLは，応答におけるLocationフィールドによって与えられることが望ましい。要求メソッドがHEADではなかった場合には，応答の実体は，新しいURIへのハイパリンクをもつ短いハイパテキストの備考を含むことが望ましい。

302状態コードがGET又はHEAD以外の要求への応答で受信される場合，利用者エージェントは，利用者が確認できないときに，自動的に要求を宛先切替えしてはならない。これは，宛先切替えが，要求が発行された際の条件を変更するかもしれないことによる。

備考　 302状態コードを受信した後でPOST要求を自動的に宛先切替えする場合，既存のHTTP/1.0利用者エージェントの中には，間違ってそれをGET要求に変更するものがある。

要求への応答は，異なるURIで見つけることができ，その資源に関してGETメソッドを使って検索することが望ましい。このメソッドは，第一義的には，POSTが活性化するスクリプトの出力が利用者エージェントを選別された資源へと宛先切替えすることが可能となるために存在する。新しいURIは，元の要求された資源に対して代用となる参照ではない。303応答はキャッシュ可能ではないが，2番目の(宛先切替えされる)要求の応答は，キャッシュ可能でもよい。

新しいURIが位置の場合，そのURLは，応答におけるLocationフィールドによって与えられることが望ましい。要求メソッドがHEADではなかった場合には，応答の実体は，新しいURIへのハイパリンクをもつ短いハイパテキストの備考を含むことが望ましい。

クライアントが条件付きGET要求を実行しておりアクセスは許可されているが，文書が修正されていない場合には，サーバは，この状態コードで応答することが望ましい。応答は，メッセージ本体を含んではならない。

応答は，次のヘッダフィールドを含まなければならない。

• Date。
• ETag及び/又はContent-Location。ただし，ヘッダが，同じ要求への200応答で送信されている場合とする。
• Expires，Cache-Control及び/又はVary。ただし，field-valueが同じ変形に対して，以前の応答で送信されたものとは異なるかもしれない場合とする。

条件付きGETが強キャッシュ有効性検証子(13.3.3)を使用していた場合，応答は，他の実体ヘッダを含まないことが望ましい。そうでない場合には(すなわち，条件付きGETが弱有効性検証子を使用していた場合には)，応答は，他の実体ヘッダを含んではならない。これは，キャッシュされた実体本体と更新されたヘッダとの間の矛盾を防ぐ。

304応答が現在キャッシュされていない実体を指し示す場合には，キャッシュは，応答を無視し，無条件に要求を繰り返さなければならない。

キャッシュがキャッシュエントリを更新するために受信した304応答を使用する場合には，キャッシュは，応答で与えられる新しいフィールド値を反映するためにエントリを更新しなければならない。

304応答は，メッセージ本体を含んではならない。そこで，常に，ヘッダフィールドの後の最初の空行によって終端される。

要求された資源は，Locationフィールドが与えるプロキシを通じてアクセスされなければならない。Locationフィールドは，プロキシのURLを与える。受け手は，プロキシ経由で要求を繰り返すことが期待される。

状態コードの4xxクラスは，クライアントが間違いをしたと予想される場合を意図している。HEAD要求への応答の場合以外は，サーバは，エラー状況及びそれが一時的な条件か又は永久的な条件かの説明を包含する実体を含むことが望ましい。これらの状態コードは，あらゆる要求メソッドに適用可能とする。利用者エージェントは，含まれる実体を利用者エージェントに表示することが望ましい。

備考　 クライアントがデータを送信中の場合，TCPを使用しているサーバ実装は，サーバが入力コネクションを閉じる前に，応答を含むパケットの受信をクライアントが確認していることを注意深く確かめることが望ましい。クライアントがコネクションを閉じた後もサーバにデータを送信し続けている場合には，サーバのTCPスタックは，クライアントへのパケットをリセットする。これによって，クライアントの未確認の入力バッファをHTTPアプリケーションが読み込んで解釈可能とする前に削除してもよい。

要求は，正しくない構文のためにサーバによって理解不可能であった。クライアントは，修正なしにその要求を繰り返さない方がよい。

要求は，利用者認証を必要とする。応答は，要求された資源に適用可能なチャレンジ(挑戦，challenge)を含むWWW-Authenticateヘッダフィールド(14.46)を含まなければならない。クライアントは，適切なAuthorizationヘッダフィールド(14.8)を伴った要求を繰り返してもよい。要求が既にAuthorization身分証明書を含んでいた場合には，401応答は，認定がその身分証明書に対して拒否されたことを示す。401応答が先行する応答と同じチャレンジを含み，利用者エージェントが既に少なくとも1度は認証を試みた場合には，利用者に，応答で与えられた実体が表示されることが望ましい。これは，その実体が関連する診断情報を含んでいてもよいことによる。HTTPアクセス認証は，11で示す。

このコードは，将来の使用のために予約されている。

サーバは要求を理解したが，それを果たすことを拒否している。認定は役に立たないし, 要求は繰り返さない方がよい。要求メソッドがHEADでなく，サーバが要求が果たされなかった理由を公開したい場合には，サーバは，実体に拒否の理由を記述することが望ましい。この状態コードは，サーバが要求が拒否された理由を明らかにしたくない場合，又は他の応答が適用可能ではない場合にも，共通的に使用される。

サーバは，Request-URIと一致するものを見出せなかった。この条件が一時的か永久的かの指示は与えられない。

サーバがこの情報をクライアントに利用可能としたくない場合には，状態コード403(Forbidden)を変わりに使用できる。410(Gone)状態コードは，サーバが，何らかの内部的に構成可能な機構を通じて，古い資源は永久に使用可能ではなく転送先アドレスが分からない場合に，使用することが望ましい。

Request-Lineで指定されたメソッドは，Request-URIによって識別される資源に対して許容されない。応答は，要求された資源に対して有効なメソッドのリストを含むAllowヘッダを含んでいなければならない。

要求が識別する資源は，要求において送信された受諾ヘッダに従って，受諾可能ではない内容特徴をもつ応答実体を生成することだけができる。

要求がHEAD要求でなかった場合には，応答は，利用者又は利用者エージェントがその中から最も適切な一つを選択できる利用可能な実体の特徴及び位置のリストを包含する実体を含むことが望ましい。実体のフォーマットは，Content-Typeヘッダフィールドに与えられるメディア型によって指定される。利用者エージェントのフォーマット及び能力に依存して，最適選択の選別を自動的に行ってもよい。しかし，この規定は，それら自動的な選別に対するいかなる標準も定義しない。

備考　 HTTP/1.1サーバは，要求で送信された受諾ヘッダに従って受諾可能ではない応答を返却してもよい。406応答を送信するよりもこの方が望ましい場合もある。利用者エージェントは，受諾可能かどうか決定するために到着する応答のヘッダを審査することが望ましい。応答が受諾可能ではない場合，利用者エージェントは，一時的にそれ以上のデータの受信を停止し，更なる動作の決定を求めて利用者に問い合わせることが望ましい。

このコードは，401(Unauthorized)と類似しているが，クライアントが，プロキシを伴ったそれ自体を最初に認証しなければならないことを示す。プロキシは，要求される応答のためにプロキシに適用可能なチャレンジを含むProxy-Authenticateヘッダフィールド(14.33)を返却しなければならない。クライアントは，適切なProxy-Authorizationヘッダフィールド(14.34)をもつ要求を再送してもよい。HTTPアクセス認証については，11.で示す。

クライアントは，サーバの待機時間内に要求を生成できなかった。クライアントは，後で，修正なしでその要求を繰り返してもよい。

要求は，資源の現在の状態と矛盾するために完了できなかった。このコードは，利用者が矛盾を解決し要求を再提出できるかもしれないと期待される状況においてだけ許される。応答の本体は，利用者が矛盾の源を認識するために十分な情報を含んでいることが望ましい。理想的には，応答の実体は，利用者又は利用者エージェントが問題を解決するために順文和情報を含んでいるものとする。しかし，それは可能ではないかもしれないので，必須とはしない。

矛盾は，PUT要求への応答において発生することが最も多い。版管理機構が使用されており，PUT(要求)の実体が，それ以前の(第3者の)要求によってなされた資源への変更と矛盾する(PUTによる)資源への変更を含む場合には，サーバは，その要求を完了できないことを示す409応答を使用してもよい。この場合，応答の実体は，応答のContent-Typeが定義するフォーマットで二つの版の間の差異のリストを含むことが望ましい。

要求された資源が，もはやサーバで利用可能ではなく，回送するアドレスは分からない。この条件は，永久的と見なすのがよい。リンク編集の能力をもつクライアントは，利用者の承認の後に，そのRequest-URIへの参照を削除することが望ましい。サーバが，条件が永久的かどうか分からない，又は決定する能力をもたない場合には，状態コード404(Not Found)を代わりに使用することが望ましい。この応答は，特に断らない場合には，キャッシュ可能とする。

410応答は，第一義には，資源が意図的に利用不可能になっており，サーバの所有者はその資源への遠隔リンクが取り除かれることを望んでいる，ということを受け手に通知することによって，ウェブの維持管理の作業を支援することを意図している。こうした事態は，時間限定の宣伝サービスとか，サーバのサイトでもはや働いていない個人に属する資源に対してよくあることである。すべての永久的に利用不可能な資源を"消滅(gone)"と印を付ける，又はその印を任意の時間保持する，ということは必要ではない。それは，サーバの所有者の判断に任される。

サーバは，定義されたContent-Lengthをもたない要求を受諾することを拒否する。クライアントは，要求メッセージの中のメッセージ本体の長さを含む有効なContent-Lengthヘッダフィールドを追加する場合には，その要求を繰り返してもよい。

一つ以上の要求ヘッダフィールドで与えられる事前条件が，サーバで試験されたときに，偽(条件が満たされない)と評価された。この応答コードは，クライアントが現在の資源のメタ情報(ヘッダフィールドデータ)に事前条件をおくことを可能にし，要求されたメソッドが意図された資源以外の資源に適用されることを防ぐ。

要求実体が，サーバが処理する用意がある又は処理可能であるものよりも大きいために，サーバは，要求の処理を拒否している。サーバは，クライアントが要求を継続するのを防ぐために，コネクションを閉じてもよい。

(拒否の)条件が一時的な場合，サーバは，一時的でありクライアントは少し後で再び試みてもよいということを示すために，Retry-Afterヘッダフィールドを含めることが望ましい。

Request-URIが，サーバが解釈する用意がある以上に長いので，要求をサービスすることを拒否している。このまれな条件は，クライアントがPOST要求を長い問合せ情報をもつGET要求に不正に変換した場合，クライアントが宛先切替えのURL"ブラックホール"(例えば，宛先切替えしたURLの接頭辞が，それ自体の接尾辞を指す，など。)に落ち込んでしまった場合，又はRequest-URIを読むため若しくは操作するために固定長バッファを使うサーバに存在するセキュリティホールを見つけようとする，クライアントの企てによる攻撃にサーバがさらされている場合にだけ，発生することが多い。

要求の実体が，要求されたメソッドに対する要求された資源によってサポートされていないフォーマットになっているために，サーバは，要求をサービスすることを拒否している。

数字"5"で始まる応答状態コードは，サーバが要求の実行を誤る又は実行できないと気付いた場合を示す。HEAD要求に応答する場合を除いて，サーバは，エラー状況の説明及びそれが一時的なのか永久的なのかを含む実体を(応答に)含めることが望ましい。利用者エージェントは，利用者に含まれている実体を表示するのがよい。ここに示す応答コードは，あらゆる要求メソッドに対して適用可能とする。

サーバは，要求を果たすことを阻む予想しない条件に出会った。

サーバは，要求を果たすために必要な機能をサポートしていない。これは，サーバが要求メソッドを認識できずいかなる資源に対してもその要求メソッドをサポートできない場合に，適切な応答とする。

サーバは，ゲートウェイ又はプロキシとして動作しているのだが，要求を果たそうとしてアクセスした上流サーバから有効ではない応答を受信した。

サーバは，現在，サーバの一時的な過負荷又は保守管理のために要求を扱うことができない。これは，ある猶予時間の後に軽減する一時的な条件であることを示唆している。分かる場合には，猶予時間の長さをRetry-Afterヘッダに示してもよい。Retry-Afterが与えられない場合には，クライアントは，500応答に対するものとしてその応答を扱うことが望ましい。

備考　 503状態コードが存在するからといって，サーバは過負荷になった場合にはそれを使わなければならないというわけではない。単にコネクションを拒否しようとするサーバがあってもよい。

サーバは，ゲートウェイ又はプロキシとして動作しているのだが，要求を完了しようとしてアクセスした上流サーバから適時な応答を受信できなかった。

サーバは，要求メッセージで使用されていたHTTPプロトコルの版をサポートしていない，又はサポートすることを拒否している。サーバは，このエラーメッセージを用いずに，3.1で示すとおりに，クライアントと同じ主版(数)を使った要求を完了できない又は完了する気がないことを示している。応答は，その版をサポートしない理由及び他のどのプロトコルをそのサーバはサポートするかを示す実体を含むことが望ましい。

HTTPは，単純なチャレンジ応答認証機構を提供する。この機構は，サーバがクライアント要求にチャレンジを与え，クライアントが認証情報を提供するために使用してよい。HTTPは，この認証方式を識別するための拡張可能な大文字・小文字を区別するトークン(token)を使用し，それに，その方式を通して認証を達成するために必要なパラメタを運ぶ属性及び値の対のコンマで区切ったリストを続ける。

          auth-scheme    = token

          auth-param     = token "=" quoted-string

401(Unauthorized)応答メッセージは，原サーバが利用者エージェントの認定にチャレンジを与えるために使用する。この応答は，要求された資源に適用可能な少なくとも一つのチャレンジ(challenge)を含むWWW-Authenticateヘッダフィールドを含まなければならない。

          challenge      = auth-scheme 1*SP realm *( "," auth-param )

          realm          = "realm" "=" realm-value
          realm-value    = quoted-string

realm属性(範囲属性。大文字・小文字は区別しない。)が，チャレンジを発行するすべての認証方式に対して要求される。範囲値(realm-value。大文字・小文字は区別しない。)は，アクセスされているサーバの正準ルートURL(5.1.2参照)を結合することで，保護空間を定義する。これら範囲によって，サーバ上の保護される資源は，それ自体の認証方式及び/又は認定データベースをもつ保護空間の集合に分割可能となる。範囲値は，一般に原サーバが割り当てる文字列であって，認証方式に特有の付加的なセマンティクスをもっていてもよい。

必ずしもそうとはいえないが，通常，401応答又は411応答を受け取った後に，それ自体をサーバに認証させることを望む利用者エージェントは，その要求をもつAuthorizationヘッダフィールドを含めることによって行ってもよい。Authorizationフィールド値は，要求されている資源の範囲に対する利用者エージェントの認証情報を含む身分証明書(credentials)から構成される。

          credentials    = basic-credentials
                         | auth-scheme #auth-param

利用者エージェントが自動的に身分証明を適用できる領域は，保護空間が決定する。先行する要求が認定されている場合，同じ身分証明書が，認証方式，パラメタ及び/又は利用者の好みが決定するある期間の間，その保護空間内のすべての他の要求のために再利用されてもよい。認証方式が他の方法で定義しない限り，一つの保護空間をそのサーバの有効範囲の外部に拡張することはできない。

サーバが要求を用いて送られた身分証明書を受諾したくない場合，サーバは，401(Unauthorized)応答を返すことが望ましい。応答は，要求された資源に適用可能な(恐らく新しい)チャレンジ及びその拒否を説明する実体を含むWWW-Authenticateヘッダフィールドを含まなければならない。

HTTPプロトコルは，応用を，アクセス認証のためのこの単純なチャレンジ応答機構に制限しない。トランスポートレベル又はメッセージカプセル化を通じた暗号化，及び認証情報を指定する付加的なヘッダフィールドの使用といった，付加的な機構を使用してもよい。しかし，これら付加的な機構は，この規定では定義しない。

プロキシは，利用者エージェント認証に関して完全に透過的でなければならない。すなわち，プロキシは，WWW-Authenticateヘッダ及びAuthorizationヘッダには触れずに回送し，14.8に示す規則に従わなければならない。

HTTP/1.1によって，クライアントは，Proxy-Authenticateヘッダ及びProxy-Authorizationヘッダを通じて，認証情報をプロキシに渡しプロキシから得ることができる。

"基本"認証方式は，利用者エージェントが，各範囲に対して，利用者ID及びパスワードを用いてそれ自体を認証しなければならないというモデルに基づいている。範囲値は，そのサーバ上の他の範囲との同等性のためにだけ比較可能な不透明な(中の見えない)文字列と考えるのがよい。サーバは，Request-URIの保護空間に対する利用者ID及びパスワードを有効性検証できた場合にだけ，その要求をサービスする。オプションの認証パラメタは存在しない。

サーバは，保護空間内のURIに対して未認定の要求を受信した場合，次のようなチャレンジで応答してよい。

          WWW-Authenticate: Basic realm="WallyWorld"

ここで，"WallyWorld"は，Request-URIの保護空間を識別するためにサーバが割り当てた文字列とする。

認定を受信するためには，クライアントは，一つのコロン(":")文字で分離された利用者ID(userid)及びパスワード(password)を，身分証明書の中のbase64符号化された文字列の内部に入れて送信する。

          basic-credentials = "Basic" SP basic-cookie

          basic-cookie   = <user-passのbase64 [7]符号化。
                           ただし，1行に76文字までという制限はない。>

          user-pass   = userid ":" password

          userid      = *<":"を除くTEXT>

          password    = *TEXT

利用者ID(userid)は，大文字・小文字を区別するかもしれない。

利用者エージェントが，利用者ID(userid)"Aladdin"及びパスワード(password)"open sesame"を送信したい場合には，次のヘッダフィールドを使用することになる。

          Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

基本認証と関連するセキュリティへの配慮については，15.を参照すること。

HTTPに対するダイジェスト認証は，RFC 2069[32]で規定される。

大部分のHTTP応答は，人間の利用者が解釈するための情報を含む実体を含んでいる。当然だが，要求に対応した"最もよく利用可能な"実体を利用者に供給するのが望ましい。サーバ及びキャッシュにとっては不幸なことだが，すべての利用者が何が"最もよい"かについて同じ好みをもっているわけではないし，すべての利用者エージェントがすべての実体型を等しくレンダリングする能力をもっているわけではない。そのために，HTTPは，"内容折衝"のために幾つかの機構を準備している。ここで，"内容折衝"とは，複数の表現が利用可能な場合，与えられた応答に対して最もよい表現を選別する処理のこととする。

備考　 これを"フォーマット折衝"とは呼ばない。これは，代替表現が同じメディア型であってもよいが，その型の異なる機能を使用する，異なる言語で記述されている，などであってもよいことによる。

エラー応答を含んだ，実体本体を含むあらゆる応答は，折衝に従ってよい。

HTTPで可能な内容折衝には，サーバ駆動折衝及びエージェント駆動折衝の2種類がある。これら2種類に折衝は直交しており(相互に依存せず)，そのために，分離して又は結合して使用してよい。透過的折衝として参照される結合の一つの方法は，キャッシュが，その後の要求に対するサーバ駆動折衝を提供するために，原サーバによって提供されるエージェント駆動折衝情報を使用する場合に発生する。

応答に対する最もよい表現の選別がサーバに位置するアルゴリズムによって行われる場合，これをサーバ駆動折衝と呼ぶ。選別は，応答の利用可能な表現(すなわち，応答で変化できる範囲，例えば，言語，内容符号化など。)及び要求メッセージの中の特定のヘッダフィールドの内容，又は要求に関係するその他の情報(クライアントのネットワークアドレスなど)に基づく。

サーバ駆動折衝は，利用可能表現からの選別のためのアルゴリズムが利用者エージェントには記述困難な場合，又はサーバが最初の応答と一緒にクライアントにサーバの"最もよい予想"を送信したい場合に利点がある。例えば，サーバの"最もよい予想"が利用者に十分よい場合には，それに続く要求の一往復時間の遅延を避けることを，サーバは期待している。サーバの予想を改善するために，利用者エージェントは，それら応答に対する利用者エージェントの好みを記述した要求ヘッダフィールド(Accept，Accept-Language，Accept-Encodingなど)を含めてもよい。

サーバ駆動折衝には，次の不都合がある。

HTTP/1.1は，利用者エージェントの能力及び利用者の好みを通じてサーバ駆動折衝を可能するために，Accept(14.1参照)，Accept-Charset(14.2参照)，Accept-Encoding(14.3参照)，Accept-Language(14.4参照)，及びUser-Agent(14.42参照)の要求ヘッダフィールドを含む。しかし，原サーバはこれらの範囲に制限されず，要求ヘッダフィールドの外部の情報又はこの規定が定義しない拡張ヘッダフィールド内の情報を含む，要求のあらゆる様相に基づいて応答を変化させてもよい。

HTTP/1.1の原サーバは，サーバ駆動折衝に基づいたあらゆるキャッシュ可能な応答の中に，適切なVaryヘッダフィールド(14.43参照)を含めなければならない。Varyヘッダフィールドは，応答が変化するかもしれない範囲(すなわち，原サーバが，複数の表現から"最もよいと予想する"応答を取り上げる範囲。)を記述する。

HTTP/1.1の公開キャッシュは，Varyヘッダフィールドが応答に含まれていて，それが13.6で示すキャッシュ化と内容折衝との間の相互作用を記述している要件に従っている場合には，そのフィールドを認識しなければならない。

エージェント駆動折衝では，応答に対する最もよい表現の選別は，原サーバからの初期応答を受信した後で利用者エージェントが実行する。選別は，特定のヘッダフィールド(この規定は，19.6.2.1で示すとおりフィールド名Alternatesを予約する。)又は初期応答の実体本体の内部に含まれる応答の利用可能な表現の，各表現がそれ自体のURIによって識別されているリストに基づく。幾つかの表現の中からの選別は，(利用者エージェントが可能な場合には，)自動的に行ってもよいし，生成された(恐らくハイパテキストの)メニューから利用者が選択することによって人間が行ってもよい。

エージェント駆動折衝は，応答が(型，言語又は符号化といった)共通に使用される範囲を変化する場合，原サーバが要求を調査することで利用者エージェントの能力を決定できない場合，及び一般に公開キャッシュがサーバの負荷を分散しネットワークの利用を減らすために使用される場合に，有利になる。

エージェント駆動折衝は，最もよい代替表現を得るために2回目の要求を必要とする点は不利になる。この2回目の要求は，キャッシュを使用する場合にだけ効率化できる。さらに，この規定は，自動的な選別をサポートするいかなる機構も定義しない。しかし，それら機構を，拡張として開発しHTTP/1.1内で使用することを禁止するものでもない。

HTTP/1.1は，サーバがサーバ駆動折衝を使用して様々な応答を提供することを望んでいない又はできない場合，エージェント駆動折衝を可能とするために，300(Multiple Choices)及び406(Not Acceptable)の状態コードを定義する。

透過的な折衝は，サーバ駆動折衝及びエージェント駆動折衝の両方の結合とする。キャッシュが(エージェント駆動折衝におけるとおりに)応答の利用可能な表現のリストの形式とともに供給されていて，変化の範囲がそのキャッシュによって完全に理解されている場合，キャッシュは，その資源に関する後続の要求に対して原サーバの代わりにサーバ駆動折衝を実行可能になる。

透過的な折衝は，原サーバに要求される折衝の仕事を分散し，キャッシュが正しい応答を正しく予想できる場合にはエージェント駆動折衝の2回目の要求の遅延を取り除くという利点をもつ。

この規定は，透過的な折衝のいかなる機構も定義しない。しかし，それら機構を，拡張として開発しHTTP/1.1内で使用することを禁止もしない。透過的な折衝を実行するHTTP/1.1のキャッシュは，すべてのHTTP/1.1クライアントとの正しい相互操作を確実にするために応答をキャッシュ可能な場合には，(変化の範囲を定義する)Varyヘッダフィールドを応答に含めなければならない。原サーバが供給するエージェント駆動折衝情報は，透過的に折衝される応答とともに含まれることが望ましい。

HTTPは，典型的には，分散情報システムに使用される。このシステムでは，応答キャッシュの使用によって性能が改善される。HTTP/1.1プロトコルは，可能な限りキャッシュ作業を行うことを意図した多くの要素を含む。これらの要素はプロトコルの他の様相と不可分で互いに相互作用しているので，HTTPの基本的なキャッシュ化の設計を，メソッド，ヘッダ，応答コードなどの詳細な記述とは分離して示すのが役に立つ。

キャッシュは，性能をそれ程は改善しない場合には意味がない。HTTP/1.1のキャッシュの目標は，多くの場合に要求の送信の必要性をなくし，他の多くの場合に完全な応答の送信の必要性をなくすことにある。前者は，多くの操作に要求されるネットワーク1往復の回数を減らす。このために，"有効期限切れ"機構(13.2参照)を使用する。後者は，ネットワーク帯域幅要件を減らす。このためには，"有効性検証"機構(13.3参照)を使用する。

性能，利用可能性及び分離された操作に対する要件は，意味的に透過になるという目標を緩和できることを要求する。HTTP/1.1プロトコルは，原サーバ，キャッシュ及びクライアントが必要な場合には透過性を明示的に軽減できるようにする。しかし，非透過的な操作は，専門家ではない利用者を混乱させるかもしれないし，(商品の注文といった)あるサーバプリケーションとは互換性がないかもしれないので，次の場合にだけ，プロトコルは透過性の緩和を要求する。

• クライアント又は原サーバによって緩和される場合には，明示的なプロトコルレベルの要求によってだけ行う。
• キャッシュ又はクライアントによって緩和される場合には，末端利用者に明示的な警告を示すことによってだけ行う。

ぞこで､HTTP/1.1プロトコルは，次の重要な要素を提供する。

基本的な原理は，クライアントが意味的透過性の潜在的な緩和を検知できなければならないこと，とする。

備考　 サーバ，キャッシュ又はクライアントの実装者は，この規定では明示的に議論しない設計の決定に直面するかもしれない。決定が意味的透過性に影響を与えるかもしれない場合には，実装者は，注意深い完全な解析によって透過性を壊すことに重要な利点があると示されない場合には，(決定が誤りのときには)透過性を維持する側に誤るほうがよい。

正しいキャッシュは，要求に適切なキャッシュが保持する最も最近に更新された応答(13.2.5，13.2.6及び13.12参照)で，次の条件の一つを満たす応答を，その要求に応答しなければならない。

キャッシュが原サーバと通信できない場合，正しいキャッシュは，応答をキャッシュから正しく提供できるときには，上記のとおりに応答することが望ましい。キャッシュから正しく提供できない場合には，通信失敗があったことを示すエラー又は警告を返さなければならない。

キャッシュが要求しているクライアントに正常に回送する応答[完全な応答又は304(Not Modified)応答]を受信し，受信した応答がもはや新鮮でない場合，キャッシュは，新しいWarningを追加することなしに(ただし既存のWarningヘッダを取り除かずに)，要求しているクライアントにその応答を回送するのがよい。キャッシュは，その応答が通過中に新鮮でなくなったという理由だけで，応答を有効性再検証しようとはしないほうがよい。これは，無限ループを生じるかもしれない。Warningをもたない新鮮でない応答を受信した利用者エージェントは，利用者に警告の指示を表示してもよい。

キャッシュが直接でもなく(13.1.1の条件b)の意味で)"十分に新鮮"でもない応答を返すときにはいつでも，Warning応答ヘッダを使い，その効果への警告を添付しなければならない。この警告によって，クライアントは適切な動作をとることができる。

警告は，キャッシュに関係する目的及びそれ以外の目的の両方のために使用してもよい。エラー状態コードとは違い，警告の使用は，これらの応答を真の失敗と区別する。

警告は，常にキャッシュ可能とする。これは，警告が応答の透過性を弱めることは決してないことによる。このことは，危険なしに，警告をHTTP/1.0のキャッシュに渡すことができることを意味する。それらHTTP/1.0のキャッシュは，応答の中の実体ヘッダとして，単に警告をそのまま渡す。

警告は，0〜99の数が割り当てられる。この規定は，現在割り当てられている警告のコード番号及び意味を定義する。これによって，クライアント又はキャッシュは，幾つかの場合に(ただしすべての場合ではないが)，自動化された動作をとることができる

警告は，警告テキストを運んでもよい。そのテキストは，(恐らくクライアントのAcceptヘッダに基づいた)あらゆる適切な自然言語で記述されてよく，どの文字集合を使用するかの指示をオプションで含んでもよい。

複数の警告が，(原サーバ又はキャッシュのいずれかによって)一つの応答に添付されてもよい。これには，同じコード番号をもつ複数の警告が含まれる。例えば，サーバは，英語及びバスク語の両方で書かれたテキストをもつ同じ警告を提供してもよい。

複数の警告が一つの応答に添付される場合，それらのすべてを利用者に表示することは，実際的ではないし理にかなっているわけでもないかもしれない。HTTPのこの版は，どの警告を表示するのがよいか，及びどの順番で表示するのがよいかを決定する厳密な優先順位付け規則を規定しない。ただし，幾つかの発見的な手法は提案する。

Warningヘッダ及び現在定義されている警告は，14.45で示す。

HTTP/1.1における基本的なキャッシュ機構(サーバ指定の有効期限切れ時間及び有効性検証)は，キャッシュに対しては暗黙的な指令とする。サーバ又はクライアントが，HTTPキャッシュに対して明示的な指令を提供することが必要な場合もあってよい。この目的には，Cache-Controlヘッダを使用する。

Cache-Controlヘッダは，クライアント又はサーバが，要求又は応答のどちらかにおける様々な指令を伝送することを可能にする。これらの指令は，典型的には，デフォルトのキャッシュ化アルゴリズムを上書きする。一般的な規則として，ヘッダ値の間で明らかな矛盾が存在する場合には，最も制限的な解釈(すなわち，意味的透過性を保持することが最も可能な解釈)を適用するのがよい。しかし，例えば，"max-stale"，"public"など，意味的透過性の近似を弱めるものとしてCache-Control指令を明示的に指定する場合もある。

Cache-Control指令は，14.9で詳細に示す。

多くの利用者エージェントは，利用者が基本的なキャッシュ化機構を上書きすることを可能にする。例えば，利用者エージェントは，利用者が，キャッシュされた実体を，明示的に新鮮ではない実体であっても，決して有効性検証しないと指定できるものとする。そうしないと，利用者は，習慣的に，"Cache-Control: max-stale=3600"をすべての要求に追加するかもしれない。利用者は，透過的ではない振る舞い，又は異常に非効率的なキャッシュを生じる振る舞いのいずれかを明示的に要求しなければならないことになる。

利用者が基本的なキャッシュ化機構を上書きした場合，利用者エージェントは，この上書きがサーバの透過性要件を満足しないかもしれない情報の表示を生じるときにはいつでも，特に，表示される実体が新鮮ではないと分かっている場合には，明示的に利用者に指示することが望ましい。プロトコルは，通常，利用者エージェントに応答が新鮮ではないかどうかを決定可能にするので，この指示は，実際に新鮮ではない事態が発生した場合にだけ表示する必要がある。指示は，対話ボックスである必要はなく，(例えば，腐っている魚の絵といった)アイコン又は他の視覚的な指示子であってよい。

利用者が，キャッシュの効率性を異常に低くする方法でキャッシュ化機構を上書きした場合には，利用者エージェントは，(例えば，燃えている通貨の絵といった)指示を表示し続けるのがよい。それによって，利用者は，うっかりと余分な資源を消費したり不必要な遅延に悩まされたりしなくて済む。

キャッシュの操作主体が，クライアントが要求をしない場合であっても，新鮮ではない応答を返すようにキャッシュを構成することを選択してもよい場合がある。この決定は，軽々しくは行われないことが望ましいが，利用可能性又は性能に関する理由のために，特に，キャッシュが原サーバと不完全に接続されている場合には，必要になることがある。キャッシュが新鮮ではない応答を返すときにはいつでも，キャッシュは，(Warningヘッダを使って)そのことを応答に印付けしなければならない。これによって，クライアントソフトウェアは，潜在的な問題が存在するかもしれないことを利用者に警告できる。

このことは，利用者エージェントが，(原サーバからの)直接の応答又は新鮮な応答を得るための段階を踏むことも可能にする。この理由のために，キャッシュは，クライアントが直接の応答又は新鮮な応答を明示的に要求している場合であって，技術的又は方針的な理由でそれに応じられない場合には，新鮮でない応答を返さないほうがよい。

原サーバ(及び多少拡張して応答の経過時間への寄与によっては中間キャッシュ)は，有効期限切れ情報の第1の源だが，クライアントが，キャッシュされた応答を有効性検証をしないで返すかどうかについてのキャッシュの決断を制御する必要があってもよい場合がある。クライアントは，Cache-Controlヘッダの幾つかの指令を使ってこれを行う。

クライアントの要求は，クライアントが有効性検証を行っていない応答を受諾してもよいとする最大経過時間を指定してよい。0値の指定は，キャッシュにすべての応答の有効性再検証を強制する。クライアントは，応答が有効期限切れになる前の残されている最小時間を指定してもよい。これらのオプションは，両方とも，キャッシュの振る舞いに関する制約を増加し，そのために一層，意味的透過性のキャッシュによる近似を緩和できなくする。

クライアントは，新鮮でない程度のある最大量までは，新鮮でない応答を受諾することを指定してもよい。これは，キャッシュの制約を緩め，原サーバが指定する意味的透過性上の制約に違反するかもしれないが，悪い接続状態に直面した場合の切断された操作又は高い利用可能性をサポートするためには必要かもしれない

HTTPのキャッシュ化は，キャッシュが原サーバに要求をすることを完全に避けることができる場合に，最もよく機能する。要求を避けるための基本的な機構は，ある応答を後続の要求を満足させるために使用してよいことを示すために，原サーバが将来における明示的な有効期限切れ時間を提供することとする。言い換えると，キャッシュは，まずサーバに連絡することなしに，新鮮な応答を返すことができる。

サーバは，未来の明示的な有効期限切れ時間を，その時間に到達する前には意味的に重要な点では実体が変化することはないという信念に基づいて．応答に割り当てる，ということを期待する。これは，サーバの有効期限切れ時間が注意深く選択されている限り，通常は，意味的透過性を保存する。

有効期限切れ機構は，キャッシュからの応答にだけ適用され，要求しているクライアントにすぐに回送する直接の応答には適用されない。

原サーバが意味的に透過的なキャッシュにすべての要求の有効性検証を強制する場合には，明示的な有効期限切れ時間を過去に割り当ててよい。これは，応答は常に新鮮ではなく，キャッシュは後続の要求に対してその応答を使用する前に有効性検証することが望ましいことを意味する。有効性再検証を強制するより制限的な方法については，14.9.4を参照すること。

原サーバがあらゆるHTTP/1.1キャッシュに，それがどのように構成されていても，すべての要求の有効性検証を強制することを望む場合，"must-revalidate"("有効性再検証をしなければならない") Cache-Control指令を使用することが望ましい(14.9参照)。

サーバは，Expiresヘッダ，又はCache-Controlヘッダの最大経過時間(max-age)指令のいずれかを使用して，明示的な有効期限切れ時間を指定する。

有効期限切れ時間は，利用者エージェントに，その表示を更新すること又は資源を再ロードすることを強制するためには使用できない。有効期限切れ時間のセマンティクスは，キャッシュ化機構にだけ適用され，それら機構は，資源に対する新しい要求が開始された場合だけに，その資源の有効期限切れ状態を検査する必要がある。キャッシュと履歴機構との差異については，13.13を参照すること。

原サーバが明示的な有効期限切れ時間を常に提供するわけではないので，典型的には，HTTPキャッシュが，もっともらしい有効時間切れ時間を見積もるために[Last-Modified時間(最終修正時間)といった]他のヘッダ値を使うアルゴリズムを使って，発見的有効期限切れ時間を割り当てる。HTTP/1.1規定は，特定のアルゴリズムを提供しないが，その結果に最悪な場合の制約を課す。発見的有効期限切れ時間は意味的透過性を損なうかもしれないので，注意深く使用することが望ましく，可能な限り，原サーバが明示的な有効期限切れ時間を提供することを推奨する。

キャッシュされたエントリが新鮮かどうかを知るためには，キャッシュは，その経過時間が新鮮保持期間を超えているかどうかを知る必要がある。13.2.4では，新鮮保持期間を計算する方法を示す。一方，13.2.3では，応答又はキャッシュエントリの経過時間を計算する方法を示す。

これらの記述において，"now"(現時点)を，"計算を実行するホストにおける時計の現在の値"を意味するために使用する。HTTPを使うホストだが，特に原サーバ及びキャッシュを動作させているホストは，そのホストの時計を大域的に正確な基準時間に同期させるために，NTP[28]又はそれに類似したプロトコルを使用するほうがよい。

HTTP/1.1は，応答が生成された時刻を与えるために，すべての応答と一緒にDatヘッダを送信することを原サーバに要求する，ということにも注意すること。"date_value"(日付値)を，算術操作に適切な形式での，Dateヘッダの値を表すために使用する。

HTTP/1.1は，キャッシュ間で経過時間情報を運ぶのを支援するためにAge応答ヘッダを使用する。Ageヘッダ値は，応答が原サーバで生成されてからの時間総量の送信側での評価とする。キャッシュされた応答が原サーバとの有効性再検証された場合には，Age値は，元の応答の時間ではなく有効性再検証の時間に基づく。

本質的には，Age値は，応答が，原サーバからの経路に沿ったキャッシュそれぞれに存在していた時間の合計に，ネットワーク経路に沿って移動していた時間の総量を加えたものとする。

"age_value"(経過時間値)は，算術操作に適切な形式での，Ageヘッダの値を表すために使用する。

応答の経過時間は，次の二つの完全に独立な方法で計算できる。

応答を受信したときにその応答の経過時間を計算する二つの独立な方法をもっている場合には，これらを次のとおりに組み合わせることができる。

          corrected_received_age = max(now - date_value, age_value)

ほとんど同期している時計又はすべてHTTP/1.1で実装されている経路のいずれかをもっている限り，信頼性のある(保守的な)結果を得る。

この訂正は，経路に沿った各HTTP/1.1キャッシュで適用されることに注意すること。そこで，経路に一つのHTTP/1.0キャッシュが存在する場合には，受信側キャッシュの時計がほとんど同期している限り，正しい受信された経過時間が計算される。端点間の時計同期は，(それがあることはいいことだが，)必要ではなく，したがって，明示的な時計同期の段階は存在しない。

ネットワークが課す遅延のために，サーバが応答を生成する時間及びその応答が次のキャッシュ又はクライアントで受信される時間から，無視できない時間間隔が経過することもある。訂正できなかった場合には，この遅延が不適正に無意味な経過時間を生じさせることがある。

その返却されたAge値を生じた要求は，そのAge値の生成より前に開始されていなければならないので，要求が開始された時間を記録しておくことによってネットワークが課す遅延に対する訂正を行うことができる。その場合，Age値を受信したときに，その値を，応答を受信した時間ではなく要求を開始した時間に対して相対的に解釈しなければならない。このアルゴリズムは，遅延をどれほど経験しようとも，保守的な振る舞いを結果として生じる。そこで，次を計算する。

         corrected_initial_age = corrected_received_age
                               + (now - request_time)

ここで，"request_time"(要求時間)は，この応答を引き出した要求が送信された(局所時計に従った)時間とする。

キャッシュが応答を受信する場合の経過時間計算のアルゴリズムをまとめると，次のとおりとなる。

      /*
       * age_value
       *      は，この応答をもつキャッシュが受信したAgeヘッダの値。
       * date_value
       *      は，現サーバのDateヘッダの値。
       * request_time
       *      は，このキャッシュされた応答を生じた要求を
       *          キャッシュが作成した(局所)時間。
       * response_time
       *      は，キャッシュが応答を受信した(局所)時間。
       * now
       *      は，現在の(局所)時間。
       */
      apparent_age = max(0, response_time - date_value);
      corrected_received_age = max(apparent_age, age_value);
      response_delay = response_time - request_time;
      corrected_initial_age = corrected_received_age + response_delay;
      resident_time = now - response_time;
      current_age   = corrected_initial_age + resident_time;

キャッシュが応答を送信する場合，corrected_initial_age(訂正初期経過時間)に応答が局所的に存在していた時間の総量を加えなければならない。キャッシュは，Ageヘッダを使って，この合計の経過時間を次の受け手キャッシュに伝送しなければならない。

クライアントは，応答が直接のものと確実にいうことはできないが，Ageヘッダの存在は，応答が確実に直接のものではないことを示していることに注意すること。応答のDateがクライアントの局所的な要求時間よりも前の場合にも，応答は，(重大な時計の誤りがない場合には，)恐らく直接ではない。

応答が新鮮か新鮮でないかを決定するためには，新鮮保持期間を経過時間と比較する必要がある。経過時間は，13.2.3で示したとおりに計算する。13.2.4では，新鮮保持期間を計算し応答が有効期限切れでないかどうかを決定する方法を示す。以下では，値は，算術操作に適したあらゆる形式で表現できるものとする。

"expires_value"(有効期限切れ値)を，Expiresヘッダの値を表すために使用する。"max_age_value"(最大経過時間値)を，応答のCache-Controlヘッダのmax_age(最大経過時間)指令が運ぶ秒数の適切な値を表すために使用する。

max_age指令は，Expiresよりも高い優先度をもつ。そのために，max_ageが応答に存在する場合には，計算は，単に次による。

         freshness_lifetime = max_age_value

そうでない場合で，Expiresが応答に存在する場合には，計算は次による。

         freshness_lifetime = expires_value - date_value

これらの計算はいずれも，時計の誤りに対して影響されないことに注意すること。これは，すべての情報が原サーバに由来することによる。

ExpiresもCache-Control: max-ageも応答に出現しない場合であって，応答がキャッシュ化に関して他の制限を含まない場合には，キャッシュは，発見的手法を使用して新鮮保持期間を計算してもよい。値が24時間よりも大きい場合，警告13を，その警告が既に付加されていないときには，経過時間が24時間よりも多いあらゆる応答に対して添付しなければならない。

応答がLast-Modified時間をもつ場合にも，発見的な有効期限切れ値は，そのLast-Modified時間からの時間間隔の一部よりも多くないほうがよい。この一部の典型的な設定は，10%かもしれない。

応答が有効期限切れかどうかを決定するための計算は，非常に簡単で，次による。

         response_is_fresh = (freshness_lifetime > current_age)

有効期限切れ値は楽観的に割り当てられているので，二つのキャッシュが，同じ資源に対して異なる新鮮な値を含むことが可能になる。

検索を実行するクライアントが，要求に対してそれ自体のキャッシュの中で既に新鮮とされていた直接的ではない応答を受信する場合であって，その既存のキャッシュエントリの中のDateヘッダが新たな応答のDateよりも新しい場合，クライアントはその応答を無視してよい。その場合，原サーバとの検査を強制するために，"Cache-Control: max-age=0"指令(14.9参照)をもつ要求を再送してもよい。

キャッシュが同じ表現に対して異なる有効性検証子をもつ二つの新鮮な応答をもつ場合，より最近のDateヘッダをもつもの使用しなければならない。この状況は，キャッシュが他のキャッシュからの応答を溜めているという理由で，又はクライアントが見た目には新鮮なキャッシュエントリの再ロード若しくは有効性再検証を求めているという理由で，発生することがある。

クライアントは，複数の経路を経由して応答を受信していてもよく，その結果，ある応答はキャッシュの一つの集合を通じて流れ，他の応答はキャッシュの異なる集合を通じて流れてもよいので，クライアントは，原サーバが応答を送信したのとは異なる順番で応答を受信するかもしれない。より古い応答がまだ新鮮に見える場合であっても，最も最近に生成された応答を使用することを，クライアントに対して望む。

実体タグも有効期限切れ値も応答の順番付けに制約を課すことはできない。これは，後の応答が意図的により早い有効期限切れ時間を運ぶことが可能なことによる。しかし，HTTP/1.1規定は，すべての応答にDateヘッダの伝送を要求し，Date値は，1秒の粒度まで順番付けられる。

クライアントがキャッシュエントリを有効性再検証しようとしていて，クライアントが受信する応答が既存のエントリに対するものよりも古く見えるDateヘッダを含んでいる場合には，クライアントは，要求を無条件に繰り返し，次を含めるのがよい。

          Cache-Control: max-age=0

これを含めることによって，あらゆる中間キャッシュに，それらのコピーに対して直接に原サーバとの有効性検証を行うことを強制する。次を含めた要求を送信するのもよい。

          Cache-Control: no-cache

この場合には，中間キャッシュに，原サーバから新しいコピーを得ることを強制する。

Date値が等しい場合には，クライアントは，どちらの応答を使用してもよく，クライアントが非常に用心深い場合には，新しい応答を要求してもよい。サーバは，応答の有効期限切れ時間が重複する場合に，同じ1秒の間に生成された応答の間でクライアントが決定論的に応答を選択できることに依存してはならない。

キャッシュが，クライアントの要求への応答として使用したいが新鮮ではないエントリをもっている場合，そのキャッシュエントリがまだ使用可能かどうかを調べるために，まず，原サーバとの間で(又は恐らく新鮮な応答をもつ中間キャッシュとの間で)検査をしなければならない。これを，キャッシュエントリを"有効性再検証する"と呼ぶ。キャッシュエントリが問題ない場合に，完全な応答を再伝送するオーバヘッドを払わねばならないのは望ましくないし，キャッシュエントリが妥当ではない場合に，余分な一往復のオーバヘッドを払いたくないので，HTTP/1.1プロトコルは，条件付きメソッドの使用をサポートする。

条件付きメソッドをサポートするための主要なプロトコル機能は，"キャッシュ有効性検証子"に関わるものとする。原サーバが完全な応答を生成する場合，それにある種の有効性検証子を添付する。これは，キャッシュエントリとともに保持される。クライアント(利用者エージェント又はプロキシキャッシュ)が資源に対してキャッシュエントリが存在する条件付き要求を行う場合，要求の中に関連する有効性検証子を含める。

サーバは，その実体のための現在の有効性検証子に対してその(要求の中の)有効性検証子を検査し，それらが一致する場合には，特殊な状態コード[通常は，304 (Not Modified)]を付け実体本体なしで応答する。そうでない場合には，(実体本体を含む)完全な応答を返す。このようにして，有効性検証子が一致する場合には，完全な応答を伝送することを避け，一致しない場合には余分な一往復を避ける。

備考　 有効性検証子が一致するかどうかを決定するため使用する比較関数は，13.3.3で定義する。

HTTP/1.1では，条件付き要求は，それがメソッド(通常はGET)を暗黙的に条件付きとする(有効性検証子を含んだ)特殊なヘッダを運ぶ以外は，同じ資源に対する通常の要求と全く同じに見える。

プロトコルは，キャッシュの有効性検証条件の肯定的な意味及び否定的な意味の両方を含む。すなわち，メソッドは，有効性検証子が一致する場合及びその場合に限り，又は有効性検証子が一致しない場合及びその場合に限り，それらのいずれかで，メソッドを実行することを要求できる。

備考　 有効性検証子を欠く応答をキャッシュしてもよいし，応答が有効期限切れになるまでキャッシュから提供してもよい。ただし，これは，Cache-Control指令によって明示的に禁止されていない場合とする。しかし，キャッシュは，実体に対する有効性検証子をもたない場合には，条件付き検索を行うことはできない。これは，(条件付き検索が)有効期限切れになった場合には，再び新鮮にすることができないことを意味する。

Last-Modified(最終修正)実体ヘッダ値は，キャッシュ有効性検証子として使用されることが多い。簡単に言うと，キャッシュエントリは，実体がLast-Modified値から修正されていない場合には，有効と考えられる。

ETag実体ヘッダ値，すなわち，実体タグ，は，"不透明な"キャッシュ有効性検証子のために用意されている。これは，修正日付を記憶するのが不都合な状況，HTTP日付値の1秒の精度が十分ではない状況，又は原サーバが修正日付の使用から生じるかもしれない逆説的な状態を回避したいと願う状況において，より信頼性のある有効性検証子とできることがある。

実体タグは，3.11で示す。実体タグとともに使用するヘッダは，14.20，14.25，14.26及び14.43で示す。

原サーバ及びキャッシュの両方は，二つの有効性検証子が同じ実体を表現しているのか異なる実体を表現しているのかを決定するためにそれら有効性検証子を比較するので，通常は，実体(実体本体又はあらゆる実体ヘッダ)がいかなる方法にせよ変化する場合，関連する有効性検証子も変化すると期待される。これが正しい場合，この有効性検証子を"強有効性検証子"と呼ぶ。

しかし，意味的に重要な変化に関してだけサーバが有効性検証子を変化させることを望み，実体の重要ではない様相が変化した場合には変化させないという場合が存在してもよい。資源が変化する場合に常に変化するわけではない有効性検証子を"弱有効性検証子"とする。

実体タグは，通常は"強有効性検証子"だが，プロトコルは，実体タグを"弱"としてタグ付けする機構を提供する。強有効性検証子は実体のビットが変化する場合にいつでも変化するものと考えることができるが，弱有効性検証子は，実体の意味が変化する場合にいつでも変化する。言い換えると，強有効性検証子は特定の実体の識別子の一部と考えることができるが，弱有効性検証子は意味的に等価な実体の集合に対する識別子の一部とする。

備考　 強有効性検証子の例の一つに，実体が変化するごとに安定な記憶において増加する整数がある。

実体の修正時間は，1秒の精度で表現されている場合には，弱有効性検証子とすることができる。これは，資源が1秒の間に2回修正されるかもしれない可能性があることによる。

弱有効性検証子のサポートは，オプションとする。しかし，弱有効性検証子は，等価なオブジェクトのより効率的なキャッシュ化を考慮している。例えば，サイト上のヒットカウンタ(訪問回数計数器)は，2〜3日ごと又は2〜3週ごとに更新されれば恐らく十分である。その期間の間の値は，等価とすれば"十分"であることが多い。

有効性検証子は，クライアントが要求を生成し有効性検証ヘッダフィールドに有効性検証子を含める場合，又はサーバが二つの有効性検証子を比較する場合のいずれかに，"使用"される。

強有効性検証子は，あらゆる文脈で使用可能とする。弱有効性検証子は，実体の正確な同等性に依存しない文脈だけで使用可能とする。例えば，どちらかの種類が，完全な実体の条件付きGETに対して使用可能である。しかし，強有効性検証子だけが，補助範囲の検索に対して使用できる。これは，そうでない場合には，クライアントが内部的に矛盾した実体をともなって終了してしまうかもしれないことによる。

HTTP/1.1プロトコルが有効性検証子に関して定義する関数だけを，比較関数とする。次の二つの有効性検証子比較関数が存在する。これらは，比較文脈が弱有効性検証子の使用を許すかどうかに依存する。

• 強比較関数。両方の有効性検証子を等しいとするためには，それらがすべての点で同等でなければならず，いずれもが弱であってはならない。
• 弱比較関数。両方の有効性検証子を等しいとするためには，それらがすべての点で同等でなければならないが，それらの片方又は両方が結果に影響することなく"弱"とタグ付けされていてもよい。

弱比較関数は，単純な(補助範囲ではない)GET要求に使用されてもよい。強比較関数は，すべての他の場合に使用しなければならない。

実体タグは，明示的に弱とタグ付けされていない場合には，強とする。3.11に，実体タグの構文を与える。

Last-Modifiedは，要求の中で有効性検証子として使用されているとき，次のいずれかの規則を使用して，強と演繹できない場合には，暗黙的に弱とする。

規則1

• 有効性検証子は，原サーバによって，実体に対する実際の現在の有効性検証子と比較されている。
• その原サーバは，関連する実体が提示されている有効性検証子がもつ時間単位の間に2回変化しなかったということを，確信をもって知っている。

規則2

• 有効性検証子は，クライアントが関連する実体のキャッシュエントリをもっているので，If-Modified-Sinceヘッダ又はIf-Unmodified-Sinceヘッダの中でクライアントによって使用されようとしている。
• そのキャッシュエントリは，Date値を含み，その値は，原サーバが元の応答を送信したときの時間を与えている。
• 提示されたLast-Modified時間は，そのDate値よりも少なくとも60秒前になっている。

規則3

• 有効性検証子は，中間キャッシュによって，実体に対するキャッシュエントリに記憶された有効性検証子と比較されている。
• そのキャッシュエントリは，Date値を含み，その値は，原サーバが元の応答を送信したときの時間を与えている。
• 提示されたLast-Modified値は，そのDate値よりも少なくとも60秒前になっている。

この手法は，二つの異なる応答が同じ時間単位の間に原サーバによって送信されたが両方とも同じLast-Modified時間をもっている場合に，これら応答の少なくとも一つがLast-Modified時間に等しいDate値をもっているという事実に依存している。任意の60秒の限界によって，Date値及びLast-Modified値が異なる時計から生成されている，又は応答の準備中の幾分異なる時間に生成されているという可能性を防いでいる。実装は，60秒が短すぎると信じられる場合には，60秒よりも大きな値を使用してもよい。

クライアントが，ある値に対してLast-Modified時間だけをもち不透明な有効性検証子をもたないような，その値の補助範囲の検索を実行したい場合には，Last-Modified時間が13.3.3で示した意味で強となる場合にだけ，この検索を行ってもよい。

完全本体のGET要求以外のキャッシュ条件付き要求を受信したキャッシュ又は原サーバは，その条件を評価するために強比較関数を使用しなければならない。

これらの規則によって，HTTP/1.1のキャッシュ及びクライアントは，HTTP/1.0サーバから得られた値に関して補助範囲の検索を安全に実行できる。

多様な有効性検証子の型を使用することが望ましい場合，及び目的に関して，原サーバ，クライアント及びキャッシュのための規則及び推奨の集合を次に示す。

HTTP/1.1原サーバに対する規則及び推奨を次に示す。

• HTTP/1.1原サーバは，実体タグ有効性検証子を，それを生成することが適切ではない場合以外は，送信することが望ましい。
• HTTP/1.1原サーバは，性能を考慮して弱実体タグの使用をサポートする場合，又は強実体タグを送信するのが適切ではない場合には，強実体タグの代わりに弱実体タグを送信してもよい。
• HTTP/1.1原サーバは，Last-Modified値を，それを送信するのが適切な場合には送信することが望ましい。ただし，If-Modified-Sinceヘッダの中でこの日付を使用することで生じる可能性がある意味的透過性の破綻の危険が重大な問題を引き起こす場合は除く。

言い換えると，HTTP/1.1原サーバの望ましい振る舞いは，強実体タグ及びLast-Modified値の両方を送信することとする。

正しい動作のためには，強実体タグは，関連する実体値が何らかの方法で変化するときにはいつでも変化しなければならない。弱実体タグは，関連する実体が意味的に重要な方法で変化するときにはいつでも変化することが望ましい。

備考　 意味的に透過なキャッシュ化を提供するためには，原サーバは，二つの異なる実体に対して特定の強実体タグを再利用することを，又は二つの意味的に異なる実体に対して特定の弱実体タグを再利用することを，避けなければならない。キャッシュエントリは，有効期限切れ時間に関係なく，任意の長期間に渡って残存していてもよい。そのために，キャッシュが，過去のある時点で取得した有効性検証子を使って再びエントリを有効性検証しようとはしないと期待することは適切ではないかもしれない。

HTTP/1.1クライアントに対する規則及び推奨を次に示す。

• HTTP/1.1クライアントは，実体タグが原サーバによって提供された場合には，(If-Match又はIf-None-Matchを使って)あらゆるキャッシュ条件付き要求の中でその実体タグを使用しなければならない。
• HTTP/1.1クライアントは，Last-Modified値だけが原サーバによって提供された場合には，(If-Modified-Sinceを使って)補助範囲ではないキャッシュ条件付き要求の中でその値を使用することが望ましい。
• HTTP/1.1クライアントは，Last-Modified値だけがHTTP/1.0原サーバによって提供された場合には，(If-Unmodified-Since:を使って)補助範囲のキャッシュ条件付き要求の中でその値を使用してもよい。利用者エージェントは，困難な場合には，これを使用不可にする方法を提供することが望ましい。
• HTTP/1.1クライアントは，実体タグ及びLast-Modified値の両方が原サーバによって提供された場合には，キャッシュ条件付き要求の中で両方の有効性検証子を使用することが望ましい。これによって，HTTP/1.0キャッシュ及びHTTP/1.1キャッシュの両方が適切に応答できるようになる。

要求の受信において，HTTP/1.1キャッシュは，クライアントのキャッシュエントリがキャッシュ自体のキャッシュエントリと一致するかどうかを決定する場合に最も限定された有効性検証子を使用しなければならない。これは，要求が実体タグ及び最終修正日付有効性検証子(If-Modified-Since又はIf-Unmodified-Since)の両方を含む場合にだけ問題となる。

これら規則の根拠に関する備考を次に示す。すなわち，これら規則の背景には，HTTP/1.1のサーバ及びクライアントは，それらの応答及び要求で利用可能なできるだけ無駄ではない多くの情報を伝送することが望ましいという一般的な原理がある。この情報を受信するHTTP/1.1システムは，受信する有効性検証子について最も保守的な(安全な)仮定をする。

HTTP/1.0のクライアント及びキャッシュは，実体タグを無視する。一般に，これらシステムによって受信又は使用される最終修正の値は，透過的で効率的なキャッシュ化をサポートする。そこで，HTTP/1.1原サーバは，Last-Modified値を提供することが望ましい。Last-Modified値をHTTP/1.0システムが有効性検証子として使用することで重大な問題が生じる可能性がある数少ない場合には，HTTP/1.1原サーバは，Last-Modified値を提供しないほうがよい。

実体タグの背後には，サービス作成者だけが適切なキャッシュ有効性検証機構を選択するために十分に資源のセマンティクスを知っているという原理がある。バイト同等性よりも複雑な有効性検証子比較関数の規定は，やっかいな問題の原因となる可能性がある(訳者注："ミミズ，寄生虫などのくねくねした虫の缶詰を開けることになろう。"が元の英語の意味だが．．．)。そこで，(HTTP/1.0との互換性のために，Last-Modifiedは除く)あらゆる他のヘッダの比較は，キャッシュエントリを有効性検証するためには決して使用しない。

Cache-Control(14.9)指令によって特に制約されていない場合には，キャッシュ化システムは，キャッシュエントリとして成功時応答を常に記憶しておいてよく(13.8参照)，それが新鮮な場合には有効性検証なしにそれを返してもよく，有効性検証に成功した後に返してもよい。応答に関連したキャッシュ有効性検証子も明示的な有効期限切れ時間も存在しない場合には，キャッシュされるとは期待しないが，(例えば，ネットワーク接続性がほとんど利用可能ではない又は全く利用可能ではない場合には，)この期待に反するキャッシュが行われることもある。クライアントは，通常，Dateヘッダを現在時間と比較することによって，それら応答がキャッシュから行われたことを検出できる。

HTTP/1.0キャッシュの中には，警告を提供することなしに，この期待に反する動作をするものがあることに注意すること。

しかし，キャッシュが実体を保持し続けること，又は後続の要求の応答でそれを返すことが不適切な場合もある。これは，絶対的な意味透過性がサービス作成者によって必要とされているとか，セキュリティ又はプライバシへの配慮によっていることもある。それら理由のために，一定のCache-Control指令が提供されて，その結果，サーバは，他の配慮には関係なく，ある資源実体又はその一部がキャッシュされないように指示することができる。

14.8は，通常は，共有キャッシュが以前の要求に対する応答を，その要求がAuthorizationヘッダを含んでいた場合には，保存し返却することを禁じていることに注意すること。

200，203，206，300，301，又は410の状態コードをもつ受信応答は，Cache-Control指令がキャッシュを禁止していない場合，有効期限切れ機構に従って，キャッシュに記憶し後続の要求の応答に使用してもよい。しかし，Rangeヘッダ及びContent-Rangeヘッダをサポートしないキャッシュは，206(Partial Content)応答をキャッシュしてはならない。

それ以外の状態コードをもつ受信応答は，明示的に許可するCache-Control指令又は他のヘッダが存在しない場合，後続の要求への応答で返してはならない。例えば，これらには，Expiresヘッダ(14.21)，又は"max-age"，"must-revalidate"，"proxy-revalidate"，"public"，若しくは"private"のCache-Control指令(14.9)が含まれる。

HTTPキャッシュの目的は，将来の要求への応答で使用するために，要求への応答で受信される情報を記憶することにある。多くの場合，キャッシュは，単に，要求側への応答の適切な部分を返す。しかし，キャッシュが以前の応答に基づくキャッシュエントリを保持している場合，新しい応答の部分をキャッシュエントリに保持されているものと組み合わせなければならないことがある。

キャッシュ及びキャッシュ化されていないプロキシの振る舞いを定義するために，HTTPヘッダを次の二つのカテゴリに分割する。

• 端点間ヘッダ。これは，要求又は応答の最終の受け手に伝送されなければならない。応答における端点間ヘッダは，キャッシュエントリの一部として記憶され，キャッシュエントリから形成される応答で伝送されなければならない。
• ホップごとのヘッダ。これは，単一の転送レベルのコネクションだけに対して意味があり，キャッシュによって記憶されたりプロキシによって回送されたりしない。

次のHTTP/1.1ヘッダは，ホップごとのヘッダとする。

• Connection
• Keep-Alive
• Public
• Proxy-Authenticate
• Transfer-Encoding
• Upgrade

HTTP/1.1が定義する他のすべてのヘッダは，端点間ヘッダとする。

HTTPの将来の版で導入されるホップごとのヘッダは，14.10で示すとおり，Connectionヘッダに一覧されなければならない。

Digest Authentication(ダイジェスト認証)などのHTTP/1.1プロトコルの幾つかの機能は，ある端点間ヘッダの値に依存する。キャッシュ又は非キャッシュ化プロキシは，端点間ヘッダを修正しないことが望ましい。ただし，そのヘッダの定義が修正を要求する又は特に許可する場合は除く。

キャッシュ又は非キャッシュ化プロキシは，要求又は応答の次のフィールドのいずれも修正してはならないし，既に存在していない場合には，これらフィールドのいずれをも追加してはならない。

• Content-Location
• ETag
• Expires
• Last-Modified

キャッシュ又は非キャッシュ化プロキシは，"no-transform"(非変換)のCache-Control指令を含む応答又はあらゆる要求の中の次のフィールドのいずれをも修正又は追加してはならない。

• Content-Encoding
• Content-Length
• Content-Range
• Content-Type

キャッシュ又は非キャッシュ化プロキシは，"no-transform"を含まない応答の中のこれらフィールドを修正又は追加してもよい。しかし，その場合には，警告14(Transformation applied，変換が適用された)を，応答に既に警告が現れていないならば，追加しなければならない。

警告。端点間ヘッダの不必要な修正は，より強い認証機構がHTTPの後の版で導入される場合には，認証失敗を引き起こすかもしれない。それら認証機構は，この規定で一覧として示さないヘッダフィールドの値に依存してもよい。

キャッシュがサーバへの有効性検証の要求を作成し，サーバが304(Not Modified)応答を提供する場合，キャッシュは，要求側クライアントへ送信する応答を構成しなければならない。キャッシュは，この出力する応答の実体本体として，キャッシュエントリに記憶された実体本体を使用する。キャッシュエントリに記憶された端点間ヘッダが，構成された応答に対して使用される。ただし，304応答で提供された端点間ヘッダは，キャッシュエントリからの対応するヘッダを置き換えなければならない。キャッシュは，キャッシュエントリを削除すると決定しない場合には，キャッシュエントリとともに記憶されている端点間ヘッダも，入力する応答で受信される対応するヘッダで置き換えなければならない。

言い換えると，入力する応答で受信される端点間ヘッダの集合は，キャッシュエントリとともに記憶されているすべての対応する端点間ヘッダを上書きする。キャッシュは，この集合にWarningヘッダ(14.45)を追加してもよい。

入力する応答のヘッダfield-nameがキャッシュエントリの中の二つ以上のヘッダと一致する場合には，すべてのそれら古いヘッダが置き換えられる。

備考　 この規則によって，原サーバは，304(Not Modified)応答を使用して，同じ実体に対する以前の応答に関連するあらゆるヘッダを更新することができる。ただし，そうすることが，常には意味がある又は正しいわけではないかもしれない。この規則は，原サーバが，304(not Modified)応答を使用して，以前の応答とともに提供したヘッダを完全に削除できるようにするわけではない。

応答は，要求が一つ以上のRange規定を含んでいたこと，又はコネクションが不安全で切れたことのいずれかの理由で，実体本体のバイトの補助範囲だけを転送してもよい。幾つかのそれら転送の後に，キャッシュは，同じ実体本体の幾つかの範囲を受信してもよい。

キャッシュが記憶された空でない実体に対する補助範囲の集合をもち，入力する応答が他の補助範囲を転送する場合，キャッシュは，次の条件が満たされるならば，その新しい補助範囲を既存の集合と組み合わせてもよい。

• 入力する応答及びキャッシュエントリの両方は，キャッシュ有効性検証子をもたなければならない。
• その二つのキャッシュ有効性検証子は，強比較関数(13.3.3参照))を使用して一致しなければならない。

要件のどちらも意味をもたない場合には，キャッシュは，(すべての応答とともに伝送されるDate値に基づいた，ただし，これら値が等しい又は欠けている場合には入力する応答を使用した)<最も最近の部分応答だけを使用し，他の部分情報を破棄しなければならない。

応答におけるVaryヘッダフィールドの存在によって示されるとおり，サーバ駆動内容折衝(12)の使用は，キャッシュが後続の要求に対して応答を使用できる条件及び手続きを変更する。

サーバは，Varyヘッダフィールド(14.43)を使用して，キャッシュに，キャッシュ可能な応答の複数な表現の中から選択するためにどのヘッダフィールド範囲を使用するかを知らせる。キャッシュは，後続の要求がVary応答ヘッダで指定されたすべての応答ヘッダフィールドに対して同じ又は等価な値をもつ場合にだけ，その資源に関する後続の要求への返答に対して選択された表現(その特定の応答とともに含まれる実体)を使用してもよい。一つ以上のそれらヘッダフィールドに対して異なる値をもつ要求は，原サーバに向けて回送される。

実体タグが表現に割り当てられていた場合には，回送された要求は，条件付きであって，Request-URIに対してすべてのキャッシュエントリからのIf-None-Matchヘッダフィールドにその実体タグを含むことが望ましい。この要求は，キャッシュが現在保持している実体の集合をサーバに対して運ぶ。その結果として，これら実体の任意の一つが要求された実体と一致する場合には，サーバは，304(Not Modified)応答の中のETagヘッダを使用してどの実体が適切かをキャッシュに告げる。新しい応答の実体タグが既存のエントリの実体タグと一致する場合には，新しい応答は，既存のエントリのヘッダフィールドを更新するために使用されることが望ましく，その結果が，クライアントに返さなければならない。

Varyヘッダフィールドは，キャッシュに，要求ヘッダに限定されない基準を使用して表現が選別されたことを知らせてもよい。この場合，キャッシュは，後続の要求への返答でその応答を使用してはならない。ただし，キャッシュが条件付き要求で原サーバに新しい要求を連携し，どの実体を使用するのがよいかを示す実体タグ又はContent-Locationを含む304(Not Modified)でサーバが応答することがない場合は除く。

既存のキャッシュエントリのいずれかが関連する実体に対する部分内容だけを含む場合，その実体タグは，要求がその実体によって完全に満足される範囲に対するものでなければ，If-None-Matchヘッダに含まれないことが望ましい。

Content-Locationフィールドが同じRequest-URIに対する既存のキャッシュエントリのContent-Locationフィールドに一致し，実体タグが既存のエントリの実体タグとは異なり，Dateが既存のエントリのDateよりも最近となっている成功応答を，キャッシュが受信する場合，既存のエントリは，将来の要求への応答で返されないほうよく，キャッシュから削除されることが望ましい。

セキュリティ及びプライバシの理由のために，"共有"キャッシュと"非共有"キャッシュとの間の区別を行うことが必要になる。非共有キャッシュとは，単一利用者だけに対してアクセス可能なキャッシュとする。この場合のアクセス可能性は，適切なセキュリティ機構によって実施されることが望ましい。すべての他のキャッシュは，"共有"されると考えられる。この規定の他の箇条では，プライバシの損失又はアクセス制御の失敗を防ぐために共有キャッシュの操作にある制約を課す。

不完全な応答(例えば，Content-Lengthヘッダで指定されているよりもデータのバイト数が少ない応答)を受信するキャッシュは，その応答を記憶してもよい。しかし，キャッシュは，これを部分応答として取り扱わなければならない。部分応答は，13.5.4で示すとおりに組み合わされてよい。その結果は，完全な応答になるかもしれないし，未だ部分応答かもしれない。キャッシュは，206(Partial Content)状態コードを使うなどでそれを明示的に印することなしに，部分応答をクライアントに返してはならない。キャッシュは，200(OK)の状態コードを使って部分応答を返してはならない。

キャッシュが，エントリを有効性再検証しようとしている際中に5xx応答を受信する場合，この応答を要求側クライアントに回送するか，サーバが応答に失敗したものとして動作するかしてよい。後者の場合，キャッシュは，キャッシュされたエントリが"must-revalidate"(有効性再検証をしなければならない) Cache-Control指令(14.9参照)を含まない場合には，以前に受信した応答を返却してもよい。

原サーバが明示的に応答のキャッシュ化を禁止していない場合には，GETメソッド及びHEADメソッドの資源に対する適用は，それらの応答がキャッシュから取られているならば，誤った振る舞いを生じる副作用をもたないことが望ましい。なおそれでも，副作用はもってもよく，キャッシュは，キャッシュ化の決定においてそれら副作用を検討する必要はない。キャッシュには，常に，原サーバのキャッシュ化に関する明示的な制限を守ることが期待される。

この規則に対する一つの例外に注意すること。すなわち，重要な副作用をもつ操作を実行するために(rel_path部分に"?"を含んだ)問合せURLをもつGET及びHEADを使用する従来のアプリケーションも存在するので，キャッシュは，サーバが明示的な有効期限切れ時間を提供しない場合には，それらURLへの応答を新鮮として取り扱ってはならない。このことは，特に，それらURLに対するHTTP/1.0サーバからの応答は，キャッシュから取らないほうがよいことを意味する。関係する情報については，9.1.1を参照すること。

原サーバにおけるあるメソッドの効果が，一つ以上の既存のキャッシュエントリを非透過的に無効にすることがある。すなわち，それらは"新鮮"であり続けるのだが，原サーバが新しい要求に対して返すものを正確には反映していない。

HTTPプロトコルがそれらキャッシュエントリすべてを無効と印付けることを保証する方法は存在しない。例えば，原サーバにおいて変更を引き起こす要求は，キャッシュエントリが記憶されているプロキシを通過しなくてもよい。しかし，幾つかの規則が，誤った振る舞いを発生を少なくすることを支援する。

13.10では，"実体を無効化する"という表現で，キャッシュが記憶からその実体のすべてのインスタンスを取り除くのが望ましい，又はそれらインスタンスを"無効"と印付けし必ず有効性再検証を行わなければ後続の要求への応答でそれらを返すことができないとするのが望ましい，ことを意味する。

実体を無効化してもよいHTTPメソッドも存在する。これは，Request-URI，又は(存在する場合には)Location若しくはContent-Locationの応答ヘッダのいずれかによって参照される実体とする。これらメソッドは，次のとおりとする。

• PUT
• DELETE
• POST

サービス否認の攻撃を防止するために，Locationヘッダ又はContent-LocationヘッダにおけるURIに基づく無効化は，そのホスト部分がRequest-URIの中のそれと同じ場合にだけ実行しなければならない。

原サーバの資源に修正を生じさせることが期待されるすべてのメソッドは，原サーバへ向けて通し書きされなければならない。現時点では，これには，GET及びHEDAを除くすべてのメソッドが含まれる。キャッシュは，対象となるサーバに要求を伝送してしまい，対象となるサーバから対応する応答を受信してしまうより前に，クライアントからのそれら要求に返答してはならない。このことは，キャッシュが，対象となるサーバが返答する前に100(Continue)応答を送信することを妨げるものではない。

("書き戻し"キャッシュ化又は"コピー戻し"キャッシュ化として知られる)代替方式を，HTTP/1.1では許さない。これは，矛盾のない更新を提供することが困難なこと，及び書き戻しに先行するサーバ，キャッシュ又はネットワークの失敗から生じる問題があることによる。

新しいキャッシュ可能な(14.9.2，13.2.5，13.2.6及び13.8を参照)応答を資源から受信する場合であって，その一方でその同じ資源に対する既存の応答をキャッシュしている場合，キャッシュは，現在の要求へ返答するためにその新しい応答を使用することが望ましい。キャッシュは，その応答をキャッシュ記憶に挿入し，すべての他の要件を満足する場合には，以前には古い応答を返すとしていた要求の将来のものに応答するためにその新しい応答を使用してもよい。その新しい応答をキャッシュ記憶に挿入する場合，キャッシュは，13.5.3の規則に従うことが望ましい。

備考　 既存のキャッシュされた応答よりも古いDateヘッダ値をもつ新しい応答は，キャッシュ可能とはしない。

利用者エージェントは，"Back"ボタン及び履歴リストといった，履歴機構をもつことが多い。履歴機構は，セションにおいてより以前に検索された実体を再表示するために使用できる。

履歴機構とキャッシュとは異なる。特に，履歴機構は，資源の現在の状態の意味的に透過なビューを示そうとはしないほうがよい。むしろ，履歴機構は，資源が検索されたときに利用者が見たものを正確に示すことを意図している。

デフォルトでは，有効期限切れ時間は，履歴機構に適用されない。実体が未だ記憶にある場合には，履歴機構は，その実体が有効期限切れになっていたとしても，表示することが望ましい。ただし，利用者が，特に，エージェントを有効期限切れした履歴文書を新しくするように構成した場合は除く。

このことは，履歴機構が利用者にビューが新鮮ではないかもしれないと告げることを禁止すると説明することにはならない。

備考　 履歴リスト機構が不必要に利用者が新鮮ではない資源を見ることを妨げる場合には，このことは，サービス作成者に，そうでない場合には使いたがるであろう，HTTPの有効期限切れ制御及びキャッシュ制御の使用を避けるように強制しがちになる。サービス作成者は，利用者が，以前に取ってきた資源を見るために(BACKなどの)たどり制御を使用するとき，エラーメッセージ又は警告メッセージ付きで表示されないことが重要と考えてもよい。ときには，それら資源はキャッシュされない方がよかったり早く有効期限切れになったほうがよかったりするにもかかわらず，利用者インタフェースの観点からは，履歴機構を不完全に機能させた影響に悩まないために，サービス作成者に，キャッシュ化を禁止する他の手法(例えば，"ただ一度だけの"URL)に頼るように強制してもよい。

14.では，すべての標準的なHTTP/1.1ヘッダフィールドの構文及び意味を定義する。実体ヘッダフィールドに対しては，送信側及び受信側の両方は，実体を送信する側及び実体を受信する側に依存して，クライアント又はサーバのどちらかを参照する。

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/*"はその型(type)のすべての下位型を示すために使用する。media-range(メディア範囲)は，その範囲に適用可能なメディア型パラメタを含んでよい。

各media-rangeには，相対的な品質因子を示すための"q"パラメタで開始する，一つ以上のaccept-paramsが続いてよい。最初の"q"パラメタは，(存在する場合には)media-rangeパラメタをaccept-paramsから分離する。品質因子は，0〜1のqvalue目盛りを使用して，利用者又は利用者エージェントが，そのmedia-rangeに対する好みの相対的な度数を示すことを可能にする。デフォルト値は，q=1とする。

備考　 メディア型パラメタをAccept拡張パラメタから分離するために"q"パラメタという名前を使用するのは，歴史的な実践による。これによって"q"という名前のメディア型パラメタをメディア範囲で使用することが妨げられるが，そうした使用に関し，IANAメディア型レジストリに"q"パラメタが存在しないこと，及びAcceptにおいてメディア型パラメタがほとんど使用されないことを気にかけることはあまりないと信じられている。将来のメディア型には，"q"と名前付けされたパラメタを登録しないことが望ましい。

例を次に示す。

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

これは，"私は，audio/basicを好むが，品質に関して80%下げた後で最もよく利用可能な場合には，あらゆるaudio型を送信すること。"と解釈することが望ましい。

Acceptヘッダフィールドが存在しない場合には，クライアントは，すべてのメディア型を受諾すると仮定する。Acceptヘッダが存在し，サーバが組み合わされたAcceptフィールド値に従った受諾可能な応答を送信できない場合には，サーバは，406(not acceptable)応答を送信することが望ましい。

さらに複雑な例を次に示す。

          Accept: text/plain; q=0.5, text/html,
                  text/x-dvi; q=0.8, text/x-c

説明すると，これは，"text/html及びtext/x-cが好ましいメディア型だが，それらが存在しない場合には，text/x-dvi実体を送信し，それが存在しない場合には，text/plain実体を送信すること。"と解釈される。

メディア範囲は，より特定のメディア範囲又はより特定のメディア型によって上書き可能とする。二つ以上のメディア範囲が一つの与えられた型に適用される場合には，最も特定される参照が優先される。例を次に示す。

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

これは，次の優先順位をもつ。

与えられた型に関連するメディア型品質因子は，その型に合致する最高の優先順位をもつメディア範囲を見つけることによって決定される。例を次に示す。

          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

備考　 利用者エージェントは，あるメディア範囲に対する品質因子のデフォルト集合を提供されてもよい。しかし，利用者エージェントが他のレンダリングエージェントと相互作用できない閉システムではない場合には，このデフォルト集合は，利用者によって構成可能とすることが望ましい。

Accept-Charset要求ヘッダ(request-header)フィールドは，どの文字集合が応答に対して受諾可能かを示すために使用できる。このフィールドによって，より包括的な又は特殊目的の文字集合を理解可能なクライアントが，その能力を，それら文字集合で文書を表現できるサーバに通知することができる。ISO-8859-1文字集合は，すべての利用者エージェントに受諾可能と仮定できるとする。

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

文字集合値は，3.4で示す。各charsetには，そのcharsetに対する利用者の好みを表現する関連する品質値を与えてもよい。デフォルト値は，q=1とする。次に例を示す。

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

Accept-Charsetヘッダが存在しない場合，デフォルトは，いかなる文字集合も受諾可能とする。Accept-Charsetヘッダが存在し，サーバがそのAccept-Charsetヘッダに従って受諾可能な応答を送信できない場合，サーバは，406(not acceptable)状態コードをもつエラー応答を送信することが望ましい。ただし，受諾可能ではないという応答を送信することも許される。

Accept-Encoding要求ヘッダはAcceptに似ているが，応答で受諾可能な内容符号化(content-coding)の値(14.12)を制限する。

          Accept-Encoding  = "Accept-Encoding" ":"
                                    #( content-coding )

使用例を次に示す。

          Accept-Encoding: compress, gzip

Accept-Encodingヘッダが要求に存在しない場合には，サーバは，クライアントはあらゆる内容符号化を受諾すると仮定してよい。Accept-Encodingヘッダが存在し，サーバがそのAccept-Encodingヘッダに従って受諾可能な応答を送信できない場合，サーバは，406(Not Acceptable)状態コードをもつエラー応答を送信することが望ましい。

空のAccept-Encoding値は，何も受諾できないことを示す。

Accept-Language要求ヘッダフィールドはAcceptに似ているが，その要求への応答として好ましい自然言語の集合を制限する。

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

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

各language-rangeは，その範囲が指定する言語に対する利用者の好みの評価を表現する関連する品質値を与えられてもよい。品質値のデフォルトは，"q=1"とする。次に例を示す。

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

これは，"私はオランダ語を好むが，英国英語及び英語の他の型を受諾する。"，ということを意味する。language-rangeは，それがlanguage-tagと完全に等しい場合，又はそれがlanguage-tagの接頭辞に続く最初のタグ文字が"-"となるlanguage-tagの接頭辞と完全に等しい場合，language-tagと一致する。特殊な範囲"*"は，それがAccept-Languageフィールドに存在する場合には，そのAccept-Languageフィールドに存在する他の範囲とは一致しないすべてのタグと一致する。

備考　 接頭辞一致規則のこの使用は，利用者がある言語タグをもつ言語を理解する場合，この利用者はこのタグを接頭辞とするタグをもつすべての言語を理解するということが常に正しいといった方法で，言語タグは言語に割り当てられているということを暗示するわけではない。接頭辞規則は，単に，これが正しい場合には，接頭辞タグを使用してよいことを示している。

Accept-Languageフィールドによってlanguage-tagに割り当てられている言語品質因子は，そのlanguage-tagに一致するそのフィールドの中の最も長いlanguage-rangeの品質値とする。フィールドの中のlanguage-rangeがlanguage-tagに一致しない場合，割り当てられる言語品質因子は，0とする。要求にAccept-Languageヘッダが存在しない場合，サーバは，すべての言語が等しく受諾可能と仮定することが望ましい。Accept-Languageヘッダが存在する場合には，0よりも大きい品質因子を割り当てられたすべての言語が受諾可能とする。

すべての要求で利用者の完全な言語的な好みを示すAccept-Languageヘッダを送信することは，利用者のプライバシの予想には反するかもしれない。この問題の議論については，15.7を参照すること。

備考　 (言語理解の)明瞭さは個々の利用者に大いに依存するので，クライアントアプリケーションで，利用者に利用可能な言語的好みの選択が行われることが望ましい。選択が利用可能でない場合には，Accept-Languageヘッダフィールドは，要求において与えられてはならない。

Accept-Ranges応答ヘッダフィールドは，サーバが，資源に対する範囲要求の受諾を示すことを可能にする。

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

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

バイト範囲要求を受諾する原サーバは，次を送信してよい。

          Accept-Ranges: bytes

ただし，これを送信することは必須ではない。クライアントは，関連する資源に対するこのヘッダを受信することなしに，バイト範囲要求を生成してもよい。

資源に対するいかなる種類の範囲要求も受諾しないサーバは，次を送信してよい。

          Accept-Ranges: none

これによって，クライアントに範囲要求を試みないように助言できる。

Age応答ヘッダフィールドは，応答(又はその有効性再検証)が原サーバで生成されてからの時間総量の送信側の見積もりを運ぶ。その経過時間が新鮮さの期限を超えない場合には，キャッシュされた応答は"新鮮"とする。Age値は，13.2.3で指定されるとおりに計算される。

           Age = "Age" ":" age-value

           age-value = delta-seconds

キャッシュが表現可能な最大の正整数よりも大きな値を受信する場合，又は経過時間計算が桁あふれを起こす場合，キャッシュは，Ageヘッダを値2147483648 (2^31)として伝送しなければならない。HTTP/1.1キャッシュは，すべての応答でAgeヘッダを送信しなければならない。キャッシュは，範囲が少なくとも31ビットの算術型を使用することが望ましい。

Allow実体ヘッダフィールドは，Request-URIが識別する資源がサポートするメソッドの集合の一覧を示す。このフィールドの目的は，厳密に，受け手にその資源に関連する有効なメソッドを知らせることにある。Allowヘッダフィールドは，405(Method Not Allowed)応答には存在しなければならない。

          Allow          = "Allow" ":" 1#method

使用例を次に示す。

          Allow: GET, HEAD, PUT

このフィールドは，クライアントが他のメソッドを試そうとすることを禁止はできない。しかし，Allowヘッダフィールド値が与える指示には，従うことが望ましい。許されるメソッドの実際の集合は，各要求時に原サーバが定義する。

Allowヘッダフィールドは，新しい又は修正された資源がサポートするのがよいメソッドを推奨するためにPUT要求で提供してよい。サーバは，これらのメソッドをサポートすることを要求されない。サーバは，応答の中に，実際にサポートするメソッドを与えるAllowヘッダを含めることが望ましい。

プロキシは，たとえ指定されたメソッドすべてを理解しないとしても，利用者エージェントが原サーバと通信する他の手段をもっていてもよいので，Allowヘッダフィールドを修正してはならない。

Allowヘッダフィールドは，サーバにおいてどのメソッドが実装されているかを示さない。サーバは，サーバでそのメソッドが実装されているかを全体として記述するためにPublic応答ヘッダフィールド(14.35)を使用してもよい。

それ自体をサーバに認証させたい利用者エージェントは，Authorization要求ヘッダフィールドを要求に含めることによってこれを行ってよい。なお，このことは，必ずしもそうではないが，通常は，401応答を受信した後に行われる。Authorizationフィールド値は，要求されている資源の関係する範囲に対する利用者エージェントの認証情報を含む身分証明書(credentials)から成る。

          Authorization  = "Authorization" ":" credentials

HTTPアクセス認証は，11で示される。要求が認証され範囲が指定されている場合には，この範囲内のすべての他の要求に対して同じ身分証明書を有効とするのが望ましい。

共有キャッシュ(13.7参照)がAuthorizationフィールドを含む要求を受信する場合，共有キャッシュは，次の特定の例外が成立しない場合には，対応する応答を他の要求への返答として返してはならない。

Cache-Control一般ヘッダフィールドは，要求及び応答の連鎖に沿ったすべてのキャッシュ化機構が従わなければ成らない指令を指定するために使用する。指令は，キャッシュが不都合に要求又は応答に干渉することを防ぐことを意図した振る舞いを指定する。これら指令は，典型的には，デフォルトのキャッシュ化アルゴリズムを上書きする。キャッシュ指令は，要求の中に指令が存在するからといって，応答の中に同じ指令が与えられるのが望ましいというわけではないという点で，一方向的とする。

HTTP/1.0キャッシュは，Cache-Controlを実装しなくともよく，Pragma: no-cache(14.32参照)だけを実装すればよいことに注意すること。

キャッシュ指令は，プロキシ又はゲートウェイのアプリケーションによって，それら指令がそのアプリケーションに対して重要であっても，そのまま通過させられなければならない。これは，指令が，要求及び応答の連鎖に沿ったすべての受け手に適用可能であってもよいことによる。特定のキャッシュに対してキャッシュ指令(cache-directive)を指定することは可能とはしない。

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

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

          cache-request-directive =
                            "no-cache" [ "=" <"> 1#field-name <"> ]
                          | "no-store"
                          | "max-age" "=" delta-seconds
                          | "max-stale" [ "=" delta-seconds ]
                          | "min-fresh" "=" delta-seconds
                          | "only-if-cached"
                          | cache-extension

          cache-response-directive =
                            "public"
                          | "private" [ "=" <"> 1#field-name <"> ]
                          | "no-cache" [ "=" <"> 1#field-name <"> ]
                          | "no-store"
                          | "no-transform"
                          | "must-revalidate"
                          | "proxy-revalidate"
                          | "max-age" "=" delta-seconds
                          | cache-extension

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

指令が1#field-nameのパラメタ(一つ以上のfield-nameをコンマで区切った並び)のパラメタなしに出現する場合には，その指令は，要求又は応答の全体に適用される。それら指令が1#field-nameパラメタ付きで出現する場合には，その指令は，その名前のフィールドにだけ提供され，要求又は応答のそれ以外の部分には適用されない。この機構は，拡張可能性をサポートする。HTTPの将来の版の実装は，これら指令をHTTP/1.1で定義されないヘッダフィールドに適用してもよい。

cache-control指令は，次の一般的なカテゴリに分けることができる。

• キャッシュ可能なものに関する制限。これらは，原サーバだけが課してよい。
• キャッシュが記憶してもよいものに関する制限。これらは，原サーバ又は利用者エージェントのいずれかが課してよい。
• 基本有効期限切れ機構の修正。これらは，原サーバ又は利用者エージェントのいずれかが課してよい。
• キャッシュの有効性再検証及び再ロードに関する制御。これらは，利用者エージェントだけが課してよい。
• 実体の変換に関する制御。
• キャッシュ化システムへの拡張。

デフォルトで，要求メソッドの要件，要求ヘッダフィールド及び応答状態が応答はキャッシュ可能と指示している場合には，応答はキャッシュ可能とする。13.4は，キャッシュ可能性についてのこれらデフォルトをまとめている。次のCache-Control応答指令は，原サーバが応答のデフォルトキャッシュ可能性を上書きすることを許している。

public

応答が，通常はキャッシュ可能ではない又は非共有キャッシュ内でだけキャッシュ可能とする場合であっても，あらゆるキャッシュによってキャッシュ可能とすることを示す。追加情報については14.8 Authorizationも参照すること。

備考　 "private"のこの利用では，応答をキャッシュしてもよい場所だけを制御し，メッセージ内容のプライバシを確実にすることはできない。

no-cache

応答メッセージのすべて又は一部はどこでもキャッシュしてはならないことを示す。これによって，原サーバは，クライアント要求へ新鮮でない応答を返すように構成されているキャッシュによるキャッシュ化さえも防ぐことができる。

備考　 大部分のHTTP/1.0キャッシュは，この指令を認識しないし従うこともない。

no-store(記憶しない)指令の目的は，(例えば，バックアップテープの)重要な情報の不注意な公表又は保持を防ぐことにある。no-store指令は，メッセージ全体に適用され，応答又は要求のいずれかの中で送信してよい。要求で送信した場合には，キャッシュは，この要求又はその要求の応答のいずれのいかなる部分も記憶してはならない。応答で送信した場合には，キャッシュは，この応答又はその応答を引き出した要求のいずれのいかなる部分も記憶してはならない。この指令は，非共有キャッシュ及び共有キャッシュの両方に適用される。この文脈での"記憶してはならない"は，キャッシュは，不揮発性記憶に情報を意図的に記憶してはならないこと，及びその情報を回送した後は可能か限り速やかに揮発性記憶からその情報を削除するために最大限の試みをしなければならないことを意味する。

この指令が応答と関連する場合であっても，利用者は，(例えば，"Save As"(として保存)ダイアログを使って)キャッシュ化システムの外部でそれら応答を明示的に記憶してもよい。履歴バッファは，正常操作の一部としてそれら応答を記憶してもよい。

この指令の目的は，キャッシュデータ構造への予期しないアクセス経由による情報の偶発的な公表に関心のある利用者及びサービス作成者の明言された要件を満たすことにある。この指令の使用によってプライバシが改善されることがあるが，プライバシを確実にするための信頼できる又は十分な機構ではないことに気を付けること。特に，悪意のある又は信用を危うくするキャッシュは，この指令を認識しない又は従わないかもしれない。さらに，通信ネットワークは，盗聴の攻撃を受けやすい。

実体の有効期限切れ時間は，Expiresヘッダ(14.21参照)を使用して原サーバが指定してよいが，応答でmax-age指令を使用して指定してもよい。

応答がExpiresヘッダ及びmax-age指令の両方を含む場合，Expiresヘッダがより限定的であっても，max-age指令がExpiresヘッダを上書きする。この規則によって，原サーバは，与えられた応答に対して，HTTP/1.1(又はそれ以降の版の)キャッシュに対してHTTP/1.0に対するよりも長い有効期限切れ時間を提供できる。このことは，HTTP/1.0キャッシュが，恐らく同期化されていない時計のために，不適切に経過時間又は有効期限切れ時間を計算することがある場合に役に立つかもしれない。

備考　 この規定に準拠しない大部分のより古いキャッシュは，Cache-Control指令を実装していない。HTTP/1.1準拠のキャッシュによるキャッシュ化を制限する，ただし禁止はしない，Cache-Control指令を使用したい原サーバは，max-age指令がExpiresヘッダを上書きするという要件，及びHTTP/1.1準拠ではないキャッシュはmax-age指令には従わないという事実を利用してもよい。

その他の指令は，利用者エージェントが基本有効期限切れ機構を修正することを可能にする。次の指令は，要求において指定してよい。

クライアントは，その経過時間が(この指令の)秒単位で指定された時間よりも大きくない応答を受諾する準備があることを示す。max-stale指令も含まれている場合でなければ，クライアントは，新鮮でない応答を受諾する用意はない。

クライアントは，その新鮮保持期間が現在の経過時間に(この指令の)秒単位で指定された時間を加えたものよりも小さくない応答を受諾する準備があることを示す。すなわち，クライアントは，少なくとも指定された秒数の間は未だ新鮮な応答を望んでいる。

クライアントは，有効期限切れ時間を超えた応答を受諾する準備があることを示す。max-staleに値が割り当てられている場合には，クライアントは，(この指令の)指定された秒数よりも多くない秒数まで有効期限切れ時間を超えた応答を受諾する準備がある。値がmax-staleに割り当てられていない場合には，クライアントは，あらゆる経過時間の新鮮でない応答を受諾する準備がある。

キャッシュが新鮮でない応答を返す場合，要求におけるmax-stale指令のため，又はキャッシュが応答の有効期限切れ時間を上書きするように構成されているためのいずれかの理由によって，キャッシュは，Warning 10 (Response is stale)を使って，その新鮮でない応答にWarningヘッダを添付しなければならない。

利用者エージェントが，キャッシュはそのキャッシュエントリを(原サーバへの経路に沿って単に次のキャッシュとのではなく)原サーバとの有効性再検証をすることを主張するか，そのキャッシュエントリを原サーバから再ロードするかを望む又は必要とすることがある。端点間の有効性再検証は，キャッシュ又は原サーバがキャッシュされた応答の有効期限切れ時間を多く見積もった場合には，必要としてもよい。端点間の再ロードは，キャッシュエントリが何らかの理由で壊れた場合には，必要としてもよい。

端点間の有効性再検証は，クライアントがそれ自体の局所的なキャッシュされたコピーをもたない場合，又はクライアントが局所的なキャッシュされたコピーをもつ場合のいずれかで要求されてもよい。前者の場合を，"未指定の端点間有効性再検証"と呼び，後者の場合を，"特定の端点間有効性再検証"と呼ぶ。

クライアントは，Cache-Control要求指令を使用して，これらの3種類の動作を次のとおりに指定できる。

端点間再ロード

要求は，"no-cache"(キャッシュなし) Cache-Control指令，又はHTTP/1.0クライアントとの互換性のためには"Pragma: no-cache"を含む。フィールド名は，要求のno-cache指令とともに含めなくてよい。サーバは，それら要求へ応答する場合には，キャッシュされたコピーを使用してはならない。

要求は，"max-age=0" Cache-Control指令を含む。これによって，原サーバへの経路に沿った各キャッシュは，それ自体のエントリを，存在する場合には次のキャッシュ又はサーバとの間で有効性検証することを強制される。最初の要求は，クライアントの現在の有効性検証子を用いたキャッシュ有効性検証条件を含む。

未指定の端点間有効性再検証

要求は，"max-age=0" Cache-Control指令を含む。これによって，原サーバへの経路に沿った各キャッシュは，それ自体のエントリを，存在する場合には次のキャッシュ又はサーバとの間で有効性検証することを強制される。最初の要求は，キャッシュ有効性検証条件を含まない。(存在する場合には，)この資源に対するキャッシュエントリを保持する経路に沿った最初のキャッシュが，そのキャッシュの現在の有効性検証子を用いたキャッシュ有効性検証条件を含める。

中間キャッシュが，"max-age=0"指令によって，それ自体のキャッシュエントリを有効性再検証することを強制され，クライアントが要求でそれ自体の有効性検証子を供給した場合，供給された有効性検証子は，キャッシュエントリとともに現在記憶されている有効性検証子と異なっていてもよい。この場合，キャッシュは，それ自体の要求を作成する際，意味的透過性に影響を与えることなしにいずれの有効性検証子を使用してもよい。

しかし，有効性検証子の選択は，性能に影響することがある。最も良い手法は，中間キャッシュがその要求を作成するときにそれ自体の有効性検証子を使用することである。サーバが304(Not Modified)で返答する場合には，キャッシュは，200(OK)で，そのキャッシュの現在の有効性検証されたコピーをクライアントに返すのがよい。しかし，サーバが新しい実体及びキャッシュ有効性検証子付きで返答する場合には，中間キャッシュは，その返された有効性検証子をクライアントの要求の中で提供されたものとを，強比較関数を使って比較することが望ましい。クライアントの有効性検証子が原サーバのそれと等しい場合には，中間キャッシュは，単に，304(Not Modified)を返す。そうでない場合には，200(OK)でその新しい実体を返す。

要求がno-cache指令を含む場合，要求は，min-fresh，max-stale及びmax-ageを含まない方がよい。

極端にネットワーク接続性が悪いときなどの場合には，クライアントは，キャッシュに，そのキャッシュが現在記憶している応答を，原サーバとの間で再ロードしたり有効性再検証したりするのではなく，ただ返すことだけを望んでもよい。これをするためには，クライアントは，要求にonly-if-cached指令を含めればよい。キャッシュがこの指令を受信する場合には，キャッシュは，その要求の他の制約と矛盾しないキャッシュされたエントリを使って応答するか，又は504(Gateway Timeout)状態で応答するのがよい。しかし，キャッシュのグループが，状況のよい内部接続で一つの統一的システムとして操作されている場合，それら要求は，キャッシュのそのグループ内で回送されてもよい。

キャッシュはサーバの指定した有効期限切れ時間を無視するように構成されていてもよく，クライアント要求は(同じ効果をもつ)max-stale指令を含んでいてもよいので，プロトコルは，原サーバがあらゆる後続の使用においてキャッシュエントリの有効性再検証を要求するという機構も含んでいる。must-revalidate指令がキャッシュが受信した応答の中に存在する場合には，そのキャッシュは，エントリが後続の要求に対して応答するために新鮮ではなくなった後には，まず原サーバとの間で有効性再検証しなければ，そのエントリを使用してはならない。すなわち，キャッシュは，原サーバのExpires値又はmax-age値だけに基づいてそのキャッシュされた応答が新鮮でない場合には，端点間の有効性再検証を常に行わなければならない。

must-revalidate指令は，幾つかのプロトコル機能にとって信頼性のある操作をサポートするために必要になる。すべての状況において，HTTP/1.1キャッシュは，must-revalidate指令に従わなければならない。特に，キャッシュが何らかの理由で原サーバに到達できない場合には，504(Gateway Timeout)応答を生成しなければならない。

サーバは，実体に関する要求の有効性再検証の失敗が，誰にも気付かれずに実行されないままの金融関係のトランザクションといった正しくない操作，を生じる可能性がある場合及びその場合に限り，must-revalidate指令を送信することが望ましい。受け手は，この指令に違反するいかなる自動的な動作も取ってはならないし，有効性再検証が失敗した場合には，その実体の有効性再検証されていないコピーを自動的に提供してはならない。

望ましくないことだが，状況の非常に悪い接続性の制約下で操作されている利用者エージェントは，この指令に違反してもよい。しかし，その場合には，有効性再検証されていない応答が提供されたことを利用者に明示的に警告しなければならない。警告は，有効性再検証されていないアクセスごとに提供されなければならないし，明示的な利用者の確認を要求することが望ましい。

proxy-revalidate指令は，must-revalidate指令と同じ意味をもつ。ただし，非共有の利用者エージェントキャッシュには適用されない点は除く。proxy-revalidate指令は，認証された要求への応答に関して，利用者のキャッシュに，その応答を記憶しそれを有効性再検証する必要なしに後に返すことを許す(これは，その利用者によって一度は既に認証されていることによる。)ために使用できるが，それでも，多くの利用者にサービスをするプロキシに(各利用者が既に認証されていることを確実にするために)毎回有効性再検証することを要求する。それら認証された応答は，それらをキャッシュ可能とするために公開キャッシュ制御(public Cache-Control)指令も必要とすることに注意すること。

中間キャッシュ(プロキシ)の実装者は，ある実体本体のメディア型を変換することが有用と分かっている。例えば，プロキシは，キャッシュ領域を節約するために，又は低速のリンク上のトラフィック量を減らすために，画像フォーマットの間で変換をするかもしれない。HTTPは，今までのところ，これら変換に関して何も規定していない。

しかし，これらの変換がある種のアプリケーションに意図された実体本体に適用された場合，重大な操作上の問題が既に発生している。例えば，医療用画像，科学的データ解析及び端点間認証に使用するデータに対するアプリケーションは，すべて，元の実体本体とビットごとに同一な実体本体を受信することに依存している。

そのために，応答がno-transform指令を含んでいる場合には，中間キャッシュ又はプロキシは，no-transform指令に従うとして13.5.2に一覧を示されたヘッダを変更してはならない。このことは，キャッシュ又はプロキシは，これらヘッダが指定する実体本体(entity-body)のいかなる側面も変更してはならないことを暗黙に示している。

Cache-Controlヘッダフィールドは，それぞれがオプションの割り当てられた値をもつ一つ以上のcache-extensionトークンを使って拡張できる。情報的な拡張(キャッシュの振る舞いには変更を要求しないもの)は，他の指令の意味を変更することなしに追加してよい。振る舞いに関する拡張は，キャッシュ指令の既存の基底(基本的なもの)への修飾子として振る舞うことによって作動するように設計されている。新しい指令及び標準指令の両方が供給されるが，新しい指令を理解しないアプリケーションはデフォルトで標準指令が指定する振る舞いをし，新しい指令を理解するアプリケーションはその指令を標準指令と関連する要件を修正すると認識するようになっている。この方法で，Cache-Control指令への拡張は，基底プロトコルへの変更を要求することなしに行える。

この拡張機構は，HTTPキャッシュに依存するが，そのHTTPキャッシュは，HTTPキャッシュ本来のHTTPの版に対して定義されるすべてのキャッシュ制御指令に従い，ある拡張に従い，それが理解しないすべての指令は無視する。

例えば，"private"指令への修飾子として動作する"community"と呼ぶ仮想的な新しい応答指令を考える。この新しい指令は，非共有キャッシュに加えて，その値の範囲内の名前が付いたコミュニティのメンバだけが共有するあらゆるキャッシュが応答をキャッシュしてよい，という意味をもつと定義する。"UCI"コミュニティに，そのコミュニティの共有キャッシュの中のそのコミュニティ以外には私的な応答を使用してよいとしたい原サーバは，次を含めることによってこれを行ってよい。

          Cache-Control: private, community="UCI"

このヘッダフィールドを見るキャッシュは，"community"キャッシュ拡張を理解しなくとも，正しく動作する。これは，そのキャッシュが"private"指令も見て理解し，デフォルトで安全な振る舞いをすることによる。

認識しないキャッシュ指令は，無視しなければならない。HTTP/1.1キャッシュが認識しないことが多いキャッシュ指令は，キャッシュが拡張を理解しない場合であってもキャッシュの振る舞いが最小限正しいままになるように，標準指令(又は応答のデフォルトのキャッシュ可能性)と組み合わせる。

Connection一般ヘッダフィールドは，送信側に，その特定のコネクションに望まれるがそれ以外に付け加えられたコネクション上のプロキシによっては通信されてはならないオプションを，指定できるようにする。

Connectionヘッダは，次の文法をもつ。

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

HTTP/1.1プロキシは，メッセージを回送する前にConnectionヘッダフィールドを構文解析し，このフィールドの中の各connection-tokenに対して，そのメッセージからそのconnection-tokenと同じ名前をもつヘッダフィールドを取り除かなければならない。コネクションオプションは，Connectionヘッダフィールドの中のconnection-tokenの存在によって通知される。対応する付加的なヘッダフィールドによっては知らされない。これは，そのコネクションオプションと関連するパラメタが存在しない場合には，付加的なヘッダフィールドは送信されなくともよいことによる。HTTP/1.1は，コネクションは応答の完了後に閉じられることを送信側が通知するために"close"コネクションオプションを定義する。次に例を示す。

          Connection: close

要求又は応答のヘッダフィールドの中にあるこれは，コネクションが，現在の要求又は応答が完了後には'永続的'(8.1)ではないと考えることが望ましいことを示している。

永続的コネクションをサポートしないHTTP/1.1アプリケーションは，すべてのメッセージに"close"コネクションオプションを含めなければならない。

Content-Base実体ヘッダフィールドは，実体内の相対的URLを解決するために基底URIを指定するために使用してよい。このヘッダフィールドは，RFC1808におけるBaseとして示される。ただし，RFC1808は改訂が予定されている。

          Content-Base      = "Content-Base" ":" absoluteURI

Content-Baseフィールドが存在しない場合には，実体の基底URIが，(Content-Location URIが絶対URIの場合には)その実体のContent-Location，又は要求を開始するために使用されたURIのいずれかによって定義される。ただし，Content-Locationを優先する。しかし，実体本体内の内容の規定URIは，その実体本体内で再定義されてもよいことに注意すること。

Content-Encoding実体ヘッダフィールドは，そのメディア型への修飾子として使用する。存在する場合には，その値は，どの付加的な内容符号化(content codings)が実体本体に適用されているか，及びどの復号機構がContent-Typeヘッダフィールドが参照するメディア型を取得するために適用されなければならないかを示す。Content-Encodingは，基本的には，文書をその基本となるメディア型の識別性を失うことなく圧縮できるために使用する。

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

内容符号化(content-coding)は，3.5で定義される。その使用例を次に示す。

          Content-Encoding: gzip

Content-Encodingは，Request-URIが識別する実体の特質とする。典型的には，実体本体は，この符号化で記憶され，レンダリング又はそれに類似した利用の前にだけ復号される。

複数の符号化が一つの実体に適用されている場合，それら内容符号化は，適用された順番に一覧として示されなければならない。

符号化パラメタについての追加情報を，この規定が定義しない他の実体ヘッダフィールドが提供してもよい。

Content-Language実体ヘッダフィールドは，同封された実体に対して意図された視聴者の自然言語を記述する。これは，実体本体内で使用されるすべての言語と等価ではないかもしれないことに注意すること。

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

言語タグ(language-tag)は，3.10で定義する。Content-Languageの基本的な目的は，利用者に利用者自身の好む言語に従って実体を識別し区別することを可能にすることにある。そこで，本体内容がオランダ語の読み書きができる視聴者だけに対して意図されている場合，その適切なフィールドは次のとおりになる。

          Content-Language: da

Content-Languageが指定されていない場合，デフォルトとして，その内容はすべての言語の視聴者を意図しているものとする。これは，送信側がその内容をいずれかの自然言語に特定なものとは考えないこと，又は送信側がその内容がどの言語を意図しているかを知らないことを意味してもよい。

複数の言語が，複数の視聴者に対して意図された内容について，一覧として示されてもよい。例えば，元々のマオリ語及び英語のそれぞれの版で同時に表示される"Treaty of Waitangi"の描出には，次が必要となる。

          Content-Language: mi, en

しかし，実体内に複数の原語が存在するからといって，その内容が複数の言語の視聴者を意図しているとはいえない。例えば，"A First Lesson in Latin"といった初心者用の言語入門がその例になる。これは，明らかに，英語を読み書きする視聴者が使用することを意図している。この場合，Content-Languageは，"en"だけを含むのがよい。

Content-Languageは，あらゆるメディア型に適用してよい。特に，テキスト文書に限定されない。

Content-Length実体ヘッダフィールドは，受け手に送信されるメッセージ本体の大きさを，オクテットの10進数表示で示す、ただし，HEADメソッドの場合には，要求がGETだったものとして送信された実体本体の大きさとする。

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

次に例を示す。

          Content-Length: 3495

アプリケーションは，実体のメディア型には関係なく，このフィールドを使用して転送されたメッセージ本体の大きさを示すことが望ましい。例えば，要求は有効なContent-Lengthフィールドをもっていたり，Transfer-Encoding: chunked又はマルチパートを使っているので，それを信頼して受け手が実体本体を含むHTTP/1.1の要求の終端を決定できなければならない。

0以上のContent-Lengthを有効な値とする。4.4では，Content-Lengthが与えられない場合に，メッセージ本体の長さを決定する方法を示す。

備考　 このフィールドの意味は，MIMEにおける対応する定義とは大いに異なっている。MIMEでは，このフィールドは"message/external-body"内容型の内部で使用されるオプションのフィールドになっている。HTTPでは，メッセージの長さが転送する前に決定できる場合にはいつでも，このフィールドを送信することが望ましい。

Content-Location実体ヘッダフィールドは，メッセージの中に同封された実体に対する資源の位置を供給するために使用してよい。資源がそれに関連する複数の実体をもち，それらの実体が実際には別々にアクセスされるかもしれない分離された位置をもっている場合には，サーバは，返される特定の変形に対してContent-Locationを提供するのがよい。さらに，サーバは，応答実体に対応する資源に対してContent-Locationを提供するのがよい。

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

Content-Baseヘッダフィールドが存在しない場合には，Content-Locationの値も実体の基底URLを定義する(14.11参照)。

Content-Location値は，オプションの要求(された)URIの代わりではない。その値は，要求時におけるこの特定の実体に対応する資源の位置を述べているだけとする。その特定の実体の源を特定することが要求されている場合には，その後の要求でContent-Location URIを使用してもよい。

キャッシュは，実体を検索するために使用されるURIとは異なるContent-Locationをもつその実体を，そのContent-Location URIに関するその後の要求へ応答するために使用できると仮定することはできない。しかし，Content-Locationは，13.6で示すとおり，単一の要求された資源から検索される複数の実体を区別するために使用できる。

Content-Locationが相対URIの場合，そのURIは，応答で提供されるContent-Base URIに対して相対的に解釈される。Content-Baseが提供されない場合には，相対URIは，Request-URIに対して相対的に解釈される。

Content-MD5実体ヘッダフィールドは，RFC1864[23]で定義するとおり，実体本体の端点間のメッセージ完全性検査(Message Integrity Check，MIC)を提供する目的の実体本体のMD5ダイジェストとする。(ただし，MICは，転送中にある実体本体の偶発的な修正を検知するためには有用だが，悪意のある攻撃に対する証明にはならないことには注意すること。)

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

           md5-digest   = <RFC 1864に従う128ビットMD5ダイジェストのbase64>

Content-MD5ヘッダフィールドは，実体本体の完全性検査として機能させるために原サーバが生成してよい。原サーバだけが，Content-MD5ヘッダフィールドを生成してよい。端点間の完全性検査としてのContent-MD5ヘッダフィールドの値を使えなくするので，プロキシ及びゲートウェイは生成してはならない。ゲートウェイ及びプロキシを含む，実体本体のあらゆる受け手は，このヘッダフィールドの中のダイジェスト値が受信した実体本体のダイジェスト値と一致することを検査してよい。

MD5ダイジェストは，適用されたContent-Encodingを含むがメッセージ本体に適用されていてもよいTransfer-Encodingを含まない実体本体の内容に基づいて計算される。メッセージがTransfer-Encodingをともなって受信される場合，その符号化は，受信された実体に対するContent-MD5値の検査に先立って取り除かれなければならない。

これによって，Transfer-Encodingが適用されていないものとして送信された正確にそのとおりの，及びその順番での，実体本体のオクテットに基づいてダイジェストは計算される，という結果を得る。

HTTPは，RFC1864を拡張し，MIME複合メディア型(例えば，multipart/*，message/rfc822など。)に対してダイジェストを計算することを許している。しかし，このことは，ここで定義しているとおりのダイジェストの計算方法を変更はしない。

備考1　 このことに関する結果が幾つか存在する。複合型に対する実体本体は，多くの本体部分(body-part)を含んでよく，それぞれがそれ自体の(Content-MD5ヘッダ，Content-Transfer-Encodingヘッダ及びContent-Encodingヘッダを含む)MIMEヘッダ及びHTTPヘッダをもつ。本体部分がContent-Transfer-Encodingヘッダ又はContent-Encodingヘッダをもつ場合，本体部分の内容はその符号化が適用され，本体部分は(適用された後)そのままContent-MD5ダイジェストに含まれる，と仮定される。Transfer-Encodingヘッダフィールドは，本体部分内には許されない。

備考2　 Content-MD5の定義は，HTTP実体本体に対して，MIME実体本体に対するRFC1864におけるのと正確に同じだが，Content-MD5のHTTP実体本体への適用がMIME実体本体への適用とは異なる，幾つかの方法が存在する。MIMEとは異なり，HTTPは，Content-Transfer-Encodingを使用せずTransfer-Encoding及びContent-Encodingを使用するという方法がある。HTTPは，MIMEよりもバイナリ内容型をより多く使用し，そのために，それらの場合では，ダイジェストを計算するために使用するバイト順をその型に対して定義された伝送バイト順とするという注意は意味がある，というものもある。さらに，HTTPは，テキストの伝送に，CRLFを使う正準形式だけでなく幾つかの行区切り規約のいずれも使用できる。すべての行区切りのCRLFへの変換は，ダイジェストの計算又は検査の前に行わないほうがよい。実際に伝送されるテキストで使用される行区切り規約は，ダイジェストを計算するときには，変更しないでおくほうがよい。

Content-Range実体ヘッダは，全実体本体の中で部分的な本体が挿入されることが望ましい場所を指定するために，部分的な実体本体とともに送られる。これは全実体本体の全サイズも示している。サーバがクライアントに部分的な応答を返す場合，応答によってカバーされる範囲の程度及び全実体本体の長さの両方を記述しなければならない。

          Content-Range = "Content-Range" ":" content-range-spec

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

          byte-content-range-spec = bytes-unit SP first-byte-pos "-"
                                    last-byte-pos "/" entity-length

          entity-length           = 1*DIGIT

byte-ranges-specifier値とは違って，byte-content-range-specは一つの範囲だけを指定してもよく，さらに範囲の最初及び最後のバイトの両方に絶対的なバイト位置を含まなければならない。

last-byte-pos値がそのfirst-byte-pos値よりも小さいか，又は，entity-length値が last-byte-pos値以下であるbyte-content-range-specは無効である。無効なbyte-content-range-specの受け手は，これを無視しなければならないしそれとともに転送されたすべての内容を無視しなければならない。

次に，実体が全1234 バイトを含んでいると仮定して，byte-content-range-spec値の例を示す。

o 最初の 500 バイト:

bytes 0-499/1234

o 次の 500 バイト:

bytes 500-999/1234

o 最初の 500 バイト以外のすべて:

bytes 500-1233/1234

o 最後の 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メッセージが複数の範囲の内容を含んでいる場合(例えば，複数の重複していない範囲に対する要求の応答)，これらはマルチパートのMIMEメッセージとして伝送される。この目的で使用されるマルチパートのMIME内容型はこの規定の中で"multipart/byteranges"であると定義される。その定義に対しては附属情報19.2を参照。

MIME multipart/byterangesメッセージを解読できないクライアントは単一の要求で複数のバイト範囲を求めないほうがよい。

クライアントが一つの要求で複数のバイト範囲を要求する場合，サーバは要求に現れる順番にそれらを返すことが望ましい。

サーバが無効のため，byte-range-specを無視する場合，サーバは無効なRangeヘッダフィールドが存在していなかったかのように要求を取り扱うことが望ましい。(通常，これは全実体を含む200応答を返すことを意味する)。理由は，クライアントがそのような無効な要求をするときは，実体が直前の要求によって検索された実体よりも小さい場合だけであるということである。

Content-Type実体ヘッダフィールドは受け手に送られた実体本体のメディア型を示すか，又はHEADメソッドの場合，要求がGETで送られたメディア型を示している。

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

メディア型は，3.7で定義する。フィールドの例は次のようになる。

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

実体のメディア型を識別する方法の詳細は 7.2.1に示す。

14.19 Date(日付)

Date一般ヘッダフィールドは，RFC822のorig-dateと同じセマンティクスをもち，メッセージが生じた日付及び時間を表わす。フィールド値は，3.3.1で記述する，HTTP-dateである。

          Date  = "Date" ":" HTTP-date

次に例を示す。

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

理論上は，日付は実体が生成されるちょうどその瞬間を表すことが望ましい。実際上は，日付はそのセマンティクス値に影響を与えることなしにメッセージ発生の間のいつでも生成することができる。

Dateフォーマットは，3.3のHTTP-dateで定義されているような絶対日付及び絶対時間である。それは，RFC1123 [8]の日付フォーマットで送られなければならない。

ETag実体ヘッダフィールドは関連する実体のための実体タグを定義する。実体タグに使用されているヘッダは，14.20，14.25及び14.43に記述する。実体タグは，他の実体との比較のために同じ資源から用いられてもよい(13.3.2を参照)。

         ETag = "ETag" ":" entity-tag

例:

         ETag: "xyzzy"
         ETag: W/"xyzzy"
         ETag: ""

Expires実体ヘッダフィールドは，応答が新鮮でないと考慮された後の日付/時間を与える。新鮮でないキャッシュ実体は，通常，最初に原サーバ(又は，実体の新鮮な複写をもつ中間キャッシュ)に有効性検証されていない場合であっても，キャッシュ(プロキシキャッシュか利用者エージェントキャッシュのどちらか)によって戻されなくてもよい。有効期限切れモデルの詳細は，13.2に示す。

Expiresフィールドの出現は，原資源がその時間の前又は後に，変更又は存在を終了するということを暗示していない。

フォーマットは，3.3 HTTP-dateによって定義される絶対日付及び絶対時刻である。それは，RFC1123の日付フォーマットでなければならない：

         Expires = "Expires" ":" HTTP-date

次に，使用例を示す。

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

HTTP/1.1クライアント及びキャッシュは他の無効な日付フォーマット，特に値"0"を含むものを，過去のものである("既に有効期限切れ"等)として扱わなければならない。

応答を"既に有効期限切れ"としてマークするために，原サーバはDateヘッダ値に等しい Expires日付を使用することが望ましい。(13.2.4の有効期限切れ計算の規則参照)

応答を"有効期限が切れでない"としてマークするために，原サーバは応答が送信された時からExpires日付として約1年の日付を使用すべきである。 HTTP/1.1サーバは将来にわたり，1年より多いExpires日付を送ることは望ましくない。

デフォルトではキャッシュ不可能である他の応答で，将来のある時間の日付値をもつ Expiresヘッダフィールドの存在は，Cache-Controlのヘッダフィールド(14.9参照)による他の方法が指定されていない場合，応答がキャッシュ可能であることを示す。

From要求ヘッダフィールドが与えられるのであれば，それは要求する利用者エージェントを制御する人間の利用者のインターネット電子メールアドレスを含むことが望ましい。アドレスは， RFC822(RFC1123として更新)のメールボックスで定義されるように，機械使用可能であることが望ましい：

          From   = "From" ":" mailbox

次に，例を示す。

          From: webmaster@w3.org

このヘッダフィールドはログを取る目的並びに無効な要求及び望まれない要求の出所を識別する手段として用いてもよい。これはアクセス保護の安全でない形式として用いない事が望ましい。このフィールドの解釈は，要求が人のために実行されるものであるので，このメソッドを実行するために責任を受諾する人により与えられる。 特に，ロボットエージェントは，問題が受信側で起きた場合，ロボットを作動するのに責任のある人に連絡できるように，このヘッダを含めることが望ましい。

このフィールドのインターネット電子メールアドレスは，要求を発行するインターネットのホストと分かれていてもよい。例えば，要求がプロキシから渡されている場合，原発行者のアドレスが使われることが望ましい。

Host要求ヘッダフィールドは，利用者又は参照する資源（普通は，3.2.2で記述する HTTP URL）によって与えられる原URLから得られるように，要求されている資源のインターネットのホスト及びポート番号を指定する。 Hostフィールド値は，原URLによって与えられた原サーバ又はゲートウェイのネットワークロケーションを表さなければならない。これは，原サーバ又はゲートウェイに，単一の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ヘッダフィールドを含まなければならない。つまり，要求されたサービスのインターネットホストアドレスを含む URLに対する要求に相当するすべてのメッセージにである。Hostフィールドがまだ存在していない場合，HTTP/1.1プロキシはインターネット上でそれを回送する前に要求メッセージにHost フィールドを追加しなければならない。すべてのインターネットベースの HTTP/1.1サーバは，Hostヘッダフィールドに欠けているすべてのHTTP/1.1要求メッセージを 400の状態コードで応答しなければならない。

Hostに関係する他の要求に関しては，5.2及び19.5.1を参照。

If-Modified-Since要求ヘッダフィールドは，GETメソッドを条件付きにするために使用される。要求された可変部がこのフィールドで指定された時間から修正されていない場合，実体はサーバから返されない。その代わりに，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)応答を返さなければならない。

この特徴の目的は最小のトランザクション付加でキャッシュされた情報の効率的な更新を行えるようにすることである。

備考：Rangeの要求ヘッダフィールドはIf-Modified-Sinceの意味を修正する。詳細は14.36を参照。

備考：If-Modified-Sinceの時間はサーバによって解釈され，そのクロックはクライアントとは同期していなくてもよい。

備考：クライアントが，同じ要求に対して，Last-Modifiedヘッダから取り出される日付の代わりに， If-Modified-Sinceヘッダの日付を任意に使用する場合，クライアントはこの日付がサーバの理解する時間として解釈されるということを知ることが望ましい。クライアントはクライアント及びサーバ間の時間の異なった符号化による非同期クロック及びその周りの問題を考慮することが望ましい。これは，文書が最初に要求された時間及び後続する要求のIf-Modified-Since日付の間に変更しているかの時間経過条件の可能性，並びにIf-Modified-Sinceの日付がサーバクロックの訂正なしにクライアントクロックに由来するかどうかのクロック歪みに関係する問題の可能性を含んでいる。クライアントとサーバの間の異なる時間基準の訂正は，ネットワーク潜在のための最良の近似による。

If-Match要求ヘッダフィールドは，メソッドを条件付きにすることに使用される。資源から前もって得られた一つ以上の実体を持つクライアントは，それらの実体の一つがIf-Matchヘッダフィールドの関連した実体タグのリストを含めることで，最新であることを検証する。この特徴の目的は最小のトランザクション付加でキャッシュされた情報の効率的な更新を許すことである。要求の更新で，資源の間違った版の不注意な修正を妨げるためにも使用される。特殊な場合として，値"*"は資源のあらゆる最新の実体と一致する。

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

すべての実体タグが，資源上での類似した(If-Modifiedヘッダなしの)GET要求への応答に返された実体の実体タグに一致したり，又は，"*"が与えられ，すべての最新の実体がその資源に対して存在する場合，サーバはIf-Matchヘッダフィールドが存在しなかったかのように要求されたメソッドを実行してもよい。

サーバはIf-Matchの実体タグを比較するために強い比較機能を使用しなければならない。 (3.11参照）

実体タグがどれとも一致しなかったり，又は，"*"が与えられて，最新の実体が存在していない場合，サーバは要求されたメソッドを実行してはならない。さらに412(Precondition Failed)応答を返さなければならない。この動作は，PUTのような更新するメソッドを，クライアントが最後に資源を検索した以後，変更した資源を修正させないことを望む場合，もっとも有用である。

If-Matchヘッダフィールドなしの要求が，2xx状態以外の何かを結果として生じる場合，If-Matchヘッダは無視されなければならない。

"If-Match: *"の意味は，メソッドが原サーバによって(又は，Vary機構を使っているキャッシュによって - 14.43参照) 選択された表現が存在する場合，実行されることが望ましく，表現が存在しない場合，実行されてはいけない。

資源を更新しようとする要求(PUT等)は，要求メソッドがIf-Match値(単一の実体タグ)に相当する実体がもはやその資源の表現でない場合，適用されてはならないように通知するためにIf-Matchヘッダフィールドを含んでいてよい。これは，利用者に資源が彼らの知らないうちに変更されていた場合，要求の成功を望まないことを示せるようにしている。

例えば

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

If-None-Match要求ヘッダフィールドはメソッドを条件付けするのに使われる。資源から前もって得られた一つ以上の実体をもつクライアントは，If-None-Matchヘッダフィールドのそれらに関連する実体タグのリストを含めることにより，それらの実体のすべてが最新でないことを検証する事が出来る。この特徴の目的は，最小のトランザクション負荷でキャッシュされた情報の効率的な更新を行えるようにすることである。これは，更新要求に応じて，存在を知られていない資源の不注意な修正を妨げるのにも使用される。

特別な場合として，値"*"は資源のすべての最新の実体と一致する。

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

二つの実体タグが一致するのかを決定する規則に関しては，13.3.3を参照。弱い比較機能は，GET又はHEAD要求にだけ使われることができる。

実体タグがどれとも一致しなかったり，又は"*"が与えられ，最新の実体が何も存在しない場合，サーバはIf-None-Matchヘッダフィールドが存在しなかったように要求されたメソッドを実行してもよい。

If-None-Matchヘッダフィールドなしで，要求が2xx状態以外の何かを結果として生じる場合，If-None-Matchヘッダは無視されなければならない。

"If-None-Match: *"の意味は，メソッドが原サーバ(或いは，Vary機構を使っているキャッシュにより，14.43参照)により選択された表現が存在する場合には実行されてはならず，又は，その表現が存在しない場合，実行されることが望ましい。この特徴は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-Unmodified-Since及びIf-Matchのどちらか一方又は両方を使用して) 条件付きGETにRange要求ヘッダを使うことができる。しかしながら，条件が実体の修正のため失敗する場合，クライアントは現在の全実体本体を取得する第2の要求を作らなければならないだろう。

If-Rangeヘッダは，クライアントに第2の要求を"短く迂回する"ことを認めている。非公式であるが，これは，`実体が変更されていない場合，私が持っていない部分を送れ;さもなければ，新しい全実体を送れ'ということを意味している。

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

クライアントが実体に実体タグをもっていないが，Last-Modified日付を持っている場合， If-Rangeヘッダにその日付を使ってもよい。(サーバは有効なHTTP-date及び2文字以下を検査することで実体タグのすべての形式を区別することができる。）If-Rangeヘッダは，Rangeヘッダとともにだけ使われることが望ましく，要求がRangeヘッダを含んでいなかったり，又はサーバが補助範囲操作をサポートしない場合無視されなければならない。

If-Rangeヘッダに与えられる実体タグが実体に対して最新の実体タグと一致する場合，サーバは206(Partial Content)応答を使って実体の指定された補助範囲を供給することが望ましい。実体タグが一致しない場合，サーバは200(OK)応答を使って全実体を返すことが望ましい。

If-Unmodified-Since要求ヘッダフィールドは，メソッドを条件付きにするのに使われる。要求された資源がこのフィールドに指定された時間から修正されていない場合，サーバはIf-Unmodified-Sinceヘッダが存在していないかのように要求された操作を実行することが望ましい。

要求された可変部が指定された時間から修正されている場合，サーバは要求された操作を実行してはならず， 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状態以外の何かを結果として生じる場合， If-Unmodified-Sinceヘッダは無視されることが望ましい。

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

Last-Modified実体ヘッダフィールドは，原サーバが最後の可変部の修正であると信じている日付及び時間を示す。

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

次に，使用例を示す。

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

原サーバはメッセージ発生のサーバの時間よりも後のLast-Modifiedの日付を送ってはならない。このような場合，資源の最後の修正は，将来のある時間を示し，サーバはその日付をメッセージ発生の日付に置き換えなければならない。

原サーバは応答のDate値を生成する時間に可能な限り近い実体のLast-Modified値を得ることが望ましい。これは，特に実体が応答の生成された時間の近くで変更する場合，受け手に実体の修正時間の正確な査定を行えるようにする。

HTTP/1.1サーバは，実行可能なときいつでも，Last-Modifiedを送ることが望ましい。

Location応答ヘッダフィールドは，要求の完了又は新しい資源の識別のためのRequest-URI以外の位置を受け手に宛先を切り替えるために使われる。 201(Created)応答に関しては，Location は要求によって生成された新しい資源のものである。 3xx応答に関しては，位置は資源を自動的に宛先を切り替えるためにサーバ優先のURLを指定することが望ましい。フィールド値は単一の絶対URLからなる。

          Location       = "Location" ":" absoluteURI

次に，例を示す。

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

Max-Forwardsの要求ヘッダフィールドは，次の帰りのサーバに要求を回送できるプロキシ又はゲートウェイの数を制限するためにTRACEメソッド（14.31参照)が使われてもよい。これは，クライアントが中間連鎖で失敗又はループの発生する要求連鎖のトレースを試みる場合に有効である。

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

Max-Forwards値はこの要求メッセージが回送されてもよい残りの回数を示す10進整数である。

Max-Forwardsのヘッダフィールドを含むTRACE要求の各々のプロキシ及びゲートウェイの受け手は，要求を回送する前にこの値を検査して更新することが望ましい。受け取った値がゼロ (0)の場合，受け手は要求を回送しないほうがよい。代わりに，応答実体本体(9.8参照）として，受け取った要求メッセージを含む200(OK)応答を最後の受け手として応答することが望ましい。受け取ったMax-Forwards値が１以上の場合，回送されるメッセージは，1を引いた値に更新した Max-Forwardsフィールドを含むことが望ましい。

Max-Forwardsのヘッダフィールドはこの規定によって定義された他のすべてのメソッド及びそのメソッド定義の一部として明示的に参照されていないすべての拡張メソッドに対して無視されることが望ましい。

14.32 Pragma(実用)

Pragma一般ヘッダフィールドは，要求/応答連鎖に沿って，すべての受け手に適用してよいように実装依存の指令を含めるために使われる。すべてのpragmaの指令はプロトコルの観点からオプションの動作を指定する。しかしながら，いくつかのシステムは指令に一致する動作を要求してもよい。

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

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

no-cache指令が要求メッセージに表現される場合，アプリケーションは要求されているもののキャッシュされたコピーをもつとしても，要求を原サーバに回送することが望ましい。このpragmaの指令は，キャッシュ無しのキャッシュ指令(14.9参照)と同じセマンティクスを持ち， HTTP/1.0と下位互換性のためここで定義される。クライアントは，キャッシュ無しの要求がHTTP/1.1に準拠しているか分からないサーバに送られる場合，両方のヘッダフィールドを含むことが望ましい。

pragma指令が要求/応答連鎖に沿ってすべての受け手に適用できるので，アプリケーションの重要性に関係なく，Pragma指令はプロキシ又はゲートウェイアプリケーションによって渡されなければならない。特定の受け手のためにpragmaを指定することはできない。しかしながら、受け手に関係ないすべてのpragma指令はその受け手によって無視されることが望ましい。

HTTP/1.1のクライアントは，Pragma要求ヘッダを送らないほうがよい。HTTP/1.1のキャッシュは，クライアントが"Cache-Control: no-cache"を送ったかのように"Pragma: no-cache"を取り扱うことが望ましい。新しいPragma指令は，HTTPの中では何も定義されない。

Proxy-Authenticate応答ヘッダフィールドは，407(Proxy Authentication Required)応答の一部として含められなければならない。フィールド値はこのRequest-URIのためプロキシに適用できる認証スキーム及びパラメタを示すチャレンジからなる。

          Proxy-Authenticate  = "Proxy-Authenticate" ":" challenge

HTTPのアクセス認証プロセスは，11で記述される。WWW-Authenticateとは違い，Proxy-Authenticateのヘッダフィールドは現接続にだけ適用され，下流のクライアントに渡されない方が望ましい。しかしながら，中間プロキシが下流のクライアントからそれらを要求することによってそれ自身の身分証明書を得る必要があってもよく，いくつかの環境でプロキシがProxy-Authenticateヘッダフィールドに回送しているかのように現れる。

Proxy-Authorization要求ヘッダフィールドは，クライアントに認証を要求するプロキシにそれ自身(又は，その利用者)を識別することを可能にする。Proxy-Authorizationのフィールド値は，プロキシに関して利用者エージェントの認証情報及び/又は要求された資源の範囲を含む身分証明書からなる。

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

HTTPのアクセス認証プロセスは，11で記述される。Authrizationとは違い，Proxy-Authorizationヘッダフィールドは，Proxy-Authorizationフィールドを使って認証を要求した次の外向きのプロキシにだけ適用する。複数のプロキシが連鎖中に使われてる場合，Proxy-Authorizationヘッダフィールドは身分証明書を受け取ることを期待している最初の外向きのプロキシによって消費される。プロキシは，それが与えられた要求を連携して認証するという機構である場合，クライアント要求から次のプロキシに身分証明書を中継してもよい。

Publicの応答ヘッダフィールドはサーバによりサポートされるメソッドの集合の列挙である。このフィールドの目的は通常でないメソッドに関してサーバの能力を厳格に受け手に知らせることである。列挙されるメソッドはRequest-URIに適用できてもできなくてもよい。Allowヘッダフィールド(14.7)は特定のURIに関して可能とさせるメソッドを示すために使われてよい。

          Public         = "Public" ":" 1#method

以下に，使用例を示す。

          Public: OPTIONS, MGET, MHEAD, GET, HEAD

すべてのHTTP実体がバイトの列としてHTTPメッセージで表されるので，バイト範囲の概念はすべてのHTTP実体に関して意味がある。(しかしながら，すべてのクライアント及びサーバがバイト範囲操作をサポートする必要はない)。

HTTPのバイト範囲規定は実体本体(メッセージ本体と同じである必要はない)のバイトの列に適用する。

バイト範囲操作はバイトの単一の範囲又は単一の実体内の範囲の集合を指定してもよい。

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

byte-range-specのfirst-byte-pos値は，範囲の最初のバイトのオフセットを与える。last-byte-pos値は範囲の最後のバイトのオフセットを与える。即ち，指定されたバイト位置が含まれる。バイトオフセットはゼロから開始する。

last-byte-pos値が存在する場合，この値はbyte-range-specのfirst-byte-pos以上でなければならないか，又はbyte-range-specは無効である。無効なbyte-range-specの受け手はそれを無視しなければならない。

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-specifier値の例を示す。(但し，長さ10000の実体本体を仮定):

o 最初の500 バイト(バイトオフセット 0-499 を含む):

bytes=0-499

o 2番目の500バイト(バイトオフセット 500-999 を含む):

bytes=500-999

o 最後の500バイト(バイトオフセット 9500-9999 を含む):

bytes=-500

o 又は，

bytes=9500-

o 最初と最後のバイトだけ(バイト0及び9999):

bytes=0-0,-1

o 2番目の500バイトの正式な規定ではないがいくつかの合法的なもの(バイトオフセット 500-999 を含む):

bytes=500-600,601-999

bytes=500-700,601-999

条件付き又は条件なしGETメソッドを使ったHTTP検索要求は，Range要求ヘッダを使って全実体の代わりに実体の一つ以上の補助範囲を要求してよい。そして，これは要求の結果として返される実体に適用する。

         Range = "Range" ":" ranges-specifier

サーバはRangeヘッダを無視してもよい。しかしながら，Rangeが部分的に失敗した転送からの効果的な回復をサポートし，及び大きい実体の効果的な部分的な検索をサポートするので，HTTP/1.1の原サーバ及び中間キャッシュは可能であればバイト範囲をサポートすることが望ましい。

サーバがRangeヘッダをサポートし，指定された範囲又は範囲群が実体に関して適切である場合，次のことがいえる:

• o 条件なしGETのRangeヘッダの存在は，GETが別の方法で成功した場合，返されるものを修正する。言いかえれば，応答は200(OK)の代わりに206(Partial Content)の状態コードを伝える。
• o 条件付きGET(If-Modified-Since及びIf-None-Matchの一つ又は両方，若しくはIf-Unmodified-Since及びIf-Matchの一つ又は両方を使った要求)のRangeヘッダの存在は，GETが別の方法で成功し，条件が真の場合，返されるものを修正する。条件が偽の場合には，返される304(Not Modified)応答に影響しない。

いくつかの場合，Rangeヘッダに加えて，If-Rangeヘッダ(14.27 参照)を使うことがより適切である。

範囲をサポートするプロキシが，Range要求を受信し，戻りサーバに要求を回送し，及び返信中に全実体を受信する場合，プロキシはそのクライアントに要求した範囲のみを返すことが望ましい。キャッシュ割当て方針に一致する場合，プロキシはそのキャッシュに全受信応答を保存することが望ましい。

Referer[sic]要求ヘッダフィールドは，クライアントにサーバの利益のため，Request-URIが得られたものから資源のアドレス(URI)を指定することを可能にする。("referrer"，ヘッダフィールドの綴りは間違っているが)。 Refererの要求ヘッダフィールドはサーバに関心，ログ，最適化されたキャッシュなどのための資源への戻りリンクの一覧表を発生することを可能にする。これは古くなったリンク又はミス入力されたリンクを保守のためトレースされることも可能にする。 Refererフィールドは，Request-URIが利用者キーボードからの入力のようなそれ自身のURIを持たないソースから得られた場合，送られてはいけない。

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

例:

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

フィールド値が部分的なURIである場合，この値はRequest-URIに関連して解釈されることが望ましい。 URIは断片を含んではならない。

備考：リンクのソースが私的情報であったり，別の私的情報ソースを表してもよいので，利用者はRefererフィールドが送られるかどうかの選択ができることを強く推奨する。例えば，ブラウザのクライアントは公然/匿名での閲覧に関してトグルスイッチをもつことができ，これは各々のReferer及びFrom情報の送信を使用可/使用不可にする。

14.38 Retry-After(後の再試行)

Retry-After応答ヘッダフィールドは，要求しているクライアントが利用できなくなるには，どれくらいの長さのサービスが期待されているか示すため，503(Service Unavailable)応答を用いることができる。このフィールドの値は， HTTP-date又は応答の時間後の整数秒数(10進数で)のどちらかである。

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

次に，二つの使用例を示す。

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

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

14.39 Server(サーバ)

Server応答ヘッダフィールドは，要求を操作するために原サーバによって使われるソフトウェアについての情報を含む。フィールドは，サーバ及びすべての重要な下位製品を識別している複数の製品トークン(3.8参照)及びコメントを含むことができる。製品トークンはアプリケーションを識別するためにそれらの重要性の順で列挙される。

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

例：

          Server: CERN/3.0 libwww/2.17

応答がプロキシを通して回送されている場合，プロキシのアプリケーションはServerの応答ヘッダを修正してはいけない。その代わりに，Viaフィールド(14.44 で記述される)を含むことが望ましい。

備考：サーバの特定のソフトウェアの版を表すことは，サーバマシンをセキュリティホールを含むことで知られているソフトウェアに対する攻撃をより無防備にすることを可能にする。サーバ実装者はこのフィールドを構成可能なオプションにすることが奨励される。

Transfer-Encodingの一般ヘッダフィールドは送り手と受け手との間でメッセージ本体を安全に転送するために，それに適用されている変換の型が何か（もしあれば）を示す。これは転送符号化が実体の特性ではなく，メッセージの特性であるという点でContent-Encodingとは違う。

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

転送符号化は，3.6で定義されている。次に，例を示す。

          Transfer-Encoding: chunked

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

Upgrade一般ヘッダは，サーバーがプロトコルを切り替えるために適当であるとわかった場合に，サポートし用いるためにクライアントが追加通信プロトコルの指定を可能にする。 サーバは，101(SwitchingProtocols)応答内にプロトコルが切り替えられていることを示すために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ヘッダフィールドは最新の接続にだけ適用する。それゆえ，Upgradeキーワードは，Upgrade がHTTP/1.1 メッセージに存在しているときはいつでも，Connectionヘッダフィールド(14.10 参照)の中で供給されなければならない。

Upgradeヘッダフィールドは異なった接続へのプロトコルの切替を示すために使われることはできない。この目的のため， 301, 302, 303, 又は305への宛先切替応答を使用するのがより適切である。

この規定は，3.1のHTTP版番規則及びこの規定の将来の更新によって定義されるように，Hypertext Transfer Protocolのファミリによって使用するプロトコル名"HTTP"だけを定義する。すべてのトークンは，プロトコル名として用いることができる。しかしながら，これはクライアント及びサーバの両方が同じプロトコルをもつ名前に関連している場合にだけ役にたっている。

User-Agent要求ヘッダフィールドは要求を作る利用者エージェントについての情報を含む。これは統計上の目的，プロトコル違反の追跡，及び応答の利用者エージェントの自動認識のためのもので，特定の利用者エージェントの制限を回避するために応答を仕立てるためのものである。利用者エージェントは要求で，このフィールドを含むことが望ましい。このフィールドはエージェント及び利用者エージェントの重要な部分を形成するすべての下位製品を識別する複数の製品トークン(3.8 )及び注釈を含むことができる。規約により，製品トークンはそのアプリケーションを識別するためにそれらの重要性の順に列挙される。

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

例:

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

Vary応答ヘッダフィールドは，応答実体がサーバ駆動の折衝(12参照)を使う応答の利用可能な表現から選択された信号を送るためサーバによって使われる。Varyヘッダで列挙されるフィールド名は要求ヘッダのものである。 Varyフィールド値は，ヘッダフィールドの与えられた集合が表現が変化してもよい範囲を包囲することか，変化の範囲が指定されず ("*") 将来要求のすべての局面で変化してもよい，ということのどちらかを示す。

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

HTTP/1.1サーバは，サーバ駆動の折衝に従うすべてのキャッシュ可能な応答に適切なVaryヘッダフィールドを含まなければならない。そうする事で，キャッシュにその資源の将来の要求を適切に解釈し，その資源の折衝の存在について利用者エージェントに知らせることを可能にする。サーバは，応答が変化してもよい範囲について都合のよい情報を利用者エージェントに供給してもよいので，サーバ駆動の折衝に従属するキャッシュ不可能な応答をもつ適切なVaryヘッダを含むことが望ましい。

Varyフィールド値によって名付けられたヘッダフィールドの集合は"selecting" 要求ヘッダとして知られる。

キャッシュがRequest-URIがVaryヘッダを含む一つ以上のキャッシュエントリを指定して後に続く要求を受け取る場合，キャッシュされたVaryヘッダに名付けられたすべてのヘッダが新しい要求において存在しない限り，及び 前の要求から格納された選択している要求ヘッダのすべてが新しい要求で対応するヘッダにマッチしない限り，新しい要求への応答を構築するキャッシュエントリのようなものを使ってはならない。

二つの要求から選択する要求ヘッダは，最初の要求で選択する要求ヘッダが対応するBNFによって許される場所に連続した空白(LWS)を追加又は削除したりすること，及び/又は4.2で解説するメッセージヘッダについての規則に従う同じフィールド名をもつ複数のメッセージヘッダフィールドを組み合わせることにより2番目の要求で選択する要求ヘッダに変換されることができる場合，及びその場合だけにマッチすると定義される。

"*"のVaryフィールド値は，特定できないパラメタ (おそらく，クライアントのネットワークアドレスのような要求ヘッダフィールドの内容以外のもの）が応答表現の選択に役割を果たすことを通知する。その資源上の後に続く要求は原サーバによって適切に解釈されるだけで，キャッシュは資源に関してキャッシュされた新鮮な応答を持っている場合でさえ，要求を回送(たぶん，条件付きであるが)しなればならない。キャッシュによるVaryヘッダの使用に関しては13.6を参照。

Varyフィールド値は，応答に関して選択された表現が最も適切な表現を選択して列挙された要求ヘッダフィールド値だけを考慮する選択アルゴリズムに基づいていることを通知する。キャッシュは，応答が新鮮である間に，同じ選択が列挙されたフィールド名に関して同じ値をもつ将来の要求のために作られるということを仮定してもよい。

与えられたフィールド名は，この規定で定義された標準要求ヘッダフィールドの集合に限定されない。フィールド名は大文字小文字を区別しない。

Via一般ヘッダフィールドは，要求時の利用者エージェントとサーバ間 及び応答時の原サーバとクライアント間の中間プロトコル及び中間の受け手であることを示すために，ゲートウェイ及びプロキシに使用されなければならない。 これはRFC 822の"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"である場合に限りオプションである。 received-byフィールドは，通常，その後にメッセージを回送する受け手サーバ又は受け手クライアントのホスト番号及びオプションのポート番号とする。 しかしながら，本当のホストが機密性の高い情報に関するものであるときには，仮名に置き換えてもよい。 ポートが与えられていないときは，受信したプロトコルのデフォルトポートにしてもよい。

複合Viaフィールド値は， メッセージを回送する各プロキシ又はゲートウェイを代表する。 各受け手は， 回送するアプリケーションの順序に従って，最終結果が順序づけられるようにその情報を付加しなければならない。

注釈は，利用者エージェント及びサーバヘッダフィールドからの推定で， 受け手プロキシ又はゲートウェイのソフトウェアを識別するために Viaヘッダフィールドを用いてもよい。 しかしながら，Viaフィールドのすべての注釈はオプションであり，メッセージを回送するより前の任意の受け手によって削除されてもよい。

例えば，要求メッセージが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)

ネットワークファイアウォールを通してポータルとして用いられるプロキシ及びゲートウェイは，デフォルトでは，ファイアウォール部分の中ではホストの名前及びポート番号を回送しないことが望ましい。 この情報は，明示的に作動させる場合にだけ，伝えられる事が望ましい。作動しないのであればファイアウォールの背後にあるあらゆるホストのreceived-by(受信)ホストは，そのホストのために適当な仮名で置き換える事が望ましい。

内部構造を隠すために強いプライバシ要件をもつ組織には，プロキシは， 同一の受信したプロトコル値をもつViaヘッダフィールドエントリの順序付けられた後続部分をひとつのエントリに結合してもよい。例えば，

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

           は，次のようにたたむ事ができる

          Via: 1.0 ricky, 1.1 mertz, 1.0 lucy


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

           could be collapsed to

          Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

 

アプリケーションは， そのすべてが同じ組織管理の元にあり，ホストが仮名にすでに置き換えられているのでないなら，複合エントリを結合しない事が望ましい。 アプリケーションは，異なる受け手プロトコル値をもつとき， エントリを結合してはならない。

Warningヘッダは，次の応答を用いて送られる

          Warning    = "Warning" ":" 1#warning-value

          warning-value = warn-code SP warn-agent SP warn-text
          warn-code  = 2DIGIT
          warn-agent = ( host [ ":" port ] ) | pseudonym
                          ; the name or pseudonym of the server adding
                          ; the Warning header, for use in debugging
          warn-text  = quoted-string

応答は，2つ以上のWarningヘッダで伝えてもよい。

文字セットにISO-8859-1以外が用いられている場合， RFC 1522 [14]で記述する方法を用いて警告文を符号化しなければならない。

サーバ又はキャッシュは，応答にWaringヘッダを加えてもよい。 新規のWarningヘッダは，あらゆる現Warningヘッダの後に付加される事が望ましい。 キャッシュは，応答で受信したあらゆるWarningヘッダも削除してはならない。 しかし，キャッシュがキャッシュエントリを成功裏に有効性を検証するのであれば，特定のWarningコードのために指定されたエントリを除き，先に添付したWarningヘッダを削除する事が望ましい。 その後，有効性検証した応答で受信したWarningヘッダを加えなければならない。 言い換えれば，Warningヘッダは，もっとも新しい適切な応答に添付されるものである。

複合Warningヘッダが応答に添付されるとき，利用者エージェントは， 応答に現れる順番に，可能な限りそれらを表示する事が望ましい。 警告のすべてを表示することが不可能であれば，利用者エージェントは，次の発見的手法で行うことが望ましい。

• 応答で早く現れる警告は，応答で遅く現れるものよりも優先する。
• 利用者の優先する文字セットの警告は，同一の警告コード及び警告エージェントを除いて他の言語セットでの警告よりも優先する。

     o  Warnings that appear early in the response take priority over those
        appearing later in the response.
     o  Warnings in the user's preferred character set take priority over
        warnings in other character sets but with identical warn-codes and
        warn-agents.

複合Warningヘッダで生成されたシステムは，この利用者エージェントの行動を考慮した順序にする事が望ましい。

これは，現規定警告コードのリストであり，英語の推奨警告文及びその意味の詳細である。

10　Response is stale(古い応答)
　応答の返信が古くなった時に含まれなければならない。 キャッシュは，この警告をあらゆる応答に含んでよいが，応答が新たに更新がわかるまで動かしてはならない。

11 Revalidation failed(有効性再検証の失敗)
　キャッシュが，サーバに到達出来ず，応答の有効性再検証の試みが失敗したために，古い応答を返す場合に含まなければならない。キャッシュはあらゆる応答にこの警告に含んでよいが，応答が有効性再検証に成功するまで削除してはならない。

12 Disconnected operation(接続断の操作)
　キャッシュがある期間内に故意にネットワークの他部分から切り離される場合を含むことが望ましい。

13 Heuristic expiration(発見的有効期限)
　キャッシュが発見的に24時間以上の新鮮保持期間を選択し，応答の経過時間が24時間以上である場合に含まなくてはならない。

14 Transformation applied(変換適用)
　応答の内容符号化(Content-Encodingヘッダで指定される)又はメディア型(Content-Typeヘッダで指定される)を変えるあらゆる変換に適用する場合， Warningコードがすでに応答に出現していない限り， 中間キャッシュ又は中間プロキシによって追加されなければならない。 有効性再検証のあとであっても，応答から削除してはならない。

99 Miscellaneous warning(各種警告)
　警告文は，人のエラー又はログを表すための任意の情報を含む事ができる。 システムは，この警告を受信した場合，あらゆる自動行動をしてはならない。

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

さらに，Basic認証は偽サーバのなりすましにも弱い。利用者が，彼はBasic認証によって保護されている情報を含むホストに接続していると信じさせられているが，実際には，彼は悪意をもったサーバ又はゲートウェイに接続している場合，攻撃者は，パスワードを要求し，後で使用するためにそれを記憶し，エラーを装うことができる。この型の攻撃は，Digest Authentication[32]を用いれば可能ではない。サーバ実装者は，ゲートウェイ又はCGIスクリプトによるこの種のなりすましの可能性に対して防御することが望ましい。特に，サーバがゲートウェイへ単純に接続を返すことは非常に危険になる。これは，そのゲートウェイがクライアントによって探知できないある方法で原サーバになりすましている間に，そのゲートウェイが，クライアントとの複数のトランザクション処理に従事するための永続的接続機構を使用できることによる。

15.2 認証方式の選択提示

HTTP/1.1サーバは，401(Authenticate)応答で複数のチャレンジを返してもよく，各チャレンジは，異なる方式を使ってもよい。利用者エージェントに返されるチャレンジの順番は，それらチャレンジが選択されるのをサーバが好む順番とする。そのサーバは，"最も安全な"認証方式をもつチャレンジを最初に順番付けることが望ましい。利用者エージェントは，利用者エージェントが理解する最初の認証方式を利用者に行わせるチャレンジとして選択することが望ましい。

WWW-Authenticateヘッダを使用してサーバが認証方式の選択を提示する場合，認証の"セキュリティ"は，悪意ある利用者がチャレンジの集合を捕捉し，その認証方式の最も弱い箇所を使用してその悪意ある利用者自身を認証しようと試みることが可能になる程度のものに過ぎない。したがって，その(チャレンジの)順番付けは，サーバの情報よりも利用者の身分証明を保護するために，より多くの点で役に立つ。

可能なman-in-the-middle(MITM)攻撃は，クライアントが利用者の身分証明(例えば，パスワード)を開示するものを使用することを期待して，選択の集合に弱い認証方式を加えるものである。この理由のために，クライアントは，受理された選択からクライアントが理解する最強の方式を常に使用することが望ましい。

より優れたMITM攻撃は，提示された選択をすべて取り除き，Basic認証を要求するチャレンジを挿入する。この理由のために，この種類の攻撃について気にかける利用者エージェントは，サーバによってそれまでに要求された最強の認証方式を覚えておき，より弱い認証方式を使用する前に利用者確認を要求する警告メッセージを生成することができるかもしれない。そのようなMITM攻撃を行う特に油断のならない方法は，だまされやすい利用者に対して"無料の"プロキシキャッシュ化サービスを提供することである。

15.3 サーバログ情報の悪用

サーバは，利用者の読取りパタン又は関心ある主題を識別できる利用者の要求についての個人データを保存する立場にある。この情報は，その性質上明らかに機密的であって，その取扱いは国によっては法律によって規制されるかもしれない。データを提供するためにHTTPプロトコルを使用する人々は，公開された場合に識別可能なあらゆる個人の許可を得ずに，それらの資料が配布されないことを保証する責任を負う。

15.4 要注意情報の転送

一般的なデータ転送プロトコルと同様に，HTTPは，転送されるデータの内容を規制できないし，与えられた要求の文脈内における情報の特定部分の取扱い要注意の程度を決定する予め決まった方法も存在しない。したがって，アプリケーションは，その情報の提供者に，この情報に対する可能な限り多くの制御を供給することが望ましい。次の四つのヘッダフィールドは，この文脈において特別に言及する価値がある。

• Server
• Via
• Referer
• From

サーバの特定のソフトウェアの版を明らかにすることは，サーバ機が，セキュリティホールを含むことが知られているソフトウェアに対する攻撃に，より弱くなる可能性があるかもしれない。実装者は，Serverヘッダフィールドを構成可能オプションにすることが望ましい。

ネットワークファイアウォールを通してポータル(入り口)として動作するプロキシは，ファイアウォールの背後のホストを識別するヘッダ情報の転送に関して特別の予防措置をとることが望ましい。特に，プロキシは，ファイアウォールの背後で生成されたあらゆるViaフィールドを，削除するか，又は浄化された版で置き換えることが望ましい。

Refererフィールドは，読取りパタンの調査及び逆向きリンクの設定を可能にする。それは非常に有用である可能性はあるが，利用者の詳細情報がRefererに含まれる情報から分離されない場合には，その効力が悪用される可能性がある。個人情報が取り除かれt場合であっても，Refererフィールドは，公開が不適当な私的文書のURIを示すかもしれない。

Fromフィールドで送られる情報は，利用者のプライバシ関心又はそれらのサイトのセキュリティ方針と矛盾するかもしれない。したがって，その情報は，利用者がフィールドの内容を無効にし，有効にし，及び修正することができない場合には，伝送しないことが望ましい。利用者は，利用者の好み又はアプリケーションのデフォルト構成の範囲で，このフィールドの内容を設定できなければならない。

要求はされないが，利用者がFrom及びRefererの情報の送信を有効にする又は無効にするために便利な切換えインタフェースが提供されることを提案する。

15.5 ファイル名及び経路名に基づく攻撃

HTTP原サーバの実装は，HTTP要求によって返される文書をサーバ管理者によって意図されたものだけに制限するように注意することが望ましい。HTTPサーバがHTTP URIを直接にファイルシステム呼出しに翻訳する場合，サーバは，HTTPクライアントに配布するように意図されなかったファイルを提供しないために，特別に注意しなければならない。例えば，UNIX，Microsoft Windows，及び他のオペレーティングシステムは，現在のディレクトリの上位のディレクトリレベルを示すための経路の構成要素として，".."を使用する。そのようなシステム上では，HTTPサーバは，HTTPサーバによってアクセス可能とすることを意図した以外の資源へのアクセスを別途許可する場合，Request-URIの中にそれら構成要素(".."など)が存在することを許してはならない。同様に，サーバへの内部的な参照だけを意図したファイル(アクセス制御ファイル，構成ファイル，及びスクリプトコードといったもの)は，要注意情報を含むかもしれないので，不適切な検索から保護されなければならない。経験上，そのようなHTTPサーバ実装における小さなバグが，セキュリティ危機をもたらすことが分かっている。

15.6 個人情報

HTTPクライアントは，多くの個人情報(例えば，利用者の名前，位置，メールアドレス，パスワード，暗号化鍵など)に関与することが多く，この情報がHTTPプロトコルを介して他の資源に対する意図しない連携を生じることを防ぐために非常に注意することが望ましい。利用者がそれら情報の配布を制御する便利なインタフェースが提供されること，並びに設計者及び実装者が特にこの領域で注意することを，極めて強く推奨する。歴史的には，この領域のエラーが，重要なセキュリティ及び/又はプライバシの問題を生じることが多く，実装者の会社にとって非常に不利な評判になることが多い。

15.7 受諾ヘッダに関係したプライバシの課題

Accept(受諾)要求ヘッダは，アクセスされたすべてのサーバに利用者についての情報を示すことができる。特にAccept-Languageヘッダは，利用者が個人的性質と考える情報を示すことができる。これは，特定の言語を理解することは，特定の少数民族集団の一員であることに強く関連することが多いからである。すべての要求で送信されるAccept-Languageヘッダの内容を構成するためのオプションを提供する利用者エージェントには，関連するプライバシの損失を利用者に意識させるメッセージをその構成処理が含むようにすることを，強く推奨する。

プライバシの損失を制限する取組みは，利用者エージェントが，デフォルトでAccept-Languageヘッダの送信を省略し，サーバによって生成されたVary応答ヘッダフィールドを探すことによって，そのような送信がサーバの品質を改善できることを検知した場合には，サーバへAccept-Languageヘッダの送信を開始するのがよいかどうかを利用者に尋ねることとする。

すべての要求で送信される利用者環境に調整された精巧な受諾(Accept)ヘッダフィールドは，特にそれらが品質値を含んでいる場合には，比較的信頼できる長い間使用可能な(long-lived)利用者の識別子としてサーバによって利用できる。そのような利用者識別子は，内容提供者が(利用者のマウスなどの)クリック情報追跡を行うのを可能にし，協調作業している内容供給者達が個別の利用者のサーバ相互のクリック情報追跡又はフォーム提出を照合することを可能にする。プロキシの背後にいない多くの利用者に対しては，利用者エージェントを実行しているホストのネットワークアドレスも，長い間使用可能な利用者の識別子として役立つことに注意すること。プロキシがプライバシを強化するために使用される環境では，利用者エージェントは，末端利用者に対して受諾ヘッダ構成のオプションを提供することは，用心したほうがよい。強力なプライバシ対策として，プロキシは，中継された要求における受諾ヘッダをろ過(filter)することができる。高度なヘッダ構成可能性を提供する一般目的の利用者エージェントは，関連する可能性があるプライバシの損失について利用者に警告することが望ましい。

15.8 DNSのなりすまし

HTTPを使用しているクライアントは，ドメイン名サービス(Domain Name Service，DNS)に大いに依存しており，したがって，一般的に，IPアドレス及びDNS名の関連を故意に間違えることに基づくセキュリティ攻撃を受ける傾向がある。クライアントは，IP番号及びDNS名の関連が継続的に妥当であると仮定することに注意する必要がある。

特に，HTTPクライアントは，以前のホスト名検索の結果をキャッシュしたものではなく，IP番号及びDNS名の関連の確認のために，クライアントの名前解決器に頼ることが望ましい。多くのプラットホームは，適切な場合には，既に局所的にホスト名検索をキャッシュできるが，そうするように構成されるほうがよい。しかし，名前サーバによって報告されたTTL(Time To Live，生存時間)情報によって，キャッシュされた情報が有用であり続ける可能性が高いとされた場合だけに，これらの検索結果はキャッシュされることが望ましい。

HTTPクライアントが性能向上を達成するためにホスト名検索の結果をキャッシュする場合，それらのクライアントは，DNSによって報告されるTTL情報を観察し守らなければならない。

HTTPクライアントがこの規則を守らない場合には，クライアントは，事前にアクセスしたサーバのIPアドレスが変更されたときに，なりすましを受ける可能性がある。ネットワークアドレスの変更がますます一般的になると予想されるにつれて，この形式の攻撃を受ける可能性は大きくなる。そのために，この要件を守ることは，この潜在的なセキュリティ脆弱性を低減する。

この要件によって，同じDNS名を使用している複製されたサーバにクライアントの負荷均衡化の振る舞いも改善され，その戦略を使うサイトにアクセスする際に利用者が経験する失敗の可能性も低減される。

15.9 位置ヘッダ及びなりすまし

単一のサーバが，お互いを信頼しない複数の組織をサポートする場合，信頼しない組織の制御の下で生成される応答のLocationヘッダ及びContent-Locationヘッダの値を検査して，それら組織が権限をもたない資源を無効化しようとしていないことを確めなければならない。

16. 貢献者

この規定は，RFC 822のためにDavid H. Crockerによって定義された強化BNF及び共通構成要素を大いに使用している。同様に，MIMEのためにNathaniel Borenstein及びNed Freedによって提供された定義の多くを再使用している。この規定にこれらを取り込むことが，HTTPとインターネットのメールメッセージフォーマットとの間の関係において過去に生じた混乱を減らす手助けになると希望する。

HTTPプロトコルは，過去4年にわたって，かなり発展を遂げてきた。それは，大きく活動的な開発者のコミュニティ(www-talkメーリングリストに参加した多くの人々)から利益を与えられてきた。そのコミュニティは，一般に，HTTP及びWorld-Wide Webでの成功のために最大の責任を果たしてきたものである。Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett, Tony Sanders, 及び Marc VanHeyningenは，プロトコルの初期の様相を定義する際の努力に対して，特別な賞賛を受けるに値する。

この標準仕様書(TS)の原規定は，HTTP-WGに参加しているすべての人々のコメントから大きな利益を得ている。既に述べた人々に加えて，次の個々の人々がこの規定に貢献した。

          Gary Adams                  Albert Lunde
          Harald Tveit Alvestrand     John C. Mallery
          Keith Ball                  Jean-Philippe Martin-Flatin
          Brian Behlendorf            Larry Masinter
          Paul Burchard               Mitra
          Maurizio Codogno            David Morris
          Mike Cowlishaw              Gavin Nicol
          Roman Czyborra              Bill Perry
          Michael A. Dolan            Jeffrey Perry
          David J. Fiander            Scott Powers
          Alan Freier                 Owen Rees
          Marc Hedlund                Luigi Rizzo
          Greg Herlihy                David Robinson
          Koen Holtman                Marc Salomon
          Alex Hopmann                Rich Salz
          Bob Jernigan                Allan M. Schiffman
          Shel Kaphan                 Jim Seidman
          Rohit Khare                 Chuck Shotton
          John Klensin                Eric W. Sink
          Martijn Koster              Simon E. Spero
          Alexei Kosut                Richard N. Taylor
          David M. Kristol            Robert S. Thau
          Daniel LaLiberte            Bill (BearHeart) Weinman
          Ben Laurie                  Francois Yergeau
          Paul J. Leach               Mary Ellen Zurko
          Daniel DuBois

キャッシュ化設計の内容及び表示の多くが，Shel Kaphan, Paul Leach, Koen Holtman, David Morris, 及び Larry Masinterを含む個々人からの助言及びコメントによるものである。

範囲の規定の大部分は，元々Ari Luotonen及びJohn Franksによって行われた作業に，Steve Zillesからの追加の入力を加えたものに基づいている。

Palo Altoの"cave men"(原始時代の洞窟人)に感謝する。あなたは，あなたが誰であるかを知っている。

Jim Gettys(この標準仕様書(TS)の原規定の現在の編集者)は，John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Alex Hopmann, 及び Larry Masinterとともに，この標準 仕様書(TS)の原規定の以前の編集者であるRoy Fieldingに，特に感謝したい。

17. 文献

• [1] Alvestrand, H., "Tags for the identification of languages", RFC 1766, UNINETT, March 1995.
• [2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, D., and B. Alberti. "The Internet Gopher Protocol: (a distributed document search and retrieval protocol)", RFC 1436, University of Minnesota, March 1993.
• [3] Berners-Lee, T., "Universal Resource Identifiers in WWW", A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web", RFC 1630, CERN, June 1994.
• [4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota, December 1994.
• [5] Berners-Lee, T., and D. Connolly, "HyperText Markup Language Specification - 2.0", RFC 1866, MIT/LCS, November 1995.
• [6] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0.", RFC 1945 MIT/LCS, UC Irvine, May 1996.
• [7] TR X 0069:2002, 多目的インターネットメール拡張(MIME) 第1部 インターネットメッセージ本体のフォーマット
  備考 Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, First Virtual, November 1996.がこの規定に一致している。
• [8] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, IETF, October 1989.
• [9] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982.
• [10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R., Sui, J., and M. Grinbaum. "WAIS Interface Protocol Prototype Functional Specification", (v1.5), Thinking Machines Corporation, April 1990.
• [11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, UC Irvine, June 1995.
• [12] Horton, M., and R. Adams. "Standard for interchange of USENET messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic Studies, December 1987.
• [13] Kantor, B., and P. Lapsley. "Network News Transfer Protocol." A Proposed Standard for the Stream-Based Transmission of News", RFC 977, UC San Diego, UC Berkeley, February 1986.
• [14]TS X 0071:2004, 多目的インターネットメール拡張(MIME) 第3部 非ASCIIテキストへのメッセージヘッダ拡張
  備考 Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, University of Tennessee, November 1996. がこの規定に一致している。
• [15] Nebel, E., and L. Masinter. "Form-based File Upload in HTML", RFC 1867, Xerox Corporation, November 1995.
• [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/ISI, August 1982.
• [17] Postel, J., "Media Type Registration Procedure", RFC 2048, USC/ISI, November 1996.
• [18] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, USC/ISI, October 1985.
• [19] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/ISI, October 1994.
• [20] Sollins, K., and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation, December 1994.
• [21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
• [22] ISO-8859. International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets --

  Part 1: Latin alphabet No. 1, ISO 8859-1:1987.

  Part 2: Latin alphabet No. 2, ISO 8859-2, 1987.

  Part 3: Latin alphabet No. 3, ISO 8859-3, 1988.

  Part 4: Latin alphabet No. 4, ISO 8859-4, 1988.

  Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988.

  Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987.

  Part 7: Latin/Greek alphabet, ISO 8859-7, 1987.

  Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.

  Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.

• [23] Meyers, J., and M. Rose "The Content-MD5 Header Field", RFC 1864, Carnegie Mellon, Dover Beach Consulting, October, 1995.
• [24] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC 1900, IAB, February 1996.
• [25] Deutsch, P., "GZIP file format specification version 4.3." RFC 1952, Aladdin Enterprises, May 1996.
• [26] Venkata N. Padmanabhan and Jeffrey C. Mogul. Improving HTTP Latency. Computer Networks and ISDN Systems, v. 28, pp. 25-35, Dec. 1995. Slightly revised version of paper in Proc. 2nd International WWW Conf. '94: Mosaic and the Web, Oct. 1994, which is available at http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/ HTTPLatency.html.
• [27] Joe Touch, John Heidemann, and Katia Obraczka, "Analysis of HTTP Performance", [URL: http://www.isi.edu/lsam/ib/http-perf/], USC/Information Sciences Institute, June 1996
• [28] Mills, D., "Network Time Protocol, Version 3, Specification, Implementation and Analysis", RFC 1305, University of Delaware, March 1992.
• [29] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3." RFC 1951, Aladdin Enterprises, May 1996.
• [30] Spero, S., "Analysis of HTTP Performance Problems" [URL:http://sunsite.unc.edu/mdma-release/http-prob.html].
• [31] Deutsch, P., and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, Aladdin Enterprises, Info-ZIP, May 1996.
• [32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E., and L. Stewart, "An Extension to HTTP : Digest Access Authentication", RFC 2069, January 1997.

18. 原規定の著者の連絡先

   Roy T. Fielding
   Department of Information and Computer Science
   University of California
   Irvine, CA 92717-3425, USA

   Fax: +1 (714) 824-4056
   EMail: fielding@ics.uci.edu


   Jim Gettys
   MIT Laboratory for Computer Science
   545 Technology Square
   Cambridge, MA 02139, USA

   Fax: +1 (617) 258 8682
   EMail: jg@w3.org


   Jeffrey C. Mogul
   Western Research Laboratory
   Digital Equipment Corporation
   250 University Avenue
   Palo Alto, California, 94305, USA

   EMail: mogul@wrl.dec.com


   Henrik Frystyk Nielsen
   W3 Consortium
   MIT Laboratory for Computer Science
   545 Technology Square
   Cambridge, MA 02139, USA

   Fax: +1 (617) 258 8682
   EMail: frystyk@w3.org


   Tim Berners-Lee
   Director, W3 Consortium
   MIT Laboratory for Computer Science
   545 Technology Square
   Cambridge, MA 02139, USA

   Fax: +1 (617) 258 8682
   EMail: timbl@w3.org

19. 附属情報

19.1 インターネットメディア型 message/http

HTTP/1.1プロトコルの定義に加えて，この標準仕様書(TS)は，インターネットメディア型"message/http"のための規定としても使用できる。次が，IANAで登録されている。

       メディア型名:         message
       メディア下位型名:     http
       必須パラメタ:         なし
       オプションパラメタ:   version, msgtype

        version: 同封されるメッセージのHTTP版番号(例えば，"1.1")。
                 存在しない場合には，版は，本体の最初の行から決定できる。

        msgtype: メッセージ型，"要求(request)"又は"応答(response)"。
                 存在しない場合には，メッセージ型は，本体の最初の行から決定できる。

       符号化への考慮:       "7ビット(7bit)"，"8ビット(8bit)"又は"バイナリ(binary)"だけが許される。

       セキュリティへの考慮: なし

19.2 インターネットメディア型 multipart/byteranges

HTTPメッセージが複数範囲の内容(例えば，複数の重なり合わない範囲についての要求の応答)を含む場合，これらの範囲は，マルチパートMIMEメッセージとして伝送される。この目的のためのマルチパートメディア型を，"multipart/byteranges"と呼ぶ。

multipart/byterangesメディア型は，各々それ自体のContent-Typeフィールド及びContent-Rangeフィールドが付いた二つ以上の部分を含む。その部分は，MIME境界パラメタを使用して分離される。

       メディア型名:         multipart
       メディア下位型名:     byteranges
       必須パラメタ:         boundary
       オプションパラメタ:   なし

       符号化への考慮:       "7ビット(7bit)"，"8ビット(8bit)"又は"バイナリ(binary)"だけが許される。

       セキュリティへの考慮: なし

例

   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-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

   --THIS_STRING_SEPARATES
   Content-type: application/pdf
   Content-range: bytes 500-999/8000

   ...the first range...
   --THIS_STRING_SEPARATES
   Content-type: application/pdf
   Content-range: bytes 7000-7999/8000

   ...the second range
   --THIS_STRING_SEPARATES--

19.3 耐障害アプリケーション

この標準仕様書(TS)は，HTTP/1.1メッセージの生成のための要件を規定するが，すべてのアプリケーションが，その実装において正しいということはない。そのために，実装の(規定からの)逸脱があいまい性なく解釈できる場合には，操作的アプリケーションは，その逸脱に耐えられることが望ましい。

クライアントは，Status-Lineの構文解析において耐障害的であることが望ましく，サーバは，Request-Lineの構文解析時に耐障害的であることが望ましい。特に，たとえ単一のSPだけが要求されているとしても，フィールド間にある任意量のSP文字又はHT文字を受諾することが望ましい。

メッセージヘッダフィールドのための行終端子は，列CRLFとしている。しかし，それらのヘッダを構文解析しているとき，アプリケーションは，単一のLFを行終端子として認識し，その前のCRを無視することが望ましい。

実体本体の文字集合は，その本体内で使用される文字符号群の最小公約なものとしてラベル付けされることが望ましい。ただし，ラベルに，US-ASCII又はISO-8859-1以上のものを望まない場合は除く。

日付の構文解析及び符号化に関する要件，並びに日付符号化を伴う他の潜在的な問題のための追加規則は，次を含む。

• HTTP/1.1のクライアント及びキャッシュは，将来の50年より先に見えるRFC-850日付は，実際は，過去の日付と仮定することが望ましい。(これは，"2000年"問題を解決する手助けになる。)
• HTTP/1.1の実装は，意図的に，構文解析されたExpires(有効期限切れ)日付を適正な値よりも早期の日付として表現してもよいが，構文解析されたExpires日付を適正な値よりも遅い日付として表現してはならない。
• すべての有効期限切れに関係する計算は，GMTで行われなければならない。局所時間帯は，経過時間又は有効期限切れ時間の計算又は比較に影響を及ぼしてはならない。
• HTTPヘッダが間違ってGMT以外の時間帯の日付値を運んだ場合には，最も保守的で可能な変換を使用してGMTに変換しなければならない。

19.4 HTTP実体とMIME実体との差

HTTP/1.1は，実体が公開された様々な表現及び拡張可能な機構で転送できるために，インターネットメール(RFC 822)及び多目的インターネットメール拡張(MIME)のために定義されている多くの構成要素を使用する。しかし，MIME [7]は，メールを論議し，HTTPは，MIMEにおいて示されるこれらとは異なる幾つかの特徴をもっている。これらの違いは，バイナリ接続上で性能を最適化するために，新しいメディア型の使用においてより大きな自由を認めるために，日付の比較を容易にするために，及び幾つかの初期のHTTPサーバ及びクライアントの実際の経験を認めるために，注意深く選択された。

19.4は，HTTPがMIMEと異なる特定の領域を示す。厳密なMIME環境へのプロキシ及びゲートウェイは，これらの違いを意識し，必要な場合には適切な変換を提供することが望ましい。MIME環境からHTTPへのプロキシ及びゲートウェイも，同じ変換が要求されてよいので，その違いを意識することが必要になる。

19.4.1 正準形式への変換

MIMEは，転送に先立って，インターネットメール実体を正準形式に変換することを要求する。この標準仕様書(TS)の3.7.1は，HTTP上で転送される場合の"text"メディア型の下位型に対して許される形式を記述する。MIMEは，"text"型をもつ内容が行区切りをCRLFとして表現し，行区切り列以外でのCR又はLFの使用を禁止することを要求とする。HTTPは，メッセージがHTTP上で転送される場合に，テキスト内容の内部に行区切りを示すCRLF，単独のCR，及び単独のLFを許す。

可能な場合には，HTTPから厳密なMIME環境へのプロキシ又はゲートウェイは，この標準仕様書(TS)の3.7.1で記述されるテキストメディア型内のすべての行区切りをCRLFのMIME正準形式に変換することが望ましい。しかし，これは，Content-Encodingの存在によって，及び幾つかの多バイト文字集合に対してそうなのだが，CR及びLFを表現するためにオクテット13及び10を使用しない幾つかの文字集合の使用をHTTPが認めている事実によって，複雑になる可能性があることに注意すること。

19.4.2 日付フォーマットの変換

HTTP/1.1は，日付比較の処理を簡単にするために日付フォーマット(3.3.1)の制限された集合を使用する。他のプロトコルからのプロキシ及びゲートウェイは，メッセージに存在するDateヘッダフィールドがHTTP/1.1フォーマットの一つに適合すること，及び必要な場合には日付を書き換えることを確実に行うことが望ましい。

19.4.3 Content-Encoding(内容符号化)の導入

MIMEは，HTTP/1.1のContent-Encodingヘッダフィールドに等価な概念を含まない。これはメディア型についての修飾子として動作するので，HTTPからMIME準拠プロトコルへのプロキシ及びゲートウェイは，Content-Typeヘッダフィールドの値を変更するか，メッセージを回送する前に実体本体を復号するかのどちらかをしなければならない。(インターネットメールのためのContent-Typeの実験的なアプリケーションの中には，Content-Encodingとして等価な機能を実行するために";conversions="のメディア型パラメタを使用したものがある。しかし，このパラメタは，MIMEの一部ではない。)

19.4.4 Content-Transfer-Encoding(内容転送符号化)なし

HTTPは，MIMEのContent-Transfer-Encoding (CTE)フィールドを使用しない。MIME準拠プロトコルからHTTPへのプロキシ及びゲートウェイは，HTTPクライアントに応答メッセージを配信する前にあらゆる識別性のない((non-identify )CTE("quoted-printable"又は"base64")の符号化を取り除かなければならない。

HTTPからMIME準拠プロトコルへのプロキシ及びゲートウェイは，メッセージがそのプロトコル上の安全な転送のために正しいフォーマット及び符号化になっていることを確実にする責任がある。この場合，"安全な転送"は，使用されているプロトコルの制限によって定義される。そのようなプロキシ又はゲートウェイは，それを行うことが到達先のプロトコル上での安全な転送の可能性を改善する場合には，適切なContent-Transfer-Encodingを用いてデータをラベル付けをすることが望ましい。

19.4.5 マルチパート本体部分の中のHTTPヘッダフィールド

MIMEでは，一般的に，マルチパート本体部分の中の大部分のヘッダフィールドは，そのフィールド名が"Content-"で始まる場合を除いて，無視される。HTTP/1.1では，マルチパート本体部分は，その部分の意味にとって重要なHTTPヘッダフィールドを含んでよい。

19.4.6 Transfer-Encoding(転送符号化)の導入

HTTP/1.1は，Transfer-Encodingヘッダフィールド(14.40)を導入する。プロキシ及びゲートウェイは，MIME準拠プロトコルを介してメッセージを回送する前にあらゆる転送符号化を取り除かなければならない。

"chunked"転送符号化(3.6)を復号するための処理は，擬似コードで次のとおりに表現できる。

          length := 0
          chunk-size，(存在する場合には)chunk-ext及びCRLFを読み込む
          while (chunk-size > 0) {
             chunk-data及びCRLFを読み込む
             chunk-dataをentity-bodyに追加する
             length := length + chunk-size
             chunk-size及びCRLFを読み込む
          }
          entity-headerを読み込む
          while (entity-headerが空でない) {
             entity-headerを既存のheader field群に追加する
             entity-headerを読み込む
          }
          Content-Length := length
          "chunked"をTransfer-Encodingから取り除く

19.4.7 MIME-Version(MIME版)

HTTPは，MIME準拠プロトコルではない(19.4参照)。しかし，HTTP/1.1メッセージは，MIMEプロトコルのどの版がメッセージを構成するために使用されたかを示すために，一つのMIME-Version一般ヘッダフィールドを含んでもよい。MIME-Versionヘッダフィールドの使用は，メッセージがMIMEプロトコルに完全に準拠していることを示す。プロキシ及びゲートウェイは，HTTPメッセージを厳密なMIME環境に移出(export)する場合，(可能なときには)完全に準拠することを確実に行う責任を負う。

          MIME-Version   = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

MIMEの版"1.0"は，HTTP/1.1での使用についてデフォルトとする。しかし，HTTP/1.1メッセージの構文解析及びセマンティクスは，この標準 仕様書(TS)で定義されるのであって，MIME規定ではない。

19.5 HTTP/1.0からの変更点

19.5では，HTTP/1.0とHTTP/1.1との間の，主要な相違を要約する。

19.5.1 マルチホームウェブサーバを簡素化しIPアドレスを節約するための変更点

クライアント及びサーバが，Host要求ヘッダをサポートし，HTTP/1.1要求からHost要求ヘッダ(14.23)が欠落している場合エラーを報告し，絶対URI(5.1.2)を受諾するという要件は，この規定によって定義される最も重要な変更点の一つである。

旧来のHTTP/1.0クライアントは，IPアドレス及びサーバの1対1の関係が仮定していた。要求が送られたIPアドレス以外に，要求の意図するサーバを区別するための他の確立された機構は存在しなかった。旧来のHTTPクライアントがもはや一般的ではなくなると，上に概観された変更点によって，インターネットは，単一のIPアドレスから複数のWebサイトをサポートできるようになり，単一のホストに多くのIPアドレスを割り当てることによって深刻な問題を生じさせていた，大規模の操作的Webサーバを大いに簡略化できるようになる。インターネットは，特殊目的のドメイン名をルートレベルのHTTP URLで使用可能にするというだけの目的のために割り当てられていたIPアドレスも取り戻すことができるようになる。Webの発展の割合及び既に配備されたサーバの数からすると，(既存のHTTP/1.0アプリケーションの更新も含む)HTTPのすべての実装が次の要件を正しく実装することは，極めて重要になる。

• クライアント及びサーバの両方は，Host要求ヘッダをサポートしなければならない。
• Host要求ヘッダは，HTTP/1.1要求において必須とする。
• サーバは，HTTP/1.1要求がHost要求ヘッダを含まない場合には，400(Bad Request)エラーを報告しなければならない。
• サーバは，絶対URIを受諾しなければならない。

19.6 追加機能

この附属情報は，幾つかの既存のHTTP実装によって使用されているが，ほとんどのHTTP/1.1アプリケーションでは一貫していないし正確でもないプロトコル要素を文書化する。実装者は，これらの機能を承知していることが望ましいが，他のHTTP/1.1アプリケーションにそれら機能が存在すること，又は他のHTTP/1.1アプリケーションと相互運用可能なことを当てにすることはできない。これらのあるものは，提案された実験的な機能を記述し，他のあるものは，実験的な配備によって欠けていることが見出され，基本となるHTTP/1.1規定で現在取り組まれている機能を記述する

19.6.1 追加の要求メソッド

19.6.1.1 PATCH

PATCHメソッドは，PUTと類似しているが，Request-URIによって識別される資源の元の版と，PATCH動作が適用された後の資源の望ましい内容との間の差異のリストを実体が含む点が異なる。差異のリストは，実体のメディア型(例えば，"application/diff")によって定義されるフォーマットになっており，資源の元の版を望ましい版に変換するのに必要な変更を，サーバが再生成できるために十分な情報を含んでいなければならない。

要求がキャッシュを通じて渡され，Request-URIが現在キャッシュされている実体を識別する場合には，その実体は，キャッシュから取り除かれなければならない。このメソッドへの応答は，キャッシュ可能ではない。

パッチを当てられた資源がどのように配置されるか，及びそれ以前の資源に何が起きるかを決定するための実際のメソッドは，原サーバによって完全に定義される。パッチを当てられた資源の元の版がContent-Versionヘッダフィールドを含んでいた場合には，要求実体は，元のContent-Versionヘッダフィールドの値に対応するDerived-Fromヘッダフィールドを含めなければならない。アプリケーションは，版付け関係を構成し版矛盾を解決するために，これらのフィールドを使用することを奨励される。

PATCH要求は，8.2で示されたメッセージ伝送要件に従わなければならない。

PATCHを実装するキャッシュは，PUTに対して13.10で定義されるとおりに，キャッシュされた応答を無効にすることが望ましい。

19.6.1.2 LINK

LINKメソッドは，Request-URIによって識別される既存の資源と他の既存の資源との間に一つ以上のリンク関係を確立する。LINKと資源間にリンクを確立できる他のメソッドとの間の違いは，LINKメソッドが，要求の中にいかなるメッセージ本体も送ることを許さず，新しい資源の生成を直接的には生じないということとする。

要求がキャッシュを通じて渡され，Request-URIが現在キャッシュされている実体を識別する場合には，その実体は，キャッシュから取り除かれなければならない。このメソッドへの応答は，キャッシュ可能ではない。

LINKを実装するキャッシュは，PUTに対して13.10で定義されるとおりにキャッシュされた応答を無効にすることが望ましい。

19.6.1.3 UNLINK

UNLINKメソッドは，Request-URIによって識別される既存の資源から一つ以上のリンク関係を取り除く。これらの関係は，LINKメソッドの使用又はLinkヘッダをサポートする他のメソッドによって確立されたものであってよい。資源へのリンクの削除は，資源が，その存在を終了したり，将来の参照に対してアクセス不可能になることを意味するのではない。

要求がキャッシュを通じて渡され，Request-URIが現在キャッシュされている実体を識別する場合には，その実体は，キャッシュから取り除かれなければならない。このメソッドへの応答は，キャッシュ可能ではない。

UNLINKを実装するキャッシュは，PUTに対して13.10で定義されるとおりに，キャッシュされた応答を無効にすることが望ましい。

19.6.2 追加のヘッダフィールド定義

19.6.2.1 Alternates(代替)

Alternatesヘッダフィールドは，原サーバが，要求された資源の他の利用可能な表現について，その表現の特徴的な属性と共にクライアントに知らせるための手段として，したがって，利用者エージェントが，(12.でエージェント駆動折衝として示されている，)その利用者の要望によりよく適した他の表現をその後に選択するためのより信頼できる手段が提供されるように，提案された。

Alternatesヘッダフィールドは，Varyヘッダフィールドと，それら両方が応答又は利用可能な表現の解釈に影響せずにメッセージの中で共存できるという点で，直交している。Alternatesは，型及び言語のような共通的な範囲上を変化するこれらの資源のためにVaryフィールドによって提供されるサーバ駆動折衝に重要な改善を与えると期待される。

Alternateヘッダフィールドは，将来の規定において定義される。

19.6.2.2 Content-Version(内容版)

Content-Version実体ヘッダフィールドは，進展する実体の描出と関連する版のタグを定義する。19.6.2.3で示されるDerived-Formフィールドと共に，これは，人々のグループが反復的工程としての作品の創出に関して同時に作業できるようにする。このフィールドは，異なる表現における派生的な作業又は描出ではなく，単一工程に沿った特定の作業の進展を可能にするために使用されることが望ましい。

          Content-Version = "Content-Version" ":" quoted-string

Content-Versionフィールドの例は，次を含む。

          Content-Version: "2.1.2"
          Content-Version: "Fred 19950116-12:26:48"
          Content-Version: "2.5a4-omega7"

19.6.2.3 Derived-From(派生元)

Derived-From実体ヘッダフィールドは，送り側によって変更が行なわれる前に実体が導出された資源の版のタグを示すために使用される。このフィールドは，資源への連続する変更を，特にそれらの変更が並列的に複数の発生元から行われる場合に，併合する処理の管理を支援するために使用される。

          Derived-From   = "Derived-From" ":" quoted-string

そのフィールドの使用例は，次のとおり。

          Derived-From: "2.1.1"

Derived-Fromフィールドは，送られている実体が前もって同じURIから取得されており，最後にそれが取得されたときにContent-Versionヘッダが実体と一緒に含まれている場合には，PUT要求及びPATCH要求に対して要求される。

19.6.2.4 Link(リンク)

Link実体ヘッダフィールドは，二つの資源の間，一般には要求された資源とそれ以外の資源との間の関係を記述するための手段を提供する。実体は，複数のLink値を含んでもよい。メタ情報レベルでのLinkは，典型的には，階層構造及びたどり経路のような関係を示す。Linkフィールドは，HTML[5]における<LINK>要素と意味的に等価とする。

          Link           = "Link" ":" #("<" URI ">" *( ";" link-param )

          link-param     = ( ( "rel" "=" relationship )
                             | ( "rev" "=" relationship )
                             | ( "title" "=" quoted-string )
                             | ( "anchor" "=" <"> URI <"> )
                             | ( link-extension ) )

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

          relationship   = sgml-name
                         | ( <"> sgml-name *( SP sgml-name) <"> )

          sgml-name      = ALPHA *( ALPHA | DIGIT | "." | "-" )

relationship値は，大文字・小文字を区別せず，sgml-name構文の制約内で拡張してよい。titleパラメタは，人が読むことができるメニュー内の識別として使用できる目的で，リンク先をラベル付けするために使用してよい。anchorパラメタは，この資源の素片又は第三者資源といった，現在の資源全体以外のソースアンカを示すために使用できる。

使用例は，次を含む。

       Link: <http://www.cern.ch/TheBook/chapter2>; rel="Previous"

       Link: <mailto:timbl@w3.org>; rev="Made"; title="Tim Berners-Lee"

最初の例は，chapter2が論理的たどり経路においてこの資源の前であることを示す。2番目の例は，資源を利用可能にするために責任のある人が与えられたe-mailアドレスによって識別されることを示す。

19.6.2.5 URI

この規定の過去の版において，URIヘッダフィールドは，既存のLocation，Content-Location及びVaryのヘッダフィールド，さらに将来的なAlternatesフィールド(19.6.2.1)，の組合せとして使用されてきた。この第一の目的は，名前及び鏡像(mirror)位置を含む資源のための付加的なURIのリストを含めることであった。しかし，この単一のフィールド内で多くの異なる機能を組み合わせることは，それらの機能の任意のものを一貫して正しく実装するために障害となってきた。さらに，名前及び鏡像位置の識別がLinkヘッダフィールドによってよりよく実行されると考える。そのために，URIヘッダフィールドは非推奨とし，それら他のフィールドを使用することを推奨する。

          URI-header    = "URI" ":" 1#( "<" URI ">" )

19.7 以前の版との互換性

以前の版への準拠を必須とすることは，プロトコル規定の適用範囲外とする。しかし，HTTP/1.1は，以前の版のサポートを容易にするように慎重に設計された。この規定を構成した時点では，商業的なHTTP/1.1サーバが次を行うことを期待していることを備考として示すのは価値がある。

• HTTP/0.9，HTTP/1.0及びHTTP/1.1の要求に対するRequest-Lineのフォーマットを認識する。
• HTTP/0.9，HTTP/1.0又はHTTP/1.1のフォーマットのあらゆる有効な要求を理解する。
• クライアントが使用するのと同じ主版でのメッセージを用いて適切に応答する。

さらに，HTTP/1.1クライアントが，次を行うことを期待する。

• HTTP/1.0及びHTTP/1.1の応答に対するStatus-Lineのフォーマットを認識する。
• HTTP/0.9，HTTP/1.0及びHTTP/1.1のフォーマットでのあらゆる有効な応答を理解する。

HTTP/1.0のほとんどの実装では，各々のコネクションは，要求に先立ってクライアントによって確立され，応答を送った後にサーバによって閉じられる。実装の中には，19.7.1.1で示される永続的コネクションのKeep-Alive版を実装するものも少数ながら存在する。

19.7.1 HTTP/1.0の永続的コネクションとの互換性

クライアント及びサーバの中には，HTTP/1.0のクライアント及びサーバにおける永続的コネクションの以前の実装と互換性をもつことを望むものがあるかもしれない。HTTP/1.0における永続的コネクションは，それらがデフォルト振る舞いではないので，明示的に折衝されなければならない。HTTP/1.0の永続的コネクションの実験的な実装は欠陥があり，HTTP/1.1における新しい機能は，これらの問題を修正するために設計されている。その問題とは，既存の1.0クライアントの中には，Connectionを理解しないプロキシサーバにKeep-Aliveを送るかもしれないものがあることである。この場合，そのプロキシは，次の境界内サーバに誤ってそれを回送する。そのサーバは，Keep-Aliveコネクションを確立することを望むだろうが，その結果として，応答の閉じを待っている異常停止したHTTP/1.0プロキシを生じてしまう。結局，HTTP/1.0クライアントは，プロキシと通信する場合には，Keep-Aliveの使用を禁止されなければならない。

しかし，プロキシとの通信は永続的コネクションの最も重要な使用であって，その禁止は明らかに受け入れられない。そのために，永続的コネクションが望まれていることを示すための他の機構が必要になる。この機構は，Connectionを無視する古いプロキシと通信する場合であっても(永続的コネクションの)使用を安全にするものとする。永続的コネクションは，HTTP/1.1メッセージについてはデフォルトとする。非永続性を宣言するために新しいキーワード(Connection: close)を導入する。

次に，永続的コネクションの元来のHTTP/1.0形式を示す。

HTTPクライアントは，原サーバと接続しているとき，Persistコネクショントークンに加えて，Keep-Aliveコネクショントークンを送信してもよい。

          Connection: Keep-Alive

HTTP/1.0サーバは，Keep-Aliveコネクショントークンで応答し，クライアントは，HTTP/1.0(又はKeep-Alive)の永続的コネクションを用いて継続してもよい。

HTTP/1.1サーバも，Keep-Aliveコネクショントークンを受信した際に，HTTP/1.0クライアントと永続的コネクションを確立してもよい。しかし，HTTP/1.0クライアントとの永続的コネクションは，かたまり(chunked)転送符号化を使用できず，それゆえに，各々のメッセージの終了境界に印を付けるためにContent-Lengthを使用しなければならない。

HTTP/1.0プロキシサーバは，Connectionヘッダフィールドを構文解析するためのHTTP/1.1の規則に従わないので，クライアントは，プロキシサーバにKeep-Aliveコネクショントークンを送信してはならない。

19.7.1.1 Keep-Aliveヘッダ

Keep-Aliveコネクショントークンが要求又は応答とともに伝送された場合，Keep-Aliveヘッダフィールドも含まれてよい。Keep-Aliveヘッダフィールドは次の形式をとる。

          Keep-Alive-header = "Keep-Alive" ":" 0# keepalive-param

          keepalive-param = param-name "=" value

Keep-Aliveヘッダそれ自体は，オプションであって，パラメタが送信された場合だけに使用される。HTTP/1.1は，パラメタを定義しない。

Keep-Aliveヘッダが送信された場合，対応するコネクショントークンが，転送されなければならない。Keep-Aliveヘッダは，コネクショントークン無しで受信された場合には，無視されなければならない。