HTTP セマンティクス

"http" URI スキームは、指定されたポートで TCP ([TCP]) 接続を待ち受ける可能性のある HTTP オリジンサーバーによって管理される 階層的な名前空間内で識別子を作成するために、ここで定義される。

  http-URI = "http" "://" authority path-abempty [ "?" query ]

"http" URI のオリジンサーバーは、authority コンポーネントによって識別され、これには host 識別子 ([URI], 3.2.2節) と任意のポート番号 ([URI], 3.2.3節) が含まれる。port サブコンポーネントが空であるか指定されていない場合、TCP ポート 80 ( WWW サービス用に予約されたポート) がデフォルトである。オリジンは、 4.3.2節 で定義されるように、識別されたリソースをターゲットとするリクエストに 権威をもって応答する権利を誰が持つかを決定する。

送信者は、空の host 識別子を持つ "http" URI を生成してはならない。そのような URI 参照を処理する受信者は、それを 無効として拒否しなければならない。

階層的な path コンポーネントと任意の query コンポーネントは、そのオリジンサーバーの 名前空間内のターゲットリソースを識別する。

"https" URI スキームは、指定されたポートで TCP 接続を待ち受け、HTTP 通信のために安全化された TLS ([TLS13]) 接続を確立できる可能性のあるオリジンサーバーによって管理される階層的な名前空間内で識別子を作成するために、ここで定義される。この文脈では、 安全化されたとは具体的に、サーバーが識別された authority の代理として動作していることが 認証され、そのサーバーとのすべての HTTP 通信が、クライアントとサーバーの双方に受け入れられる 機密性および完全性の保護を備えていることを意味する。

  https-URI = "https" "://" authority path-abempty [ "?" query ]

"https" URI のオリジンサーバーは、authority コンポーネントによって識別され、これには host 識別子 ([URI], 3.2.2節) と任意のポート番号 ([URI], 3.2.3節) が含まれる。port サブコンポーネントが空であるか指定されていない場合、TCP ポート 443 ( TLS 上の HTTP 用に予約されたポート) がデフォルトである。オリジンは、 4.3.3節 で定義されるように、識別されたリソースをターゲットとするリクエストに 権威をもって応答する権利を誰が持つかを決定する。

送信者は、空の host 識別子を持つ "https" URI を生成してはならない。そのような URI 参照を処理する受信者は、それを 無効として拒否しなければならない。

階層的な path コンポーネントと任意の query コンポーネントは、そのオリジンサーバーの 名前空間内のターゲットリソースを識別する。

クライアントは、"https" リソースに対する HTTP リクエストが通信される前に安全化されていること、およびそれらのリクエストに対する 安全化されたレスポンスのみを受け入れることを保証しなければならない。クライアントとサーバーに受け入れられる暗号 メカニズムの定義は通常ネゴシエートされ、時間とともに変化し得ることに注意すること。

"https" スキームを介して利用可能になるリソースは、 "http" スキームと共有される識別性を持たない。それらは別個の名前空間を持つ異なるオリジンである。しかし、 Cookie プロトコル [COOKIE] のように、同じ host を持つすべてのオリジンに適用されるものとして定義された HTTP の拡張は、 一つのサービスによって設定された情報が、一致する host ドメイン群内の他のサービスとの 通信に影響することを許可する。このような拡張は、安全化された接続から取得された情報が 安全化されていないコンテキスト内で意図せず交換されることを防ぐため、十分に慎重に設計するべきである。

"http" または "https" スキームを持つ URI は、各スキームについて上記で説明したデフォルトを使用して、 [URI] の 6節 で定義された 方法に従って正規化および比較される。

HTTP は、等価性を判定するために特定の方法を使用することを要求しない。たとえば、 キャッシュキーは単純な文字列として、構文ベースの 正規化後に、またはスキームベースの正規化後に比較される場合がある。

• port がスキームのデフォルトポートと等しい場合、正規形では port サブコンポーネントを省略する。
• OPTIONS リクエストのターゲットとして使用されていない場合、空の path コンポーネントは "/" という絶対 path と等価であるため、正規形では代わりに "/" という path を指定する。
• scheme と host は大文字小文字を区別せず、通常は小文字で指定される。他の すべてのコンポーネントは大文字小文字を区別して比較される。
• "reserved" 集合に含まれない文字は、その パーセントエンコードされたオクテットと等価である。正規形ではそれらをエンコードしない (2.1節および 2.2節、[URI] を参照)。

   http://example.com:80/~smith/home.html
   http://EXAMPLE.com/%7Esmith/home.html
   http://EXAMPLE.com:/%7esmith/home.html

正規化後に (任意の方法を使用して) 等価となる二つの HTTP URI は、 同じリソースを識別すると仮定でき、任意の HTTP コンポーネントは正規化を実行してもよい。したがって、異なるリソースを 正規化後に等価となる HTTP URI ( 6.2節 の [URI] で定義される任意の方法を使用) によって識別することは 望ましくない。

authority の URI 汎用構文には、URI にユーザー認証情報を含めるための userinfo サブコンポーネント ([URI], 3.2.1節) も含まれる。その サブコンポーネントでは、"user:password" 形式の使用は非推奨である。

一部の実装は、コマンド呼び出しオプション、設定 ファイル、ブックマークリストなどにおいて、認証情報の内部設定のために userinfo コンポーネントを使用するが、 そのような使用によってユーザー識別子または パスワードが露出する可能性がある。

送信者は、"http" または "https" URI 参照がメッセージ内で ターゲット URI またはフィールド値として生成される場合、userinfo サブコンポーネント (およびその "@" 区切り文字) を生成してはならない。

信頼されていない ソースから受信した "http" または "https" URI 参照を使用する前に、受信者は userinfo を解析し、その 存在をエラーとして扱うことが望ましい。これはフィッシング攻撃のために authority を隠す目的で使用されている可能性が高い。

フラグメント識別子は、3.5節 の [URI] で定義されるように、URI スキームとは独立して副次的リソースを間接的に識別できるようにする。 URI を参照する一部のプロトコル要素はフラグメントを含めることを許可するが、 他の要素は許可しない。それらは、フラグメントが許可される要素では ABNF 規則を使用することで 区別され、それ以外ではフラグメントを除外する特定の規則が使用される。

指定された URI の オリジンは、scheme と host を小文字に正規化し、port から 先頭のゼロを除去するよう正規化した後の scheme、host、および port の三つ組である。 URI から port が省略されている場合、そのスキームのデフォルトポートを 使用する。たとえば、URI

   https://Example.Com/happy.js

のオリジンは

   { "https", "example.com", "443" }

   https://example.com:443

各オリジンは独自の名前空間を定義し、その 名前空間内の識別子をどのようにリソースへ対応付けるかを制御する。そして、オリジンが有効な リクエストに時間を通じて一貫してどのように応答するかが、ユーザーが URI と関連付ける セマンティクスを決定し、それらのセマンティクスの有用性によって、最終的にこれらの 機構が、ユーザーが将来参照およびアクセスするためのリソースへと変わる。

scheme、host、または port が異なる場合、二つのオリジンは別個である。同じ主体が 二つの異なるオリジンを制御していることを検証できる場合でも、それらのオリジンの下にある二つの名前空間は、 そのオリジンについて権威を持つサーバーによって明示的にエイリアス化されない限り別個である。

オリジンは、この文書の範囲外である HTML および関連する Web プロトコル内でも使用され、 [RFC6454] で説明されている。

HTTP はトランスポートプロトコルから独立しているが、"http" スキーム (4.2.1節) は、 authority コンポーネント内で識別された host の指定ポートで TCP 接続を待ち受けるオリジンサーバーを制御する者と authority を関連付けることに特化している。 これは、クライアント固有の名前解決機構と、経路上の攻撃者から 保護されていない可能性のある通信の両方に依存するため、非常に弱い意味での authority である。それでも、 信頼された環境内で一貫して解決するために、"http" 識別子をオリジンサーバーへ 結び付ける最低限の方法としては十分である。

host 識別子が IP アドレスとして提供されている場合、オリジンサーバーは、その IP アドレスの指定された TCP ポート上のリスナー (存在する場合) である。host が 登録名である場合、その登録名は、DNS などの名前 解決サービスで適切なオリジンサーバーのアドレスを見つけるために使用する間接的な識別子である。

"http" URI が指定された リソースへのアクセスを必要とするコンテキストで使用される場合、クライアントは host 識別子を IP アドレスに解決し、そのアドレスの指定された ポートへ TCP 接続を確立し、その接続上でクライアントのターゲット URI と一致する リクエストターゲットを含む HTTP リクエストメッセージを送信することによってアクセスを試みてもよい (7.1節)。

サーバーがそのようなリクエストに、15節 で 説明される暫定ではない HTTP レスポンスメッセージで応答した場合、その レスポンスはクライアントのリクエストに対する権威ある回答とみなされる。

ただし、上記は権威ある レスポンスを得る唯一の手段ではなく、権威あるレスポンスが常に必要であることを意味するものでもない ([CACHING] を参照)。たとえば、Alt-Svc ヘッダー フィールド [ALTSVC] により、オリジン サーバーはそのオリジンについて権威を持つ他のサービスを識別できる。 "http" で識別されるリソースへのアクセスは、この文書の範囲外の プロトコルによって提供される場合もある。

"https" スキーム (4.2.2節) は、 識別されたオリジンサーバーについてクライアントが信頼できるとみなす証明書に対応する 秘密鍵をサーバーが使用できる能力に基づいて authority を関連付ける。クライアントは通常、 事前に取り決められた、または設定されたトラストアンカーから伝達される信頼の連鎖に依存して、 証明書を信頼できるとみなす (4.3.4節)。

HTTP/1.1 以前では、クライアントは、 その URI オリジンの host 専用に正常に確立され安全化された接続上で 通信している場合にのみ、サーバーに authority を帰属させる。接続の確立と証明書の 検証が authority の証明として使用される。

HTTP/2 および HTTP/3 では、正常に確立され安全化された接続上で 通信している場合、URI オリジンの host がサーバーの証明書に存在するいずれかの host と一致し、かつ クライアントがその URI についてその host への接続を開けると考えるなら、クライアントはサーバーに authority を帰属させる。実際には、 クライアントは DNS クエリを行い、オリジンの host に 確立済み接続と同じサーバー IP アドレスが含まれていることを確認する。この制限は、 オリジンサーバーが等価な ORIGIN フレーム [RFC8336] を送信することで解除できる。

リクエストターゲットの host および port の値は各 HTTP リクエスト内で渡され、 オリジンを識別し、同じサーバーによって 制御される可能性のある他の名前空間から区別する (7.2節)。証明書の秘密鍵を制御するサービスが 対応する "https" 名前空間の管理にも同等の責任を負うこと、または 少なくとも誤送信されたように見えるリクエストを拒否する準備ができていることを保証するのはオリジンの責任である (7.4節)。

オリジンサーバーは、そうする authority を持っている場合でも、特定のターゲット URI に対する リクエストを処理したくない場合がある。たとえば、host が異なるポート (例: 443 と 8000) で別個のサービスを運用している場合、 ネットワーク攻撃者があるポートへの接続を別の ポートで受信させる可能性があるため、接続が安全化された後であってもオリジンサーバーでターゲット URI を確認する必要がある。 ターゲット URI を確認しないと、そのような攻撃者が、ある ターゲット URI (例: "https://example.com/foo") へのレスポンスを、別のポートからの見かけ上 権威あるレスポンス (例: "https://example.com:8000/foo") に置き換えることを許す可能性がある。

"https" スキームは authority の関連付けに TCP および接続されたポート番号を 依存しないことに注意すること。両方とも安全化された通信の外部にあり、 決定的なものとして信頼できないためである。したがって、HTTP 通信は、 4.2.2節 で定義されるように安全化された任意のチャネル上で行うことができ、 TCP を使用しないプロトコルも含まれる。

"https" URI が指定された リソースへのアクセスを必要とするコンテキストで使用される場合、クライアントは host 識別子を IP アドレスへ解決し、そのアドレスの指定された ポートへ TCP 接続を確立し、機密性および完全性の保護を伴う TLS を TCP 上で正常に開始することによって接続をエンドツーエンドで安全化し、その 接続上でクライアントのターゲット URI と一致するリクエストターゲットを含む HTTP リクエストメッセージを送信することでアクセスを試みてもよい (7.1節)。

サーバーがそのようなリクエストに、15節 で 説明される暫定ではない HTTP レスポンスメッセージで応答した場合、その レスポンスはクライアントのリクエストに対する権威ある回答とみなされる。

ただし、上記は権威ある レスポンスを得る唯一の手段ではなく、権威あるレスポンスが常に必要であることを意味するものでもない ([CACHING] を参照)。

URI を参照解除するために 安全化された接続を確立するには、 クライアントはサービスの 識別性が URI のオリジンサーバーに対して許容可能な一致であることを検証しなければならない。証明書 検証は、経路上の攻撃者または 名前解決を制御する攻撃者によるサーバーなりすましを防ぐために使用される。このプロセスには、クライアントが 一組のトラストアンカーで設定されていることが必要である。

一般に、クライアントは 6節 の [RFC6125] で定義された検証プロセスを使用して サービス識別性を検証しなければならない。 クライアントはサービスの host から参照識別性を構築しなければならない: host がリテラル IP アドレスである場合 (4.3.5節)、参照識別性は IP-ID であり、それ以外では host は名前であり、参照識別性は DNS-ID である。

CN-ID 型の参照識別性をクライアントが使用してはならない。6.2.1節 の [RFC6125] に記載されているように、 CN-ID 型の参照識別性は古いクライアントによって使用される場合がある。

クライアントは、代替形式のサーバー 識別性検証を受け入れるよう特別に設定されている場合がある。たとえば、クライアントが アドレスとホスト名が動的なサーバーに接続しており、そのサービスが ターゲット URI のオリジンと一致する証明書ではなく、特定の証明書 (または外部で定義された何らかの参照 識別性と一致する証明書) を提示することを期待している場合がある。

特殊な場合には、クライアントが単純にサーバーの 識別性を無視することが適切な場合もあるが、これは接続を能動的な 攻撃にさらしたままにすることを理解しなければならない。

証明書がターゲット URI のオリジンに対して有効でない場合、ユーザーエージェントは、 続行する前にユーザーから確認を得る (3.5節 を参照) か、 不正な証明書エラーで接続を終了しなければならない。自動化されたクライアントは、 適切な監査ログ (利用可能な場合) にエラーを記録しなければならず、接続を (不正な証明書 エラーで) 終了することが望ましい。自動化されたクライアントは、この確認を無効にする設定を 提供してもよいが、それを有効にする設定を 提供しなければならない。

"https" URI の "host" フィールド内で IP アドレスリテラルを使用して識別されるサーバーは、IP-ID 型の参照識別性を持つ。IP バージョン 4 アドレスは "IPv4address" ABNF 規則を使用し、IP バージョン 6 アドレスは "IPv6address" オプションを持つ "IP-literal" 生成規則を使用する。3.2.2節 の [URI] を参照。 IP-ID の参照識別性は、IP アドレスを復号したバイト列を含む。

IP バージョン 4 アドレスは 4 オクテット、IP バージョン 6 アドレスは 16 オクテットである。 IP-ID の使用は、その他の IP バージョンについては定義されていない。証明書の subjectAltName 拡張における iPAddress 選択肢は IP バージョンを明示的には含まないため、 バージョンの区別はアドレスの長さに依存する。4.2.1.6節 の [RFC5280] を参照。

IP-ID 型の参照識別性は、そのアドレスが証明書の subjectAltName 拡張の iPAddress 値と同一である場合に一致する。

[RFC5234] の ABNF 規則に対する #rule 拡張は、 一部のリストベースのフィールド値の定義における可読性を向上させるために使用される。

コンマ区切りの 要素リストを定義するため、"*" と同様の構造 "#" が定義される。完全な形式は "<n>#<m>element" であり、少なくとも <n> 個、最大で <m> 個の要素を示し、それぞれは単一のコンマ (",") と 任意の空白 (OWS、5.6.3節 で定義) で区切られる。

トークンは、空白または区切り文字を含まない 短いテキスト識別子である。

  token          = 1*tchar

  tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
                 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
                 / DIGIT / ALPHA
                 ; 区切り文字を除く任意の VCHAR

多くの HTTP フィールド値は、 共通の構文コンポーネントを使用し、空白または特定の区切り 文字によって分離されて定義される。区切り文字は、 token で許可されない US-ASCII 可視文字の集合 (DQUOTE および "(),/:;<=>?@[\]{}") から選択される。

この仕様では、線形空白の使用を表すために三つの規則を使用する: OWS (任意の空白)、RWS (必須の空白)、および BWS ("不正な" 空白)。

OWS 規則は、0 個以上の線形空白オクテットが現れ得る場所で使用される。 可読性を向上させるため任意の空白が望まれるプロトコル要素では、 送信者は任意の空白を単一の SP として生成することが望ましい。それ以外では、送信者は インプレースのメッセージフィルタリング中に無効または不要なプロトコル要素を 上書きするために必要な場合を除き、任意の空白を生成しないことが望ましい。

RWS 規則は、フィールドトークンを 分離するために少なくとも一つの線形空白オクテットが必要な場合に使用される。送信者は RWS を 単一の SP として生成することが望ましい。

OWS および RWS は単一の SP と同じセマンティクスを持つ。OWS または RWS として定義されていることが分かっている 任意の内容は、それを解釈する前、またはメッセージを下流へ 転送する前に、単一の SP に置き換えてもよい。

BWS 規則は、文法が歴史的な 理由だけで任意の空白を許可する場所で使用される。送信者はメッセージ内に BWS を生成してはならない。 受信者は、そのような不正な空白を解析し、 プロトコル要素を解釈する前に除去しなければならない。

BWS にはセマンティクスがない。BWS として定義されていることが分かっている任意の内容は、 それを解釈する前、またはメッセージを 下流へ転送する前に除去してもよい。

  OWS            = *( SP / HTAB )
                 ; 任意の空白
  RWS            = 1*( SP / HTAB )
                 ; 必須の空白
  BWS            = OWS
                 ; "不正な" 空白

テキスト文字列は、二重引用符を使用して引用されている場合、 単一の値として解析される。

  quoted-string  = DQUOTE *( qdtext / quoted-pair ) DQUOTE
  qdtext         = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text

バックスラッシュオクテット ("\") は、quoted-string および comment 構造内で 単一オクテットの引用 機構として使用できる。quoted-string の値を処理する受信者は、 quoted-pair をバックスラッシュに続くオクテットで 置き換えたかのように扱わなければならない。

  quoted-pair    = "\" ( HTAB / SP / VCHAR / obs-text )

送信者は、その 文字列内に現れる DQUOTE およびバックスラッシュオクテットを引用するために必要な場合を除き、quoted-string 内に quoted-pair を生成しないことが望ましい。送信者は、 comment 内に現れる括弧 ["(" および ")"] とバックスラッシュ オクテットを引用するために必要な場合を除き、comment 内に quoted-pair を生成しないことが望ましい。

一部の HTTP フィールドには、コメントテキストを 括弧で囲むことによってコメントを含めることができる。コメントは、フィールド値定義の一部として "comment" を含むフィールドでのみ許可される。

  comment        = "(" *( ctext / quoted-pair / comment ) ")"
  ctext          = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text

パラメーターは名前/値ペアのインスタンスであり、項目に補助情報を追加するための 共通構文としてフィールド値内でよく使用される。 各パラメーターは通常、直前のセミコロンによって区切られる。

  parameters      = *( OWS ";" OWS [ parameter ] )
  parameter       = parameter-name "=" parameter-value
  parameter-name  = token
  parameter-value = ( token / quoted-string )

パラメーター名は大文字小文字を区別しない。パラメーター値は、 パラメーター名のセマンティクスに応じて大文字小文字を区別する場合も、しない場合もある。 パラメーターおよびいくつかの等価な形式の例は、メディアタイプ (8.3.1節) および Accept ヘッダー フィールド (12.5.1節 ) に見ることができる。

token 生成規則に一致するパラメーター値は、token としても quoted-string 内でも送信できる。引用された値と引用されていない値は等価である。

1995 年以前、サーバーが タイムスタンプを伝えるために一般的に使用していた形式は三つあった。古い実装との互換性のため、三つすべてを ここで定義する。推奨形式は、Internet Message Format [RFC5322] で使用される 日付および時刻仕様の固定長かつ単一ゾーンのサブセットである。

  HTTP-date    = IMF-fixdate / obs-date

推奨形式の例は次のとおりである

Sun, 06 Nov 1994 08:49:37 GMT    ; IMF-fixdate

二つの廃止形式の例は次のとおりである

Sunday, 06-Nov-94 08:49:37 GMT   ; 廃止された RFC 850 形式
Sun Nov  6 08:49:37 1994         ; ANSI C の asctime() 形式

HTTP フィールド内のタイムスタンプ値を解析する受信者は、三つすべての HTTP-date 形式を受け入れなければならない。送信者が HTTP-date として定義された一つ以上のタイムスタンプを含むフィールドを生成する場合、 送信者はそれらのタイムスタンプを IMF-fixdate 形式で生成しなければならない。

HTTP-date 値は、協定世界時 (UTC) における時点として時間を表す。最初の二つの形式は、 UTC 名の前身であるグリニッジ標準時の三文字略称 "GMT" によって UTC を示す。asctime 形式の値は UTC であると仮定される。

時計とは、UTC における現在の時点の妥当な 近似を提供できる実装である。時計実装は、UTC と同期するために NTP ([RFC5905])、 または同様のプロトコルを使用するべきである。

  IMF-fixdate  = day-name "," SP date1 SP time-of-day SP GMT
  ; 形式の固定長/ゾーン/大文字小文字サブセット
  ; [RFC5322] の 3.3節 を参照

  day-name     = %s"Mon" / %s"Tue" / %s"Wed"
               / %s"Thu" / %s"Fri" / %s"Sat" / %s"Sun"

  date1        = day SP month SP year
               ; 例: 02 Jun 1982

  day          = 2DIGIT
  month        = %s"Jan" / %s"Feb" / %s"Mar" / %s"Apr"
               / %s"May" / %s"Jun" / %s"Jul" / %s"Aug"
               / %s"Sep" / %s"Oct" / %s"Nov" / %s"Dec"
  year         = 4DIGIT

  GMT          = %s"GMT"

  time-of-day  = hour ":" minute ":" second
               ; 00:00:00 - 23:59:60 (うるう秒)

  hour         = 2DIGIT
  minute       = 2DIGIT
  second       = 2DIGIT

  obs-date     = rfc850-date / asctime-date

  rfc850-date  = day-name-l "," SP date2 SP time-of-day SP GMT
  date2        = day "-" month "-" 2DIGIT
               ; 例: 02-Jun-82

  day-name-l   = %s"Monday" / %s"Tuesday" / %s"Wednesday"
               / %s"Thursday" / %s"Friday" / %s"Saturday"
               / %s"Sunday"

  asctime-date = day-name SP date3 SP time-of-day SP year
  date3        = month SP ( 2DIGIT / ( SP 1DIGIT ))
               ; 例: Jun  2

HTTP-date は大文字小文字を区別する。4.2節 の [CACHING] は、 キャッシュ受信者についてこれを緩和していることに注意すること。

送信者は、文法内で SP として明示的に含まれるものを超えて、 HTTP-date 内に追加の空白を生成してはならない。day-name、day、month、year、および time-of-day のセマンティクスは、 対応する名前を持つ Internet Message Format 構造について定義されたものと同じである ([RFC5322]、3.3節)。

2 桁の年を使用する rfc850-date 形式のタイムスタンプ値を受信した受信者は、 50 年を超えて 未来にあるように見えるタイムスタンプを、末尾 2 桁が同じであった過去の最も 近い年を表すものとして解釈しなければならない。

フィールド定義によって別途制限されない限り、タイムスタンプ値の受信者は タイムスタンプの解析において堅牢であることが推奨される。たとえば、メッセージが Internet Message Format によって定義された任意の 日付および時刻仕様を生成する可能性のある非 HTTP ソースから、HTTP を介して転送されることがある。

リクエスト内のコンテンツの目的は、メソッドセマンティクス (9節) によって定義される。

たとえば、PUT リクエスト (9.3.4節) のコンテンツ内の表現は、 リクエストが正常に適用された後の ターゲットリソース の望ましい状態を表す一方、 POST リクエスト (9.3.3節) のコンテンツ内の表現は、 ターゲットリソースによって処理される情報を表す。

レスポンスでは、コンテンツの目的はリクエストメソッド、レスポンス ステータスコード (15節)、および そのコンテンツを記述するレスポンスフィールドによって定義される。たとえば、GET (200 (OK) レスポンスのコンテンツは、メッセージ生成日時 (9.3.1節) へのレスポンスとして 観測された ターゲットリソース の現在の状態を表し、 メッセージ生成日時 (6.6.1節) における状態である一方、 同じステータスコードを持つ POST へのレスポンスのコンテンツは、処理 結果または処理適用後のターゲットリソースの新しい状態のいずれかを表す場合がある。

GET への 206 (Partial Content) レスポンスのコンテンツには、選択された表現の単一の部分、または その表現の複数の部分を含むマルチパートメッセージ本文のいずれかが含まれる。これは 15.3.7節 で説明される。

エラーステータスコードを持つレスポンスメッセージは通常、 エラー状態を表すコンテンツを含み、そのコンテンツはエラー状態と それを解決するために推奨される手順を記述する。

HEAD リクエストメソッド (9.3.2節) へのレスポンスには決してコンテンツが含まれない。関連するレスポンス ヘッダーフィールドは、リクエストメソッドが GET (9.3.1節) であった場合にその値が何であったかだけを示す。

CONNECT リクエストメソッド (2xx (成功) レスポンスは、 コンテンツを持つ代わりに接続をトンネルモードへ切り替える (9.3.6節 )。

すべての 1xx (情報)、204 (No Content)、および 304 (Not Modified) レスポンスにはコンテンツが含まれない。

その他のすべてのレスポンスにはコンテンツが含まれるが、そのコンテンツの長さが 0 である場合もある。

完全または部分的な表現がメッセージコンテンツとして転送される場合、 送信者が提供するか、受信者が、その特定の表現に対応するリソースの 識別子を判断できることが望ましい場合が多い。たとえば、 「現在の天気 レポート」というリソースに GET リクエストを行うクライアントは、返されたコンテンツに固有の識別子 (例: 「20210720T1711 時点の Laguna Beach の天気 レポート」) を必要とする場合がある。これは、 時間とともに表現が変化すると予想されるリソースからのコンテンツを共有または ブックマークする際に役立つ。

• リクエストに Content-Location ヘッダーフィールドがある場合、送信者は コンテンツが Content-Location フィールド値によって識別されるリソースの表現であると表明する。ただし、そのような表明は 他の手段 (この仕様では定義されない) によって検証できない限り信頼できない。 それでも、この情報は改訂履歴のリンクに役立つ場合がある。
• それ以外の場合、コンテンツは HTTP によって識別されないが、より具体的な識別子が コンテンツ自体の中で提供される場合がある。

1. リクエストメソッドが HEAD、またはレスポンスステータスコードが 204 (No Content) または 304 (Not Modified) である場合、レスポンスに コンテンツはない。
2. リクエストメソッドが GET でレスポンスステータスコードが 200 (OK) である場合、コンテンツは ターゲット リソースの表現である (7.1節)。
3. リクエストメソッドが GET でレスポンスステータスコードが 203 (Non-Authoritative Information) である場合、 コンテンツは、仲介者によって提供された ターゲットリソース の 潜在的に変更または拡張された表現である。
4. リクエストメソッドが GET でレスポンスステータスコードが 206 (Partial Content) である場合、コンテンツは ターゲットリソースの表現の一つ以上の部分である。
5. レスポンスに Content-Location ヘッダーフィールドがあり、そのフィールド値が ターゲット URI と同じ URI への参照である場合、コンテンツは ターゲットリソースの表現である。
6. レスポンスに Content-Location ヘッダーフィールドがあり、そのフィールド値が ターゲット URI とは異なる URI への参照である場合、送信者は コンテンツが Content-Location フィールド値によって識別されるリソースの表現であると表明する。ただし、そのような表明は 他の手段 (この仕様では定義されない) によって検証できない限り信頼できない。
7. それ以外の場合、コンテンツは HTTP によって識別されないが、より具体的な識別子が コンテンツ自体の中で提供される場合がある。

トレーラーセクションは、使用中の HTTP バージョンによってサポートされ、 明示的なフレーミング機構によって有効にされている場合にのみ可能である。たとえば、 HTTP/1.1 のチャンク化転送コーディングでは、コンテンツの後にトレーラーセクションを送信できる ( [HTTP/1.1] の 7.1.2節)。

多くのフィールドは、その評価が コンテンツを受信する前に必要であるため、ヘッダーセクション外では処理できない。これにはメッセージ フレーミング、ルーティング、認証、リクエスト修飾子、レスポンス制御、またはコンテンツ 形式を記述するものが含まれる。送信者は、対応するヘッダーフィールド名の定義がそのフィールドを トレーラーで送信することを許可していると分かっている場合を除き、トレーラーフィールドを生成してはならない。

あるプロトコルバージョンから別のプロトコルバージョンへメッセージを転送する仲介者にとって、 トレーラーフィールドは処理が難しい場合がある。メッセージ全体を転送中にバッファーできる場合、 一部の仲介者は、転送前にトレーラーフィールドをヘッダーセクションへ (適切に) 統合できる。しかし、ほとんどの場合、トレーラーは単に 破棄される。受信者は、対応するヘッダーフィールド 定義を理解し、その定義がトレーラーフィールド 値を安全に統合できる方法を明示的に許可および定義していない限り、トレーラーフィールドを ヘッダーセクションへ統合してはならない。

リクエストの TE ヘッダーフィールド (10.1.4節) にキーワード "trailers" が存在することは、 クライアントが自身および任意の 下流クライアントの代理としてトレーラーフィールドを受け入れる意思があることを示す。仲介者からのリクエストでは、これは すべての下流クライアントが転送されたレスポンス内のトレーラーフィールドを受け入れる意思があることを意味する。 "trailers" が存在することは、クライアントが レスポンス内の特定のトレーラーフィールドを処理することを意味するのではなく、トレーラーセクションが どのクライアントによっても破棄されないことだけを意味する点に注意すること。

トレーラーフィールドが転送中に破棄される可能性があるため、サーバーは、 ユーザーエージェントが受信するために必要だと考えるトレーラーフィールドを 生成しないことが望ましい。

"Trailer" ヘッダーフィールド (6.6.2節) は、トレーラーセクションで送信される可能性の高い フィールドを示すために送信でき、これにより受信者はコンテンツを処理する 前にそれらの受信に備えることができる。たとえば、フィールド名によって、 コンテンツの受信中に動的チェックサムを計算し、 トレーラーフィールド値を受信したら直ちに確認する必要があることが示される場合に役立つ。

ヘッダーフィールドと同様に、同じ名前を持つトレーラーフィールドは受信した順序で 処理される。同じ名前を持つ複数のトレーラーフィールド行は、複数の値を メンバーのリストとして追加した場合と同等のセマンティクスを持つ。メッセージ中に 複数回生成される可能性のあるトレーラーフィールドは、各メンバー値が受信した フィールド行ごとに一度しか処理されない場合でも、リストベースフィールドとして定義されなければならない。

メッセージの終端で、受信者は、受信した トレーラーフィールドの集合を、ヘッダーフィールドに似ているが別個の 名前/値ペアのデータ構造として扱ってもよい。追加の処理要件がある場合、 トレーラーでの使用を意図したフィールドのフィールド仕様内で定義できる。

"Date" ヘッダーフィールドは、メッセージが 生成された日時を表し、[RFC5322] の 3.6.1節 で定義される Origination Date Field (orig-date) と 同じセマンティクスを持つ。フィールド値は、5.6.7節 で定義される HTTP-date である。

  Date = HTTP-date

例:

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

Date ヘッダーフィールドを生成する送信者は、 メッセージ生成の日時について利用可能な最良の近似としてそのフィールド値を生成することが望ましい。 理論上、その日時は メッセージコンテンツを生成する直前の瞬間を表すべきである。実際には、送信者は メッセージ生成中の任意の時点で日時値を生成できる。

時計 (5.6.7節 で定義) を持つオリジンサーバーは、 すべての 2xx (成功)、3xx (リダイレクト)、および 4xx (クライアントエラー) レスポンスで Date ヘッダーフィールドを生成しなければならず、1xx (情報) および 5xx (サーバーエラー) レスポンスでは Date ヘッダーフィールドを生成してもよい。

時計を持たないオリジンサーバーは Date ヘッダーフィールドを生成してはならない。

時計を持つ受信者が Date ヘッダーフィールドのないレスポンスメッセージを受信した場合、 その受信時刻を記録し、そのメッセージがキャッシュされるか 下流へ転送される場合には、対応する Date ヘッダーフィールドをメッセージのヘッダーセクションへ追加しなければならない。

時計を持つ受信者が無効な Date ヘッダーフィールド 値を持つレスポンスを受信した場合、その値をレスポンスの 受信時刻で置き換えてもよい。

ユーザーエージェントはリクエスト内で Date ヘッダーフィールドを送信してもよいが、 一般には、それがサーバーへ有用な情報を伝えると考えられる場合を除き、 そうしない。たとえば、HTTP のカスタムアプリケーションでは、サーバーが ユーザーエージェントとサーバーの時計の差に基づいてユーザーのリクエストの解釈を調整すると 予想される場合、Date を伝達することがある。

"Trailer" ヘッダーフィールドは、送信者がそのメッセージ内で トレーラーフィールドとして送信することを予期するフィールド名のリストを提供する。これにより受信者は、 コンテンツの処理を開始する前に、示されたメタデータの受信に備えることができる。

  Trailer = #field-name

たとえば、送信者は、コンテンツの ストリーミング中に署名が計算され、最終的な署名をトレーラーフィールドとして提供することを示す場合がある。これにより、 受信者はコンテンツを受信しながら同じチェックを逐次実行できる。

メッセージ内に一つ以上のトレーラーフィールドを生成する予定の送信者は、 そのメッセージのヘッダーセクションに Trailer ヘッダーフィールドを生成して、 トレーラーに存在する可能性のあるフィールドを示すことが望ましい。

仲介者が転送中にトレーラーセクションを破棄した場合、Trailer フィールドは 失われたメタデータの手掛かりを提供できるが、Trailer の送信者が 常に指定されたフィールドを実際に送信する保証はない。

クライアントがキャッシュ [CACHING] を持ち、リクエストをそれによって 満たせる場合、通常、リクエストは最初にそこへ送られる。

リクエストがキャッシュによって満たされない場合、一般的なクライアントは、 リクエストを満たすためにプロキシを使用するかどうかを判断するため設定を確認する。 プロキシ設定は実装依存だが、多くの場合 URI 接頭辞の 一致、選択的な authority の一致、またはその両方に基づき、プロキシ自体は通常 "http" または "https" URI によって識別される。

"http" または "https" プロキシが適用可能な場合、クライアントは そのプロキシへの接続を確立 (または再利用) して受信方向へ接続し、その後、 クライアントのターゲット URI と一致するリクエストターゲットを含む HTTP リクエストメッセージを送信する。

プロキシが適用されない場合、一般的なクライアントは、識別されたリソースへのアクセスを得るため、 (ターゲット URI のスキームに固有の) ハンドラールーチンを呼び出す。その実現方法は ターゲット URI スキームに依存し、関連する 仕様によって定義される。

4.3.2節 は、 識別されたオリジンサーバーへの受信方向接続を確立 (または再利用) し、 クライアントのターゲット URI と一致するリクエストターゲットを含む HTTP リクエストメッセージを そのサーバーへ送信することによって、"http" リソースへのアクセスを得る方法を定義する。

4.3.3節 は、 識別されたオリジンについて権威を持つオリジンサーバーへの受信方向の安全化された 接続を確立 (または再利用) し、 クライアントのターゲット URI と一致するリクエストターゲットを含む HTTP リクエストメッセージをそのサーバーへ送信することによって、 "https" リソースへのアクセスを得る方法を定義する。

"Connection" ヘッダーフィールドにより、送信者は 現在の接続に対する望ましい制御オプションを列挙できる。

  Connection        = #connection-option
  connection-option = token

Connection オプションは大文字小文字を区別しない。

Connection 以外のフィールドが現在の接続に対する、または現在の接続に関する 制御情報を提供するために使用される場合、送信者は、 対応するフィールド名を Connection ヘッダーフィールド内に列挙しなければならない。HTTP の一部のバージョンは そのような情報のためのフィールドの使用を禁止しており、そのため Connection フィールドを許可していないことに注意すること。

仲介者は、メッセージを転送する前に受信した Connection ヘッダーフィールドを 解析し、このフィールド内の各 connection-option について、 connection-option と同じ名前を持つ任意のヘッダーまたはトレーラーフィールドをメッセージから 削除し、その後 Connection ヘッダーフィールド自体も削除しなければならない (または 転送するメッセージに対する仲介者自身の制御オプションで置き換える)。

したがって、Connection ヘッダーフィールドは、直近の受信者だけを対象とする フィールド ("hop-by-hop") と、チェーン上のすべての受信者を対象とする フィールド ("end-to-end") を宣言的に区別する方法を提供し、 メッセージを自己記述的にし、将来の接続固有の 拡張を、古い仲介者が盲目的に転送することを懸念せずに 配備できるようにする。

• Proxy-Connection ( [HTTP/1.1] の付録 C.2.2)
• Keep-Alive ( [RFC2068] の 19.7.1節)
• TE (10.1.4節)
• Transfer-Encoding ( [HTTP/1.1] の 6.1節)
• Upgrade (7.8節)

送信者は、コンテンツのすべての受信者を対象とする フィールドに対応する connection option を送信してはならない。たとえば、Cache-Control は connection option として決して適切ではない ( [CACHING] の 5.2節)。

Connection option は必ずしもメッセージ内に存在するフィールドに対応するとは限らない。 connection option に関連付けられたパラメーターがない場合、 接続固有のフィールドが不要なことがあるためである。対照的に、対応する connection option なしで 受信した接続固有のフィールドは通常、そのフィールドが 仲介者によって不適切に転送されたことを示し、受信者は無視するべきである。

フィールドに対応しない新しい connection option を定義するとき、 仕様の作成者は後の衝突を避けるため、 対応するフィールド名をいずれにせよ予約するべきである。そのような予約済みフィールド名は "Hypertext Transfer Protocol (HTTP) Field Name Registry" (16.3.1節) に登録される。

"Max-Forwards" ヘッダーフィールドは、TRACE (9.3.8節) および OPTIONS (9.3.7節) リクエストメソッドに対し、リクエストが プロキシによって転送される回数を制限する機構を提供する。これは、 チェーンの途中で失敗またはループしているように見えるリクエストを クライアントが追跡しようとする場合に役立つ。

  Max-Forwards = 1*DIGIT

Max-Forwards 値は、このリクエストメッセージを あと何回転送できるかを示す 10 進整数である。

Max-Forwards ヘッダーフィールドを含む TRACE または OPTIONS リクエストを受信する各仲介者は、 リクエストを転送する前にその値を確認し更新しなければならない。受信した値が 0 (0) の場合、仲介者は リクエストを転送してはならず、代わりに仲介者自身が 最終受信者として応答しなければならない。受信した Max-Forwards 値が 0 より大きい場合、仲介者は、転送された メッセージ内に更新された Max-Forwards フィールドを生成しなければならず、そのフィールド値は a) 受信値を 1 (1) 減らした値、または b) 受信者が Max-Forwards に対してサポートする最大値のうち小さい方とする。

受信者は、その他のリクエストメソッドとともに受信した Max-Forwards ヘッダーフィールドを無視してもよい。

"Via" ヘッダーフィールドは、リクエストではユーザーエージェントとサーバーの間、レスポンスではオリジン サーバーとクライアントの間にある中間プロトコルおよび 受信者の存在を示し、電子メールの "Received" ヘッダーフィールドに似ている ([RFC5322] の 3.6.7節)。Via は、 メッセージ転送の追跡、リクエストループの回避、および リクエスト/レスポンスチェーンに沿った送信者のプロトコル能力の識別に使用できる。

  Via = #( received-protocol RWS received-by [ RWS comment ] )

  received-protocol = [ protocol-name "/" ] protocol-version
                    ; 7.8節 を参照
  received-by       = pseudonym [ ":" port ]
  pseudonym         = token

Via フィールド値の各メンバーは、メッセージを転送したプロキシまたはゲートウェイを表す。 各仲介者は、メッセージがどのように 受信されたかに関する自身の情報を追加し、その結果は 転送受信者の順序に従って並べられる。

プロキシは、以下で説明する適切な Via ヘッダーフィールドを、 自身が転送する各メッセージ内で送信しなければならない。HTTP-to-HTTP ゲートウェイは、 各受信方向リクエストメッセージ内で適切な Via ヘッダーフィールドを送信しなければならず、転送する レスポンスメッセージ内では Via ヘッダーフィールドを送信してもよい。

各仲介者について、received-protocol は、メッセージの上流送信者が使用したプロトコルおよび プロトコルバージョンを示す。したがって、Via フィールド値は リクエスト/レスポンスチェーンで通知されたプロトコル能力を記録し、 下流の受信者から見える状態を維持する。これは、レスポンス内、または 後のリクエスト内で、どの後方互換性のない機能を安全に使用できるか判断する際に役立つ。2.5節 で説明されている。簡潔にするため、受信したプロトコルが HTTP の場合、 protocol-name は省略される。

received-by 部分は通常、後にメッセージを転送した受信 サーバーまたはクライアントの host と任意の port 番号である。ただし、実際の host が 機密情報とみなされる場合、送信者は それを仮名に置き換えてもよい。port が指定されていない場合、受信者は、 received-protocol にデフォルト port があるなら、そこで受信したことを意味すると解釈してもよい。

送信者は、User-Agent および Server ヘッダーフィールドと同様に、各受信者のソフトウェアを識別するためコメントを生成してもよい。 ただし、Via のコメントは任意であり、受信者は メッセージを転送する前に削除してもよい。

Via: 1.0 fred, 1.1 p.example.net

ネットワークファイアウォールを通過するポータルとして使用される仲介者は、 明示的に有効化されていない限り、ファイアウォール領域内の host の名前および port を 転送しないことが望ましい。有効化されていない場合、そのような仲介者は、 ファイアウォールの背後にある任意の host の各 received-by host を その host に適した仮名で置き換えることが望ましい。

仲介者は、Via ヘッダーフィールドのリストメンバーの順序付き部分列について、それらのエントリーが同一の received-protocol 値を持つ場合、単一のメンバーに結合してもよい。たとえば、

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

は次のようにまとめることができる

Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

送信者は、すべてが同じ組織の管理下にあり、 host がすでに仮名で 置き換えられている場合を除き、複数のリストメンバーを結合しないことが望ましい。送信者は、 異なる received-protocol 値を持つメンバーを結合してはならない。

HTTP は、Content-Type (8.3節) および Accept (12.5.1節) ヘッダーフィールド内で、オープンで 拡張可能なデータ型付けと型ネゴシエーションを提供するために、メディアタイプ [RFC2046] を使用する。メディアタイプは、データ形式と さまざまな処理モデル、すなわちメッセージコンテキストに従ってそのデータをどのように処理するかの両方を定義する。

  media-type = type "/" subtype parameters
  type       = token
  subtype    = token

type および subtype トークンは大文字小文字を区別しない。

type/subtype の後には、名前/値ペア形式のセミコロン区切り パラメーター (5.6.6節) が続いてもよい。 パラメーターの有無は、メディアタイプ レジストリ内の定義に応じて、メディアタイプの処理にとって重要な場合がある。 パラメーター値は、パラメーター名の セマンティクスに応じて、大文字小文字を区別する場合もしない場合もある。

  text/html;charset=utf-8
  Text/HTML;Charset="utf-8"
  text/html; charset="utf-8"
  text/html;charset=UTF-8

メディアタイプは、[BCP13] で定義される手順に従って IANA に登録するべきである。

HTTP は、テキスト表現の文字エンコーディング 方式 ([RFC6365], 2節) を示す、またはネゴシエートするためにcharset名を使用する。 この文書で定義されるフィールドでは、charset 名は パラメーター (Content-Type) 内、または Accept-Encoding の場合は、単純な token の形式で現れる。どちらの 場合も、charset 名は大文字小文字を区別せずに照合される。

Charset 名は、[RFC2978] の 2節 で定義される手順に従って、 IANA "Character Sets" レジストリ (https://www.iana.org/assignments/character-sets) に登録するべきである。

MIME は、多数の "multipart" タイプ — 一つ以上の 表現を単一のメッセージ本文内にカプセル化するもの — を提供する。すべての multipart タイプは、 [RFC2046] の 5.1.1節 で定義される共通の 構文を共有し、メディアタイプ値の一部として boundary パラメーターを含む。メッセージ本文 自体がプロトコル要素であるため、送信者は 本文部分間の改行を表すために CRLF のみを生成しなければならない。

HTTP メッセージフレーミングは、multipart boundary をメッセージ 本文長の指標として使用しないが、コンテンツを生成または処理する実装が使用する場合はある。 たとえば、"multipart/form-data" タイプは、[RFC7578] で説明されるように、 リクエスト内でフォームデータを運ぶためによく使用され、 "multipart/byteranges" タイプは一部の 206 (Partial Content) レスポンスで使用するためにこの仕様で定義される (15.3.7節 を参照)。

コンテンツコーディング値は、表現に適用済み、または適用可能な エンコーディング変換を示す。コンテンツコーディングは主に、 基盤となるメディアタイプの識別性を失わず、情報を失うことなく、 表現を圧縮したり、その他の有用な方法で変換したりできるようにするために使用される。多くの場合、 表現は符号化形式で保存され、直接送信され、最終的な 受信者によってのみ復号される。

  content-coding   = token

すべてのコンテンツコーディングは大文字小文字を区別せず、16.6節 で説明されるように、"HTTP Content Coding Registry" に登録するべきである。

Content-coding 値は、Accept-Encoding (12.5.3節 ) および Content-Encoding (8.4節) ヘッダーフィールドで使用される。

[RFC5646] で定義される言語タグは、 人間が他の人間へ情報を伝達するために話す、書く、またはその他の方法で伝える 自然言語を識別する。コンピューター言語は 明示的に除外される。

HTTP は、Accept-Language および Content-Language ヘッダーフィールド内で言語タグを使用する。Accept-Language は、12.5.4節 で定義される、より広範な language-range 生成規則を使用する一方、Content-Language は以下で定義される language-tag 生成規則を使用する。

  language-tag = <Language-Tag, see [RFC5646], Section 2.1>

  fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN

詳細については [RFC5646] を参照すること。

バリデーターには二種類ある: 強いものと弱いもの。弱いバリデーターは生成しやすいが、 比較にははるかに役に立たない。強いバリデーターは比較に理想的だが、 効率的に生成するのが非常に難しい (場合によっては不可能な) ことがある。 すべての形式のリソースに同じ強度の バリデーターを要求する代わりに、HTTP は使用中のバリデーターの型を公開し、 弱いバリデーターを事前条件として使用できる場合に制限を課す。

強いバリデーターとは、GET への 200 (OK) レスポンスのコンテンツで観測可能な 表現データの変更が発生するたびに値が変化する表現メタデータである。

強いバリデーターは、表現 データの変更以外の理由、たとえば表現メタデータのセマンティクス上重要な部分が 変更された場合 (例: Content-Type) にも変化する可能性があるが、 リモートキャッシュやオーサリング ツールが保持する保存済みレスポンスを無効化する必要がある場合にのみ値を変更することが、 オリジンサーバーにとって最も利益になる。

キャッシュエントリーは、有効期限にかかわらず、任意に長い期間存続する場合がある。 したがって、キャッシュは遠い過去に 取得したバリデーターを使用してエントリーを検証しようとする場合がある。強いバリデーターは、 特定のリソースに関連付けられたすべての表現のすべてのバージョンにわたって一意である。ただし、 異なるリソースの表現間での一意性を意味するものではない (すなわち、 同じ強いバリデーターが同時に複数のリソースの表現で使用される場合があり、 それらの表現が等価であることを意味しない)。

実際にはさまざまな強いバリデーターが使用される。最良のものは 厳密なリビジョン管理に基づき、表現への各変更によって必ず 一意のノード名とリビジョン識別子が割り当てられ、その後に表現が GET からアクセス可能になる。表現 データに適用した衝突耐性ハッシュ関数も、レスポンスヘッダーフィールドを送信する前にデータを利用でき、 検証リクエストを受信するたびにダイジェストを再計算する必要がない場合には十分である。 ただし、リソースが、同じデータ形式を偶然共有する メディアタイプに対するコンテンツネゴシエーションなどによって、メタデータだけが異なる別個の 表現を持つ場合、オリジンサーバーは、それらの表現を 区別するためにバリデーターへ追加情報を組み込む必要がある。

対照的に、弱いバリデーターとは、表現データのすべての 変更に対して値が変化するとは限らない表現メタデータである。この弱さは、 値の計算方法の制限 (例: 時計の分解能)、リソースのすべての可能な表現について 一意性を保証できないこと、または リソース所有者が、一意のデータ列ではなく自身で決めた何らかの 等価性の集合によって表現をグループ化したいことに由来する場合がある。

オリジンサーバーは、以前の表現を現在の 表現の代替として受け入れられないとみなすたびに、弱い entity tag を変更することが望ましい。 言い換えると、オリジンサーバーがキャッシュに古いレスポンスを無効化させたいときは、 弱い entity tag を変更するべきである。

たとえば、動的な測定に基づいてコンテンツが毎秒変化する天気レポートの 表現は、同じ弱いバリデーターを持つ等価な 表現の集合 (オリジンサーバーの観点から) にグループ化され、 キャッシュされた表現が妥当な期間 (サーバー負荷や天候品質に基づいて動的に調整される場合もある) 有効となるようにする場合がある。同様に、 表現の変更時刻が 1 秒の分解能でしか定義されていない場合、 その表現が 1 秒の間に二度変更され、 その変更の間に取得される可能性があるなら、弱いバリデーターとなる場合がある。

同様に、バリデーターが同時に特定のリソースの 二つ以上の表現によって共有されている場合、それらの表現が同一の 表現データを持たない限り、そのバリデーターは弱い。たとえば、オリジンサーバーが gzip content coding を適用した表現と、content coding がない表現に 同じバリデーターを送信する場合、そのバリデーターは弱い。ただし、同時に存在する二つの 表現が、同じ表現データに対して二つの異なるメディアタイプが利用可能である場合など、 表現メタデータだけが異なるのであれば、同じ強いバリデーターを共有できる。

強いバリデーターは、キャッシュ 検証、部分コンテンツ範囲、および「更新の喪失」の回避を含むすべての条件付きリクエストで使用できる。 弱いバリデーターは、キャッシュエントリーの検証や Web 巡回を最近の変更に限定する場合など、以前に取得した 表現データとの厳密な同一性をクライアントが必要としない場合にのみ使用できる。

レスポンス内の "Last-Modified" ヘッダーフィールドは、リクエスト処理の終了時点で判断された、 オリジンサーバーが 選択された表現 が 最後に変更されたと考える日時を示すタイムスタンプを提供する。

  Last-Modified = HTTP-date

使用例:

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

レスポンス内の "ETag" フィールドは、リクエスト処理の終了時点で決定された 選択された表現 の現在の entity tag を提供する。 entity tag は、同じリソースの複数の表現を区別するための不透明な バリデーターであり、それらの複数の表現が、時間経過によるリソース状態の 変化、コンテンツネゴシエーションによって複数の表現が同時に 有効となること、またはその両方によるかどうかには依存しない。entity tag は不透明な引用文字列からなり、 任意で弱さを示す指標が接頭辞として付く。

  ETag       = entity-tag

  entity-tag = [ weak ] opaque-tag
  weak       = %s"W/"
  opaque-tag = DQUOTE *etagc DQUOTE
  etagc      = %x21 / %x23-7E / obs-text
             ; 二重引用符を除く VCHAR と obs-text

変更日時を保存することが不便な場合、 HTTP-date 値の 1 秒の分解能では不十分な場合、または変更 日時が一貫して維持されない場合、entity tag は変更日時よりも 信頼性の高い検証手段となり得る。

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

entity tag は弱いバリデーターまたは強いバリデーターのいずれにもなり得、 デフォルトは強いものである。オリジンサーバーが表現に entity tag を提供し、その entity tag の生成が強い バリデーター (8.8.1節) の特性をすべて満たさない場合、オリジンサーバーは 不透明な値の前に "W/" (大文字小文字を区別) を付けて、entity tag を弱いものとして マークしなければならない。

送信者はトレーラーセクション内で ETag フィールドを送信してもよい (6.5節 を参照)。ただし、 トレーラーはしばしば無視されるため、 entity tag がコンテンツ送信中に生成される場合を除き、ETag はヘッダーフィールドとして送信する方が望ましい。

リクエストメソッドは、その定義されたセマンティクスが 本質的に読み取り専用である場合、安全であるとみなされる。すなわち、クライアントは、安全なメソッドをターゲット リソースに適用した結果として、オリジンサーバー上でいかなる 状態変更も要求せず、期待もしない。同様に、安全なメソッドの合理的な使用は、 オリジンサーバーに損害、財産の損失、または異常な負担を引き起こすことを想定しない。

この安全なメソッドの定義は、安全なメソッドを呼び出している間に、 潜在的に有害な、完全には読み取り専用でない、または 副作用を引き起こす振る舞いを実装が含めることを妨げない。ただし重要なのは、 クライアントがその追加の振る舞いを要求しておらず、その責任を負わせることができない点である。 たとえば、ほとんどのサーバーはメソッドにかかわらず、 各レスポンス完了時にリクエスト情報をアクセスログファイルへ追記し、 ログ記憶域がいっぱいになってサーバー障害を引き起こす可能性があっても、それは安全とみなされる。 同様に、Web 上の広告を選択することで開始された安全なリクエストは、 広告アカウントに課金するという副作用を持つことが多い。

この仕様で定義されるリクエストメソッドのうち、GET、HEAD、OPTIONS、および TRACE メソッドは安全であると定義される。

安全なメソッドと安全でないメソッドを区別する目的は、自動化された 取得処理 (スパイダー) およびキャッシュ性能最適化 (プリフェッチ) が、 損害を引き起こす心配なく動作できるようにすることである。さらに、ユーザーエージェントが 潜在的に信頼できないコンテンツを処理するとき、安全でないメソッドの自動使用に 適切な制約を適用できるようにする。

ユーザーエージェントは、ユーザーに潜在的なアクションを提示するとき、 ユーザーが要求前に安全でないアクションを認識できるよう、 安全なメソッドと安全でないメソッドを区別することが望ましい。

ターゲット URI 内のパラメーターがアクションを選択する 効果を持つようリソースが構築されている場合、 そのアクションがリクエストメソッドセマンティクスと整合することを保証するのはリソース所有者の責任である。たとえば、 Web ベースのコンテンツ編集ソフトウェアが query パラメーター内で "page?do=delete" のようなアクションを使用することは一般的である。そのようなリソースの目的が 安全でないアクションを実行することである場合、リソース所有者は、 安全なリクエストメソッドを使用してアクセスされたとき、そのアクションを 無効化または禁止しなければならない。 そうしないと、自動化された処理が リンク保守、プリフェッチ、検索インデックスの構築などのためにすべての URI 参照に GET を実行した際、 望ましくない副作用を生じる。

あるメソッドによる複数の同一リクエストがサーバーに与える意図された 効果が、一つのそのようなリクエストの 効果と同じである場合、そのリクエストメソッドはべき等であるとみなされる。この 仕様で定義されるリクエストメソッドのうち、PUT、DELETE、および安全なリクエスト メソッドはべき等である。

安全の定義と同様に、べき等というプロパティはユーザーによって 要求されたものだけに適用される。サーバーは各リクエストを個別に記録したり、 リビジョン管理履歴を保持したり、各 べき等リクエストに対してその他の非べき等な副作用を実装したりしてよい。

べき等メソッドが区別されるのは、クライアントが サーバーのレスポンスを読み取れる前に通信障害が発生した場合、リクエストを自動的に繰り返せるためである。たとえば、クライアントが PUT リクエストを送信し、 レスポンスを受信する前に基盤となる接続が閉じられた場合、クライアントは 新しい接続を確立し、べき等リクエストを再試行できる。元のリクエストが 成功していたとしても、リクエストを繰り返すことで同じ意図された効果になることを知っている。 ただしレスポンスは異なる可能性がある。

クライアントは、メソッドにかかわらずリクエストセマンティクスが 実際にべき等であることを知る手段、または 元のリクエストが決して適用されなかったことを検出する手段がない限り、 非べき等メソッドを持つリクエストを自動的に再試行しないことが望ましい。

たとえば、ユーザーエージェントは、 (設計または設定を通じて) そのリソースに対してリクエストが安全であると分かっている場合、POST リクエストを自動的に繰り返せる。 同様に、バージョン管理 リポジトリを操作するために特別に設計されたユーザーエージェントは、接続障害後に ターゲットリソースのリビジョンを確認し、部分的に適用された 変更を元に戻すか修正し、その後失敗したリクエストを 自動的に再試行することで、部分障害状態から回復できる場合がある。

一部のクライアントはより危険な方法を取り、自動再試行が 可能な時期を推測しようとする。たとえば、レスポンスの一部も受信される前に 基盤となるトランスポート接続が閉じられた場合、 特にアイドル状態の永続接続が使用されていたなら、クライアントは POST リクエストを自動的に再試行することがある。

プロキシは非べき等リクエストを自動的に再試行してはならない。 クライアントは、失敗した自動 再試行を自動的に再試行しないことが望ましい。

キャッシュがレスポンスを保存および使用するには、関連するメソッドが キャッシュを明示的に許可し、レスポンスをどの条件で後続 リクエストの充足に使用できるかを詳細に定める必要がある。そうしていないメソッド定義はキャッシュできない。 追加要件については [CACHING] を参照。

この仕様では GET、HEAD、および POST のキャッシュセマンティクスを定義するが、 圧倒的多数のキャッシュ実装は GET および HEAD のみをサポートする。

GET メソッドは、ターゲットリソースについて、現在の 選択された表現 の転送を要求する。成功したレスポンスは、 ターゲット URI によって識別される「同一性」の性質を反映する ( [URI] の 1.2.2節)。 したがって、HTTP を介した識別可能な情報の取得は通常、その情報を 200 (OK) レスポンスで提供する可能性に関連付けられた識別子に GET リクエストを行うことで実行される。

GET は情報取得の主要な機構であり、ほぼすべての 性能最適化の中心である。重要な各 リソースについて URI を生成するアプリケーションは、それらの最適化の恩恵を受けつつ、他の アプリケーションによる再利用を可能にし、Web のさらなる拡張を促すネットワーク効果を生み出す。

リソース識別子をリモートファイルシステムのパス名、 表現をそのようなファイルの内容のコピーと考えたくなる。実際、 多くのリソースはそのように実装されている (関連する セキュリティ上の考慮事項については 17.3節 を参照)。ただし、実際にはそのような制限はない。

リソースの HTTP インターフェイスは、コンテンツオブジェクトのツリー、 さまざまなデータベースレコードに対するプログラム的ビュー、または 他の情報システムへのゲートウェイとして実装される可能性も同じくらいある。URI 対応付け機構がファイル システムに結び付けられている場合でも、オリジンサーバーは、リクエストを入力としてファイルを実行し、 ファイルを直接転送する代わりに出力を表現として送信するよう設定されている場合がある。 いずれにせよ、各リソース 識別子が実装にどのように対応し、その実装がターゲットリソースの現在の表現を どのように選択して送信するかを知る必要があるのはオリジンサーバーだけである。

クライアントは、リクエストで Range ヘッダーフィールドを送信することで、 選択された表現の一部だけの転送を要求する「範囲リクエスト」となるよう GET のセマンティクスを変更できる (14.2節)。

リクエストメッセージのフレーミングは使用されるメソッドから独立しているが、 GET リクエストで受信したコンテンツには一般的に定義されたセマンティクスがなく、 リクエストの意味またはターゲットを変更できず、リクエストスマグリング攻撃として悪用される可能性があるため、 一部の実装がリクエストを拒否して 接続を閉じることにつながる場合がある ([HTTP/1.1] の 11.2節)。クライアントは、 そのようなリクエストに目的があり適切にサポートされることを、帯域内または帯域外で以前に示した オリジンサーバーへ直接行う場合を除き、GET リクエスト内にコンテンツを 生成しないことが望ましい。オリジンサーバーは、HTTP 通信の参加者が リクエストチェーン上の仲介者を認識していないことが多いため、 コンテンツ受信について私的な取り決めに依存しないことが望ましい。

GET リクエストへのレスポンスはキャッシュ可能である。 [CACHING] の 5.2節 の Cache-Control ヘッダーフィールドによって別途示されない限り、キャッシュは 後続の GET および HEAD リクエストを満たすためにそれを使用してもよい。

GET を使用するフォームの query フィールドなど、ユーザー提供情報からターゲット URI を 構築する機構によって情報取得を実行する場合、 URI 内で開示するのに適切でない潜在的に機密性のあるデータが提供される可能性がある (17.9節 を参照)。場合によっては、 そのような情報を明らかにしないようデータをフィルタリングまたは変換できる。 その他の場合、特にレスポンスをキャッシュする利点がない場合、 GET の代わりに POST メソッド (9.3.3節) を使用することで、そのような情報を ターゲット URI 内ではなくリクエストコンテンツ内で送信できる。

HEAD メソッドは、サーバーがレスポンス内にコンテンツを送信してはならない点を除き、GET と同一である。 HEAD は、表現データを 転送せずに 選択された表現 に関するメタデータを取得するため、 多くの場合、ハイパーテキストリンクのテスト または最近の変更の確認を目的として使用される。

サーバーは、リクエストメソッドが GET であった場合に送信したものと同じヘッダーフィールドを HEAD リクエストへのレスポンスでも送信することが望ましい。ただし、 コンテンツ生成中にのみ値が決定されるヘッダーフィールドは、 サーバーが省略してもよい。たとえば、一部のサーバーは、少量のレスポンスをより 効率的に区切ったり、コンテンツ 選択について遅い時点で判断したりできるよう、最小量のデータが生成されるまで動的な GET レスポンスをバッファーする。そのような GET へのレスポンスは、たとえば Content-Length および Vary フィールドを含む場合があるが、HEAD レスポンスでは生成されないことがある。これらの小さな 不整合は、HEAD が通常効率性のために要求されることから、 HEAD リクエストのためにコンテンツを生成して破棄するより望ましいとみなされる。

リクエストメッセージのフレーミングは使用されるメソッドから独立しているが、 HEAD リクエストで受信したコンテンツには一般的に定義されたセマンティクスがなく、 リクエストの意味またはターゲットを変更できず、リクエストスマグリング攻撃として悪用される可能性があるため、 一部の実装がリクエストを拒否して 接続を閉じることにつながる場合がある ([HTTP/1.1] の 11.2節)。クライアントは、 そのようなリクエストに目的があり適切にサポートされることを、帯域内または帯域外で以前に示した オリジンサーバーへ直接行う場合を除き、HEAD リクエスト内にコンテンツを 生成しないことが望ましい。オリジンサーバーは、HTTP 通信の参加者が リクエストチェーン上の仲介者を認識していないことが多いため、 コンテンツ受信について私的な取り決めに依存しないことが望ましい。

HEAD リクエストへのレスポンスはキャッシュ可能である。 [CACHING] の 5.2節 の Cache-Control ヘッダーフィールドによって別途示されない限り、キャッシュは 後続の HEAD リクエストを満たすためにそれを使用してもよい。HEAD レスポンスは、以前にキャッシュされた GET へのレスポンスにも影響し得る。 [CACHING] の 4.3.5節 を参照。

• HTML フォームに入力されたフィールドなどのデータブロックを、 データ処理プロセスへ提供する。
• 掲示板、ニュースグループ、メーリングリスト、ブログ、または類似の 記事グループへメッセージを投稿する。
• オリジンサーバーによってまだ識別されていない新しいリソースを作成する。および
• リソースの既存の表現にデータを追加する。

オリジンサーバーは POST リクエストの処理結果に応じて適切なステータスコードを 選択することでレスポンスセマンティクスを示す。この仕様で定義されるほぼすべてのステータス コードが POST へのレスポンスとして受信され得る (例外は 206 (Partial Content)、304 (Not Modified)、および 416 (Range Not Satisfiable))。

POST リクエストの正常な処理によって オリジンサーバー上に一つ以上のリソースが作成された場合、オリジンサーバーは、 作成された主要な リソースの識別子を提供する Location ヘッダーフィールド (10.2.2節) と、新しいリソースを参照しながら リクエストの状態を記述する表現を含む 201 (Created) レスポンスを送信することが望ましい。

POST リクエストへのレスポンスは、明示的な鮮度 情報 ([CACHING] の 4.2.1節 を参照) と、 POST のターゲット URI と同じ値を持つ Content-Location ヘッダーフィールド (8.7節 ) を含む場合にのみキャッシュ可能である。キャッシュされた POST レスポンスは、後の GET または HEAD リクエストを満たすために再利用できる。対照的に、POST は潜在的に安全でないため、 POST リクエストをキャッシュされた POST レスポンスによって満たすことはできない。 [CACHING] の 4節 を参照。

POST の処理結果が既存の リソースの表現と等価になる場合、オリジンサーバーは、既存リソースの識別子を Location フィールドに含む 303 (See Other) レスポンスを送信して、ユーザー エージェントをそのリソースへリダイレクトしてもよい。これには、 ユーザーエージェントへリソース識別子を提供し、共有キャッシュにより適した方法で 表現を転送できるという利点があるが、ユーザーエージェントがその表現をすでにキャッシュしていない場合は 追加リクエストのコストがかかる。

PUT メソッドは、ターゲットリソースの状態を、 リクエストメッセージコンテンツに含まれる表現によって定義される状態で作成または置換することを要求する。 特定の表現に対する PUT が成功した場合、その後に同じターゲット リソースへ GET を行うと、等価な表現が 200 (OK) レスポンスで送信されることを示唆する。ただし、 ターゲットリソースが他のユーザーエージェントによって並行して操作される場合や、 後続の GET を受信する前にオリジンサーバーによる動的 処理の対象となる場合があるため、そのような状態変更が観測可能である保証はない。成功した レスポンスは、オリジンサーバーによる処理時点で ユーザーエージェントの意図が達成されたことだけを意味する。

ターゲットリソースが現在の表現を持たず、PUT が 正常に一つを作成した場合、オリジンサーバーは 201 (Created) レスポンスを送信してユーザーエージェントへ通知しなければならない。 ターゲットリソースが現在の表現を持ち、その 表現が含まれる表現の状態に従って正常に変更された場合、オリジンサーバーは、 リクエストの正常な完了を示すため、200 (OK) または 204 (No Content) のいずれかのレスポンスを送信しなければならない。

オリジンサーバーは、PUT 表現がターゲットリソースに対して設定された 制約と整合していることを検証することが望ましい。たとえば、 オリジンサーバーが URI に基づいてリソースの表現メタデータを決定する場合、 オリジンサーバーは、成功した PUT リクエストで受信したコンテンツがそのメタデータと整合していることを保証する必要がある。PUT 表現が ターゲットリソースと整合しない場合、オリジンサーバーは、 表現を変換するかリソース 設定を変更して整合させるか、表現が不適切である理由を説明する十分な 情報を含む適切なエラーメッセージで応答することが望ましい。409 (Conflict) または 415 (Unsupported Media Type) ステータスコードが推奨され、後者は Content-Type 値に対する制約に特有である。

1. 新しいメディアタイプを反映するようターゲットリソースを再設定する。
2. PUT 表現をリソースの 形式と整合する形式へ変換してから、新しいリソース状態として保存する。または、
3. ターゲットリソースが "text/html" に限定されていることを示す 415 (Unsupported Media Type) レスポンスでリクエストを拒否し、場合によっては 新しい表現に適したターゲットとなる別のリソースへのリンクを含める。

HTTP は、ユーザーエージェントリクエストの意図および オリジンサーバーレスポンスのセマンティクスで表現できるものを超えて、PUT メソッドがオリジンサーバーの状態へ どのような影響を与えるかを正確には定義しない。また、HTTP を介して提供されるインターフェイスを超えて、 「リソース」がその語のいかなる意味で何であるかも定義しない。リソース状態がどのように 「保存」されるか、そのような保存がリソース状態の変更によってどのように変化するか、 オリジンサーバーがリソース状態を 表現へどのように変換するかも定義しない。一般的に、リソース インターフェイスの背後にあるすべての実装詳細は、サーバーによって意図的に隠される。

これはヘッダーおよびトレーラーフィールドの保存方法にも及ぶ。Content-Type のような一般的なヘッダーフィールドは通常 保存され、後続の GET リクエストで返されるが、ヘッダーおよびトレーラーフィールドの処理は リクエストを受信したリソースに固有である。したがって、オリジンサーバーは、 PUT リクエストで受信した認識できないヘッダーおよびトレーラーフィールドを無視することが望ましい (すなわち、それらをリソース状態の一部として保存しない)。

リクエストの表現データがコンテンツに いかなる変換も適用されず保存された場合 (すなわち、リソースの新しい表現データが PUT リクエストで 受信したコンテンツと同一である) で、かつバリデーターフィールド値が新しい 表現を反映する場合を除き、オリジンサーバーは、成功した PUT へのレスポンスで 8.8節 のバリデーターフィールド、たとえば ETag または Last-Modified フィールドを送信してはならない。 この要件により、ユーザーエージェントは、自身が送信した (そしてメモリ内に保持している) 表現が PUT の結果である時点を知ることができ、 オリジンサーバーから再取得する必要がなくなる。レスポンスで受信した新しいバリデーターは、 偶発的な 上書きを防ぐため、将来の条件付きリクエストに使用できる (13.1節)。

POST と PUT メソッドの根本的な違いは、 含まれる表現に対する意図の違いによって明確になる。POST リクエストのターゲットリソースは、含まれる表現を リソース固有のセマンティクスに従って処理することを意図する一方、PUT リクエストに含まれる表現は、 ターゲットリソースの状態を置き換えるものとして定義される。したがって、PUT の意図は べき等であり、正確な効果はオリジンサーバーだけが知っているとしても 仲介者から見える。

PUT リクエストを正しく解釈するには、ユーザーエージェントが望ましい ターゲットリソースを知っていることが前提となる。状態変更リクエストを受信した後、 クライアントに代わって適切な URI を選択するサービスは、 PUT ではなく POST メソッドを使用して実装することが望ましい。 オリジンサーバーがターゲットリソースに要求された PUT 状態変更を 行わず、その代わりに、リソースが 別の URI へ移動した場合など、別のリソースへ適用させたい場合、オリジンサーバーは 適切な 3xx (Redirection) レスポンスを送信しなければならない。 その後、ユーザーエージェントはリクエストを リダイレクトするかどうかを自身で決定してもよい。

ターゲットリソースに適用された PUT リクエストは、他の リソースに副作用を与える場合がある。たとえば、ある記事が「現在の バージョン」(あるリソース) を識別する URI と、各特定の バージョン (ある時点では現在の バージョンリソースと同じ状態を共有していた別のリソース) を識別する URI を別々に持つ場合がある。 したがって、「現在のバージョン」URI への成功した PUT リクエストは、 ターゲットリソースの状態変更に加えて新しいバージョンリソースを作成し、 関連する リソース間にリンクを追加する場合もある。

一部のオリジンサーバーは、Content-Range ヘッダーフィールド (14.4節) を リクエスト修飾子として使用し、14.5節 で説明される部分 PUT を実行することをサポートする。

PUT メソッドへのレスポンスはキャッシュ可能ではない。成功した PUT リクエストが ターゲット URI に対して一つ以上の保存済みレスポンスを持つキャッシュを通過した場合、 それらの保存済みレスポンスは無効化される ([CACHING] の 4.4節 を参照)。

DELETE メソッドは、オリジンサーバーに対し、 ターゲットリソースとその現在の 機能との関連付けを削除することを要求する。実質的に、このメソッドは UNIX の "rm" コマンドに似ており、 以前に関連付けられていた情報そのものが削除されるという期待ではなく、 オリジンサーバーの URI 対応付けに対する削除操作を表す。

ターゲットリソースが一つ以上の現在の表現を持つ場合、それらが オリジンサーバーによって破棄されるかどうか、関連する記憶域が 解放されるかどうかは、リソースの性質と オリジンサーバーによる実装 (この 仕様の範囲外) に完全に依存する。同様に、DELETE の結果として、データベースまたはゲートウェイ 接続など、リソースの他の実装側面も 無効化またはアーカイブする必要がある場合がある。一般に、オリジンサーバーは削除を実行するための 所定の機構を持つリソースに対してのみ DELETE を許可すると想定される。

DELETE メソッドを許可するリソースは比較的少なく、その主な用途は リモートオーサリング環境であり、ユーザーがその効果についてある程度制御できる場合である。たとえば、 以前 PUT リクエストで作成されたリソース、または POST リクエストへの 201 (Created) レスポンス後に Location ヘッダーフィールドで識別された リソースは、それらのアクションを取り消すために対応する DELETE リクエストを許可する場合がある。同様に、HTTP を リモート操作に使用するリビジョン管理クライアントなど、オーサリング機能を実装するカスタムユーザーエージェント実装は、 サーバーの URI 空間がバージョンリポジトリに対応するよう構築されているという前提に基づいて DELETE を使用する場合がある。

DELETE メソッドが正常に適用された場合、オリジンサーバーは次を送信することが望ましい

• アクションが成功する可能性は高いがまだ実行されていない場合、 202 (Accepted) ステータスコード、
• アクションが実行され、追加情報を提供しない場合、 204 (No Content) ステータスコード、または
• アクションが実行され、レスポンスメッセージに 状態を記述する表現が含まれる場合、200 (OK) ステータスコード。

リクエストメッセージのフレーミングは使用されるメソッドから独立しているが、 DELETE リクエストで受信したコンテンツには一般的に定義されたセマンティクスがなく、 リクエストの意味またはターゲットを変更できず、リクエストスマグリング攻撃として悪用される可能性があるため、 一部の実装がリクエストを拒否して 接続を閉じることにつながる場合がある ([HTTP/1.1] の 11.2節)。クライアントは、 そのようなリクエストに目的があり適切にサポートされることを、帯域内または帯域外で以前に示した オリジンサーバーへ直接行う場合を除き、DELETE リクエスト内にコンテンツを 生成しないことが望ましい。オリジンサーバーは、HTTP 通信の参加者が リクエストチェーン上の仲介者を認識していないことが多いため、 コンテンツ受信について私的な取り決めに依存しないことが望ましい。

DELETE メソッドへのレスポンスはキャッシュ可能ではない。成功した DELETE リクエストが ターゲット URI に対して一つ以上の保存済みレスポンスを持つキャッシュを通過した場合、 それらの保存済みレスポンスは無効化される ([CACHING] の 4.4節 を参照)。

CONNECT メソッドは、受信者に対して、リクエストターゲットによって識別される宛先 オリジンサーバーへのトンネルを確立し、成功した場合、その後 トンネルが閉じられるまで、両方向でデータをブラインド転送するだけに 振る舞いを制限することを要求する。トンネルは一般に、一つ以上のプロキシを介したエンドツーエンドの仮想 接続を作成するために使用され、その後 TLS (Transport Layer Security、[TLS13]) を使用して安全化できる。

CONNECT は、このメソッドに固有の特別な形式のリクエストターゲットを使用し、 トンネル宛先の host と port 番号だけをコロンで区切ったものから構成される。デフォルト port はなく、CONNECT リクエストが port を省略した authority コンポーネントを含む URI 参照に基づいている場合でも、クライアントは port 番号を送信しなければならない (4.1節)。たとえば、

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com

サーバーは、空または無効な port 番号をターゲットとする CONNECT リクエストを、通常は 400 (Bad Request) ステータス コードで応答して拒否しなければならない。

CONNECT は HTTP 接続のリクエスト/レスポンスの性質を変更するため、 特定の HTTP バージョンでは、そのセマンティクスをプロトコルの 通信路形式へ対応付ける方法が異なる場合がある。

CONNECT はプロキシへのリクエストで使用することを意図している。受信者は、 リクエストターゲットによって識別されるサーバーへ直接接続するか、 別のプロキシを使用するよう設定されている場合、CONNECT リクエストを 次の受信方向プロキシへ転送することでトンネルを確立できる。オリジンサーバーは CONNECT リクエストを受け入れてもよいが、ほとんどのオリジンサーバーは CONNECT を実装しない。

任意の 2xx (Successful) レスポンスは、 送信者 (およびすべての受信方向プロキシ) が レスポンスヘッダーセクションの直後にトンネルモードへ切り替わることを示す。そのヘッダーセクション後に受信されたデータは、 リクエストターゲットによって識別されたサーバーからのものである。成功レスポンス以外の レスポンスは、トンネルがまだ形成されていないことを示す。

トンネル仲介者がいずれか一方の接続が閉じられたことを検出すると、トンネルは閉じられる。 仲介者は、閉じられた側から来た未送信の データを他方へ送信しようとし、両方の 接続を閉じ、その後、配信されずに残ったデータをすべて破棄しなければならない。

トンネルを作成する権限を確立するためにプロキシ認証が使用される場合がある。たとえば、

CONNECT server.example.com:443 HTTP/1.1
Host: server.example.com:443
Proxy-Authorization: basic aGVsbG86d29ybGQ=

任意のサーバーへのトンネル確立には重大なリスクがあり、 特に宛先が Web トラフィックを 意図していない周知または予約済み TCP ポートの場合に危険である。たとえば、"example.com:25" への CONNECT は、 プロキシが SMTP トラフィック用に予約されたポートへ接続することを意味する。これを許可すると、 プロキシをだましてスパムメールを中継させる可能性がある。CONNECT をサポートするプロキシは、 その使用を限られた既知のポート集合、または 設定可能な安全なリクエストターゲットのリストに制限することが望ましい。

サーバーは、CONNECT への 2xx (Successful) レスポンスで、Transfer-Encoding または Content-Length ヘッダーフィールドを 送信してはならない。クライアントは、CONNECT への成功レスポンスで受信した Content-Length または Transfer-Encoding ヘッダーフィールドを無視しなければならない。

CONNECT リクエストメッセージはコンテンツを持たない。CONNECT リクエストメッセージの ヘッダーセクション後に送信されるデータの解釈は、使用中の HTTP バージョンに固有である。

CONNECT メソッドへのレスポンスはキャッシュ可能ではない。

OPTIONS メソッドは、オリジンサーバーまたは途中の仲介者において、 ターゲットリソースに利用可能な通信オプションに関する情報を要求する。 このメソッドにより、クライアントは、リソース アクションを暗示することなく、リソースに関連するオプションや要件、 またはサーバーの能力を判断できる。

リクエストターゲットとしてアスタリスク ("*") を持つ OPTIONS リクエスト (7.1節) は、 特定のリソースではなくサーバー全体に適用される。サーバーの 通信オプションは通常リソースに依存するため、"*" リクエストは 「ping」または「no-op」型のメソッドとしてのみ有用であり、 クライアントがサーバーの能力をテストできること以外は何もしない。たとえば、これは HTTP/1.1 への適合 (または非適合) についてプロキシをテストするために使用できる。

リクエストターゲットがアスタリスクでない場合、OPTIONS リクエストは ターゲットリソースとの通信時に利用可能なオプションに適用される。

OPTIONS への成功レスポンスを生成するサーバーは、 サーバーによって実装され、ターゲットリソースに 適用可能な任意機能を示し得るヘッダー (例: Allow) を、この仕様で定義されていない潜在的な拡張も含めて 送信することが望ましい。レスポンスコンテンツがある場合、通信 オプションを機械可読または人間可読な表現で記述する場合もある。そのような 表現の標準形式はこの仕様では定義しないが、将来の HTTP 拡張によって定義される場合がある。

クライアントは、リクエストチェーン内の 特定の受信者をターゲットとするため、OPTIONS リクエスト内で Max-Forwards ヘッダーフィールドを送信してもよい (7.6.2節 を参照)。 プロキシは、そのリクエストが Max-Forwards フィールドとともに受信された場合を除き、 リクエスト転送中に Max-Forwards ヘッダーフィールドを生成してはならない。

コンテンツを含む OPTIONS リクエストを生成するクライアントは、その表現のメディア タイプを記述する有効な Content-Type ヘッダーフィールドを送信しなければならない。この仕様では、そのようなコンテンツの用途を定義していないことに注意すること。

OPTIONS メソッドへのレスポンスはキャッシュ可能ではない。

TRACE メソッドは、リクエスト メッセージのリモートなアプリケーションレベルのループバックを要求する。リクエストの最終受信者は、 以下で説明するいくつかのフィールドを除外して受信したメッセージを、200 (OK) レスポンスの コンテンツとしてクライアントへ反映することが望ましい。 "message/http" 形式 ( [HTTP/1.1] の 10.1節) は、その方法の一つである。 最終受信者は、オリジンサーバー、またはリクエスト内で Max-Forwards 値 0 (0) を最初に受信するサーバーのいずれかである (7.6.2節)。

クライアントは、レスポンスによって開示される可能性のある 機密データを含むフィールドを TRACE リクエスト内に生成してはならない。たとえば、 ユーザーエージェントが保存されたユーザー資格情報 (11節) または Cookie [COOKIE] を TRACE リクエストで送信するのは愚かなことである。リクエストの最終受信者は、 レスポンスコンテンツを生成するとき、機密データを含む可能性の高い リクエストフィールドを除外することが望ましい。

TRACE により、クライアントはリクエスト チェーンの反対側で何が受信されているかを確認し、そのデータをテストまたは診断情報に使用できる。Via ヘッダーフィールド (7.6.3節) の値は、 リクエストチェーンの追跡として機能するため特に有用である。Max-Forwards ヘッダーフィールドを使用すると、 クライアントはリクエストチェーンの長さを制限でき、 メッセージを無限ループで転送しているプロキシチェーンをテストする際に役立つ。

クライアントは TRACE リクエスト内にコンテンツを送信してはならない。

TRACE メソッドへのレスポンスはキャッシュ可能ではない。

リクエスト内の "Expect" ヘッダーフィールドは、このリクエストを 適切に処理するためにサーバーがサポートする必要がある特定の振る舞いの集合 (期待) を示す。

  Expect =      #expectation
  expectation = token [ "=" ( token / quoted-string ) parameters ]

Expect フィールド値は大文字小文字を区別しない。

この仕様で定義される唯一の期待は "100-continue" である (定義された パラメーターはない)。

100-continue 以外のメンバーを含む Expect フィールド値を受信したサーバーは、 予期しない期待を満たせないことを示すため、 417 (Expectation Failed) ステータスコードで応答してもよい。

100-continue 期待は、クライアントがこのリクエストで (おそらく大きな) コンテンツを送信しようとしており、 メソッド、ターゲット URI、およびヘッダーフィールドだけでは直ちに 成功、リダイレクト、またはエラーレスポンスを引き起こすのに十分でない場合、100 (Continue) 暫定レスポンスを受信したいことを受信者へ知らせる。 これによりクライアントは、実際に送信する前に コンテンツを送信する価値があるという指示を待つことができ、 データが巨大な場合や、クライアントがエラーの可能性が高いと予想する場合 (例: 以前に検証された認証資格情報なしで、 初めて状態変更メソッドを送信する場合) に効率を改善できる。

たとえば、次で始まるリクエストは

PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue

クライアントが不要なデータ転送で 通信路を満たし始める前に、オリジンサーバーが 401 (Unauthorized) や 405 (Method Not Allowed) などのエラーメッセージで即座に応答できるようにする。

• クライアントは、コンテンツを含まない リクエストで 100-continue 期待を生成してはならない。
• リクエストコンテンツを送信する前に 100 (Continue) レスポンスを待つクライアントは、100-continue 期待を含む Expect ヘッダーフィールドを送信しなければならない。
• 100-continue 期待を送信するクライアントは、特定の 時間待つ必要はない。そのようなクライアントは、まだレスポンスを受信していなくても コンテンツの送信を続けてもよい。さらに、 100 (Continue) レスポンスは HTTP/1.0 仲介者を通じて送信できないため、そのようなクライアントは、コンテンツ送信前に 無期限に待たないことが望ましい。
• 100-continue 期待を含むリクエストへのレスポンスとして 417 (Expectation Failed) ステータスコードを受信したクライアントは、 100-continue 期待なしでそのリクエストを繰り返すことが望ましい。 417 レスポンスは単にレスポンスチェーンが期待をサポートしていない (例: HTTP/1.0 サーバーを通過する) ことを示すためである。

• HTTP/1.0 リクエストで 100-continue 期待を受信したサーバーは、 その期待を無視しなければならない。
• 対応するリクエストのコンテンツの一部または 全部をすでに受信している場合、またはフレーミングが コンテンツがないことを示す場合、サーバーは 100 (Continue) レスポンスの送信を省略してもよい。
• 100 (Continue) レスポンスを送信するサーバーは、接続が早期に閉じられない限り、 リクエストコンテンツを受信して処理した後、最終ステータスコードを 最終的に送信しなければならない。
• リクエストコンテンツ全体を読み取る前に最終ステータスコードで応答するサーバーは、 接続を閉じる予定か (例: [HTTP/1.1] の 9.6節 を参照)、 リクエストコンテンツの読み取りを続ける予定かを示すことが望ましい。

• メソッド、ターゲット URI、およびヘッダーフィールドだけを調べて ステータスを判断できる場合、最終ステータスコードを持つ即時レスポンス、または
• クライアントにリクエストコンテンツの送信を促すための即時 100 (Continue) レスポンス。

オリジンサーバーは 100 (Continue) レスポンスを送信する前に コンテンツを待ってはならない。

• メソッド、ターゲット URI、およびヘッダーフィールドだけを調べて ステータスを判断できる場合、最終ステータスコードを持つ即時レスポンスを送信する、または
• 対応する リクエスト行およびヘッダーセクションを次の受信方向サーバーへ送信して、リクエストをオリジンサーバーへ転送する。

プロキシが (設定または過去のやり取りから) 次の受信方向 サーバーが HTTP/1.0 だけをサポートすると考える場合、プロキシは、 クライアントにコンテンツの送信開始を促すため、即時 100 (Continue) レスポンスを 生成してもよい。

  From    = mailbox

  mailbox = <mailbox, see [RFC5322], Section 3.4>

From: spider-admin@example.org

From ヘッダーフィールドがロボットではないユーザーエージェントによって送信されることはまれである。 ユーザーエージェントは、ユーザーによる明示的な 設定なしに From ヘッダーフィールドを送信しないことが望ましい。 これはユーザーのプライバシー上の 利益またはサイトのセキュリティポリシーと競合する可能性があるためである。

ロボット型ユーザーエージェントは、ロボットが過剰な、不要な、または無効な リクエストを送信するなど、サーバーで問題が発生した場合、 ロボットの実行責任者へ連絡できるよう、有効な From ヘッダーフィールドを送信することが望ましい。

サーバーは From ヘッダーフィールドをアクセス 制御または認証に使用しないことが望ましい。その値はリクエストを 受信または観測する誰にでも見えることが想定され、プライバシーを期待せずにログファイルやエラー レポートへ記録されることが多いためである。

"Referer" [原文どおり] ヘッダーフィールドにより、ユーザーエージェントは ターゲット URI を取得した元のリソースの URI 参照を指定できる (すなわち "referrer" だが、フィールド名は誤記されている)。 Referer フィールド値を生成するとき、ユーザー エージェントは URI 参照 [URI] の fragment および userinfo コンポーネントがある場合、それらを含めてはならない。

  Referer = absolute-URI / partial-URI

フィールド値は absolute-URI または partial-URI のいずれかである。後者の場合 (4節)、参照される URI は ターゲット URI に相対である ([URI], 5節)。

Referer ヘッダーフィールドにより、サーバーは簡単な解析、 ログ記録、最適化されたキャッシュなどのために他のリソースへのバックリンクを生成できる。また、 保守のために古いリンクや 誤入力されたリンクを発見できる。一部のサーバーは Referer ヘッダー フィールドを、他のサイトからのリンク (いわゆる「ディープリンク」) を拒否したり、 クロスサイトリクエストフォージェリ (CSRF) を制限したりする手段として使用するが、すべてのリクエストがそれを含むわけではない。

Referer: http://www.example.org/hypertext/Overview.html

ターゲット URI が自身の URI を持たないソースから取得された場合 (例: ユーザーのキーボードからの入力、またはユーザーのブックマーク/お気に入り内のエントリー)、 ユーザーエージェントは Referer ヘッダーフィールドを除外するか、 値 "about:blank" で送信しなければならない。

Referer ヘッダーフィールド値は、参照元 リソースの完全な URI を伝える必要はない。ユーザーエージェントは、参照元 オリジン以外の部分を切り詰めてもよい。

Referer ヘッダーフィールドは、参照元 リソースの識別子が個人情報 (アカウント名など) や 機密であることを意図したリソース (ファイアウォールの背後、または安全化されたサービスの 内部など) を明らかにする場合、リクエストコンテキストまたはユーザーの閲覧履歴に関する情報を 明らかにする可能性があり、プライバシー上の懸念となる。ほとんどの汎用ユーザーエージェントは、 参照元リソースがローカルの "file" または "data" URI の場合、Referer ヘッダーフィールドを送信しない。参照元リソースが 安全なプロトコルでアクセスされ、リクエストターゲットのオリジンが 参照元リソースのものと異なる場合、参照元リソースが Referer の送信を明示的に許可していない限り、ユーザー エージェントは Referer ヘッダーフィールドを送信しないことが望ましい。 参照元リソースが安全なプロトコルでアクセスされた場合、ユーザーエージェントは安全でない HTTP リクエストで Referer ヘッダーフィールドを送信してはならない。追加の セキュリティ上の考慮事項については 17.9節 を参照すること。

一部の仲介者は、送信リクエストから Referer ヘッダーフィールドを 無差別に削除することが知られている。これは、 CSRF 攻撃に対する保護を妨げるという不幸な副作用を持ち、その方がユーザーにはるかに有害となり得る。 Referer 内の情報開示を制限したい 仲介者およびユーザーエージェント拡張は、内部ドメイン名を仮名で置き換えたり、 query や path コンポーネントを切り詰めたりするなど、特定の編集に変更を限定するべきである。フィールド値が ターゲット URI と同じ scheme および host を共有する場合、仲介者は Referer ヘッダーフィールドを変更または削除しないことが望ましい。

"TE" ヘッダーフィールドは、transfer coding およびトレーラーセクションに関するクライアントの能力を記述する。

6.5節 で説明されるように、 リクエストで送信される "trailers" メンバーを持つ TE フィールドは、クライアントがトレーラーフィールドを 破棄しないことを示す。

TE は HTTP/1.1 内でも、クライアントがレスポンスで どの transfer coding を受け入れられるかサーバーへ通知するために使用される。公開時点では、HTTP/1.1 だけが transfer coding を使用する ([HTTP/1.1] の 7節 を参照)。

TE フィールド値はメンバーのリストであり、各メンバー ("trailers" を除く) は、 その transfer coding に対する クライアントの相対的な優先度を示す任意の重み (12.4.2節) と、その transfer coding 用の任意パラメーターを持つ transfer coding 名トークンから構成される。

  TE                 = #t-codings
  t-codings          = "trailers" / ( transfer-coding [ weight ] )
  transfer-coding    = token *( OWS ";" OWS transfer-parameter )
  transfer-parameter = token BWS "=" BWS ( token / quoted-string )

TE の送信者は、仲介者に このフィールドを転送しないよう知らせるため、Connection ヘッダーフィールド (7.6.1節) 内で "TE" connection option も送信しなければならない。

"User-Agent" ヘッダーフィールドは、リクエストを生成したユーザーエージェントに関する 情報を含み、報告された 相互運用性問題の範囲を特定する助け、特定の ユーザーエージェントの制限を回避するための対応またはレスポンスの調整、ブラウザーまたはオペレーティングシステム使用状況の解析によく使用される。 特別にそうしないよう設定されていない限り、ユーザーエージェントは各 リクエストで User-Agent ヘッダーフィールドを送信することが望ましい。

  User-Agent = product *( RWS ( product / comment ) )

User-Agent フィールド値は一つ以上の product 識別子から構成され、それぞれの後に 0 個以上のコメント (5.6.5節) が続き、 全体としてユーザーエージェントソフトウェアおよびその重要なサブプロダクトを識別する。 慣例として、product 識別子は、 ユーザーエージェントソフトウェアを識別する上での重要度が高い順に列挙される。各 product 識別子は 名前と任意のバージョンから構成される。

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

送信者は、生成する product 識別子を製品の 識別に必要なものへ制限することが望ましく、product 識別子内に広告またはその他の不要な情報を生成してはならない。 送信者は、バージョン 識別子ではない情報を product-version に生成しないことが望ましい (すなわち、同じ製品名の連続するバージョンは、 product 識別子の product-version 部分だけが異なるべきである)。

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

ユーザーエージェントは、不必要に細かい詳細を含む User-Agent ヘッダーフィールドを生成しないことが望ましく、第三者による サブプロダクトの追加を制限することが望ましい。過度に長く詳細な User-Agent フィールド値はリクエスト遅延と、ユーザーが望まない形で識別される ("fingerprinting") リスクを増加させる。

同様に、実装には、他の 実装の product トークンを使用して互換性を宣言しないことが推奨される。これは フィールドの目的を回避するためである。ユーザーエージェントが別のユーザーエージェントになりすました場合、 受信者は、実際に使用されている ユーザーエージェントではうまく動作しない可能性があっても、ユーザーがその識別されたユーザーエージェント向けに調整されたレスポンスを 意図的に望んでいると仮定できる。

"Allow" ヘッダーフィールドは、ターゲットリソースによってサポートされるものとして通知されたメソッドの集合を列挙する。この フィールドの目的は、リソースに関連する有効なリクエストメソッドを 受信者へ通知することだけである。

  Allow = #method

Allow: GET, HEAD, PUT

実際に許可されるメソッドの集合は、各 リクエスト時にオリジンサーバーによって定義される。オリジンサーバーは 405 (Method Not Allowed) レスポンスで Allow ヘッダーフィールドを生成しなければならず、 その他の任意のレスポンスでもそうしてもよい。空の Allow フィールド値は リソースがいかなるメソッドも許可しないことを示し、設定によってリソースが一時的に無効化された場合、 405 レスポンスで発生する可能性がある。

プロキシは Allow ヘッダーフィールドを変更してはならない。 汎用メッセージ処理規則に従って処理するために、 示されたすべてのメソッドを理解する必要はない。

"Location" ヘッダーフィールドは、一部のレスポンスで、レスポンスに関連する 特定のリソースを参照するために使用される。関係の型は、 リクエストメソッドとステータスコードセマンティクスの組み合わせによって定義される。

  Location = URI-reference

フィールド値は単一の URI-reference から構成される。 相対参照の形式である場合 ([URI], 4.2節)、 最終値はターゲット URI に対して解決することで計算される ([URI], 5節)。

201 (Created) レスポンスでは、Location 値はリクエストによって作成された主要なリソースを参照する。3xx (Redirection) レスポンスでは、Location 値はリクエストを自動的にリダイレクトするための優先 ターゲットリソースを参照する。

3xx (Redirection) レスポンスで提供された Location 値に fragment コンポーネントがない場合、ユーザーエージェントは、 その値がターゲット URI の生成に使用された URI 参照の fragment コンポーネントを継承するかのようにリダイレクトを処理しなければならない (すなわち、リダイレクトは元の参照の fragment があればそれを継承する)。

Location: /People.html#tim

これはユーザーエージェントが "http://www.example.org/People.html#tim" へリダイレクトすることを示唆する。

Location: http://www.example.net/index.html

これはユーザーエージェントが "http://www.example.net/index.html#larry" へリダイレクトし、元の fragment 識別子を保持することを示唆する。

Location 値内の fragment 識別子が 適切でない状況もある。たとえば、201 (Created) レスポンス内の Location ヘッダーフィールドは、 作成されたリソースに固有の URI を提供することを意図している。

サーバーは、ユーザーエージェントが後続リクエストを行う前に どの程度待つべきかを示すため、"Retry-After" ヘッダーフィールドを送信する。503 (Service Unavailable) レスポンスとともに送信された場合、Retry-After は サービスがクライアントに対してどの程度利用不能であると予想されるかを示す。任意の 3xx (Redirection) レスポンスとともに送信された場合、Retry-After は ユーザーエージェントがリダイレクトされた リクエストを発行する前に待つよう求められる最小時間を示す。

Retry-After フィールド値は、HTTP-date、または レスポンス受信後に遅延する秒数のいずれかにできる。

  Retry-After = HTTP-date / delay-seconds

delay-seconds 値は非負の 10 進整数であり、 秒単位の時間を表す。

  delay-seconds  = 1*DIGIT

使用例は二つある

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

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

"Server" ヘッダーフィールドは、リクエストを処理するためにオリジン サーバーが使用したソフトウェアに関する情報を含み、クライアントが報告された 相互運用性問題の範囲を特定する助け、特定のサーバーの制限を 回避するための対応またはリクエストの調整、サーバーまたはオペレーティング システム使用状況の解析によく使用される。オリジンサーバーは、レスポンス内に Server ヘッダー フィールドを生成してもよい。

  Server = product *( RWS ( product / comment ) )

Server ヘッダーフィールド値は一つ以上の product 識別子から構成され、それぞれの後に 0 個以上のコメント (5.6.5節 ) が続き、全体としてオリジンサーバーソフトウェアおよびその 重要なサブプロダクトを識別する。慣例として、product 識別子は オリジンサーバーソフトウェアを識別する上での重要度が高い順に列挙される。 各 product 識別子は、10.1.5節 で定義されるように、名前と任意のバージョンから構成される。

Server: CERN/3.0 libwww/2.17

オリジンサーバーは、不必要に細かい詳細を含む Server ヘッダーフィールドを生成しないことが望ましく、第三者による サブプロダクトの追加を制限することが望ましい。過度に長く詳細な Server フィールド 値はレスポンス遅延を増加させ、既知の セキュリティホールを攻撃者が発見して悪用することを (わずかに) 容易にする内部実装 詳細を明らかにする可能性がある。

"WWW-Authenticate" レスポンスヘッダーフィールドは、ターゲットリソースに適用可能な認証スキームと パラメーターを示す。

  WWW-Authenticate = #challenge

401 (Unauthorized) レスポンスを生成するサーバーは、少なくとも一つのチャレンジを含む WWW-Authenticate ヘッダーフィールドを送信しなければならない。 サーバーは、資格情報 (または異なる資格情報) を提供すると レスポンスに影響する可能性があることを示すため、その他のレスポンスメッセージでも WWW-Authenticate ヘッダーフィールドを生成してもよい。

レスポンスを転送するプロキシは、そのレスポンス内の WWW-Authenticate ヘッダーフィールドを 変更してはならない。

フィールド値には複数のチャレンジが含まれる場合があり、 各チャレンジはコンマ区切りの 認証パラメーターのリストを含む可能性があるため、ユーザーエージェントはフィールド値の解析に特に注意することが推奨される。さらに、ヘッダーフィールド自体も 複数回出現できる。

WWW-Authenticate: Basic realm="simple", Newauth realm="apps",
                 type=1, title="Login to \"apps\""

このヘッダーフィールドには二つのチャレンジが含まれる。一つは realm 値が "simple" の "Basic" スキーム用で、もう一つは realm 値が "apps" の "Newauth" スキーム用である。 さらに二つの追加パラメーター、"type" および "title" も含まれる。

ただし、一部のユーザーエージェントはこの形式を認識しない。その結果、 同じフィールド行上に複数のメンバーを持つ WWW-Authenticate フィールド値の送信は相互運用できない可能性がある。

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

  Authorization = credentials

リクエストが認証され、realm が指定されている場合、 同じ資格情報はこの realm 内の他のすべてのリクエストに対して有効であると 推定される (チャレンジ値に応じて異なる資格情報や同期時計の使用など、 認証スキーム自体が別のことを要求しないと仮定する)。

リクエストを転送するプロキシは、その リクエスト内の Authorization ヘッダーフィールドを変更してはならない。 HTTP キャッシュによる Authorization ヘッダーフィールドの処理に関する詳細と要件については、 [CACHING] の 3.5節 を参照すること。

HTTP 認証スキームは、クライアントの認証資格情報が 受け入れられた後に情報を伝達するため、"Authentication-Info" レスポンスフィールドを使用できる。 この情報にはサーバーからの最終化メッセージ (例: サーバー認証を含めることができる) が含まれる場合がある。

フィールド値は、11.3節 で定義される "auth-param" 構文を使用するパラメーター (名前/値ペア) のリストである。この仕様では 汎用形式だけを記述し、Authentication-Info を使用する認証スキームが 個々のパラメーターを定義する。たとえば "Digest" 認証スキームは、 [RFC7616] の 3.5節 で複数のパラメーターを定義する。

  Authentication-Info = #auth-param

Authentication-Info フィールドは、リクエストメソッドおよびステータスコードとは独立して、 任意の HTTP レスポンスで使用できる。そのセマンティクスは、対応するリクエストの Authorization ヘッダーフィールド (11.6.2節) によって示される 認証スキームによって定義される。

レスポンスを転送するプロキシは、フィールド値をいかなる方法でも変更することを許可されない。

認証スキームが 明示的に許可する場合、Authentication-Info はトレーラーフィールドとして送信できる (6.5節)。

"Proxy-Authenticate" ヘッダーフィールドは、このリクエストについて プロキシに適用可能な認証スキームとパラメーターを示す少なくとも一つのチャレンジから構成される。 プロキシは、自身が生成する各 407 (Proxy Authentication Required) レスポンスで、少なくとも一つの Proxy-Authenticate ヘッダーフィールドを送信しなければならない。

  Proxy-Authenticate = #challenge

WWW-Authenticate とは異なり、 Proxy-Authenticate ヘッダーフィールドは、レスポンスチェーン上の次の送信方向クライアントにのみ 適用される。これは、あるプロキシを選択したクライアントだけが 認証に必要な資格情報を持つ可能性が高いためである。ただし、同じ管理ドメイン内で複数のプロキシ、 たとえば大規模企業ネットワーク内のオフィスおよび地域キャッシュ プロキシが使用される場合、資格情報を ユーザーエージェントが生成し、消費されるまで階層を通じて渡すことが一般的である。したがって、 そのような設定では、各プロキシが同じチャレンジ集合を送信するため、Proxy-Authenticate が転送されているように 見える。

WWW-Authenticate の解析に関する考慮事項はこのヘッダーフィールドにも適用されることに注意すること。詳細については 11.6.1節 を参照。

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

  Proxy-Authorization = credentials

Authorization とは異なり、 Proxy-Authorization ヘッダーフィールドは、Proxy-Authenticate ヘッダーフィールドを使用して認証を 要求した次の受信方向プロキシにのみ適用される。チェーン内で複数のプロキシが使用される場合、 Proxy-Authorization ヘッダーフィールドは資格情報の受信を期待していた最初の受信方向 プロキシによって消費される。プロキシは、プロキシ同士が協調して特定のリクエストを認証する 機構である場合、クライアントリクエストからの資格情報を次のプロキシへ 中継してもよい。

  Proxy-Authentication-Info = #auth-param

ただし、Authentication-Info とは異なり、Proxy-Authentication-Info ヘッダーフィールドは レスポンスチェーン上の次の送信方向クライアントにのみ適用される。これは、 あるプロキシを選択したクライアントだけが認証に必要な資格情報を持つ可能性が高いためである。ただし、 大規模企業ネットワーク内のオフィスおよび地域キャッシュプロキシなど、 同じ管理ドメイン内で複数のプロキシが使用される場合、 資格情報をユーザーエージェントが生成し、消費されるまで階層を通じて渡すことが一般的である。 したがって、そのような設定では、各プロキシが 同じフィールド値を送信するため、Proxy-Authentication-Info が転送されているように見える。

認証スキームが 明示的に許可する場合、Proxy-Authentication-Info はトレーラーフィールドとして送信できる (6.5節)。

各コンテンツネゴシエーションフィールドについて、そのフィールドを含まないリクエストは、 送信者がそのネゴシエーション次元について設定を持たないことを意味する。

コンテンツネゴシエーションヘッダーフィールドがリクエストに存在し、 レスポンスに利用可能な表現のどれも それに従って受け入れ可能とみなせない場合、オリジンサーバーは、406 (Not Acceptable) レスポンスを送信してヘッダーフィールドを尊重するか、 そのリクエストヘッダーフィールドについて レスポンスがコンテンツネゴシエーションの対象ではないかのように扱ってヘッダーフィールドを無視できる。ただし、これは クライアントがその表現を使用できることを意味しない。

この仕様で定義されるコンテンツネゴシエーションフィールドは、 関連する種類のコンテンツに対する設定へ相対的な「重み」を割り当てるため、 "q" (大文字小文字を区別しない) という共通パラメーターを使用する。この重みは「品質値」(または "qvalue") と呼ばれる。これは、同じパラメーター名がサーバー設定内で、 リソースについて選択可能なさまざまな表現の相対的な品質へ 重みを割り当てるためにもよく使用されるためである。

重みは 0 から 1 の範囲の実数へ正規化され、0.001 が 最も優先度が低く、1 が最も優先度が高い。値 0 は「 受け入れ不可」を意味する。"q" パラメーターが存在しない場合、デフォルトの重みは 1 である。

  weight = OWS ";" OWS "q=" qvalue
  qvalue = ( "0" [ "." 0*3DIGIT ] )
         / ( "1" [ "." 0*3("0") ] )

qvalue の送信者は、小数点以下に 3 桁を超える数字を生成してはならない。 これらの値のユーザー設定も同様に制限するべきである。

これらのヘッダーフィールドのほとんどは、示されている場合、 指定されていない値を選択するためのワイルドカード値 ("*") を定義する。 ワイルドカードが存在しない場合、フィールド内で明示的に 言及されていない値は受け入れ不可とみなされる。Vary 内では、ワイルドカード値は変動に制限がないことを意味する。

"Accept" ヘッダーフィールドは、レスポンスメディアタイプに関する設定を ユーザーエージェントが指定するために使用できる。たとえば Accept ヘッダーフィールドは、 インライン画像へのリクエストの場合のように、 リクエストが特定の少数の望ましい型に限定されていることを示すために使用できる。

サーバーからレスポンスで送信された場合、Accept は、同じリソースへの 後続リクエストのコンテンツでどのコンテンツ タイプが優先されるかについて情報を提供する。

  Accept = #( media-range [ weight ] )

  media-range    = ( "*/*"
                     / ( type "/" "*" )
                     / ( type "/" subtype )
                   ) parameters

アスタリスク "*" 文字は、メディアタイプを範囲へグループ化するために使用され、 "*/*" はすべてのメディアタイプを、"type/*" はその type のすべての subtype を示す。 media-range は、その範囲に適用可能なメディアタイプパラメーターを含むことができる。

各 media-range の後には、適用可能な任意のメディアタイプパラメーター (例: charset) が続き、その後、 相対的な重みを示す任意の "q" パラメーター (12.4.2節) が続く場合がある。

以前の仕様では、weight パラメーターの後に追加の拡張パラメーターが現れることを許可していた。 accept 拡張文法 (accept-params、accept-ext) は、 定義が複雑で、実際には使用されておらず、 新しいヘッダーフィールドを介した方が容易に配備できるため削除された。weight を使用する送信者は、 "q" を最後に (すべての media-range パラメーターの後に) 送信することが望ましい。 受信者は、パラメーター順序にかかわらず、"q" という名前のパラメーターを weight として処理することが望ましい。

例

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

は、「audio/basic を優先するが、品質を 80% 下げてもなお利用可能な中で最善なら 任意の audio タイプを送信してほしい」と解釈される。

より複雑な例:

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 表現を送信する」と解釈される。

メディア範囲は、より具体的なメディア範囲または特定のメディアタイプによって上書きできる。 特定の type に複数のメディア範囲が適用される場合、最も具体的な参照が 優先される。たとえば、

Accept: text/*, text/plain, text/plain;format=flowed, */*

1. text/plain;format=flowed
2. text/plain
3. text/*
4. */*

特定の type に関連付けられるメディアタイプ品質係数は、 その type に一致する最も優先順位の高いメディア範囲を見つけることで決定される。たとえば、

Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed,
       text/plain;format=fixed;q=0.4, */*;q=0.5

"Accept-Charset" ヘッダーフィールドは、テキストのレスポンスコンテンツでの charset に対する設定を示すため、ユーザーエージェントが送信できる。たとえば、このフィールドにより、 より包括的または特殊用途の charset を理解できる ユーザーエージェントが、それらの charset で情報を表現できるオリジンサーバーへ その能力を通知できる。

  Accept-Charset = #( ( token / "*" ) [ weight ] )

Charset 名は 8.3.2節 で定義される。 ユーザーエージェントは、12.4.2節 で定義されるように、各 charset に品質値を関連付け、 その charset に対するユーザーの相対的な設定を示してもよい。例:

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

Accept-Charset ヘッダーフィールド内に特殊値 "*" が存在する場合、 フィールド内の他の箇所で言及されていないすべての charset に一致する。

"Accept-Encoding" ヘッダーフィールドは、content coding (8.4.1節 ) の使用に関する設定を示すために使用できる。

ユーザーエージェントがリクエストで送信した場合、Accept-Encoding はレスポンスで 受け入れ可能な content coding を示す。

サーバーがレスポンスで送信した場合、Accept-Encoding は、同じ リソースへの後続リクエストのコンテンツでどの content coding が優先されるかについて情報を提供する。

エンコーディングなしが優先される場合を伝えるため、 "identity" トークンが「エンコーディングなし」の同義語として使用される。

  Accept-Encoding  = #( codings [ weight ] )
  codings          = content-coding / "identity" / "*"

各 codings 値には、12.4.2節 で定義されるように、そのエンコーディングに対する設定を表す関連品質値 (weight) を与えてもよい。Accept-Encoding フィールド内のアスタリスク "*" 記号は、フィールドで明示的に列挙されていない利用可能な任意の content coding に一致する。

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

1. リクエストに Accept-Encoding ヘッダーフィールドがない場合、任意の content coding が ユーザーエージェントに受け入れ可能とみなされる。
2. 表現に content coding がない場合、 Accept-Encoding ヘッダーフィールドで "identity;q=0" または "identity" に対するより具体的なエントリーなしの "*;q=0" によって明示的に除外されない限り、デフォルトで受け入れ可能である。
3. 表現の content coding が Accept-Encoding フィールド値に列挙された content coding の一つである場合、qvalue 0 が伴わない限り受け入れ可能である。 (12.4.2節 で定義されるように、qvalue 0 は「 受け入れ不可」を意味する。)

表現は複数の content coding でエンコードされる場合がある。ただし、ほとんどの content coding は同じ目的 (例: データ 圧縮) を達成する代替手段である。同じ目的を持つ複数の content coding から選択するときは、 0 ではない qvalue が最も高い受け入れ可能な content coding が 優先される。

空のフィールド値を持つ Accept-Encoding ヘッダーフィールドは、 ユーザーエージェントがレスポンスでいかなる content coding も望まないことを意味する。 空でない Accept-Encoding ヘッダーフィールドがリクエストに存在し、 レスポンスに利用可能な表現のいずれも受け入れ可能として列挙された content coding を持たない場合、 identity coding が受け入れ不可と示されていない限り、オリジンサーバーは content coding なしでレスポンスを送信することが望ましい。

Accept-Encoding ヘッダーフィールドがレスポンスに存在する場合、それは関連する リクエストでリソースがどの content coding を受け入れる意思があったかを示す。 フィールド値はリクエストの場合と同じ方法で評価される。

この情報は関連するリクエスト固有であることに注意すること。同じサーバー上の他のリソースでは サポートされるエンコーディングの集合が異なる場合があり、 時間とともに変化したり、リクエストの他の側面 (リクエストメソッドなど) に依存したりする可能性がある。

サポートされていない content coding のためにリクエストを失敗させるサーバーは、 415 (Unsupported Media Type) ステータスで応答し、 そのレスポンスに Accept-Encoding ヘッダーフィールドを含め、 クライアントが content coding に関する問題とメディアタイプに関する問題を 区別できるようにするべきである。メディアタイプに関する問題との混乱を 避けるため、content coding と無関係な理由で 415 ステータスによりリクエストを失敗させるサーバーは Accept-Encoding ヘッダーフィールドを含めてはならない。

Accept-Encoding の最も一般的な用途は、クライアントが content coding を楽観的に使用したことへの レスポンスとして、415 (Unsupported Media Type) ステータスコードを持つレスポンスで使用することである。 ただし、ヘッダーフィールドは、将来の やり取りを最適化するため、content coding がサポートされていることをクライアントに示すためにも使用できる。たとえば、 リクエストコンテンツが圧縮 coding の使用を正当化するほど大きいにもかかわらず、 クライアントがそれを行わなかった場合、リソースは 2xx (Successful) レスポンスにそれを含める場合がある。

"Accept-Language" ヘッダーフィールドは、レスポンスで優先される 自然言語の集合を示すためにユーザーエージェントが使用できる。言語タグは 8.5.1節 で定義される。

  Accept-Language = #( language-range [ weight ] )
  language-range  =
            <language-range, see [RFC4647], Section 2.1>

各 language-range には、12.4.2節 で定義されるように、 その範囲によって指定される言語に対するユーザーの設定の推定値を表す関連品質値を与えることができる。たとえば、

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

は、「デンマーク語を優先するが、イギリス英語およびその他の種類の 英語も受け入れる」という意味になる。

一部の受信者は、特に等しい 品質値 (値なしは q=1 と同じ) が割り当てられたタグについて、言語タグが列挙された順序を 優先度の降順の指標として扱うことに注意すること。ただし、この振る舞いには 依存できない。一貫性および相互運用性を最大化するため、多くのユーザーエージェントは 各言語タグに一意の品質値を割り当てると同時に、品質の 降順で列挙する。言語優先順位リストに関する追加の議論は、 [RFC4647] の 2.3節 にある。

照合について、[RFC4647] の 3節 はいくつかの 照合スキームを定義する。実装は、その要件に最も適した照合スキームを提供できる。 "Basic Filtering" スキーム ([RFC4647], 3.3.1節 ) は、[RFC2616] の 14.4節 で以前 HTTP 用に定義されていた 照合スキームと同一である。

すべてのリクエストでユーザーの完全な言語設定を含む Accept-Language ヘッダーフィールドを送信することは、 ユーザーのプライバシー期待に反する可能性がある (17.13節 )。

理解可能性は個々のユーザーに大きく依存するため、ユーザーエージェントは 言語設定をユーザーが制御できるようにする必要がある (ユーザーエージェント自身の設定を通じて、またはユーザーが制御可能なシステム設定をデフォルトにすることによって)。 そのような制御をユーザーへ提供しない ユーザーエージェントは Accept-Language ヘッダーフィールドを送信してはならない。

レスポンス内の "Vary" ヘッダーフィールドは、メソッドおよびターゲット URI 以外の リクエストメッセージのどの部分が、 このレスポンスのコンテンツを選択するオリジンサーバーの 処理に影響した可能性があるかを記述する。

  Vary = #( "*" / field-name )

Vary フィールド値は、ワイルドカードメンバー "*"、または このレスポンスの表現を選択する上で役割を持った可能性がある、選択ヘッダーフィールドと呼ばれるリクエストフィールド 名のリストのいずれかである。潜在的な選択ヘッダーフィールドは、 この仕様で定義されるフィールドに限定されない。

メンバー "*" を含むリストは、 メッセージ構文外の側面 (例: クライアントのネットワークアドレス) を含む可能性もある、 リクエストの他の側面がレスポンス表現の選択に役割を持った可能性があることを示す。受信者は、 リクエストをオリジンサーバーへ転送しなければ、 このレスポンスが後のリクエストに適切かどうかを判断できない。プロキシは Vary フィールド値に "*" を生成してはならない。

たとえば、次を含むレスポンス

Vary: accept-encoding, accept-language

は、オリジンサーバーが、このレスポンスのコンテンツを選択するときの決定要因として、 リクエストの Accept-Encoding および Accept-Language ヘッダーフィールド (またはそれらの不在) を使用した可能性があることを示す。

1. 後続リクエストが元のリクエストと列挙されたヘッダーフィールドについて 同じ値を持つ ( [CACHING] の 4.1節) か、 レスポンスの再利用がオリジンサーバーによって検証されていない限り、 キャッシュ受信者はこのレスポンスを後続リクエストの充足に使用してはならないことを知らせる。 言い換えると、Vary は新しいリクエストを保存済み キャッシュエントリーに一致させるために必要なキャッシュキーを拡張する。

2. このレスポンスがコンテンツ ネゴシエーション (12節) の対象であり、列挙されたヘッダーフィールドで他の値が 提供された場合、後続リクエストで異なる 表現が送信される可能性があることをユーザーエージェント受信者へ知らせる (プロアクティブネゴシエーション)。

オリジンサーバーは、キャッシュ可能なレスポンスを 後続リクエストに選択的に再利用してほしい場合、そのレスポンスに Vary ヘッダーフィールドを生成することが望ましい。 一般に、これは、オリジンサーバーが リクエストの Accept-Language ヘッダー フィールドに基づいてレスポンス言語を選択した場合など、 選択ヘッダーフィールドによって表明された設定により適合するようレスポンスコンテンツが調整された場合である。

コンテンツ選択の変動が、Vary がキャッシュ性能に与える影響より重要でないと オリジンサーバーが判断する場合、特に キャッシュレスポンスディレクティブ ( [CACHING] の 5.2節) によって再利用がすでに制限されている場合、 Vary は省略されることがある。

異なるユーザーに対するそのレスポンスの再利用はフィールド定義によって禁止されているため、 Vary 内で Authorization フィールド名を送信する必要はない (11.6.2節)。同様に、レスポンスコンテンツが ネットワーク地域によって選択または影響されているが、受信者がある地域から別の地域へ移動しても キャッシュされたレスポンスを再利用してほしい場合、 オリジンサーバーが Vary でそのような変動を示す必要はない。

"If-Match" ヘッダーフィールドは、フィールド値が "*" の場合、 受信するオリジンサーバーがターゲット リソースの現在の表現を少なくとも一つ持っていること、または フィールド値で提供された entity tag リストのメンバーと一致する entity tag を持つ ターゲットリソースの現在の表現を持っていることを、リクエストメソッドの条件とする。

クライアントはこの 事前条件によって表現データに何らかの変更があった場合にメソッド適用を防ぐことを意図しているため、 オリジンサーバーは If-Match 用の entity tag を比較するとき、 強い比較関数 (8.8.3.2節) を使用しなければならない。

  If-Match = "*" / #entity-tag

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

If-Match は、複数のユーザーエージェントが同じリソースへ並行して作用する可能性がある場合に 誤った上書きを防ぐため、状態変更メソッド (例: POST、PUT、DELETE) とともに最もよく使用される (すなわち「更新の喪失」問題を防ぐ)。一般に、 表現の選択または変更を伴う任意のメソッドで使用でき、 選択された表現の現在の entity tag が If-Match フィールド値内のメンバーでない場合に リクエストを中止できる。

オリジンサーバーが表現を選択するリクエストを受信し、 そのリクエストに If-Match ヘッダーフィールドが含まれる場合、オリジンサーバーは、 メソッド実行前に 13.2節 に従って If-Match 条件を評価しなければならない。

1. フィールド値が "*" の場合、オリジンサーバーが ターゲットリソースの現在の表現を持っていれば条件は真である。
2. フィールド値が entity tag のリストの場合、列挙されたタグのいずれかが 選択された表現の entity tag と一致すれば条件は真である。
3. それ以外の場合、条件は偽である。

If-Match 条件を評価したオリジンサーバーは、条件が偽と評価された場合、 要求されたメソッドを実行してはならない。代わりに、 オリジンサーバーは 412 (Precondition Failed) ステータスコードで応答して、条件付きリクエストが 失敗したことを示してもよい。あるいは、リクエストが、 選択された表現にすでに適用済みのように見える状態変更 操作である場合、オリジンサーバーは 2xx (Successful) ステータスコードで応答してもよい (すなわち、 ユーザーエージェントによって要求された変更はすでに成功しているが、 以前のレスポンスが失われたか、他の ユーザーエージェントによって等価な変更が行われたため、ユーザーエージェントがそれを認識していない可能性がある)。

変更リクエストがすでに適用済みに見える場合にオリジンサーバーが成功レスポンスを送信することを許可すると、 多くのオーサリングユースケースでより効率的になるが、 複数のユーザーエージェントが非常に 類似しているが協調していない変更リクエストを行っている場合にはリスクが伴う。たとえば、 複数のユーザーエージェントが共通 リソースへセマフォとして書き込む (例: 非アトミックなインクリメント) 場合、衝突して 重要な状態遷移を失う可能性が高い。そのような種類のリソースでは、 オリジンサーバーは安全でないメソッドで失敗した各 事前条件について 412 を厳格に送信する方がよい。その他の場合、 成功レスポンスから ETag フィールドを除外すると、ユーザーエージェントが次のリクエストとして GET を実行し、 リソースの現在の状態に関する混乱を解消することを促せる。

クライアントは、選択された表現が一致しない場合に 412 (Precondition Failed) レスポンスを優先することを示すため、 GET リクエスト内で If-Match ヘッダーフィールドを送信してもよい。 ただし、これは新しい表現を望まない場合に、 以前に受信した部分表現を完了するための範囲 リクエスト (14節) でのみ有用である。 クライアントが新しい表現を受信することを優先する場合、範囲リクエストには If-Range (13.1.5節 ) の方が適している。

キャッシュまたは仲介者は、その 相互運用性機能がオリジンサーバーにのみ必要であるため、If-Match を無視してもよい。

"*" とその他の値 ("*" の他のインスタンスを含む) を含むリスト値を持つ If-Match ヘッダーフィールドは、構文的に無効であり (したがって生成することは許可されず)、さらに相互運用できる可能性が低いことに注意すること。

"If-None-Match" ヘッダーフィールドは、フィールド値が "*" の場合、 受信するキャッシュまたはオリジンサーバーがターゲット リソースの現在の表現を一つも持っていないこと、または フィールド値に列挙されたどの entity tag とも一致しない entity tag を持つ 選択された表現を持っていることを、 リクエストメソッドの条件とする。

弱い entity tag は、表現データに変更があった場合でも キャッシュ検証に使用できるため、受信者は If-None-Match 用の entity tag を比較するとき、 弱い比較関数 (8.8.3.2節) を使用しなければならない。

  If-None-Match = "*" / #entity-tag

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-None-Match は主に条件付き GET リクエストで、 最小限のトランザクションオーバーヘッドでキャッシュされた情報を効率的に 更新できるようにするため使用される。クライアントが entity tag を持つ一つ以上の保存済みレスポンスを更新したい場合、 GET リクエストを行うとき、それらの entity tag のリストを含む If-None-Match ヘッダーフィールドを生成することが望ましい。これにより、 それらの保存済みレスポンスの一つが選択された表現と一致する場合、 受信サーバーは 304 (Not Modified) レスポンスを送信できる。

If-None-Match は "*" の値とともに使用して、 クライアントがリソースに現在の 表現がないと考えているとき、安全でないリクエストメソッド (例: PUT) がターゲットリソースの既存の表現を誤って変更することを防ぐこともできる (9.2.1節)。 これは、複数の クライアントがターゲットリソースの初期表現を作成しようとする場合に生じ得る「更新の喪失」問題の一変種である。

オリジンサーバーが表現を選択するリクエストを受信し、 そのリクエストに If-None-Match ヘッダーフィールドが含まれる場合、オリジンサーバーは、 メソッド実行前に 13.2節 に従って If-None-Match 条件を評価しなければならない。

1. フィールド値が "*" の場合、オリジンサーバーが ターゲットリソースの現在の表現を持っていれば条件は偽である。
2. フィールド値が entity tag のリストの場合、列挙されたタグの一つが 選択された表現の entity tag と一致すれば条件は偽である。
3. それ以外の場合、条件は真である。

If-None-Match 条件を評価したオリジンサーバーは、 条件が偽と評価された場合、要求されたメソッドを実行してはならず、 代わりにオリジンサーバーは、リクエストメソッドが GET または HEAD の場合は a) 304 (Not Modified) ステータスコード、 その他すべてのリクエストメソッドでは b) 412 (Precondition Failed) ステータスコードで応答しなければならない。

受信した If-None-Match ヘッダーフィールドのキャッシュ処理に関する要件は、 [CACHING] の 4.3.2節 で定義される。

"*" とその他の 値 ("*" の他のインスタンスを含む) を含むリスト値を持つ If-None-Match ヘッダーフィールドは、構文的に無効であり (したがって生成することは許可されず)、さらに相互運用できる可能性が低いことに注意すること。

"If-Modified-Since" ヘッダーフィールドは、選択された表現の 変更日時がフィールド値で提供された日時より新しいことを、 GET または HEAD リクエストメソッドの条件とする。 そのデータが変更されていない場合、選択された表現のデータ転送は 回避される。

  If-Modified-Since = HTTP-date

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

リクエストに If-None-Match ヘッダー フィールドが含まれる場合、受信者は If-Modified-Since を無視しなければならない。 If-None-Match の条件は If-Modified-Since の条件をより正確に置き換えるものとみなされ、 両者は If-None-Match を実装していない可能性のある古い仲介者との 相互運用のためだけに組み合わせられる。

受信したフィールド値が有効な HTTP-date でない場合、 フィールド値に複数のメンバーがある場合、またはリクエストメソッドが GET と HEAD のどちらでもない場合、 受信者は If-Modified-Since ヘッダーフィールドを無視しなければならない。

リソースに利用可能な変更日時がない場合、 受信者は If-Modified-Since ヘッダーフィールドを無視しなければならない。

受信者は If-Modified-Since フィールド値の タイムスタンプをオリジンサーバーの時計に基づいて解釈しなければならない。

If-Modified-Since は通常、二つの異なる目的で使用される。1) entity tag を持たない キャッシュ済み表現を効率的に更新できるようにすること、および 2) Web 巡回の 範囲を最近変更されたリソースに限定することである。

キャッシュ更新に使用する場合、キャッシュは通常、キャッシュ済み メッセージの Last-Modified ヘッダーフィールドの値を 使用して If-Modified-Since のフィールド値を生成する。この振る舞いは、 時計の同期が不十分な場合や、サーバーが 厳密なタイムスタンプ一致だけを尊重することを選択している場合 (オリジンサーバーの時計が修正されたり、 アーカイブ済みバックアップから表現が復元されたりすると Last-Modified 日時が「過去に戻る」ように見える問題があるため) に最も相互運用しやすい。ただし、キャッシュは ときどき、キャッシュ済みメッセージの Date ヘッダーフィールドや、 メッセージを受信した時計時刻など、他のデータに基づいてフィールド値を生成することがある。特にキャッシュ済み メッセージに Last-Modified ヘッダーフィールドが含まれない場合である。

取得範囲を最近の時間窓に限定するために使用する場合、ユーザーエージェントは 自身の時計、または以前のレスポンスでサーバーから受信した Date ヘッダーフィールドのいずれかに基づいて If-Modified-Since フィールド値を生成する。選択された表現の Last-Modified ヘッダーフィールドに基づく厳密なタイムスタンプ一致を選択するオリジンサーバーは、 指定された時間窓で変更されたものだけに データ転送を限定するユーザーエージェントを支援できない。

オリジンサーバーが表現を選択するリクエストを受信し、 そのリクエストに If-None-Match ヘッダーフィールドなしで If-Modified-Since ヘッダーフィールドが含まれる場合、 オリジンサーバーはメソッドを実行する前に 13.2節 に従って If-Modified-Since 条件を評価することが望ましい。

1. 選択された表現の最終変更日時が フィールド値で提供された日時以前の場合、条件は偽である。
2. それ以外の場合、条件は真である。

If-Modified-Since 条件を評価したオリジンサーバーは、 条件が偽と評価された場合、要求されたメソッドを実行しないことが望ましく、代わりにオリジンサーバーは、 以前にキャッシュされたレスポンスを識別または更新するために有用なメタデータだけを含む 304 (Not Modified) レスポンスを 生成することが望ましい。

受信した If-Modified-Since ヘッダーフィールドのキャッシュ処理に関する要件は、 [CACHING] の 4.3.2節 で定義される。

"If-Unmodified-Since" ヘッダーフィールドは、選択された表現の最終 変更日時がフィールド 値で提供された日時以前であることを、リクエストメソッドの条件とする。 このフィールドは、ユーザーエージェントが表現の entity tag を持たない場合に If-Match と同じ目的を達成する。

  If-Unmodified-Since = HTTP-date

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

リクエストに If-Match ヘッダーフィールドが含まれる場合、 受信者は If-Unmodified-Since を無視しなければならない。 If-Match の条件は If-Unmodified-Since の条件をより正確に置き換えるものとみなされ、両者は If-Match を実装していない可能性のある古い仲介者との 相互運用のためだけに組み合わせられる。

受信したフィールド値が有効な HTTP-date でない場合 (フィールド値が日時のリストのように見える場合を含む)、 受信者は If-Unmodified-Since ヘッダーフィールドを無視しなければならない。

リソースに利用可能な変更日時がない場合、 受信者は If-Unmodified-Since ヘッダーフィールドを無視しなければならない。

受信者は If-Unmodified-Since フィールド 値のタイムスタンプをオリジンサーバーの時計に基づいて解釈しなければならない。

If-Unmodified-Since は、複数のユーザーエージェントが 表現に entity tag を提供しないリソース上で並行して動作する可能性がある場合に誤った上書きを防ぐため、 状態変更メソッド (例: POST、PUT、 DELETE) とともに最もよく使用される (すなわち「更新の喪失」問題を防ぐ)。一般に、表現の選択または変更を伴う 任意のメソッドで使用でき、選択された 表現の最終変更日時が If-Unmodified-Since フィールド値で提供された日時以後に変化していた場合、リクエストを中止できる。

オリジンサーバーが表現を選択するリクエストを受信し、 そのリクエストに If-Match ヘッダーフィールドなしで If-Unmodified-Since ヘッダーフィールドが含まれる場合、 オリジンサーバーはメソッド実行前に 13.2節 に従って If-Unmodified-Since 条件を評価しなければならない。

1. 選択された表現の最終変更日時が フィールド値で提供された日時以前の場合、条件は真である。
2. それ以外の場合、条件は偽である。

If-Unmodified-Since 条件を評価したオリジンサーバーは、 条件が偽と評価された場合、要求されたメソッドを実行してはならない。代わりに、オリジンサーバーは 412 (Precondition Failed) ステータスコードで応答し、 条件付きリクエストが失敗したことを示してもよい。あるいは、 リクエストが選択された表現にすでに適用済みのように見える状態変更操作である場合、 オリジンサーバーは 2xx (Successful) ステータスコードで応答してもよい (すなわち、 ユーザーエージェントによって要求された変更はすでに成功しているが、 以前のレスポンスが失われたか、 他のユーザーエージェントによって等価な変更が行われたため、ユーザーエージェントがそれを認識していない可能性がある)。

変更リクエストがすでに適用済みに見える場合にオリジンサーバーが成功レスポンスを送信することを許可すると、 多くのオーサリングユースケースでより効率的になるが、 複数のユーザーエージェントが非常に 類似しているが協調していない変更リクエストを行っている場合にはリスクが伴う。その場合、 オリジンサーバーは安全でないメソッドで失敗した各事前条件について 412 を厳格に送信する方がよい。

クライアントは、選択された表現が変更されていた場合に 412 (Precondition Failed) レスポンスを優先することを示すため、GET リクエスト内で If-Unmodified-Since ヘッダーフィールドを送信してもよい。 ただし、これは新しい表現を望まない場合に、 以前に受信した部分表現を完了するための範囲リクエスト (14節 ) でのみ有用である。クライアントが新しい表現を受信することを優先する場合、範囲リクエストには If-Range (13.1.5節) の方が適している。

キャッシュまたは仲介者は、その 相互運用性機能がオリジンサーバーにのみ必要であるため、If-Unmodified-Since を無視してもよい。

"If-Range" ヘッダーフィールドは、If-Match および If-Unmodified-Since ヘッダー フィールドに似ているが、バリデーターが一致しない場合に Range ヘッダーフィールドを無視するよう受信者へ指示し、 412 (Precondition Failed) レスポンスではなく、新しい 選択された 表現全体を転送させる、特殊な条件付きリクエスト機構を提供する。

クライアントが表現の部分コピーを持ち、 表現全体の最新コピーを取得したい場合、 条件付き GET とともに Range ヘッダーフィールドを使用できる (If-Unmodified-Since と If-Match の一方または両方を使用する)。 ただし、表現が変更されたため事前条件が 失敗した場合、クライアントはその後、現在の表現全体を取得するため 2 回目のリクエストを行う必要がある。

"If-Range" ヘッダーフィールドにより、クライアントは 2 回目のリクエストを「短絡」できる。 非公式には、その意味は次のとおりである。表現が変更されていなければ、 Range で要求している部分を送信し、それ以外なら表現全体を送信する。

  If-Range = entity-tag / HTTP-date

有効な entity-tag は、 最初の 3 文字に DQUOTE があるか調べることで、 有効な HTTP-date と区別できる。

クライアントは、Range ヘッダー フィールドを含まないリクエストで If-Range ヘッダーフィールドを生成してはならない。 サーバーは、Range ヘッダーフィールドを含まないリクエストで受信した If-Range ヘッダーフィールドを無視しなければならない。 オリジンサーバーは、Range リクエストをサポートしないターゲットリソースへのリクエストで受信した If-Range ヘッダーフィールドを無視しなければならない。

クライアントは、弱いとマークされた entity tag を含む If-Range ヘッダーフィールドを生成してはならない。対応する表現の entity tag をクライアントが持たず、 その日時が 8.8.2.2節 で定義される意味で強いバリデーターでない限り、 クライアントは HTTP-date を含む If-Range ヘッダーフィールドを生成してはならない。

Range リクエストで If-Range ヘッダーフィールドを受信したサーバーは、 メソッド実行前に 13.2節 に従って条件を評価しなければならない。

1. 提供された HTTP-date バリデーターが、 8.8.2.2節 で定義される意味で強いバリデーターでない場合、条件は偽である。
2. 提供された HTTP-date バリデーターが 選択された表現の Last-Modified フィールド値と完全に一致する場合、 条件は真である。
3. それ以外の場合、条件は偽である。

1. 提供された entity-tag バリデーターが、 強い比較関数 (8.8.3.2節) を使用して選択された表現の ETag フィールド値と完全に一致する場合、 条件は真である。
2. それ以外の場合、条件は偽である。

If-Range ヘッダーフィールドの受信者は、If-Range 条件が偽と評価された場合、Range ヘッダーフィールドを無視しなければならない。 それ以外の場合、受信者は要求されたとおりに Range ヘッダーフィールドを処理することが望ましい。

If-Range の比較は、バリデーターが HTTP-date の場合を含め、完全一致によって行われるため、 If-Unmodified-Since 条件を評価するときに使用される「以前または等しい」比較とは異なることに注意すること。

以下で除外される場合を除き、受信者キャッシュまたはオリジンサーバーは、 通常のリクエストチェックを正常に実行した後、 リクエストコンテンツ (存在する場合) を処理するか、リクエスト メソッドに関連付けられたアクションを実行する直前に、受信したリクエストの事前条件を評価しなければならない。サーバーは、 リクエストコンテンツを処理する前に、それらの条件なしの同じリクエストへのレスポンスが 2xx (Successful) または 412 (Precondition Failed) 以外のステータスコードになる場合、受信したすべての事前条件を無視しなければならない。 言い換えると、重要な処理が行われる前に 検出できるリダイレクトおよび失敗は、事前条件の評価より優先される。

ターゲットリソースのオリジンサーバーではなく、かつ ターゲットリソースへのリクエストについてキャッシュとして動作できないサーバーは、 この仕様で定義される条件付きリクエストヘッダーフィールドを評価してはならず、リクエストを転送する場合、それらを転送しなければならない。これは生成したクライアントが、それらを 現在の表現を提供できるサーバーによって評価されることを意図しているためである。同様に、サーバーは、 CONNECT、OPTIONS、TRACE など、選択された表現の選択または変更を伴わない リクエストメソッドとともに受信した場合、この仕様で定義される 条件付きリクエストヘッダーフィールドを無視しなければならない。

プロトコル拡張は、事前条件を 評価する条件や、その評価の結果を変更できることに注意すること。たとえば、immutable キャッシュ ディレクティブ ([RFC8246] で定義) は、fresh なレスポンスを保持している場合、 条件付きリクエストの転送を省略するようキャッシュへ指示する。

条件付きリクエストヘッダーフィールドは HEAD メソッドで使用可能と定義されているが (HEAD のセマンティクスを GET と一貫させるため)、 成功レスポンスは 304 (Not Modified) レスポンスとほぼ同じサイズであり、 412 (Precondition Failed) レスポンスより有用であるため、 条件付き HEAD を送信する意味はない。

複数の条件付きリクエストヘッダーフィールドがリクエストに存在する場合、 フィールドを評価する順序が重要になる。実際には、この文書で定義されるフィールドは 一つの論理的な順序で一貫して実装される。 「更新の喪失」事前条件はキャッシュ 検証より厳しい要件を持ち、検証済みキャッシュは部分レスポンスより効率的であり、entity tag は日付バリデーターより正確であると推定されるためである。

1. 受信者がオリジンサーバーであり、If-Match が存在する場合、If-Match 事前条件を評価する:

   • 真の場合、手順 3 へ進む
   • 偽の場合、状態変更リクエストがすでに成功したと 判断できない限り、412 (Precondition Failed) で応答する (13.1.1節 を参照)

2. 受信者がオリジンサーバーで、If-Match が存在せず、If-Unmodified-Since が存在する場合、If-Unmodified-Since 事前条件を評価する:

   • 真の場合、手順 3 へ進む
   • 偽の場合、状態変更リクエストがすでに成功したと 判断できない限り、412 (Precondition Failed) で応答する (13.1.4節 を参照)

3. If-None-Match が 存在する場合、If-None-Match 事前条件を評価する:

   • 真の場合、手順 5 へ進む
   • GET/HEAD で偽の場合、304 (Not Modified) で応答する
   • その他のメソッドで偽の場合、412 (Precondition Failed) で応答する

4. メソッドが GET または HEAD で、If-None-Match が存在せず、If-Modified-Since が存在する場合、If-Modified-Since 事前条件を評価する:

   • 真の場合、手順 5 へ進む
   • 偽の場合、304 (Not Modified) で応答する

5. メソッドが GET で、Range と If-Range の両方が存在する場合、If-Range 事前条件を評価する:

   • 真で、かつ Range が 選択された表現に適用可能な場合、206 (Partial Content) で応答する
   • それ以外の場合、Range ヘッダーフィールドを無視し、200 (OK) で応答する

6. それ以外の場合、

   • 要求されたメソッドを実行し、その成功または 失敗に応じて応答する。

追加の条件付きリクエストヘッダーフィールドを定義する HTTP の拡張は、 そのようなフィールドを、この 文書で定義されるものおよび実際に存在し得る他の条件との関係で評価する順序を定義するべきである。

範囲は、範囲単位と範囲指定子の集合の組み合わせとして表現される。 範囲単位名は、自身の 指定子にどの種類の range-spec が適用可能かを決定する。したがって、次の文法は汎用的であり、各範囲単位は、 int-range、 suffix-range、および other-range がいつ許可されるかについて要件を 規定することが期待される。

範囲リクエストは、単一の表現内の 単一の範囲または範囲の集合を指定できる。

  ranges-specifier = range-unit "=" range-set
  range-set        = 1#range-spec
  range-spec       = int-range
                   / suffix-range
                   / other-range

int-range は、 二つの非負整数、または一つの非負整数から 表現データの末尾までとして表現される範囲である。範囲単位は整数が 何を意味するかを規定する (例: 先頭からの単位オフセット、包含的に番号付けされた 部分などを示す場合がある)。

  int-range     = first-pos "-" [ last-pos ]
  first-pos     = 1*DIGIT
  last-pos      = 1*DIGIT

int-range は、last-pos 値が存在し、かつ first-pos より小さい場合に無効である。

suffix-range は、指定された非負整数の最大長 (範囲単位) を持つ 表現データの接尾部として表現される範囲である。言い換えると、表現データの最後の N 単位である。

  suffix-range  = "-" suffix-length
  suffix-length = 1*DIGIT

拡張性を提供するため、other-range 規則はほとんど制約のない文法であり、 アプリケーション固有または将来の範囲単位が追加の範囲指定子を定義できるようにする。

  other-range   = 1*( %x21-2B / %x2D-7E )
                ; コンマを除く 1*(VCHAR)

ranges-specifier は、 示された range-unit に対して無効または未定義の range-spec を 一つでも含む場合、無効である。

有効な ranges-specifier は、示された range-unit によって定義される意味で 充足可能な range-spec を少なくとも 一つ含む場合、充足可能である。それ以外の場合、ranges-specifier は充足不能である。

"bytes" 範囲単位は、表現データのオクテット 列の部分範囲を表現するために使用される。各バイト範囲は、表現データの 先頭 (int-range) または 末尾 (suffix-range) を基準としたあるオフセットでの整数範囲として表現される。 バイト範囲は other-range 指定子を使用しない。

bytes int-range の first-pos 値は範囲の最初の バイトのオフセットを示す。last-pos 値は 範囲の最後のバイトのオフセットを示す。すなわち、指定されるバイト位置は 包含的である。バイトオフセットは 0 から始まる。

表現データに content coding が適用されている場合、各バイト範囲は、 復号後に得られる基盤となるバイト列ではなく、 エンコードされたバイト列に対して計算される。

• 最初の 500 バイト (バイトオフセット 0-499、両端を含む):

  bytes=0-499
  

• 2 番目の 500 バイト (バイトオフセット 500-999、両端を含む):

  bytes=500-999
  

クライアントは、選択された表現のサイズを知らなくても、要求するバイト数を制限できる。 last-pos 値が存在しない場合、または その値が表現データの現在の長さ以上の場合、バイト 範囲は表現の残りとして解釈される (すなわち、サーバーは last-pos の値を、 選択された表現の現在の長さより 1 小さい値に置き換える)。

クライアントは、suffix-range を使用して、 選択された表現の最後の N バイト (N > 0) を参照できる。選択された 表現が指定された suffix-length より短い場合、表現全体が使用される。

• 最後の 500 バイト (バイトオフセット 9500-9999、両端を含む):

  bytes=-500
  

  または:

  bytes=9500-
  

• 最初と最後のバイトだけ (バイト 0 と 9999):

  bytes=0-0,-1
  

• 最初、中間、最後の各 1000 バイト:

  bytes= 0-999, 4500-5499, -1000
  

• 2 番目の 500 バイト (バイトオフセット 500-999、両端を含む) のその他の有効な (ただし正規形ではない) 指定:

  bytes=500-600,601-999
  bytes=500-700,601-999
  

• first-pos が 選択された表現の現在の長さより小さい int-range、または
• 0 ではない suffix-length を持つ suffix-range。

選択された表現の長さが 0 の場合、GET リクエスト内の range-spec で 充足可能な形式は、0 ではない suffix-length を持つ suffix-range だけである。

バイト範囲構文では、first-pos、last-pos、および suffix-length は オクテット数の 10 進数として表現される。コンテンツ長に事前定義された上限がないため、 受信者は潜在的に大きな 10 進 数値を想定し、整数変換オーバーフローによる解析エラーを防がなければならない。

100 (Continue) ステータスコードは、リクエストの最初の部分を 受信し、サーバーによってまだ拒否されていないことを示す。サーバーは、 リクエストを完全に受信して処理した後、最終レスポンスを送信する意図がある。

リクエストに 100-continue 期待値を含む Expect ヘッダー フィールドが含まれる場合、100 レスポンスは、 10.1.1節 で説明されるように、サーバーが リクエストコンテンツの受信を望んでいることを示す。クライアントは、 リクエスト送信を続け、100 レスポンスを破棄するべきである。

リクエストが 100-continue 期待値を含む Expect ヘッダーフィールドを含んでいなかった場合、クライアントはこの暫定レスポンスを単に破棄できる。

101 (Switching Protocols) ステータスコードは、サーバーが、 この接続で使用されているアプリケーションプロトコルを変更するというクライアントの要求を Upgrade ヘッダーフィールド (7.8節) を介して理解し、 それに従う意思があることを示す。サーバーは、 このレスポンス後に有効となるプロトコルを示す Upgrade ヘッダーフィールドを レスポンス内に生成しなければならない。

サーバーは、そうすることが有利な場合にのみ プロトコル切り替えに同意すると仮定される。たとえば、古いバージョンより 新しいバージョンの HTTP へ切り替えることが有利な場合があり、 そのような機能を使用するリソースを配信する場合には、リアルタイムの同期プロトコルへ 切り替えることが有利な場合がある。

CONNECT へのレスポンスを除き、200 レスポンスは、 メッセージフレーミングがコンテンツ長 0 を明示的に示さない限り、メッセージ コンテンツを含むことが期待される。リクエストの何らかの側面が成功時にコンテンツなしを優先することを示している場合、 オリジンサーバーは代わりに 204 (No Content) レスポンスを送信するべきである。CONNECT では、 成功結果がトンネルであり、200 レスポンス ヘッダーセクションの直後に開始するため、コンテンツはない。

200 レスポンスはヒューリスティックにキャッシュ可能である。すなわち、 メソッド定義または明示的なキャッシュ制御によって別途示されない限りである ( [CACHING] の 4.2.2節 を参照)。

GET または HEAD への 200 レスポンスでは、オリジンサーバーは 選択された表現について利用可能な バリデーターフィールド (8.8節) を送信することが望ましく、 強い entity tag と Last-Modified 日時の両方が推奨される。

状態変更メソッドへの 200 レスポンスでは、レスポンスで送信される バリデーターフィールド (8.8節) は、 リクエストセマンティクスを正常に適用した結果として形成された新しい表現の 現在のバリデーターを伝える。PUT メソッド (9.3.4節) には、そのようなバリデーターの送信を 妨げる可能性のある追加要件があることに注意すること。

201 (Created) ステータスコードは、リクエストが満たされ、 一つ以上の新しいリソースが作成されたことを示す。リクエストによって作成された主要なリソースは、 レスポンスの Location ヘッダーフィールド、または Location ヘッダーフィールドを受信しなかった場合は ターゲット URI によって識別される。

201 レスポンスコンテンツは通常、作成されたリソースを記述し、 それらへのリンクを含む。レスポンスで送信されるバリデーターフィールド (8.8節 ) は、リクエストによって作成された新しい 表現の現在のバリデーターを伝える。PUT メソッド (9.3.4節) には、そのようなバリデーターの送信を 妨げる可能性のある追加要件があることに注意すること。

202 (Accepted) ステータスコードは、リクエストが 処理のために受理されたが、その処理が完了していないことを示す。リクエストは、 実際に処理されるときに許可されない可能性もあるため、最終的に実行される場合もされない場合もある。 HTTP には非同期操作からステータスコードを再送信する機能はない。

202 レスポンスは意図的に確約を行わない。その目的は、ユーザーエージェントの サーバーへの接続を処理完了まで維持する必要なく、 サーバーが他の何らかの処理 (たとえば 1 日 1 回だけ実行される バッチ指向処理) のためにリクエストを受理できるようにすることである。このレスポンスとともに送信される 表現は、リクエストの現在の状態を記述し、 リクエストがいつ満たされるかの見積もりをユーザーへ提供できる状態監視機構を指す (または埋め込む) べきである。

203 (Non-Authoritative Information) ステータスコードは、 リクエストは成功したが、含まれるコンテンツが変換 プロキシ (7.7節 ) によってオリジンサーバーの 200 (OK) レスポンスのものから変更されたことを示す。 このステータスコードにより、変換が適用されたときにプロキシが受信者へ通知できる。 その知識がコンテンツに関する後の判断へ影響する可能性があるためである。たとえば、 コンテンツに対する将来のキャッシュ検証リクエストは、 同じリクエストパス (同じプロキシ経由) にのみ適用可能な場合がある。

203 レスポンスはヒューリスティックにキャッシュ可能である。すなわち、 メソッド定義または明示的なキャッシュ制御によって別途示されない限りである ( [CACHING] の 4.2.2節 を参照)。

204 (No Content) ステータスコードは、サーバーがリクエストを正常に満たし、 レスポンスコンテンツとして送信する追加コンテンツがないことを示す。 レスポンスヘッダーフィールド内のメタデータは、要求されたアクションが適用された後の ターゲットリソースおよびその 選択された表現を参照する。

たとえば、PUT リクエストへのレスポンスとして 204 ステータスコードを受信し、 レスポンスが ETag フィールドを含む場合、PUT は成功しており、ETag フィールド値にはそのターゲットリソースの新しい 表現の entity tag が含まれる。

204 レスポンスにより、サーバーはアクションがターゲットリソースへ正常に 適用されたことを示しながら、ユーザーエージェントが現在の「文書ビュー」(存在する場合) から 移動する必要がないことを暗示できる。サーバーは、 ユーザーエージェントが自身のインターフェイスに従ってユーザーへ成功の何らかの表示を提供し、 レスポンス内の新しいまたは更新されたメタデータを アクティブな表現へ適用すると仮定する。

たとえば、204 ステータスコードは、 保存される文書をユーザーが引き続き編集できるようにする「保存」アクションに対応する 文書編集インターフェイスで一般的に使用される。また、 分散バージョン管理システム内など、自動化されたデータ転送が頻繁であると想定する インターフェイスでもよく使用される。

204 レスポンスはヘッダーセクションの終端で終了し、 コンテンツまたはトレーラーを含めることはできない。

204 レスポンスはヒューリスティックにキャッシュ可能である。すなわち、 メソッド定義または明示的なキャッシュ制御によって別途示されない限りである ( [CACHING] の 4.2.2節 を参照)。

205 (Reset Content) ステータスコードは、サーバーが リクエストを満たし、そのリクエストの送信原因となった「文書ビュー」を、 オリジンサーバーから受信した元の状態へリセットすることをユーザーエージェントに望んでいることを示す。

このレスポンスは、ユーザーが データ入力をサポートするコンテンツ (フォーム、メモ帳、キャンバスなど) を受信し、その空間でデータを入力または 操作し、入力したデータを リクエストで送信させ、その後、次の入力のためにデータ入力機構をリセットして、 ユーザーが別の入力アクションを容易に開始できるようにするという一般的なデータ入力ユースケースを支援することを意図している。

205 ステータスコードは追加コンテンツが提供されないことを意味するため、 サーバーは 205 レスポンスにコンテンツを生成してはならない。

206 (Partial Content) ステータスコードは、サーバーが 選択された表現の一つ以上の部分を転送することで、 ターゲットリソースへの範囲リクエストを正常に満たしていることを示す。

範囲リクエスト (14節) をサポートするサーバーは通常、 要求されたすべての範囲を満たそうとする。送信するデータが少ないと、 残りを求める別のクライアント リクエストが発生する可能性が高いためである。ただし、サーバーは、 一時的な利用不能、キャッシュ 効率、負荷分散など、自身の理由で要求されたデータの一部だけを送信したい場合がある。206 レスポンスは自己記述的であるため、 クライアントは範囲 リクエストを部分的にしか満たさないレスポンスでも理解できる。

クライアントは、どの部分が含まれているか、および追加のリクエストが必要かを判断するため、 206 レスポンスの Content-Type および Content-Range フィールドを調べなければならない。

206 レスポンスを生成するサーバーは、以下の小節で要求されるものに加えて、 同じリクエストへの 200 (OK) レスポンスでそのフィールドが送信されていた場合、次のヘッダーフィールドを生成しなければならない: Date、Cache-Control、ETag、Expires、Content-Location、および Vary。

206 レスポンスに存在する Content-Length ヘッダーフィールドは、この メッセージのコンテンツ内のオクテット数を示し、通常は選択された表現の完全な長さではない。 各 Content-Range ヘッダーフィールドには、 選択された表現の完全な長さに関する情報が含まれる。

If-Range ヘッダーフィールドを持つリクエストへの 206 レスポンスを生成する送信者は、 クライアントがすでにそれらのヘッダーフィールドを含む以前のレスポンスを持っているため、 要求されるものを超えるその他の表現ヘッダーフィールドを 生成しないことが望ましい。それ以外の場合、送信者は、 同じリクエストへの 200 (OK) レスポンスで送信される すべての表現ヘッダーフィールドを生成しなければならない。

206 レスポンスはヒューリスティックにキャッシュ可能である。すなわち、 明示的なキャッシュ制御によって別途示されない限りである ( [CACHING] の 4.2.2節 を参照)。

300 (Multiple Choices) ステータスコードは、ターゲットリソースが複数の表現を持ち、それぞれが独自の より具体的な識別子を持ち、ユーザー (またはユーザーエージェント) が リクエストをそれらの識別子の一つ以上へリダイレクトすることで優先表現を選択できるよう、 代替に関する情報が提供されていることを示す。言い換えると、 サーバーはユーザーエージェントが、自身の必要に最も適した表現を選択するため、 リアクティブネゴシエーションを行うことを望んでいる (12節)。

サーバーに優先される選択肢がある場合、サーバーは、 優先される選択肢の URI 参照を含む Location ヘッダーフィールドを 生成することが望ましい。ユーザーエージェントは 自動リダイレクトに Location フィールド値を使用してもよい。

HEAD 以外のリクエストメソッドについて、サーバーは、 ユーザーまたはユーザーエージェントが最も優先するものを選択できるよう、 表現メタデータおよび URI 参照のリストを含む コンテンツを 300 レスポンスに生成することが望ましい。ユーザーエージェントは、 提供されたメディアタイプを理解する場合、そのリストから自動的に選択してもよい。HTTP は 自身のコンテンツ定義と直交することを目指しているため、自動選択の具体的な形式は この仕様では定義されない。実際には、表現は、 共通設計またはコンテンツネゴシエーションによってユーザー エージェントに受け入れ可能と考えられる容易に解析可能な形式、または一般に 受け入れられているハイパーテキスト形式で提供される。

300 レスポンスはヒューリスティックにキャッシュ可能である。すなわち、 メソッド定義または明示的なキャッシュ制御によって別途示されない限りである ( [CACHING] の 4.2.2節 を参照)。

301 (Moved Permanently) ステータスコードは、ターゲットリソースに新しい恒久 URI が割り当てられており、 このリソースへの将来の参照は、含まれる URI のいずれかを使用するべきであることを示す。 サーバーは、リンク編集機能を持つユーザーエージェントが、 ターゲット URI への参照を、サーバーから送信された新しい参照のいずれかへ恒久的に置き換えられることを提案している。 ただし、この提案は通常、ユーザーエージェントが実際に 参照を編集しており (例: コンテンツのオーサリング中)、接続が安全化され、 オリジンサーバーが編集中のコンテンツについて信頼できる権威である場合を除き無視される。

サーバーは、新しい恒久 URI の優先される URI 参照を含む Location ヘッダーフィールドをレスポンスに生成することが望ましい。 ユーザーエージェントは自動リダイレクトに Location フィールド値を使用してもよい。サーバーのレスポンス コンテンツには通常、新しい URI へのハイパーリンクを持つ短いハイパーテキスト注記が含まれる。

301 レスポンスはヒューリスティックにキャッシュ可能である。すなわち、 メソッド定義または明示的なキャッシュ制御によって別途示されない限りである ( [CACHING] の 4.2.2節 を参照)。

302 (Found) ステータスコードは、ターゲットリソースが一時的に 別の URI の下に存在することを示す。リダイレクトは時折変更される可能性があるため、 クライアントは将来のリクエストでもターゲット URI を引き続き使用するべきである。

サーバーは、別の URI への URI 参照を含む Location ヘッダーフィールドをレスポンスに生成することが望ましい。 ユーザーエージェントは 自動リダイレクトに Location フィールド値を使用してもよい。サーバーのレスポンスコンテンツには、 通常、別の URI へのハイパーリンクを持つ短いハイパーテキスト注記が含まれる。

303 (See Other) ステータスコードは、サーバーが Location ヘッダーフィールド内の URI によって示される別のリソースへ ユーザーエージェントをリダイレクトしており、そのリソースが元のリクエストへの 間接的なレスポンスを提供することを意図していることを示す。ユーザーエージェントは その URI をターゲットとする取得リクエスト (HTTP を使用する場合は GET または HEAD リクエスト) を実行でき、 それもリダイレクトされる場合があり、最終的な結果を元の リクエストへの回答として提示できる。Location ヘッダーフィールド内の新しい URI は ターゲット URI と等価とはみなされないことに注意すること。

このステータスコードは任意の HTTP メソッドに適用できる。主に、 POST アクションの出力からユーザーエージェントを別のリソースへリダイレクトできるようにするため使用される。 そうすることで、POST レスポンスに対応する情報を、 個別に識別、ブックマーク、キャッシュ可能なリソースとして提供できるためである。

GET リクエストへの 303 レスポンスは、オリジンサーバーが HTTP 経由でサーバーから転送できる ターゲットリソースの 表現を持たないことを示す。ただし、Location フィールド値は、 ターゲットリソースを記述するリソースを参照しており、 その別のリソースに取得 リクエストを行うと、元のターゲットリソースを表すことを意味せずに、 受信者に有用な表現が得られる場合がある。何を表現できるか、 どの表現が適切か、何が有用な記述となり得るかという問題への答えは HTTP の範囲外であることに注意すること。

HEAD リクエストへのレスポンスを除き、303 レスポンスの表現には、 Location ヘッダーフィールドで提供されたのと同じ URI 参照への ハイパーリンクを持つ短いハイパーテキスト注記を含めるべきである。

304 (Not Modified) ステータスコードは、条件付き GET または HEAD リクエストを 受信し、条件が偽と評価されなければ 200 (OK) レスポンスになっていたことを示す。 言い換えると、条件付きリクエストを行ったクライアントは すでに有効な表現を持っていることをリクエストが示しているため、 サーバーがターゲットリソースの表現を転送する必要はない。 したがって、サーバーは、保存された 表現を 200 (OK) レスポンスのコンテンツであるかのように使用するようクライアントをリダイレクトしている。

• Content-Location、Date、ETag、および Vary
• Cache-Control および Expires ([CACHING] を参照)

304 レスポンスの目的は、受信者がすでに一つ以上のキャッシュ済み表現を持つ場合の 情報転送を最小化することであるため、送信者は、 そのメタデータがキャッシュ 更新を導く目的で存在する場合を除き、上記のフィールド以外の表現メタデータを生成しないことが望ましい (例: レスポンスに ETag フィールドがない場合、Last-Modified が 有用な場合がある)。

304 レスポンスを受信したキャッシュに対する要件は、 [CACHING] の 4.3.4節 で定義される。 条件付きリクエストが、自身のキャッシュを持つユーザーエージェントが共有プロキシへ 条件付き GET を送信する場合など、送信方向クライアントから発生した場合、 プロキシは 304 レスポンスをそのクライアントへ転送することが望ましい。

304 レスポンスはヘッダーセクションの終端で終了し、 コンテンツまたはトレーラーを含めることはできない。

305 (Use Proxy) ステータスコードは、この 仕様の以前のバージョンで定義され、現在は非推奨である ( [RFC7231] の付録 B)。

306 ステータスコードはこの仕様の以前のバージョンで定義されていたが、 現在は使用されておらず、このコードは予約されている。

307 (Temporary Redirect) ステータスコードは、ターゲットリソースが一時的に 別の URI の下に存在し、ユーザーエージェントがその URI へ自動リダイレクトする場合、 リクエストメソッドを変更してはならないことを示す。リダイレクトは 時間とともに変化する可能性があるため、クライアントは将来のリクエストでも元の ターゲット URI を引き続き使用するべきである。

サーバーは、別の URI への URI 参照を含む Location ヘッダーフィールドをレスポンスに生成することが望ましい。 ユーザーエージェントは 自動リダイレクトに Location フィールド値を使用してもよい。サーバーのレスポンスコンテンツには、 通常、別の URI へのハイパーリンクを持つ短いハイパーテキスト注記が含まれる。

308 (Permanent Redirect) ステータスコードは、ターゲットリソースに新しい 恒久 URI が割り当てられており、このリソースへの将来の参照は 含まれる URI のいずれかを使用するべきであることを示す。サーバーは、 リンク編集機能を持つユーザーエージェントが、ターゲット URI への参照を サーバーから送信された新しい参照のいずれかへ恒久的に置き換えられることを提案している。ただし、 この提案は通常、ユーザーエージェントが実際に参照を編集しており (例: コンテンツのオーサリング中)、接続が安全化され、 オリジンサーバーが編集中の コンテンツについて信頼できる権威である場合を除き無視される。

サーバーは、新しい恒久 URI の優先される URI 参照を含む Location ヘッダーフィールドをレスポンスに生成することが望ましい。 ユーザーエージェントは 自動リダイレクトに Location フィールド値を使用してもよい。サーバーのレスポンスコンテンツには、 通常、新しい URI へのハイパーリンクを持つ短いハイパーテキスト注記が含まれる。

308 レスポンスはヒューリスティックにキャッシュ可能である。すなわち、 メソッド定義または明示的なキャッシュ制御によって別途示されない限りである ( [CACHING] の 4.2.2節 を参照)。

400 (Bad Request) ステータスコードは、クライアントエラーとみなされる何らかの問題 (例: 不正なリクエスト構文、無効なリクエストメッセージフレーミング、 または欺瞞的なリクエストルーティング) のため、サーバーが リクエストを処理できない、または処理しないことを示す。

401 (Unauthorized) ステータスコードは、ターゲットリソースに対する有効な 認証資格情報がないためリクエストが適用されなかったことを示す。 401 レスポンスを生成するサーバーは、ターゲットリソースに適用可能な少なくとも一つのチャレンジを含む WWW-Authenticate ヘッダーフィールド (11.6.1節) を送信しなければならない。

リクエストが認証資格情報を含んでいた場合、401 レスポンスは、 それらの資格情報に対する認可が拒否されたことを示す。ユーザーエージェントは、 新しいまたは置換された Authorization ヘッダーフィールド (11.6.2節) とともにリクエストを繰り返してもよい。 401 レスポンスが以前のレスポンスと同じチャレンジを含み、 ユーザーエージェントがすでに少なくとも一度認証を試みている場合、 含まれる表現には通常関連する 診断情報が含まれるため、ユーザーエージェントはそれをユーザーへ提示することが望ましい。

402 (Payment Required) ステータスコードは将来の使用のために予約されている。

403 (Forbidden) ステータスコードは、サーバーがリクエストを理解したが 満たすことを拒否していることを示す。リクエストが 禁止された理由を公開したいサーバーは、その理由をレスポンスコンテンツ (存在する場合) で記述できる。

認証資格情報がリクエストで提供された場合、サーバーはそれらを アクセス許可には不十分とみなす。クライアントは、 同じ資格情報でリクエストを自動的に繰り返さないことが望ましい。クライアントは、 新しいまたは異なる資格情報でリクエストを繰り返してもよい。 ただし、リクエストは資格情報と無関係な理由で禁止されている場合もある。

禁止された ターゲットリソースの現在の存在を「隠したい」オリジンサーバーは、 代わりに 404 (Not Found) ステータスコードで応答してもよい。

404 (Not Found) ステータスコードは、オリジンサーバーが ターゲット リソースの現在の表現を見つけられなかったか、その存在を開示する意思がないことを示す。404 ステータスコードは、 この表現の欠如が一時的か恒久的かを示さない。 オリジンサーバーが、何らかの設定可能な手段などを通じて 状態が恒久的である可能性が高いと知っている場合は、404 より 410 (Gone) ステータスコードが推奨される。

404 レスポンスはヒューリスティックにキャッシュ可能である。すなわち、 メソッド定義または明示的なキャッシュ制御によって別途示されない限りである ( [CACHING] の 4.2.2節 を参照)。

405 (Method Not Allowed) ステータスコードは、 request-line で受信されたメソッドをオリジンサーバーは認識しているが、ターゲットリソースではサポートしていないことを示す。 オリジンサーバーは、ターゲットリソースが現在サポートするメソッドのリストを含む Allow ヘッダーフィールドを 405 レスポンスで生成しなければならない。

405 レスポンスはヒューリスティックにキャッシュ可能である。すなわち、 メソッド定義または明示的なキャッシュ制御によって別途示されない限りである ( [CACHING] の 4.2.2節 を参照)。

406 (Not Acceptable) ステータスコードは、リクエストで受信した プロアクティブネゴシエーションヘッダー フィールド (12.1節) に従って、 ターゲットリソースにユーザーエージェントが受け入れ可能な現在の表現がなく、 サーバーがデフォルト表現の提供を望んでいないことを示す。

サーバーは、ユーザーまたはユーザーエージェントが最も適切なものを選択できる、 利用可能な表現の特性および対応するリソース識別子のリストを含む コンテンツを生成することが望ましい。ユーザーエージェントは、 そのリストから最も適切な選択肢を自動的に選択してもよい。 ただし、この仕様はそのような 自動選択の標準を定義していない。15.4.1節 で説明されるとおりである。

407 (Proxy Authentication Required) ステータスコードは 401 (Unauthorized) に似ているが、 このリクエストでプロキシを使用するにはクライアントが自身を認証する必要があることを示す。 プロキシは、そのリクエストについてそのプロキシに適用可能なチャレンジを含む Proxy-Authenticate ヘッダーフィールド (11.7.1節) を送信しなければならない。 クライアントは、新しいまたは置換された Proxy-Authorization ヘッダーフィールド (11.7.2節) とともにリクエストを繰り返してもよい。

408 (Request Timeout) ステータスコードは、サーバーが 待機する用意のある時間内に完全なリクエストメッセージを受信しなかったことを示す。

クライアントに転送中の未完了リクエストがある場合、そのリクエストを 繰り返してもよい。現在の接続が利用不能な場合 (例: リクエスト区切りが失われる HTTP/1.1 の場合)、新しい接続が使用される。

409 (Conflict) ステータスコードは、ターゲットリソースの現在の状態との 競合のためリクエストを完了できなかったことを示す。このコードは、 ユーザーが競合を解決してリクエストを再送信できる可能性がある状況で使用される。 サーバーは、ユーザーが競合の原因を認識するのに十分な情報を含む コンテンツを生成することが望ましい。

競合は PUT リクエストへのレスポンスで最も発生しやすい。たとえば、 バージョニングが使用され、PUT される表現が、 以前の (第三者による) リクエストによる変更と競合するリソースへの変更を含む場合、 オリジンサーバーはリクエストを完了できないことを示すため 409 レスポンスを使用する場合がある。この場合、レスポンス表現には、 リビジョン履歴に基づいて差分をマージするのに有用な情報が含まれる可能性が高い。

410 (Gone) ステータスコードは、ターゲットリソースへのアクセスがオリジンサーバーで利用できなくなり、 この状態が恒久的である可能性が高いことを示す。オリジンサーバーが、 状態が恒久的かどうかを知らない、または判断する手段を持たない場合、 代わりにステータスコード 404 (Not Found) を使用するべきである。

410 レスポンスは主に、リソースが意図的に利用不能であり、 サーバー所有者がそのリソースへのリモートリンクを削除してほしいことを 受信者へ通知することで、Web 保守作業を支援することを意図している。そのような事象は、 期間限定の販促サービスや、 オリジンサーバーのサイトと関係しなくなった個人に属するリソースでよく発生する。 恒久的に利用不能なすべてのリソースを "gone" としてマークしたり、そのマークを任意の 期間維持したりする必要はなく、それはサーバー所有者の判断に委ねられる。

410 レスポンスはヒューリスティックにキャッシュ可能である。すなわち、 メソッド定義または明示的なキャッシュ制御によって別途示されない限りである ( [CACHING] の 4.2.2節 を参照)。

411 (Length Required) ステータスコードは、定義された Content-Length (8.6節) なしでは サーバーがリクエストを受け入れることを拒否していることを示す。 クライアントは、リクエストコンテンツの長さを含む有効な Content-Length ヘッダーフィールドを追加する場合、リクエストを繰り返してもよい。

412 (Precondition Failed) ステータスコードは、リクエストヘッダーフィールドで与えられた 一つ以上の条件が、サーバーでテストされた際に偽と評価されたことを示す (13節)。 このレスポンスステータスコードにより、クライアントは現在の リソース状態 (現在の表現およびメタデータ) に事前条件を課し、その結果、 ターゲットリソースが予期しない状態にある場合にリクエストメソッドが適用されるのを防ぐことができる。

413 (Content Too Large) ステータスコードは、 リクエストコンテンツがサーバーが処理する意思または能力のあるサイズより大きいため、 サーバーがリクエストの処理を拒否していることを示す。使用中のプロトコルバージョンが許可する場合、サーバーは リクエストを終了してもよく、それ以外の場合、サーバーは 接続を閉じてもよい。

状態が一時的である場合、サーバーは、それが一時的であることと、 クライアントがいつ再試行してもよいかを示すため、Retry-After ヘッダーフィールドを生成することが望ましい。

414 (URI Too Long) ステータスコードは、ターゲット URI が サーバーが解釈する意思のある長さより長いため、サーバーがリクエストへのサービス提供を拒否していることを示す。 このまれな状態は、クライアントが長い query 情報を持つ POST リクエストを 不適切に GET リクエストへ変換した場合、クライアントが 無限のリダイレクトループ (例: 自身の接尾部を指すリダイレクト URI 接頭辞) に陥った場合、または潜在的なセキュリティホールを悪用しようとする クライアントによる攻撃をサーバーが受けている場合にのみ発生する可能性が高い。

414 レスポンスはヒューリスティックにキャッシュ可能である。すなわち、 メソッド定義または明示的なキャッシュ制御によって別途示されない限りである ( [CACHING] の 4.2.2節 を参照)。

415 (Unsupported Media Type) ステータスコードは、コンテンツが ターゲットリソースに対するこのメソッドでサポートされない形式であるため、 オリジンサーバーがリクエストへのサービス提供を拒否していることを示す。

形式の問題は、リクエストで示された Content-Type または Content-Encoding に起因する場合も、 データを直接調べた結果である場合もある。

問題がサポートされていない content coding によって生じた場合、 Accept-Encoding レスポンスヘッダー フィールド (12.5.3節) を使用して、 リクエストでどの content coding が受け入れられたか (ある場合) を示すべきである。

一方、原因がサポートされていないメディアタイプである場合、 Accept レスポンスヘッダーフィールド (12.5.1節 ) を使用して、リクエストでどのメディアタイプが受け入れられたかを示すことができる。

416 (Range Not Satisfiable) ステータスコードは、リクエストの Range ヘッダーフィールド (14.2節) 内の範囲集合が、要求された範囲のどれも充足可能でないため、 またはクライアントが過剰な数の小さなもしくは重複する範囲 (潜在的なサービス拒否攻撃) を要求したため拒否されたことを示す。

各範囲単位は、自身の範囲集合が充足可能となるために必要な条件を定義する。 たとえば、14.1.2節 は、 bytes 範囲集合を充足可能にする条件を定義する。

バイト範囲リクエストへの 416 レスポンスを生成するサーバーは、 選択された表現の現在の長さを指定する Content-Range ヘッダーフィールド (14.4節) を生成することが望ましい。

HTTP/1.1 416 Range Not Satisfiable
Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022

417 (Expectation Failed) ステータスコードは、リクエストの Expect ヘッダーフィールド (10.1.1節 ) で与えられた期待を、少なくとも一つの受信方向サーバーが満たせなかったことを示す。

[RFC2324] は、HTTP が悪用されていたさまざまな方法を風刺した 4 月 1 日の RFC であった。 その悪用の一つはアプリケーション固有の 418 ステータスコードの定義であり、 冗談として十分に広く配備されたため、このコードは将来の用途には使用不能になった。

したがって、418 ステータスコードは IANA HTTP Status Code Registry で予約されている。 これは、このステータスコードを現在 他のアプリケーションへ割り当てられないことを示す。将来の状況で使用が必要になった場合 (例: 4NN ステータス コードの枯渇)、別の用途へ再割り当てできる。

421 (Misdirected Request) ステータスコードは、ターゲット URI に対する 権威あるレスポンスを生成できない、または生成する意思のないサーバーへリクエストが向けられたことを示す。 オリジンサーバー (またはオリジンサーバーの代理として動作するゲートウェイ) は、 サーバーが設定されている オリジン (4.3.1節) と一致しない、 またはリクエストを受信した接続コンテキスト (7.4節) と一致しないターゲット URI を拒否するため 421 を送信する。

421 (Misdirected Request) レスポンスを受信したクライアントは、 リクエストメソッドがべき等かどうかにかかわらず、 ターゲットリソースのオリジン専用の新しい接続などの別の接続、 または代替サービス [ALTSVC] を介してリクエストを再試行してもよい。

プロキシは 421 レスポンスを生成してはならない。

422 (Unprocessable Content) ステータスコードは、サーバーが リクエストコンテンツのコンテンツタイプを理解しており (したがって 415 (Unsupported Media Type) ステータスコードは不適切)、かつ リクエストコンテンツの構文は正しいが、含まれる 命令を処理できなかったことを示す。たとえば、XML リクエストコンテンツが 整形式 (すなわち構文的に正しい) だが、セマンティクス上誤った XML 命令を含む場合、このステータスコードを送信できる。

426 (Upgrade Required) ステータスコードは、サーバーが現在の プロトコルを使用したリクエストの実行を拒否するが、クライアントが別のプロトコルへ アップグレードした後であれば実行する意思がある可能性を示す。サーバーは、 必要なプロトコルを示すため、426 レスポンスに Upgrade ヘッダーフィールドを 送信しなければならない (7.8節)。

HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain

このサービスでは HTTP/3.0 プロトコルの使用が必要です。

500 (Internal Server Error) ステータスコードは、サーバーが リクエストを満たすことを妨げる予期しない状態に遭遇したことを示す。

501 (Not Implemented) ステータスコードは、サーバーが リクエストを満たすために必要な機能をサポートしていないことを示す。これは、 サーバーがリクエストメソッドを認識せず、 いかなるリソースについてもそれをサポートできない場合の適切なレスポンスである。

501 レスポンスはヒューリスティックにキャッシュ可能である。すなわち、 メソッド定義または明示的なキャッシュ制御によって別途示されない限りである ( [CACHING] の 4.2.2節 を参照)。

502 (Bad Gateway) ステータスコードは、ゲートウェイまたは プロキシとして動作しているサーバーが、リクエストを満たそうとしてアクセスした 受信方向サーバーから無効なレスポンスを受信したことを示す。

503 (Service Unavailable) ステータスコードは、一時的な過負荷または予定された保守のため、 サーバーが現在 リクエストを処理できず、ある程度の遅延後には解消される可能性が高いことを示す。サーバーは、 クライアントがリクエストを再試行するまで待つ適切な時間を提案するため、 Retry-After ヘッダーフィールド (10.2.3節) を送信してもよい。

504 (Gateway Timeout) ステータスコードは、ゲートウェイまたは プロキシとして動作しているサーバーが、リクエストを完了するためにアクセスする必要のあった 上流サーバーから適時のレスポンスを受信しなかったことを示す。

505 (HTTP Version Not Supported) ステータスコードは、サーバーが リクエストメッセージで使用された HTTP のメジャーバージョンを サポートしていない、またはサポートすることを拒否していることを示す。サーバーは、2.5節 で説明されるように、 このエラーメッセージ以外では、クライアントと同じメジャーバージョンを使用して リクエストを完了できない、または完了する意思がないことを示している。サーバーは、 そのバージョンがサポートされない理由と、そのサーバーがサポートする他のプロトコルを記述する 表現を 505 レスポンスに生成することが望ましい。

IANA が https://www.iana.org/assignments/http-methods で管理する "Hypertext Transfer Protocol (HTTP) Method Registry" は、 method 名を登録する。

• メソッド名 (9節を参照)
• 安全 ("yes" または "no"、9.2.1節 を参照)
• べき等 ("yes" または "no"、9.2.2節を参照)
• 仕様本文への参照

この名前空間に追加する値には IETF Review が必要である ([RFC8126], 4.8節を参照)。

標準化されたメソッドは汎用的である。すなわち、特定の 一つのメディアタイプ、リソースの種類、またはアプリケーションだけでなく、任意の リソースに適用できる可能性がある。そのため、直交する技術には 直交する仕様がふさわしいので、新しいメソッドは単一のアプリケーションまたはデータ形式に 固有ではない文書で登録することが望ましい。

メッセージ解析 (6節) は、HEAD へのレスポンスを除きメソッド セマンティクスから独立している必要があるため、新しいメソッドの定義は 解析アルゴリズムを変更したり、リクエストまたは レスポンスメッセージでコンテンツの存在を禁止したりできない。新しいメソッドの定義は、 値 "0" の Content-Length ヘッダーフィールドを要求することで、長さ 0 の コンテンツだけが許可されると規定できる。

同様に、新しいメソッドは、それぞれ CONNECT および OPTIONS で許可されている特別な host:port およびアスタリスク形式の リクエストターゲットを使用できない (7.1節)。ターゲット URI には絶対 形式の完全な URI が必要であり、これはリクエストターゲットを 絶対形式で送信するか、他のメソッドと同じ方法でリクエスト コンテキストからターゲット URI を再構成する必要があることを意味する。

新しいメソッドの定義は、それが安全か (9.2.1節)、べき等か (9.2.2節)、 キャッシュ可能か (9.2.3節 )、リクエストコンテンツ (存在する場合) にどのようなセマンティクスを関連付けるか、 およびメソッドがヘッダーフィールドまたはステータスコードの セマンティクスへどのような限定を加えるかを示す必要がある。新しいメソッドがキャッシュ可能な場合、その定義は、 キャッシュがどのように、またどの条件下でレスポンスを保存し、 後続リクエストを満たすために使用できるかを記述するべきである。新しいメソッドは、 条件付きにできるか (13.1節)、また できる場合、条件が偽のときサーバーがどのように応答するかを記述するべきである。同様に、新しい メソッドが部分レスポンスセマンティクス (14.2節) を利用する可能性がある場合、 それについても文書化するべきである。

IANA が管理する "Hypertext Transfer Protocol (HTTP) Status Code Registry" は https://www.iana.org/assignments/http-status-codes で ステータスコード番号を登録する。

• ステータスコード (3 桁)
• 短い説明
• 仕様本文への参照

HTTP ステータスコード名前空間へ追加する値には IETF Review が必要である ([RFC8126], 4.8節を参照)。

現在のステータスコードで定義されていないレスポンスのセマンティクスを表現する必要がある場合、 新しいステータスコードを登録できる。ステータスコードは汎用的であり、 特定の一つのメディアタイプ、 リソースの種類、または HTTP のアプリケーションだけでなく、任意のリソースに適用できる可能性がある。そのため、新しいステータス コードは単一のアプリケーションに固有ではない文書で登録することが望ましい。

新しいステータスコードは、15節 で定義されるカテゴリのいずれかに属する必要がある。既存の パーサーがレスポンスメッセージを処理できるよう、新しいステータスコードはコンテンツを禁止できないが、 長さ 0 のコンテンツを義務付けることはできる。

まだ広く配備されていない新しいステータスコードの提案では、 登録されるという明確な合意が得られるまでは、 コードに特定の番号を割り当てないことが望ましい。その代わり、初期ドラフトでは "4NN" や "3N0" .. "3N9" のような表記を使用して、番号を 時期尚早に消費することなく提案されたステータスコードのクラスを示すことができる。

新しいステータスコードの定義は、そのステータスコードを含む レスポンスを引き起こすリクエスト条件 (例: リクエスト ヘッダーフィールドやメソッドの組み合わせ) と、レスポンスヘッダー フィールドへの依存関係 (例: どのフィールドが必須か、どのフィールドがセマンティクスを変更できるか、および 新しいステータスコードとともに使用した際にどのフィールドセマンティクスがさらに限定されるか) を説明するべきである。

デフォルトでは、ステータスコードは、そのコードが含まれるレスポンスに対応するリクエストにのみ適用される。 ステータスコードがより広い適用範囲 — たとえば、対象リソースへのすべてのリクエストやサーバーへのすべてのリクエスト — に適用される場合、 それを明示的に規定しなければならない。その際、新しいステータスコードを理解しない可能性があるため、 すべてのクライアントがより広い範囲を 一貫して適用できるとは限らないことに注意するべきである。

新しい最終ステータスコードの定義は、それが ヒューリスティックにキャッシュ可能かどうかを規定するべきである。最終ステータスコードを持つ任意のレスポンスは、 明示的な鮮度情報を持つ場合にキャッシュできることに注意すること。 ヒューリスティックにキャッシュ可能と定義されたステータスコードは、明示的な鮮度 情報なしでもキャッシュすることが許可される。同様に、must-understand キャッシュディレクティブが使用される場合、 ステータスコードの定義はキャッシュ動作へ制約を課すことができる。詳細については [CACHING] を参照。

最後に、新しいステータスコードの定義は、コンテンツが 識別されたリソースと何らかの暗黙の関連を持つかどうかを示すべきである (6.4.2節)。

"Hypertext Transfer Protocol (HTTP) Field Name Registry" は、HTTP フィールド名の 名前空間を定義する。

任意の当事者が HTTP フィールドの登録を要求できる。新しい HTTP フィールドを作成する際に 考慮すべき事項については、16.3.2節 を参照。

"Hypertext Transfer Protocol (HTTP) Field Name Registry" は https://www.iana.org/assignments/http-fields/ にある。 登録要求は、そこに記載された手順に従うか、 "ietf-http-wg@w3.org" メーリングリストへメールを送信して行える。

フィールド名は、指定専門家 (IESG またはその代理者によって任命) の助言に基づいて登録される。 ステータスが 'permanent' のフィールドには Specification Required が適用される ([RFC8126], 4.6節)。

フィールド名:

要求するフィールド名。5.1節 で定義される field-name 構文に適合しなければならず、 最初の文字を英字とし、英字、 数字、およびハイフン ('-') 文字だけに制限することが望ましい。

ステータス:

"permanent"、"provisional"、"deprecated"、または "obsoleted"。

仕様文書:

フィールドを規定する文書への参照。文書のコピーを取得するために使用できる URI を 含むことが望ましい。暫定登録では任意だが推奨される。 関連する節を示すこともできるが、必須ではない。

コメント:

予約済みエントリーに関する情報などの追加情報。

専門家は、コミュニティと協議して、レジストリで収集する追加フィールドを定義できる。

標準で定義された名前は "permanent" ステータスを持つ。その他の名前も、 専門家がコミュニティと協議し、それらが使用中であると判断した場合、permanent として 登録できる。その他の名前は "provisional" として登録するべきである。

暫定エントリーは、専門家がコミュニティと協議して 使用されていないと判断した場合、専門家によって削除できる。専門家は、 暫定エントリーのステータスをいつでも permanent に変更できる。

未登録の名前が広く配備されており、それ以外では 適時に登録される可能性が低いと専門家が判断した場合、第三者 (専門家自身を含む) が名前を登録できることに注意すること。

HTTP ヘッダーおよびトレーラーフィールドは、プロトコルで広く使用される拡張ポイントである。 アドホックに使用することもできるが、より広範な使用を意図したフィールドは、 相互運用性を確保するため慎重に文書化する必要がある。

• どの条件でフィールドを使用できるか。例: レスポンスまたは リクエストだけ、すべてのメッセージ、特定のリクエストメソッドへのレスポンスだけ、 など。
• 特定のリクエストメソッドやステータスコードでの使用など、 コンテキストによってフィールドセマンティクスがさらに限定されるか。
• 伝達される情報の適用範囲。デフォルトでは、フィールドは 関連付けられたメッセージだけに適用されるが、一部のレスポンスフィールドは、 リソースのすべての表現、リソース自体、または さらに広い範囲に適用されるよう設計される。レスポンスフィールドの範囲を拡大する仕様は、 コンテンツネゴシエーション、適用期間、 および (場合によっては) マルチテナントサーバー配備などの問題を慎重に検討する必要がある。
• どの条件で仲介者がフィールド値を挿入、削除、または変更できるか。
• フィールドがトレーラーで許可されるか。デフォルトでは許可されない (6.5.1節 を参照)。
• フィールド名を Connection ヘッダーフィールドへ列挙することが適切か、または必須であるか (すなわち、フィールドが hop-by-hop である場合。7.6.1節を参照)。
• フィールドが、プライバシー関連データの開示など、 追加のセキュリティ上の考慮事項を導入するか。

• フィールド名を Vary レスポンスヘッダーフィールドへ列挙することが適切か (例: リクエストヘッダー フィールドがオリジンサーバーのコンテンツ選択アルゴリズムで使用される場合。12.5.5節 を参照)。
• PUT リクエストで受信された際にフィールドを保存することを意図しているか (9.3.4節を参照)。
• セキュリティ上の懸念によりリクエストを自動リダイレクトする際に フィールドを削除するべきか (15.4節を参照)。

"Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" は、 チャレンジおよび資格情報内の認証スキームの名前空間を定義する。これは https://www.iana.org/assignments/http-authschemes で管理される。

• 認証スキーム名
• 仕様本文への参照
• 注記 (任意)

この名前空間に追加する値には IETF Review が必要である ([RFC8126], 4.8節を参照)。

• HTTP 認証はステートレスであると想定される。リクエストを認証するために 必要なすべての情報は、サーバーが以前のリクエストを 記憶していることへ依存するのではなく、リクエスト内で提供されなければならない。 基盤となる接続に基づく、または接続へ束縛された認証はこの仕様の範囲外であり、 認証されたユーザー以外のいかなる当事者も接続を使用できないよう保証する措置を 講じない限り、本質的に欠陥がある (3.3節を参照)。

• 認証パラメーター "realm" は、11.5節 で説明される保護 空間の定義のために予約されている。新しいスキームは、その定義と互換性のない 方法で使用してはならない。

• "token68" 表記は既存の 認証スキームとの互換性のために導入され、チャレンジまたは 資格情報ごとに一度しか使用できない。したがって、新しいスキームは、 そうしなければ将来の拡張が不可能になるため、代わりに auth-param 構文を使用するべきである。

• チャレンジおよび資格情報の解析はこの 仕様によって定義され、新しい認証スキームによって変更できない。 auth-param 構文を使用する場合、すべてのパラメーターは token と quoted-string の両方の構文をサポートするべきであり、構文上の制約は 解析後のフィールド値 (すなわち quoted-string 処理後) に対して定義するべきである。これは、受信者がすべての 認証スキームに適用可能な汎用パーサーを使用できるようにするため必要である。

  注: "realm" パラメーターの値構文を quoted-string に制限したことは悪い設計上の選択であり、新しい パラメーターで繰り返すべきではない。

• 新しいスキームの定義は、未知の 拡張パラメーターの扱いを定義するべきである。一般に、"must-understand" 規則より "must-ignore" 規則が望ましい。そうでなければ、古い受信者が存在する状況で 新しいパラメーターを導入することが困難になるためである。さらに、新しいパラメーターを 定義する方針 ("仕様を更新する" や "このレジストリを使用する" など) を記述するとよい。

• 認証スキームは、 オリジンサーバー認証 (すなわち WWW-Authenticate を使用)、 および/またはプロキシ認証 (すなわち Proxy-Authenticate を使用) で使用可能かどうかを文書化する必要がある。

• Authorization ヘッダーフィールドで運ばれる資格情報はユーザー エージェントに固有であり、そのため、それらが現れるリクエストの範囲内で、 "private" キャッシュレスポンスディレクティブ ( [CACHING] の 5.2.2.7節) と同じ効果を HTTP キャッシュに対して持つ。

  したがって、資格情報を Authorization ヘッダーフィールドで運ばないことを選択する 新しい認証スキーム (例: 新しく 定義されたヘッダーフィールドを使用) は、キャッシュレスポンスディレクティブ (例: "private") の使用を義務付けることで、キャッシュを明示的に禁止する必要がある。

• Authentication-Info、Proxy-Authentication-Info、またはその他の 認証関連レスポンスヘッダーフィールドを使用するスキームは、 関連するセキュリティ上の考慮事項を検討し、 文書化する必要がある (17.16.4節を参照)。

"HTTP Range Unit Registry" は範囲単位名の名前空間を定義し、 対応する仕様を参照する。これは https://www.iana.org/assignments/http-parameters で管理される。

• 名前
• 説明
• 仕様本文への参照

この名前空間に追加する値には IETF Review が必要である ([RFC8126], 4.8節を参照)。

ページ、節、レコード、行、時間などの形式固有境界のような他の範囲単位も、 アプリケーション固有の目的で HTTP で使用できる可能性があるが、 実際には一般的に使用されていない。代替範囲単位の実装者は、 content coding や汎用 仲介者とどのように動作するかを検討するべきである。

IANA が https://www.iana.org/assignments/http-parameters/ で管理する "HTTP Content Coding Registry" は、 content-coding 名を登録する。

• 名前
• 説明
• 仕様本文への参照

コンテンツコーディング名は、エンコーディング変換が同一の場合 (8.4.1節 で定義される圧縮 コーディングの場合のように) を除き、転送コーディング名 ("HTTP Transfer Coding Registry"、https://www.iana.org/assignments/http-parameters/ に所在) と重複してはならない。

この名前空間に追加する値には IETF Review が必要であり ( [RFC8126] の 4.8節)、 8.4.1節 で定義される content coding の目的に適合しなければならない。

新しい content coding は、可能な限り自己記述的であるべきであり、 任意パラメーターは、転送中に失われる可能性のある 外部メタデータに依存するのではなく、コーディング形式自体の中で発見できるようにするべきである。

HTTP 認証フレームワークは、資格情報の 機密性を維持する単一の機構を定義しない。代わりに、各認証スキームが 送信前に資格情報をどのようにエンコードするかを定義する。これは将来の 認証スキーム開発に柔軟性を提供する一方、自身では機密性を提供しない、 またはリプレイ攻撃に対して十分に保護しない既存スキームの 保護には不十分である。さらに、サーバーが 個々のユーザーそれぞれに固有の資格情報を期待する場合、その資格情報の交換は、 資格情報内のコンテンツが機密のままであっても、そのユーザーを識別する効果を持つ。

HTTP は、フィールドの機密送信を提供するため、 基盤となるトランスポートレベルまたはセッションレベル 接続のセキュリティ特性に依存する。個々のユーザー認証に依存するサービスは、 資格情報を交換する前に 安全化された接続を必要とする (4.2.2節)。

既存の HTTP クライアントおよびユーザーエージェントは通常、認証情報を 無期限に保持する。HTTP は、オリジンサーバーが クライアントにこれらのキャッシュ済み資格情報を破棄するよう指示する機構を提供しない。 プロトコルは、ユーザーエージェントが資格情報をどのように取得または管理するかを認識しないためである。 資格情報を期限切れまたは失効させる機構は、認証 スキーム定義の一部として規定できる。

• 長期間アイドル状態であったクライアント。その後サーバーは、 クライアントに資格情報をユーザーへ再度求めさせたい場合がある。
• セッション終了の表示 (ページ上の "logout" または "commit" ボタンなど) を含むアプリケーション。その後、アプリケーションのサーバー側は、 クライアントが資格情報を保持するさらなる理由がないことを 「知っている」。

資格情報をキャッシュするユーザーエージェントには、ユーザーの制御下で キャッシュ済み資格情報を破棄するための容易にアクセス可能な機構を提供することが推奨される。

保護空間の確立に "realm" 機構だけへ依存する 認証スキームは、オリジンサーバー上のすべてのリソースへ資格情報を公開する。 あるリソースに対して認証済みリクエストを正常に行ったクライアントは、 同じオリジンサーバー上の他のリソースにも同じ認証資格情報を使用できる。 これにより、別のリソースが他のリソース用の認証 資格情報を収集することが可能になる。

これは、オリジンサーバーが同じオリジンの下で複数の 当事者向けリソースをホストする場合に特に懸念される (11.5節)。考えられる 緩和策には、認証 資格情報への直接アクセスを制限すること (すなわち、Authorization リクエストヘッダーフィールドの内容を利用可能にしないこと)、 および各当事者に異なるホスト名 (またはポート番号) を使用して 保護空間を分離することが含まれる。

暗号化されていない通信路で送信されるレスポンスへ情報を追加すると、 セキュリティおよびプライバシーに影響する可能性がある。Authentication-Info および Proxy-Authentication-Info ヘッダーフィールドが存在するだけで、 HTTP 認証が使用中であることを示す。認証スキーム固有パラメーターの内容によって 追加情報が公開される可能性があるため、これは それらのスキーム定義で検討する必要がある。