HTTP セマンティクス

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

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

"http" URI のオリジンサーバーは authority 成分によって識別されます。authority にはホスト識別子（[URI], セクション 3.2.2）と任意のポート番号（[URI], セクション 3.2.3）が含まれます。ポートサブコンポーネントが空であるか与えられていない場合、TCP ポート 80（WWW サービスの予約ポート）がデフォルトになります。オリジンは、識別されたリソースをターゲットにするリクエストに対して権威を持って応答する権利を誰が有するかを決定します（セクション 4.3.2）。

送信者は空のホスト識別子を持つ "http" URI を生成してはなりません（MUST NOT）。そのような URI 参照を処理する受信者は、それを無効として拒否しなければなりません（MUST）。

階層的なパス成分と任意のクエリ成分が、そのオリジンサーバーの名前空間内でのターゲットリソースを特定します。

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

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

"https" URI のオリジンサーバーは authority 成分によって識別され、そこにはホスト識別子（[URI], セクション 3.2.2）と任意のポート番号（[URI], セクション 3.2.3）が含まれます。ポートサブコンポーネントが空であるか与えられていない場合、TCP ポート 443（TLS 上の HTTP の予約ポート）がデフォルトになります。オリジンは、識別されたリソースをターゲットにするリクエストに対して権威を持って応答する権利を誰が有するかを決定します（セクション 4.3.3）。

送信者は空のホスト識別子を持つ "https" URI を生成してはなりません（MUST NOT）。そのような URI 参照を処理する受信者は、それを無効として拒否しなければなりません（MUST）。

階層的なパス成分と任意のクエリ成分が、そのオリジンサーバーの名前空間内でのターゲットリソースを特定します。

クライアントは "https" リソースへの HTTP リクエストを送信する前に、それらが保護されていることを MUST 確認し、かつそのリクエストに対して返される応答も保護されたものであることのみ受け入れなければなりません。どの暗号化手段がクライアントとサーバーにとって受け入れ可能かの定義は通常ネゴシエートされ、時間とともに変化する可能性があることに注意してください。

"https" スキームで提供されるリソースは "http" スキームと共有の同一性を持ちません。これらは別個の名前空間を持つ別個のオリジンです。ただし、同じホストに対して適用される拡張（例えば Cookie プロトコル [COOKIE]）のように、あるサービスで設定された情報がホストドメインの一致するグループ内の他のサービスとの通信に影響を与えることを許すものもあります。そのような拡張は、保護された接続から得られた情報が意図せず保護されていない文脈で交換されるのを防ぐために慎重に設計されるべきです。

"http" または "https" スキームの URI は、セクション 6 の方法に従って正規化および比較されます。上記の各スキームに対するデフォルト値を使用します（[URI]）。

HTTP は同値性を決定するための特定の方法の使用を要求しません。例えば、キャッシュキーは構文ベースの正規化後に単純な文字列として比較されるかもしれませんし、スキームベースの正規化後に比較されるかもしれません。

• ポートがスキームのデフォルトポートと等しい場合、正規形ではポートのサブコンポーネントを省略します。
• OPTIONS リクエストのターゲットとして使用されていない場合、空のパス成分は "/" の絶対パスと同等であるため、正規形では "/" のパスを提供するのが通常です。
• スキームとホストは大文字小文字を区別せず、通常は小文字で提供されます；その他のすべての成分は大文字小文字を区別して比較されます。
• "reserved" セットに含まれない文字はパーセントエンコードされたオクテットと同等です：正規形ではそれらをエンコードしないことが通常です（詳細は セクション 2.1 および セクション 2.2 を参照してください）。

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

正規化後に同等である 2 つの HTTP URI は同じリソースを識別すると見なすことができ、任意の HTTP コンポーネントは正規化を行うことが できる（MAY）。その結果、正規化後に（任意の方法で）同等となる HTTP URI によって異なるリソースが識別されるべきではありません（SHOULD NOT）。

authority の URI 汎用構文には userinfo サブコンポーネント（[URI], セクション 3.2.1）が含まれ、URI にユーザー認証情報を含めることができます。そのサブコンポーネントにおける "user:password" 形式の使用は非推奨です。

一部の実装はコマンド起動オプション、設定ファイル、ブックマークリストなど、内部設定のために userinfo コンポーネントを利用することがあり、そのような使用はユーザー識別子やパスワードを露出する可能性があります。

送信者はメッセージ内でターゲット URI またはフィールド値として "http" または "https" の URI 参照を生成する際に userinfo サブコンポーネント（および "@" 区切り文字）を生成してはなりません（MUST NOT）。

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

フラグメント識別子は、セクション 3.5 に定義されるように、スキームに依存しない二次リソースの間接的識別を可能にします（[URI]）。 URI を参照する一部のプロトコル要素はフラグメントの包含を許可し、他のものは許可しません。これらはフラグメントを許可する要素の ABNF ルールの使用によって区別されます；そうでない場合はフラグメントを除外する特定のルールが使用されます。

与えられた URI の オリジン は、スキーム、ホスト、ポートの 3 つ組であり、スキームとホストは小文字に正規化され、ポートは先頭のゼロを取り除いて正規化されます。URI からポートが省略されている場合、そのスキームのデフォルトポートが使用されます。例えば、次の URI は

   https://Example.Com/happy.js

次のオリジンを持ちます

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

   https://example.com:443

各オリジンは独自の名前空間を定義し、その名前空間内の識別子がリソースにどのようにマップされるかをコントロールします。さらに、オリジンが有効なリクエストに対して一貫して応答する方法が、将来的にユーザーが URI に関連付けるセマンティクスを決定し、それらセマンティクスの有用性が最終的にユーザーが参照・アクセスするための資源へと変換されます。

オリジンはスキーム、ホスト、またはポートが異なると区別されます。同一の主体が 2 つの異なるオリジンを管理していることを検証できても、明示的にサーバーがエイリアスを設定していない限り、それらのオリジン下の 2 つの名前空間は別個です。

オリジンは HTML や関連する Web プロトコル内でも使用されますが、それは本書の範囲外であり、詳細は [RFC6454] を参照してください。

HTTP はトランスポートプロトコルから独立していますが、"http" スキーム（セクション 4.2.1）は、指定されたポートで TCP 接続を待ち受けているオリジンサーバーを制御する者と権限を結び付けることに特化しています。これは非常に弱い意味での権限であり、クライアント固有の名前解決機構や経路上の攻撃者から保護されていない通信に依存するからです。それでも、信頼された環境内で "http" 識別子をオリジンサーバーに結び付け、一貫して解決するための最小限の手段としては十分です。

ホスト識別子が IP アドレスで提供される場合、オリジンサーバーはその IP アドレスの示す TCP ポートで待ち受けているリスナー（存在する場合）です。ホストが登録名である場合、登録名は名前解決サービス（例えば DNS）を使用して適切なオリジンサーバーのアドレスを見つけるための間接的識別子です。

"http" URI が指定されたリソースへのアクセスを要求する文脈で使用される場合、クライアントはホスト識別子を IP アドレスに解決し、そのアドレスの示す指定ポートに TCP 接続を確立し、クライアントのターゲット URI に一致するリクエストターゲットを含む HTTP リクエストメッセージをその接続上で送信することを MAY 試みることができます（セクション 7.1）。

サーバーがそのようなリクエストに対して非暫定の HTTP レスポンスメッセージで応答する場合（セクション 15 参照）、その応答はクライアントのリクエストに対する権威ある応答と見なされます。

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

"https" スキーム（セクション 4.2.2）は、クライアントが識別されたオリジンサーバーに対して信頼できると見なす証明書に対応する秘密鍵を用いる能力に基づいて権限を関連付けます。クライアントは通常、ある信頼アンカーから伝達される信頼のチェーンに依存して証明書を信頼できるものと判断します（セクション 4.3.4）。

HTTP/1.1 以前では、クライアントは URI オリジンのホストに対して特に確立され保護された接続上で通信している場合にのみサーバーに権限を帰属させます。接続の確立と証明書の検証が権限の証明として用いられます。

HTTP/2 および HTTP/3 では、クライアントは証明書内に存在するホストのいずれかと URI オリジンのホストが一致し、かつクライアントがそのホストに対して接続を開くことができると信じる場合に、確立され保護された接続上で通信しているならばサーバーに権限を帰属させます。実際には、クライアントはオリジンのホストが確立された接続のサーバー IP アドレスと同じかどうかを確認するために DNS クエリを行うことが多いです。この制約はオリジンサーバーが等価な ORIGIN フレームを送信することで取り除くことができます（[RFC8336]）。

リクエストターゲットのホストおよびポート値は各 HTTP リクエスト内で渡され、オリジンを識別し、同じサーバーが制御する可能性のある他の名前空間と区別します（セクション 7.2）。オリジンは、証明書の秘密鍵の管理を他のサービスに委任する場合、それらのサービスが同等に対応する "https" 名前空間を管理するか、少なくとも誤って向けられたリクエストを拒否する準備ができていることを保証する責任があります（セクション 7.4）。

オリジンサーバーはオリジンに対する権限を持っていても、特定のターゲット URI に対するリクエストの処理を望まない場合があります。例えば、ホストが異なるポート（例: 443 と 8000）で異なるサービスを運用している場合、接続が保護された後でもターゲット URI のチェックが必要です。ネットワーク攻撃者があるポートへの接続を別のポートで受信させる可能性があるためです。ターゲット URI のチェックを怠ると、攻撃者があるターゲット URI（例: "https://example.com/foo"）への応答を別のポート（例: "https://example.com:8000/foo"）からの権威ある応答で置き換えることを許す可能性があります。

"https" スキームは権限の関連付けに TCP や接続されたポート番号を利用しません。これらは保護された通信の外側にあり、決定的とは見なせないためです。したがって、HTTP 通信は TCP を使用しないプロトコルを含め、セクション 4.2.2 で定義されるような任意の保護されたチャネル上で行われる可能性があります。

"https" URI が指定されたリソースへのアクセスを要求する文脈で使用される場合、クライアントはホスト識別子を IP アドレスに解決し、そのアドレスの示す指定ポートに TCP 接続を確立し、TCP 上で TLS を正常に開始してエンドツーエンドの機密性と完全性の保護を確保し、その接続上でクライアントのターゲット URI に一致するリクエストターゲットを含む HTTP リクエストメッセージを送信することを MAY 試みることができます（セクション 7.1）。

サーバーがそのようなリクエストに対して非暫定の HTTP レスポンスメッセージで応答する場合（セクション 15 参照）、その応答はクライアントのリクエストに対する権威ある応答と見なされます。

ただし、上記が権威ある応答を得る唯一の手段であるわけではなく、また常に権威ある応答が必要であることを意味するものでもありません（[CACHING] を参照）。

URI を逆参照して 保護された 接続を確立するために、クライアントはサービスの識別が URI のオリジンサーバーに対して受け入れ可能な一致であることを MUST 検証しなければなりません。証明書の検証は経路上の攻撃者や名前解決を制御する攻撃者によるサーバーのなりすましを防止するために使われます。このプロセスにはクライアントが信頼アンカーのセットで設定されていることが必要です。

一般に、クライアントは セクション 6 に定義された検証プロセスを用いてサービス識別を検証しなければなりません（[RFC6125]）。クライアントはサービスのホストから参照識別子を構築しなければなりません：ホストがリテラルな IP アドレスであるなら参照識別子は IP-ID です（セクション 4.3.5）、それ以外はホストは名前であり参照識別子は DNS-ID です。

CN-ID 型の参照識別子はクライアントによって使用してはなりません（MUST NOT）。古いクライアントでは CN-ID が使用される場合があることが セクション 6.2.1 に記されています（[RFC6125]）。

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

特殊な場合には、クライアントが単にサーバーの識別を無視することが適切であるかもしれませんが、その場合接続は能動的な攻撃に対して無防備であることを理解しておく必要があります。

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

"https" URI の "host" フィールドに IP アドレスリテラルが使用されて識別されたサーバーは IP-ID 型の参照識別子を持ちます。IPv4 アドレスは "IPv4address" ABNF ルールを使用し、IPv6 アドレスは "IP-literal" 生成の "IPv6address" オプションを使用します（詳細は セクション 3.2.2 を参照、[URI]）。IP-ID 型の参照識別子は IP アドレスのデコード済みバイトを含みます。

IPv4 アドレスは 4 オクテット、IPv6 アドレスは 16 オクテットです。IP-ID の利用は他の IP バージョンについては定義されていません。証明書 subjectAltName 拡張内の iPAddress 選択肢は IP バージョンを明示的に含まないため、アドレスの長さによりバージョンを区別します（詳細は セクション 4.2.1.6 を参照、[RFC5280]）。

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

ABNF ルール（[RFC5234]）への #rule 拡張は、一部の list-based フィールド値の定義における可読性を向上させるために使用されます。

"#" 構成は "*" に類似しており、要素のコンマ区切りリストを定義するために使われます。完全な形式は "<n>#<m>element" で、少なくとも <n> 個、最大 <m> 個の要素を意味し、各要素は単一のコンマ (",") とオプションの空白（OWS, セクション 5.6.3 を参照）で区切られます。

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

  token          = 1*tchar

  tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
                 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
                 / DIGIT / ALPHA
                 ; any VCHAR, except delimiters

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

本仕様は線形空白の使用を示すために 3 つのルールを使用します：OWS（optional whitespace）、RWS（required whitespace）、および BWS（"bad" whitespace）。

OWS ルールは 0 個以上の線形空白オクテットが現れる可能性がある箇所で使用されます。可読性を向上させるためにオプション空白が好まれるプロトコル要素では、送信者はオプション空白を単一の SP として生成することが SHOULD 推奨されます；それ以外の場合、送信者は不正または望ましくないプロトコル要素をインプレースでフィルタする際に必要となる場合を除きオプション空白を生成すべきではありません（SHOULD NOT）。

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

OWS と RWS は単一の SP と同じセマンティクスを持ちます。OWS または RWS として定義されている内容は、解釈前または下流へ転送する前に単一の SP に置き換えることが MAY できます。

BWS ルールは文法が歴史的理由でのみオプション空白を許す箇所で使用されます。送信者はメッセージ内で BWS を生成してはなりません（MUST NOT）。受信者はそのような悪い空白を解析して、プロトコル要素を解釈する前にそれを削除しなければなりません（MUST）。

BWS には意味はありません。BWS と定義される内容は解釈前または下流へ転送する前に削除してもよい（MAY）です。

  OWS            = *( SP / HTAB )
                 ; optional whitespace
  RWS            = 1*( SP / HTAB )
                 ; required whitespace
  BWS            = OWS
                 ; "bad" whitespace

ダブルクォートで囲まれたテキストは、単一の値として解析されます。

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

バックスラッシュ（"\"）は quoted-string および comment 構成内で単一オクテットの引用機構として使用できます。quoted-string の値を処理する受信者は、quoted-pair をバックスラッシュの後のオクテットに置き換えられたものとして扱わなければなりません（MUST）。

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

送信者は、quoted-string 内で DQUOTE とバックスラッシュのオクテットを引用する場合を除き、quoted-pair を生成すべきではありません（SHOULD NOT）。コメント内でも同様に、括弧 ["(" と ")"] とバックスラッシュのオクテットを引用する場合を除き 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）で見られます。

parameter-value が token 生成規則に一致する場合、その値は token としてまたは quoted-string 内で送信できます。引用あり／なしの値は等価です。

1995 年以前、サーバがタイムスタンプを伝達するために一般的に使用していた形式が 3 種類ありました。古い実装との互換性のため、ここではその 3 つをすべて定義します。優先される形式は、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   ; obsolete RFC 850 format
Sun Nov  6 08:49:37 1994         ; ANSI C's asctime() format

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

HTTP-date 値は協定世界時（UTC）の時刻を表します。最初の2 つの形式は "GMT" という 3 文字の略語で UTC を示します；asctime 形式の値も UTC とみなされます。

clock とは、UTC の現在時刻の合理的な近似を提供できる実装を指します。clock 実装は NTP（[RFC5905]）や同様のプロトコルを使用して UTC と同期することが望ましいです。

  IMF-fixdate  = day-name "," SP date1 SP time-of-day SP GMT
  ; fixed length/zone/capitalization subset of the format
  ; see Section 3.3 of [RFC5322]

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

  date1        = day SP month SP year
               ; e.g., 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 (leap second)

  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
               ; e.g., 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 ))
               ; e.g., Jun  2

HTTP-date は大文字小文字を区別します。なお、キャッシュ受信者については セクション 4.2（[CACHING]）がこの点を緩和しています。

送信者は文法で明示的に SP として含まれるものを超えて HTTP-date に追加の空白を生成してはなりません（MUST NOT）。day-name、day、month、year、および time-of-day のセマンティクスは、対応する名前を持つ Internet Message Format の構成と同じです（[RFC5322]、Section 3.3 参照）。

2 桁の年を使用する rfc850-date 形式のタイムスタンプ値を受信した受信者は、そのタイムスタンプが 50 年以上未来に見える場合、それと同じ下 2 桁を持つ最も最近の過去の年を表すものとして解釈しなければなりません（MUST）。

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

リクエストにおけるコンテンツの目的はメソッドのセマンティクスによって定義されます（セクション 9）。

例えば、PUT リクエストのコンテンツ内の表現（セクション 9.3.4）は、リクエストが正常に適用された後の target resource の望ましい状態を表すのに対し、POST リクエストのコンテンツ内の表現（セクション 9.3.3）はターゲットリソースによって処理される情報を表します。

レスポンスでは、コンテンツの目的はリクエストメソッド、レスポンスのステータスコード（セクション 15）、およびそのコンテンツを記述するレスポンスフィールドによって定義されます。例えば、GET に対する 200 (OK) レスポンスのコンテンツは、メッセージ発信時点（セクション 6.6.1）に観測された target resource の現在の状態を表します。一方で POST に対する同じステータスコードのレスポンスのコンテンツは、処理結果または処理適用後のターゲットリソースの新しい状態を表すかもしれません。

GET に対する 206 (Partial Content) レスポンスのコンテンツは、選択された表現の単一部分またはその表現の複数部分を含むマルチパートメッセージボディのいずれかを含みます（セクション 15.3.7 を参照）。

エラーのステータスコードを持つレスポンスは通常、エラー状態を表すコンテンツを含み、そのコンテンツはエラー状態を説明し、解決のために推奨される手順を示します。

HEAD リクエストメソッド（セクション 9.3.2）へのレスポンスは決してコンテンツを含みません；関連するレスポンスヘッダーフィールドは、その値が GET リクエストに対する場合にどのようになるかのみを示します（セクション 9.3.1）。

CONNECT リクエストメソッドへの 2xx (Successful) レスポンスは、コンテンツを持つ代わりに接続をトンネルモードに切り替えます（セクション 9.3.6）。

すべての 1xx (Informational)、204 (No Content)、および 304 (Not Modified) のレスポンスはコンテンツを含みません。

その他すべてのレスポンスはコンテンツを含みますが、そのコンテンツは長さ 0 の場合があります。

完全または部分的な表現がメッセージコンテンツとして転送される場合、送信者が識別子を供給したり、受信者がその特定の表現に対応するリソースの識別子を決定したりすることが望ましい場合があります。例えば、クライアントが「現在の天気報告」のリソースに対して GET リクエストを行うと、返されたコンテンツに特有の識別子（例: "weather report for Laguna Beach at 20210720T1711"）を欲することがあります。これは、時間とともに表現が変化することが予想されるリソースからのコンテンツを共有またはブックマークする際に有用です。

• リクエストに Content-Location ヘッダーフィールドがある場合、送信者はコンテンツが Content-Location フィールド値で識別されるリソースの表現であると主張します。ただし、そのような主張は他の手段で検証できない限り信用できません（本仕様では定義されていません）。その情報は改訂履歴リンクにとって有用である可能性はあります。
• それ以外の場合、コンテンツは HTTP によって識別されませんが、より具体的な識別子がコンテンツ自体に含まれることがあります。

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

トレーラセクションは、使用中の HTTP バージョンがそれをサポートし、明示的なフレーミング機構によって有効化されている場合にのみ可能です。例えば、HTTP/1.1 の chunked transfer coding はコンテンツの後にトレーラセクションを送信することを許します（Section 7.1.2 of [HTTP/1.1]）。

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

トレーラフィールドは、プロトコルバージョンを別のバージョンに変換してメッセージを転送する仲介者では処理が困難な場合があります。メッセージ全体を転送中にバッファできる場合、一部の仲介者はトレーラフィールドを適宜ヘッダセクションに統合してから転送することができます。しかしほとんどの場合、トレーラは単に破棄されます。受信者は、対応するヘッダフィールドの定義を理解しており、その定義が明示的にトレーラフィールド値が安全に統合されることを許可かつ定義している場合を除き、トレーラフィールドをヘッダセクションに統合してはなりません（MUST NOT）。

リクエストの TE ヘッダーフィールドに "trailers" キーワードが含まれていることは、クライアントが自身および下流のクライアントに代わってトレーラフィールドを受け入れる意思があることを示します。仲介者からのリクエストの場合、これはすべての下流クライアントが転送されたレスポンス内のトレーラフィールドを受け入れる意思があることを意味します。ただし "trailers" の存在が、クライアント群がレスポンス内の特定のトレーラフィールドを処理することを意味するわけではありません；単にトレーラセクションがクライアントのいずれかによって破棄されないことを示すのみです。

トレーラフィールドが転送中に破棄される可能性があるため、サーバはユーザーエージェントが受信することが必要だと考えるトレーラフィールドを生成すべきではありません（SHOULD NOT）。

"Trailer" ヘッダーフィールド（セクション 6.6.2）は、送信者がメッセージ内のトレーラフィールドとして送ることを予想するフィールド名のリストを示すために送信できます。これにより受信者はコンテンツを処理する前に示されたメタデータの受信に備えることができます。例えば、動的チェックサムがコンテンツ受信中に計算され、トレーラフィールド値の受信時に直ちに検査されることを示す場合に有用です。

ヘッダフィールドと同様に、同じ名前を持つトレーラフィールドは受信順に処理されます；同名の複数のトレーラフィールド行は複数の値をメンバーのリストとして付加することと同等のセマンティクスを持ちます。メッセージ中に複数回生成され得るトレーラフィールドは、各メンバー値が各受信フィールド行ごとに一度だけ処理される場合でも、リストベースのフィールドとして定義されなければなりません（MUST）。

メッセージの終わりに、受信者は受信したトレーラフィールドの集合をヘッダフィールドと類似した名前/値ペアのデータ構造として扱うことが MAY です（ただしヘッダとは別）。トレーラで使用されることを意図したフィールドのフィールド仕様内で、追加の処理期待が定義され得ます。

"Date" ヘッダーフィールドはメッセージが発信された日時を表し、Internet Message Format の Origination Date Field（orig-date）と同じセマンティクスを持ちます。フィールド値は セクション 5.6.7 で定義された HTTP-date です。

  Date = HTTP-date

例：

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

Date ヘッダーフィールドを生成する送信者は、そのフィールド値をメッセージ生成時の日時の最良の近似として生成することが SHOULD です。理論上、日付はメッセージコンテンツ生成直前の時点を表すべきですが、実務上は送信者はメッセージ起点時の任意の時点で日付値を生成できます。

時計（セクション 5.6.7 で定義）を持つオリジンサーバは、すべての 2xx (Successful)、3xx (Redirection)、および 4xx (Client Error) のレスポンスで Date ヘッダーフィールドを生成しなければなりません（MUST）。また 1xx (Informational) と 5xx (Server Error) のレスポンスでは Date を生成してもよい（MAY）です。

時計を持たないオリジンサーバは Date ヘッダーフィールドを生成してはなりません（MUST NOT）。

時計を持つ受信者が Date ヘッダーフィールドを欠くレスポンスメッセージを受信した場合、受信時刻を記録し、そのメッセージをキャッシュまたは下流へ転送する場合は対応する Date ヘッダーフィールドをヘッダセクションに付加しなければなりません（MUST）。

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

ユーザーエージェントはリクエストに Date ヘッダーフィールドを送信してもよい（MAY）が、一般にはサーバにとって有用な情報を伝えると考えられない限り送信しません。例えば、カスタムな HTTP の用途でユーザーエージェントとサーバの時計差に基づいてサーバがリクエストの解釈を調整することが期待される場合などに Date を伝えることがあります。

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

  Trailer = #field-name

例えば、送信者がコンテンツをストリーミングしながら署名を計算し、最終的な署名をトレーラフィールドとして提供することを示すかもしれません。これにより受信者はコンテンツを受信しながら同じ検査を行うことができます。

メッセージで1つ以上のトレーラフィールドを生成する意図がある送信者は、どのフィールドがトレーラに存在する可能性があるかを示すために、そのメッセージのヘッダセクションに Trailer ヘッダーフィールドを生成することが SHOULD です。

仲介者が転送中にトレーラセクションを破棄した場合、Trailer フィールドは失われた可能性のあるメタデータのヒントを提供することがありますが、Trailer を送信する送信者が常に指定されたフィールドを送信するとは保証されません。

クライアントがキャッシュ（[CACHING]）を持ち、リクエストがそれで満たせる場合、通常はまずキャッシュへリクエストを向けます。

リクエストがキャッシュで満たされない場合、典型的なクライアントはリクエストを満たすためにプロキシを使うかどうかを設定を確認します。プロキシ設定は実装依存ですが、URI プレフィックスのマッチング、選択的な authority マッチング、またはその両方に基づくことが多く、プロキシ自体は通常 "http" または "https" URI で識別されます。

"http" または "https" プロキシが適用される場合、クライアントはそのプロキシへ接続を確立（または再利用）し、クライアントの target URI に一致する request target を含む HTTP リクエストメッセージを送信します。

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

セクション 4.3.2 は、特定されたオリジンサーバへ接続を確立（または再利用）し、そのサーバへクライアントの target URI に一致する request target を含む HTTP リクエストメッセージを送信することで "http" リソースへアクセスする方法を定義しています。

セクション 4.3.3 は、特定されたオリジンに対して権威を持つオリジンサーバへセキュアな接続を確立（または再利用）し、そのサーバへクライアントの target URI に一致する request target を含む HTTP リクエストメッセージを送信することで "https" リソースへアクセスする方法を定義しています。

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

  Connection        = #connection-option
  connection-option = token

Connection オプションは大文字小文字を区別しません。

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

仲介者は受信した Connection ヘッダーフィールドを転送前に解析し、このフィールド内の各 connection-option に対して、その connection-option と同名のヘッダまたはトレーラフィールドをメッセージから削除し、次に Connection ヘッダーフィールド自体を削除する（または転送メッセージのために仲介者自身の制御オプションで置換する）必要があります（MUST）。

したがって、Connection ヘッダーフィールドは即時の受信者（"hop-by-hop"）のためだけに意図されたフィールドとチェーン上のすべての受信者（"end-to-end"）のためのフィールドを宣言的に区別する手段を提供し、メッセージを自己記述的にし、将来の接続固有の拡張を古い仲介者が盲目的に転送してしまうことを防ぎます。

• Proxy-Connection（Appendix C.2.2 of [HTTP/1.1]）
• Keep-Alive（Section 19.7.1 of [RFC2068]）
• TE（Section 10.1.4）
• Transfer-Encoding（Section 6.1 of [HTTP/1.1]）
• Upgrade（Section 7.8）

送信者は、コンテンツのすべての受信者に対して意図されているフィールドに対応する connection option を送信してはなりません（MUST NOT）。例えば、Cache-Control は connection option として適切ではありません（Section 5.2 of [CACHING]）。

Connection オプションは、そのオプションに関連するパラメータがない場合はメッセージ内に対応するフィールドが存在しないことがあります。対照的に、対応する 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 進整数です。

TRACE または OPTIONS リクエストで Max-Forwards ヘッダーフィールドを含むメッセージを受信した各仲介者は、転送前にその値を検査および更新しなければなりません（MUST）。受信値がゼロ (0) の場合、仲介者はリクエストを転送してはならず（MUST NOT）、その代わり仲介者自身が最終受信者として応答しなければなりません（MUST）。受信した Max-Forwards 値がゼロより大きい場合、仲介者は転送されたメッセージに対して、a) 受信値を 1 減じたもの、または b) 受信者がサポートする Max-Forwards の最大値、のいずれか小さい方の値をフィールド値として持つ更新済みの Max-Forwards フィールドを生成しなければなりません（MUST）。

受信者はその他のメソッドに対して受信した Max-Forwards ヘッダーフィールドを無視してもよい（MAY）です。

"Via" ヘッダーフィールドは、ユーザーエージェントとサーバの間（リクエストの場合）またはオリジンサーバとクライアントの間（レスポンスの場合）に存在する中間プロトコルおよび受信者を示します。これは電子メールにおける "Received" ヘッダーフィールドに類似しています（Section 3.6.7 of [RFC5322]）。Via はメッセージ転送の追跡、リクエストループの回避、チェーン上の送信者のプロトコル機能の識別に利用できます。

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

  received-protocol = [ protocol-name "/" ] protocol-version
                    ; see Section 7.8
  received-by       = pseudonym [ ":" port ]
  pseudonym         = token

Via フィールド値の各メンバはメッセージを転送したプロキシやゲートウェイを表します。各仲介者はメッセージをどのように受け取ったかに関する自身の情報を追記するため、最終的な値は転送受信者の順序に従って並びます。

プロキシは転送する各メッセージに対して適切な Via ヘッダーフィールドを送信しなければなりません（MUST）。HTTP→HTTP のゲートウェイは受信リクエストメッセージごとに適切な Via を送信しなければならず（MUST）、転送されたレスポンスメッセージには Via を送信してもよい（MAY）です。

各仲介者について、received-protocol はメッセージの上流送信者が使用したプロトコルとバージョンを示します。したがって Via フィールド値はリクエスト/レスポンスチェーンの広告されたプロトコル能力を記録し、下流の受信者が利用可能な後方互換性のない機能を判定するのに役立ちます。簡潔さのため、received-protocol が HTTP の場合は protocol-name を省略します。

received-by 部分は通常、その後メッセージを転送した受信サーバまたはクライアントのホストと任意のポート番号です。ただし、実際のホストが機密情報と見なされる場合、送信者はそれを pseudonym に置き換えてもよい（MAY）。ポートが提供されていない場合、受信者はそれが受信プロトコルの既定ポートで受信されたことを意味すると解釈してもよい（MAY）。

送信者は各受信者のソフトウェアを識別するコメントを生成してもよい（MAY）。これは User-Agent や Server ヘッダーフィールドに類似します。ただし Via のコメントは任意であり、受信者は転送前にそれらを削除してもよい（MAY）。

Via: 1.0 fred, 1.1 p.example.net

ネットワークファイアウォールを通じたポータルとして用いられる仲介者は、ファイアウォール領域内のホストの名前やポートを転送してはなりません（SHOULD NOT）。もし有効化されていない場合、そのような仲介者は受信した任意の behind-the-firewall ホストの received-by を適切な pseudonym に置き換えるべきです（SHOULD）。

仲介者は、received-protocol 値が同一であるリストメンバの順序付き部分列を単一のメンバに結合してもよい（MAY）。例えば、

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

は次のように折りたたむことができます：

Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

送信者は複数のリストメンバーを結合するべきではありません（SHOULD NOT）、ただしそれらがすべて同一組織の管理下にありホストがすでに pseudonym に置き換えられている場合は例外です。異なる received-protocol 値を持つメンバーを結合してはなりません（MUST NOT）。

HTTP は [RFC2046] のメディアタイプを Content-Type および Accept ヘッダーフィールドで使用し、オープンで拡張可能なデータ型付けと型交渉を提供します。メディアタイプはデータ形式と様々な処理モデルを定義します：メッセージコンテキストに従ってそのデータをどのように処理するかです。

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

type と subtype のトークンは大文字小文字を区別しません。

type/subtype の後にセミコロン区切りのパラメータ（セクション 5.6.6）が続くことが MAY あります。パラメータの有無は、メディアタイプレジストリ内での定義によってメディアタイプの処理に重要となる場合があります。パラメータ値の大文字小文字の敏感性は、パラメータ名のセマンティクスに依存します。

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

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

HTTP は charset 名を使用して、テキスト表現の文字エンコーディングスキームを示したり交渉したりします（[RFC6365]）。この文書で定義されたフィールドでは、charset 名はパラメータ（Content-Type）の中や、また Accept-Encoding のように平文の token として現れます。いずれの場合も、charset 名は大文字小文字を区別せずに照合されます。

Charset 名は IANA の "Character Sets" レジストリ（https://www.iana.org/assignments/character-sets）に [RFC2978] に定められた手順で登録されるべきです。

MIME は複数の表現を単一のメッセージボディ内にカプセル化するいくつかの "multipart" 型を提供します。すべての multipart 型は共通の構文を共有し（[RFC2046] 参照）、メディアタイプ値の一部として boundary パラメータを含みます。メッセージボディ自体がプロトコル要素であり、送信者はボディパート間の改行を表すために CRLF のみを生成することが MUST です。

HTTP のメッセージフレーミングは multipart boundary をメッセージボディ長の指標として使用しませんが、コンテンツを生成または処理する実装がそれを使用することはあります。例えば "multipart/form-data" はリクエスト内でフォームデータを運ぶためにしばしば使用され（[RFC7578]）、"multipart/byteranges" 型は一部の 206 (Partial Content) レスポンスで使用されるために本仕様で定義されています（セクション 15.3.7 を参照）。

Content coding 値は表現に適用された（または適用可能な）エンコーディング変換を示します。Content codings は主に表現を圧縮したり有用に変換したりするために使用され、基になるメディアタイプの同一性や情報の損失を防ぎます。多くの場合、表現は符号化された形式で保存され、直接送信され、最終受信者がデコードします。

  content-coding   = token

すべての content codings は大文字小文字を区別せず、"HTTP Content Coding Registry" に登録されるべきです（セクション 16.6 を参照）。

Content-coding 値は Accept-Encoding および Content-Encoding ヘッダーフィールドで使用されます。

言語タグは [RFC5646] に定義され、人間同士の情報伝達のために用いられる自然言語を識別します。コンピュータ言語は明示的に除外されます。

HTTP は Accept-Language と Content-Language ヘッダーフィールド内で言語タグを使用します。Accept-Language はより広い language-range 構文を使用し（セクション 12.5.4）、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] を参照してください。

バリデータには強弱の二種類があります：strong または weak。弱バリデータは生成が容易ですが比較にはあまり有用ではありません。強バリデータは比較に理想的ですが効率的に生成するのが非常に困難または不可能な場合があります。すべてのリソースに同じ強度のバリデータを課す代わりに、HTTP は使用中のバリデータの種類を公開し、弱バリデータを前提条件として使用できる場合に制限を課します。

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

強バリデータは表現データの変更以外の理由で変化することもあります（例: Content-Type のような表現メタデータが意味的に重要な部分で変わる場合）が、オリジンサーバはリモートキャッシュや作成ツールが古いレスポンスを無効化するために必要な場合にのみ値を変更するのが望ましいです。

キャッシュエントリは有効期限に関わらず長期間残存し得るため、キャッシュは過去に取得したバリデータを用いてエントリを検証しようとすることがあります。強バリデータは特定のリソースに関連付けられたすべての表現のバージョンにわたって一意であることが望まれますが、異なるリソースの表現に対して一意であることを意味するものではありません（複数のリソースが同じ強バリデータを同時に使用する可能性があり、それがそれらの表現が等価であることを意味するわけではありません）。

実務で使われる強バリデータには様々なものがあります。最良のものは厳格なリビジョン管理に基づき、表現の変更ごとに一意のノード名やリビジョン識別子が割り当てられます。表現データに対する衝突耐性のあるハッシュ関数も十分ですが、レスポンスヘッダーフィールドが送信される前にデータが利用可能である必要があり、検証要求のたびにダイジェストを再計算する必要がないことが望まれます。ただし、同じデータ形式を共有するがメタデータが異なる複数の表現が存在する場合、オリジンサーバはそれらの表現を区別する追加情報をバリデータに組み込む必要があります。

対照的に、weak validator は表現データのすべての変更に対して値が必ず変わるとは限らない表現メタデータです。これは値の計算方法の制限（例: 時計の分解能）、すべての可能な表現の一意性を保証できないこと、あるいはリソース所有者が一意なデータ列ではなく自己判断で等価性の集合にまとめたいことが理由になり得ます。

オリジンサーバは、以前の表現を現在の表現の代替として受け入れたくないと考えるときは弱エンティティタグを変更するべきです（SHOULD）。言い換えれば、オリジンサーバはキャッシュが古いレスポンスを無効化することを望む場合、弱エンティティタグを変更すべきです。

例えば、毎秒変化する天気報告の表現は、オリジンサーバの観点から同等とみなす表現の集合にまとめて同じ弱バリデータを割り当て、キャッシュが妥当な期間表現を使用できるようにすることがあります。同様に、1 秒の分解能しかない修正時刻は、その間に表現が 2 回変更され得る場合、弱バリデータとなり得ます。

同様に、同一リソースの二つ以上の表現が同時に同じバリデータを共有する場合、その表現データが同一でない限りそのバリデータは弱です。例えば、gzip コーディングが適用された表現と無符号の表現で同じバリデータを送信するなら、そのバリデータは弱となります。しかし、表現データのみが同一でメタデータが異なる二つの同時表現は同じ強バリデータを共有し得ます。

強バリデータはキャッシュ検証、部分範囲の要求、失われた更新の回避を含むすべての条件付きリクエストに使用できます。弱バリデータはクライアントが以前取得した表現データと正確に等しいことを要求しない場合（例えばキャッシュの検証や最近の変更への限定的な巡回のような場合）にのみ使用できます。

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

  Last-Modified = HTTP-date

使用例：

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

レスポンス内の "ETag" フィールドは、リクエスト処理の完了時に決定された selected representation の現在のエンティティタグを提供します。エンティティタグは、同一リソースの複数の表現を区別するための不透明なバリデータであり、表現データの変更や同時に有効な複数表現（コンテンツ交渉による）によらず利用できます。エンティティタグは不透明な引用文字列で構成され、必要に応じて弱性指示子で接頭辞が付くことがあります。

  ETag       = entity-tag

  entity-tag = [ weak ] opaque-tag
  weak       = %s"W/"
  opaque-tag = DQUOTE *etagc DQUOTE
  etagc      = %x21 / %x23-7E / obs-text
             ; VCHAR except double quotes, plus obs-text

エンティティタグは、修正日時よりも検証においてより信頼できる場合があります。これは修正日時を保存できない状況や、HTTP-date の 1 秒解像度が十分でない場合、または修正日時が一貫して維持されない場合に当てはまります。

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

エンティティタグは弱または強のいずれかのバリデータになり得ますが、強がデフォルトです。もしオリジンサーバがエンティティタグを提供し、その生成が強バリデータの特性を満たさないなら、オリジンサーバはその不透明値の前に "W/" を付けて弱としてマークしなければなりません（MUST）。

送信者はトレーラセクションで ETag フィールドを送信してもよい（MAY）。ただしトレーラはしばしば無視されるため、エンティティタグがコンテンツ送信中に生成されない限り、ETag はヘッダーフィールドとして送信するのが望ましいです。

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

この safe の定義は、実装が潜在的に有害な動作や完全に読み取り専用でない動作、あるいは副作用を伴う動作を含めることを妨げるものではありません。ただし重要なのは、クライアントがそれらの追加動作を要求しておらず、その責任を負わない点です。例えば、多くのサーバはすべてのレスポンス完了時にアクセスログファイルへリクエスト情報を追記しますが、それは safe と見なされます（ログ保存がいっぱいになりサーバが失敗する可能性があっても）。同様に、Web 上の広告を選択することで発生する safe リクエストは広告アカウントの課金という副作用を持つことがあります。

本仕様で定義されるリクエストメソッドのうち、GET、HEAD、OPTIONS、および TRACE が safe と定義されています。

safe と unsafe を区別する目的は、スパイダーのような自動取得プロセスやキャッシュのプリフェッチによる性能最適化が害を及ぼさずに動作できるようにするためです。加えて、未信頼のコンテンツを処理する際にユーザーエージェントが unsafe メソッドの自動使用に適切な制約を適用できるようにします。

ユーザーエージェントは、ユーザーに提示する潜在的なアクションを表示する際に safe と unsafe を区別することが SHOULD です。これによりユーザーは unsafe な操作を行う前に警告を受けられます。

ターゲット URI 内のパラメータがアクションの選択に影響を及ぼすように構築されたリソースについては、そのアクションがリクエストメソッドのセマンティクスと整合するようにリソース所有者が責任を負います。例えば、"page?do=delete" のようにクエリパラメータで動作を指定する Web ベースの編集ソフトウェアが一般的です。もしそのリソースの目的が unsafe なアクションを実行することであるなら、リソース所有者は safe メソッドでアクセスされたときにそのアクションを無効化または禁止しなければなりません。そうしないと、リンクの保守やプリフェッチ、検索インデックス作成等のために自動化プロセスが GET を実行する際に望ましくない副作用が発生します。

あるリクエストメソッドは、同一のリクエストを複数回送信した場合でもサーバに対する意図された効果が単一回と同じであるならば idempotent と見なされます。本仕様で定義されるメソッドのうち、PUT、DELETE、および safe なリクエストメソッドは idempotent です。

safe の定義と同様に、idempotent の性質はユーザーが要求した内容にのみ適用されます。サーバは各 idempotent リクエストを個別にログに記録したり、リビジョン履歴を保持したり、その他の非冪等的な副作用を実装する自由があります。

Idempotent メソッドが区別されるのは、通信障害によりクライアントがサーバのレスポンスを読み取る前に同一リクエストを自動的に再送できる点にあります。例えば、クライアントが PUT リクエストを送信し、基盤の接続がレスポンスを受け取る前に切断された場合、クライアントは新しい接続を確立して idempotent なリクエストを再試行できます。再試行により元のリクエストが成功していたとしても、意図された効果は同じであることが保証されますが、レスポンスは異なり得ます。

クライアントは、メソッドが非冪等である場合に、そのリクエストを自動的に再試行すべきではありません（SHOULD NOT）。ただし、リクエストのセマンティクスが実際には冪等であることを知っている場合や、元のリクエストが適用されなかったことを検出する手段がある場合は例外です。

例えば、ユーザーエージェントは、そのリソースに対して設計または設定によって安全に再実行できると知っている場合に限り、POST リクエストの自動再送を行えます。同様に、バージョン管理リポジトリ向けに特化したユーザーエージェントは、失敗した接続後にターゲットリソースのリビジョンを確認し、部分的に適用された変更を巻き戻すか修正してから失敗したリクエストを自動再試行できる設計もあります。

一部のクライアントはよりリスクのあるアプローチを取り、自動再試行が可能かを推測することがあります。例えば、基盤のトランスポート接続が切断され、レスポンスのどの部分も受信されていない場合に POST を自動再試行することがあります（特にアイドル状態の永続接続が使用されていた場合）。

プロキシは非冪等リクエストを自動的に再試行してはなりません（MUST NOT）。クライアントは自動再試行に失敗した場合にさらに再試行すべきではありません（SHOULD NOT）。

キャッシュがレスポンスを保存・利用するためには、関連するメソッドが明示的にキャッシュを許可し、どの条件でレスポンスが後続のリクエストを満たすために使えるかを詳細に定義している必要があります。メソッド定義がそれを行わない場合、そのレスポンスはキャッシュできません。追加の要件は [CACHING] を参照してください。

本仕様は GET、HEAD、および POST のキャッシュセマンティクスを定義しますが、実際のキャッシュ実装の大多数は GET と HEAD のみをサポートします。

GET メソッドは、selected representation の転送をターゲットリソースに対して要求します。成功したレスポンスはターゲット URI により識別される「同一性」の品質を反映します（Section 1.2.2 of [URI]参照）。したがって、HTTP を用いた識別可能な情報の取得は通常、その情報を提供する可能性のある識別子に対して GET リクエストを行うことで実行されます（200 (OK) のレスポンスで）。

GET は情報取得の主要機構であり、ほとんどすべての性能最適化の焦点です。重要なリソースごとに URI を生成するアプリケーションは、それらの最適化の恩恵を受けつつ他のアプリケーションによる再利用を可能にし、Web の拡大を促進するネットワーク効果をもたらします。

リソース識別子をリモートファイルシステムのパス名と見なし、表現をそのファイル内容のコピーと考えるのは魅力的ですが、実際には多くのリソースがそのように実装されています（関連するセキュリティ考慮は Section 17.3 を参照）。しかし、実際の制約はそれほど単純ではありません。

リソースの HTTP インターフェースは、コンテンツオブジェクトのツリー、各種データベースレコードへのプログラム的ビュー、あるいは他の情報システムへのゲートウェイとして実装されている可能性があります。URI マッピングがファイルシステムに結びついている場合でも、オリジンサーバはリクエストを入力としてファイルを実行し、その出力を表現として送信するように構成されているかもしれません。いずれにせよ、どのリソース識別子がどの実装に対応し、どのようにしてターゲットリソースの現在の表現を選択して送信するかはオリジンサーバだけが知っていれば十分です。

クライアントは、GET のセマンティクスを "レンジリクエスト"（選択された表現の一部のみを転送する）に変更するために、リクエストで Range ヘッダーフィールドを送信できます（Section 14.2参照）。

リクエストメッセージのフレーミングは使用されるメソッドに依存しませんが、GET リクエストで受信したコンテンツには一般に定義されたセマンティクスがなく、リクエストの意味やターゲットを変更できません。そのため、一部実装はそれをリクエストスミッギング攻撃の可能性と見なしてリクエストを拒否し接続を閉じることがあります（Section 11.2 of [HTTP/1.1]参照）。クライアントは、オリジンサーバがそのようなコンテンツを目的として受け取り十分にサポートすることを事前に示していない限り、GET リクエストにコンテンツを生成してはなりません（SHOULD NOT）。オリジンサーバは、経路上の仲介者を認識していない相手と個人的な取り決めに頼ってコンテンツを受け取るべきではありません（SHOULD NOT）。

GET リクエストへのレスポンスはキャッシュ可能であり、キャッシュは Cache-Control ヘッダーフィールドで示されない限りそれを用いて後続の GET および HEAD リクエストを満たすことが MAY です（Section 5.2 of [CACHING]参照）。

フォームのクエリフィールドなどユーザー提供情報からターゲット URI を構築する機構を用いて情報取得を行う場合、URI 内に記載されることが不適切な潜在的に機密なデータが提供され得ます（Section 17.9参照）。場合によっては、データをフィルタまたは変換してそのような情報が露出しないようにできます。あるいは、レスポンスをキャッシュする利点がない場合は、GET の代わりに POST を使用して機密情報をターゲット URI ではなくリクエストコンテンツで送信することが適切です（Section 9.3.3参照）。

HEAD メソッドは GET と同一ですが、サーバはレスポンスにコンテンツを送信してはなりません（MUST NOT）。HEAD は表現データを転送せずに selected representation に関するメタデータを取得するために使用され、ハイパーテキストリンクの検査や最近の変更の検出にしばしば用いられます。

サーバは HEAD リクエストに対して GET の場合に送信したであろう同じヘッダーフィールドを送信することが SHOULD です。しかしながら、コンテンツ生成中にのみ値が決定されるヘッダーフィールドは省略してもよい（MAY）ことがあります。例えば、あるサーバは動的レスポンスを最小量のデータが生成されるまでバッファして効率的に小さなレスポンスを区切ったり、コンテンツ選択について遅延決定を行ったりします。そのような GET に対するレスポンスは、HEAD には含まれない Content-Length や Vary のようなフィールドを含むかもしれません。これらの小さな不一致は、HEAD が通常効率のために要求されるので、コンテンツを生成して破棄するより望ましいと考えられます。

リクエストメッセージのフレーミングはメソッドに依存しませんが、HEAD リクエストで受信したコンテンツは一般に定義されたセマンティクスを持たず、リクエストの意味やターゲットを変更できないため、リクエストスミッギング攻撃の可能性として実装によりリクエストが拒否され接続が閉じられることがあります（Section 11.2 of [HTTP/1.1]参照）。クライアントは、オリジンサーバがそのようなリクエストを目的として受け取りサポートすることを事前に示していない限り、HEAD リクエストにコンテンツを生成してはなりません（SHOULD NOT）。オリジンサーバは、経路上の仲介者についての私的な取り決めに依存してコンテンツを受け取るべきではありません（SHOULD NOT）。

HEAD リクエストへのレスポンスはキャッシュ可能であり、キャッシュは Cache-Control によって示されない限りそれを用いて後続の HEAD リクエストを満たすことが MAY です（Section 5.2 of [CACHING]参照）。HEAD のレスポンスは以前にキャッシュされた GET のレスポンスに影響を与えることもあります（詳細は Section 4.3.5 of [CACHING] を参照）。

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

オリジンサーバは、POST リクエストの処理結果に基づいて適切なステータスコードを選択することでレスポンスのセマンティクスを示します；本仕様で定義されたほとんどのステータスコードが POST のレスポンスとして返され得ます（例外は 206、304、および 416 などです）。

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

POST リクエストへのレスポンスは、明示的な鮮度情報を含む場合にのみキャッシュ可能です（詳細は Section 4.2.1 of [CACHING]）。また、POST のターゲット URI と同じ値を持つ Content-Location が含まれる場合に限り、キャッシュされた POST レスポンスは後続の GET または HEAD リクエストを満たすために再利用できます。一方、POST リクエスト自体は潜在的に unsafe であるためキャッシュされた POST レスポンスで満たされることはできません（詳細は Section 4 of [CACHING]参照）。

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

PUT メソッドは、リクエストメッセージのコンテンツに含まれる表現でターゲットリソースの状態を作成または置換するよう要求します。ある表現の PUT が成功した場合、同一のターゲットリソースに対する後続の GET は等価な表現を 200 (OK) レスポンスで返すことが期待されます。しかし、ターゲットリソースは並行して他のユーザーエージェントによって操作され得るか、オリジンサーバによる動的処理の対象であるため、そのような状態変化が観測可能である保証はありません。成功レスポンスは、オリジンサーバが処理した時点でユーザーエージェントの意図が達成されたことを示すのみです。

ターゲットリソースに現在の表現が存在せず、PUT によって作成された場合、オリジンサーバは 201 (Created) を返さなければなりません（MUST）。ターゲットリソースに現在の表現が存在し、その表現が PUT の表現に従って正常に変更された場合、オリジンサーバは成功を示すために 200 (OK) または 204 (No Content) を返さなければなりません（MUST）。

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

1. ターゲットリソースを新しいメディアタイプに合わせて再構成する；
2. PUT 表現をリソースと整合するフォーマットに変換してから新しいリソース状態として保存する；または
3. リクエストを拒否し、ターゲットリソースが "text/html" に制限されていることを示す 415 (Unsupported Media Type) を返す（場合によっては新しい表現に適した別のリソースへのリンクを含める）。

HTTP は PUT がオリジンサーバの状態にどのように影響するかを厳密に定義するものではなく、ユーザーエージェントのリクエストの意図およびオリジンサーバのレスポンスのセマンティクスで表せる範囲に留まります。リソースが何であるか、状態がどのように「格納」されるか、格納が状態変化によってどのように変わるか、あるいはオリジンサーバがリソース状態をどのように表現に変換するかは定義していません。一般に、リソースインターフェースの裏にある実装の詳細はサーバに隠蔽されます。

これはヘッダおよびトレーラフィールドの保存方法にも及びます。一般的なヘッダフィールド（例: Content-Type）は通常保存されて後続の GET で返されますが、ヘッダとトレーラの扱いはそのリソースがリクエストを受けた具体的実装に依存します。その結果、オリジンサーバは PUT リクエストで受け取った未認識のヘッダやトレーラフィールドを（リソース状態の一部として保存するのではなく）無視することが SHOULD です。

オリジンサーバは、リクエストが保存された表現データに対して何ら変換が行われていない場合（すなわちリソースの新しい表現データが PUT リクエストで受信したコンテンツと同一である場合）を除き、成功した PUT レスポンスで ETag や Last-Modified のようなバリデータフィールドを送信してはなりません（MUST NOT）。この要件は、ユーザーエージェントが送信した表現（メモリ上に保持しているもの）が PUT の結果であり再取得を不要としてよいかを判断できるようにするためです。レスポンスで受け取った新しいバリデータは、今後の条件付きリクエストに用いて偶発的な上書きを防ぐことができます（Section 13.1参照）。

POST と PUT の基本的な違いは、囲まれた表現に対する意図の違いで強調されます。POST の場合、ターゲットリソースは囲まれた表現をリソース固有のセマンティクスに従って処理することを意図しますが、PUT の場合は囲まれた表現がターゲットリソースの状態を置換することが明示されます。したがって、PUT の意図は冪等であり仲介者にも可視ですが、正確な効果はオリジンサーバだけが知っています。

PUT の適切な解釈は、ユーザーエージェントがどのターゲットリソースを望んでいるかを知っていることを前提とします。クライアントに代わって適切な URI を選択するサービスは、状態変更リクエストを受け取った後にそれを行うならば POST を用いるべきです（SHOULD）。もしオリジンサーバがリクエストされた PUT 状態変更をターゲットリソースに対して行わず、代わりに別のリソースに適用したい場合（例えばリソースが別の URI に移動したとき）、オリジンサーバは適切な 3xx (Redirection) を返さなければなりません（MUST）；ユーザーエージェントはリダイレクトを行うかどうかを自身で決定してよい（MAY）。

ターゲットリソースに対する PUT リクエストは他のリソースに副作用をもたらすことがあります。例えば、「現在のバージョン」を識別する URI（リソース）と、各バージョンを識別する URI（別のリソース）が存在する場合、"現在のバージョン" URI への成功した PUT は新しいバージョンリソースを作成するとともにターゲットリソースの状態を変更し、関連リソース間のリンクが追加されることがあります。

一部のオリジンサーバは、リクエスト修飾子として Content-Range を用いることで部分的な PUT を行うことをサポートします（Section 14.4および Section 14.5参照）。

PUT メソッドへのレスポンスはキャッシュ可能ではありません。成功した PUT リクエストがターゲット URI に対して通過するキャッシュを経由した場合、そのターゲット URI に保存されているレスポンスは無効化されます（無効化に関する詳細は Section 4.4 of [CACHING] を参照）。

DELETE メソッドは、オリジンサーバに対して target resource とその現在の機能との関連付けを削除するよう要求します。実質的には、このメソッドは UNIX の "rm" コマンドに類似しており、オリジンサーバの URI マッピングに対する削除操作を表現するもので、以前に関連付けられていた情報の実際の削除を要求するものではありません。

ターゲットリソースに 1 個以上の現在の表現がある場合、それらがオリジンサーバによって破棄されるかどうか、また関連ストレージが回収されるかどうかは、完全にリソースの性質およびオリジンサーバの実装に依存します（これらは本仕様の範囲外です）。同様に、DELETE によってデータベースやゲートウェイ接続の無効化やアーカイブが必要となることもあります。一般に、オリジンサーバは DELETE を許可するリソースについて、その削除を達成するための仕組みを持っていることが前提です。

DELETE を許可するリソースは比較的少なく、その主な用途はリモートオーサリング環境です。例えば、以前に PUT により作成されたリソース、または POST に対する 201 (Created) レスポンスで Location により識別されたリソースは、対応する DELETE 要求を受け付けてそれらの操作を元に戻すかもしれません。同様に、HTTP を用いてリモート操作を行うリビジョン管理クライアントのようなカスタムユーザーエージェント実装は、サーバの URI 空間がバージョンリポジトリに対応していることを前提に DELETE を使用することがあります。

DELETE が正常に適用された場合、オリジンサーバは以下のいずれかを返すことが SHOULD です：

• 処理がまだ実行されていないが成功する見込みがある場合は 202 (Accepted)、
• 処理が実行され追加情報を供給する必要がない場合は 204 (No Content)、
• 処理が実行され、状態を記述する表現をレスポンスに含む場合は 200 (OK)。

リクエストメッセージのフレーミングはメソッドに依存しませんが、DELETE リクエストで受信したコンテンツは一般に定義されたセマンティクスを持たず、リクエストの意味やターゲットを変更できないため、一部実装はそれをリクエストスミッギング攻撃の可能性と見なしリクエストを拒否し接続を閉じることがあります（Section 11.2 of [HTTP/1.1]参照）。クライアントは、オリジンサーバがそのようなコンテンツを目的として受け取り十分にサポートすることを事前に示していない限り、DELETE リクエストにコンテンツを生成してはなりません（SHOULD NOT）。オリジンサーバは、経路上の仲介者についての私的な取り決めに依存してコンテンツを受け取るべきではありません（SHOULD NOT）。

DELETE メソッドへのレスポンスはキャッシュ可能ではありません。成功した DELETE リクエストがターゲット URI に対して通過するキャッシュを経由した場合、そのターゲット URI に保存されているレスポンスは無効化されます（無効化に関する詳細は Section 4.4 of [CACHING] を参照）。

CONNECT メソッドは、受信者に対してリクエストターゲットで識別される宛先オリジンサーバへのトンネルを確立するよう要求し、成功した場合はトンネルが閉じられるまで両方向のデータの盲目的転送に挙動を制限することを要求します。トンネルは、1 つ以上のプロキシを通じてエンドツーエンドの仮想接続を作成するために一般に使用され、その後 TLS（Transport Layer Security, [TLS13]）などで保護できます。

CONNECT はこのメソッドに固有の特殊な形式のリクエストターゲットを使用し、これはトンネル宛先のホストとポート番号のみをコロンで区切って構成されます。デフォルトポートはなく、クライアントはリクエストターゲットが権限成分に省略されたポートを含む URI 参照に基づく場合でもポート番号を送信しなければなりません（MUST）。例えば：

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

サーバは空または無効なポート番号をターゲットとする CONNECT リクエストを拒否しなければなりません（通常は 400 (Bad Request) で応答します）。

CONNECT は接続のリクエスト/レスポンスの性質を変更するため、特定の HTTP バージョンはそのセマンティクスをプロトコルのワイヤフォーマットにマッピングする異なる方法を持つ場合があります。

CONNECT はプロキシへのリクエストでの使用を意図しています。受信者はリクエストターゲットで識別されるサーバへ直接接続するか、別のプロキシを使用するよう構成されている場合は次のインバウンドプロキシへ CONNECT リクエストを転送することでトンネルを確立できます。オリジンサーバは CONNECT を受け入れてもよい（MAY）ですが、多くのオリジンサーバは CONNECT を実装していません。

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

トンネルは、トンネル仲介者が一方の側が接続を閉じたことを検出したときに閉じられます：仲介者は未送信の送信元データを相手側へ送信しようと試み、両方の接続を閉じ、残された未配信データを破棄しなければなりません（MUST）。

プロキシ認証はトンネル作成の権限を確立するために使用されることがあります。例えば：

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 をサポートするプロキシは、その使用を既知の制限されたポート集合または構成可能な安全なターゲットリストに制限することが SHOULD です。

サーバは CONNECT に対する Transfer-Encoding や Content-Length ヘッダーフィールドを成功レスポンスで送信してはなりません（MUST NOT）。クライアントは成功した CONNECT レスポンスで受信した Content-Length や Transfer-Encoding を無視しなければなりません（MUST）。

CONNECT リクエストメッセージにはコンテンツがありません。CONNECT リクエストヘッダセクションの後に送信されるデータの解釈は使用中の HTTP バージョンに依存します。

CONNECT メソッドへのレスポンスはキャッシュ可能ではありません。

OPTIONS メソッドは、オリジンサーバまたは仲介者でターゲットリソースに利用可能な通信オプションに関する情報を要求します。このメソッドは、クライアントがリソースに関連するオプションや要件、またはサーバの能力をリソースアクションを意味せずに判定できるようにします。

リクエストターゲットがアスタリスク ("*") の OPTIONS リクエスト（Section 7.1）は、特定のリソースではなく一般的にサーバ自体に適用されます。サーバの通信オプションは通常リソースに依存するため、"*" リクエストはサーバの能力をテストするための "ping" や "no-op" 的な用途にのみ有用です。例えば、これはプロキシの HTTP/1.1 準拠性をテストするために使えます。

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

OPTIONS に対して成功レスポンスを生成するサーバは、ターゲットリソースに適用される可能性のある任意のオプション機能（例えば Allow）を示すヘッダを送信することが SHOULD です。レスポンスのコンテンツがある場合、それは通信オプションを機械可読または人間可読の表現で記述してもよいです。本仕様はそのような表現の標準形式を定義しませんが、将来の拡張で定義され得ます。

クライアントは OPTIONS リクエストに Max-Forwards を含めてリクエストチェイン内の特定の受信者をターゲットにすることが MAY です（詳細は Section 7.6.2）。プロキシは、受信したリクエストに Max-Forwards フィールドが含まれていない限り、転送時に Max-Forwards を生成してはなりません（MUST NOT）。

クライアントがコンテンツを含む OPTIONS リクエストを生成する場合、そのコンテンツのメディアタイプを記述する有効な Content-Type ヘッダーフィールドを送信しなければなりません（MUST）。本仕様はそのようなコンテンツの用途を定義していないことに注意してください。

OPTIONS メソッドへのレスポンスはキャッシュ可能ではありません。

TRACE メソッドは、リクエストメッセージのリモートなアプリケーションレベルでのループバックを要求します。リクエストの最終受信者は、以下に述べるいくつかのフィールドを除いて受信したメッセージをクライアントへ 200 (OK) レスポンスのコンテンツとして反映して返すべきです（SHOULD）。"message/http" 形式（Section 10.1 of [HTTP/1.1]）はその一手段です。最終受信者はオリジンサーバか、リクエスト内で Max-Forwards 値が 0 の最初のサーバです（Section 7.6.2参照）。

クライアントは、TRACE リクエストでレスポンスにより公開される可能性のある機密データを含むフィールドを生成してはなりません（MUST NOT）。例えば、ユーザーエージェントが保存した認証情報（Section 11）やクッキーを TRACE リクエストで送信するのは愚かです。リクエストの最終受信者は、レスポンスコンテンツを生成する際に機密データを含む可能性のあるリクエストフィールドを除外することが SHOULD です。

TRACE はクライアントがリクエストチェインの先端で何が受信されているかを確認し、テストや診断情報としてそれを使用できるようにします。Via ヘッダーフィールドの値は特に関心が高く、リクエストチェインのトレースとして機能します。Max-Forwards を使うことでクライアントはリクエストチェインの長さを制限でき、無限ループでメッセージを転送しているプロキシのチェインをテストするのに便利です。

クライアントは TRACE リクエストにコンテンツを送信してはなりません（MUST NOT）。

TRACE メソッドへのレスポンスはキャッシュ可能ではありません。

リクエスト内の "Expect" ヘッダーフィールドは、このリクエストを適切に処理するためにサーバがサポートする必要がある一連の振る舞い（期待）を示します。

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

Expect フィールド値は大文字小文字を区別しません。

本仕様で定義される唯一の期待は "100-continue"（パラメータは定義されていません）です。

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

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 の期待を生成してはなりません（MUST NOT）。
• 100 (Continue) の応答を待ってからリクエストコンテンツを送信するクライアントは、Expect ヘッダーフィールドに 100-continue の期待を含めて送信しなければなりません（MUST）。
• 100-continue の期待を送信したクライアントは、特定の時間待機することを要求されません。そのようなクライアントは応答をまだ受け取っていなくてもコンテンツを送信してよい（MAY）。さらに、100 (Continue) 応答は HTTP/1.0 の仲介者を通して送信できないため、そのようなクライアントは無期限に待つべきではありません（SHOULD NOT）。
• 100-continue の期待を含むリクエストに対して 417 (Expectation Failed) を受け取ったクライアントは、その 417 応答が期待をサポートしないチェーンを示すだけであるため、100-continue の期待なしで同じリクエストを繰り返すことが SHOULD です。

• HTTP/1.0 リクエストで 100-continue の期待を受け取ったサーバは、その期待を無視しなければなりません（MUST）。
• サーバは、対応するリクエストのコンテンツの一部または全部を既に受信している場合、またはフレーミングがコンテンツがないことを示している場合には、100 (Continue) 応答の送信を省略してよい（MAY）。
• 100 (Continue) 応答を送信するサーバは、リクエストコンテンツを受信および処理した後で最終的なステータスコードを必ず送信しなければなりません（接続が早期に切断される場合を除く）（MUST）。
• 最終的なステータスコードで応答する前にリクエストコンテンツ全体を読み取らずに応答したサーバは、接続を閉じる意図があるかどうかを示すべきです（例: Section 9.6 を参照）（SHOULD）。

• メソッド、ターゲット URI、およびヘッダーフィールドだけを検査して決定できる最終ステータスコードでの即時応答、または
• クライアントにリクエストコンテンツの送信を促す即時の 100 (Continue) 応答。

オリジンサーバは 100 (Continue) 応答を送る前にコンテンツを待ってはなりません（MUST NOT）。

• メソッド、ターゲット URI、およびヘッダーフィールドだけを検査して決定できる最終ステータスコードで即時に応答する、または
• 対応する request-line とヘッダセクションを次のインバウンドサーバに送信してリクエストをオリジンサーバ側へ転送する。

プロキシが（設定や過去の相互作用から）次のインバウンドサーバが HTTP/1.0 のみをサポートすると判断した場合、プロキシはクライアントにコンテンツの送信を促すために即時の 100 (Continue) 応答を生成してもよい（MAY）。

  From    = mailbox

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

From: spider-admin@example.org

非ロボット系のユーザーエージェントが From ヘッダーフィールドを送信することはまれです。ユーザーの設定が明示的にない限り、ユーザーエージェントはプライバシーやサイトのセキュリティポリシーと衝突する可能性があるため、From を送信すべきではありません（SHOULD NOT）。

ロボット系ユーザーエージェントは、問題が発生したときにロボットの運用責任者に連絡できるように、有効な From を送信することが望ましい（SHOULD）です。

サーバは From をアクセス制御や認証に使用すべきではありません（SHOULD NOT）。その値はリクエストを受信・観察する誰にでも見えると期待され、ログやエラーレポートに記録されることが多いため、プライバシーの期待はありません。

"Referer"（誤綴り）ヘッダーフィールドは、ユーザーエージェントがターゲット URI を取得したリソースの URI 参照（すなわち "referrer"）を指定することを可能にします。ユーザーエージェントは、Referer 値を生成する際にフラグメントおよび userinfo 成分があればそれらを含めてはなりません（MUST NOT）。

  Referer = absolute-URI / partial-URI

フィールド値は absolute-URI または partial-URI のいずれかです。後者の場合、参照される URI はターゲット URI に対して相対的です。

Referer フィールドは、サーバが単純な解析、ログ、最適化されたキャッシュなどのために他のリソースへのバックリンクを生成することを可能にします。また、保守のために誤ったリンクを発見するのにも役立ちます。いくつかのサーバは Referer を用いて他サイトからのリンクを拒否したり（いわゆる "deep linking"）、CSRF 防止のために利用したりしますが、すべてのリクエストが Referer を含むわけではありません。

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

ターゲット URI がユーザーのキーボード入力やブックマークのエントリなど、URI を持たないソースから取得された場合、ユーザーエージェントは Referer を除外するか、"about:blank" の値で送信しなければなりません（MUST）。

Referer の値は参照元リソースの完全な URI を伝える必要はありません。ユーザーエージェントは参照元オリジン以外の部分を切り詰めてもよい（MAY）。

Referer は、参照元の識別子が個人情報や機密リソース（ファイアウォール内など）を示す場合に、リクエストコンテキストや閲覧履歴の情報を露出する可能性があり、プライバシー上の懸念があります。ほとんどの一般的なユーザーエージェントは、参照元が "file" や "data" URI の場合に Referer を送信しません。参照元が安全なプロトコルでアクセスされ、リクエストターゲットのオリジンが異なる場合、ユーザーエージェントは Referer を送信すべきではありません（SHOULD NOT）。参照元が安全なプロトコルでアクセスされていて、リクエストが非安全な HTTP で行われる場合、ユーザーエージェントは Referer を送信してはなりません（MUST NOT）。追加のセキュリティ考慮事項については Section 17.9 を参照してください。

いくつかの仲介者は Referer を無差別に削除することが知られています。これは CSRF 対策を妨げる副作用を生み、ユーザーにとってより有害になり得ます。仲介者や拡張機能が Referer 情報の開示を制限したい場合は、内部ドメイン名を偽名に置き換える、クエリやパスを切り詰めるなど特定の編集に限定すべきです。仲介者は、フィールド値がターゲット URI と同じスキームとホストを共有する場合に Referer を変更または削除してはなりません（SHOULD NOT）。

"TE" ヘッダーフィールドは、トランスファーコーディングおよびトレーラセクションに関してクライアントが持つ能力を記述します。

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

TE はまた HTTP/1.1 内で、クライアントがレスポンスで受け入れ可能なトランスファーコーディングについてサーバに通知するためにも使用されます。公開時点では、トランスファーコーディングを使用しているのは HTTP/1.1 のみです（Section 7 of [HTTP/1.1] を参照）。

TE フィールド値はメンバのリストで、"trailers" を除く各メンバはトランスファーコーディング名トークンと、そのトランスファーコーディングに対するクライアントの相対的な好み（品質値）を示すオプションの重み、およびそのトランスファーコーディングのオプションパラメータから構成されます。

  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 ヘッダーフィールド内に "TE" の接続オプションも送らなければなりません（Section 7.6.1）。

"User-Agent" ヘッダーフィールドはリクエストの発信元であるユーザーエージェントに関する情報を含み、サーバは相互運用性問題の範囲を特定したり、特定のユーザーエージェントの制約を回避するために応答を調整したり、ブラウザや OS の使用状況解析のためにこれを利用することがよくあります。ユーザーエージェントは、特に設定で無効化されていない限り、各リクエストで User-Agent を送信することが望まれます（SHOULD）。

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

User-Agent フィールド値は一つ以上の product 識別子と、それに続く 0 個以上のコメントで構成され、合わせてユーザーエージェントソフトウェアとその重要なサブプロダクトを識別します。慣習として、product 識別子は重要度の高い順に列挙されます。各 product 識別子は名前とオプションのバージョンで構成されます。

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

送信者は製品を識別するために必要な範囲に product 識別子を制限すべきであり（SHOULD）、広告等の非本質的情報を product 識別子内に含めてはなりません（MUST NOT）。また、product-version にバージョン以外の情報を生成してはなりません（連続するバージョンは product-version 部分だけが異なるべきです）（SHOULD NOT）。

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

ユーザーエージェントは過度に細かい情報を含む User-Agent を生成してはなりません（SHOULD NOT）。第三者によるサブプロダクトの追加も制限すべきです（SHOULD）。過度に長大で詳細な User-Agent はリクエストレイテンシーを増やし、ユーザーの望まない形での識別（"fingerprinting"）のリスクを高めます。

同様に、実装は互換性を宣言するために他の実装の product トークンを使用することを避けるべきです。そうした偽装は、受信者に対してその識別されたユーザーエージェント向けに応答を最適化することを意図していると仮定させ、実際のユーザーエージェントではうまく動作しない可能性があります。

"Allow" ヘッダーフィールドは、ターゲットリソースがサポートすると宣伝しているメソッドの集合を列挙します。このフィールドの目的は、リソースに関連付けられた有効なリクエストメソッドを受信者に知らせることに限定されます。

  Allow = #method

Allow: GET, HEAD, PUT

実際の許可メソッド集合は各リクエスト時点でオリジンサーバによって定義されます。オリジンサーバは 405 (Method Not Allowed) のレスポンスで Allow を生成しなければなりません（MUST）し、他のレスポンスでは生成してもよい（MAY）。空の Allow 値はそのリソースがメソッドを許可していないことを示します。これはリソースが一時的に無効化されている場合に 405 レスポンスで発生することがあります。

プロキシは Allow ヘッダーフィールドを変更してはなりません（MUST NOT） — 指示されたメソッドを理解する必要はなく、汎用のメッセージ処理規則に従って処理すればよいからです。

"Location" ヘッダーフィールドは、レスポンスに関連して特定のリソースを参照するためにいくつかのレスポンスで使用されます。関係の種類はリクエストメソッドとステータスコードの組み合わせにより定義されます。

  Location = URI-reference

フィールド値は単一の URI-reference から成ります。相対参照の形であれば、その最終値はターゲット URI に対して解決されます。

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

3xx レスポンスで提供された Location 値にフラグメント成分がない場合、ユーザーエージェントはその値がターゲット URI を生成するために使われた参照のフラグメント成分を継承するかのようにリダイレクトを処理しなければなりません（元の参照のフラグメントがあればそれを継承します）（MUST）。

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" へリダイレクトして元のフラグメント識別子を保持することを示唆します。

Location 値にフラグメント識別子が不適切な場合もあります。例えば、201 レスポンス内の Location は作成されたリソース固有の URI を提供することが期待されます。

サーバは "Retry-After" を送信して、ユーザーエージェントがフォローアップリクエストを行う前にどれだけ待つべきかを示します。503 (Service Unavailable) に添えて送る場合、Retry-After はそのサービスがクライアントに対して利用できなくなると予想される期間を示します。任意の 3xx レスポンスに添える場合、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" ヘッダーフィールドは、要求を処理するためにオリジンサーバが使用しているソフトウェアに関する情報を含みます。クライアントは相互運用性の問題の範囲を特定したり、特定のサーバの制約を回避するためにリクエストを調整したり、サーバや OS の使用状況解析のためにこれを利用します。オリジンサーバはレスポンスで Server ヘッダーフィールドを生成してもよい（MAY）です。

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

Server フィールド値は一つ以上の product 識別子と、それに続く 0 個以上のコメントで構成され、合わせてオリジンサーバソフトウェアとその重要なサブプロダクトを識別します。慣習として、product 識別子は重要度の高い順に列挙されます。各 product 識別子は名前とオプションのバージョンで構成されます（Section 10.1.5 参照）。

Server: CERN/3.0 libwww/2.17

オリジンサーバは過度に細かな情報を含む Server を生成してはなりません（SHOULD NOT）し、第三者によるサブプロダクトの追加は制限すべきです（SHOULD）。過度に長大で詳細な Server 値は応答のレイテンシを増し、内部実装の詳細を暴露して既知の脆弱性を悪用されやすくする可能性があります。

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

  WWW-Authenticate = #challenge

オリジンサーバが 401 (Unauthorized) を生成する場合、少なくとも一つのチャレンジを含む WWW-Authenticate ヘッダーフィールドを送信しなければなりません（MUST）。サーバは他のレスポンスメッセージでも、資格情報の供給（または別の資格情報）がレスポンスに影響するかもしれないことを示すために WWW-Authenticate を生成してもよい（MAY）です。

プロキシがレスポンスを転送する場合、そのレスポンス内のいかなる WWW-Authenticate ヘッダーフィールドも変更してはなりません（MUST NOT）。

ユーザーエージェントはフィールド値の解析に際して注意を払うべきです。フィールド値は複数のチャレンジを含み得、各チャレンジはカンマ区切りのパラメータ一覧を含むことができ、さらにヘッダーフィールド自体が複数回出現する可能性があるためです。

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

このヘッダーフィールドは "Basic" スキームの realm="simple" のチャレンジと、"Newauth" スキームの realm="apps" のチャレンジを含んでいます。また "type" と "title" という追加のパラメータも含んでいます。

ただし、一部のユーザーエージェントはこの形式を認識しないことがあります。そのため、同一フィールド行に複数メンバーを含む WWW-Authenticate を送信するのは相互運用性の観点から問題が生じることがあります。

"Authorization" ヘッダーフィールドは、オリジンサーバに対してユーザーエージェントが自身を認証することを可能にします。通常は 401 (Unauthorized) を受け取った後に使用されます。その値は、要求されたリソースの realm に対するユーザーエージェントの認証情報を含む資格情報から構成されます。

  Authorization = credentials

リクエストが認証されていて realm が指定されている場合、同じ資格情報は（認証スキーム自体が異なる要求を課していない限り）その realm 内の他のすべてのリクエストに対して有効であると見なされます（例: チャレンジ値に応じて資格情報が変わるスキームや同期時計を使うスキームを除く）。

プロキシがリクエストを転送する場合、そのリクエスト内の Authorization を変更してはなりません（MUST NOT）。認証されたリクエストに対するレスポンスの保存に関する詳細と要件は Section 3.5 of [CACHING] を参照してください。

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

フィールド値はパラメータ（name/value ペア）のリストであり、これは Section 11.3 で定義された "auth-param" 構文を使用します。本仕様は一般的な形式のみを示し、Authentication-Info を使用する認証スキームは個々のパラメータを定義します。例えば "Digest" 認証スキームは複数のパラメータを Section 3.5 of [RFC7616] で定義しています。

  Authentication-Info = #auth-param

Authentication-Info フィールドは、リクエストメソッドやステータスコードに依存せず任意の HTTP レスポンスで使用できます。そのセマンティクスは、対応するリクエストの Authorization ヘッダーフィールド（Section 11.6.2）で示された認証スキームによって定義されます。

レスポンスを転送するプロキシはフィールド値を何ら変更してはなりません。

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

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

  Proxy-Authenticate = #challenge

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

WWW-Authenticate の解析に関する注意点はこのヘッダーフィールドにも適用されます。詳細は Section 11.6.1 を参照してください。

"Proxy-Authorization" ヘッダーフィールドは、認証を要求するプロキシに対してクライアント（またはそのユーザー）が自身を識別することを可能にします。その値はプロキシおよび/または要求されたリソースの realm に対するクライアントの認証情報を含む資格情報から構成されます。

  Proxy-Authorization = credentials

Authorization と異なり、Proxy-Authorization はチャレンジを要求した次のインバウンドプロキシのみに適用されます。複数のプロキシがチェインで使われる場合、Proxy-Authorization は期待している最初のインバウンドプロキシによって消費されます。プロキシは、プロキシ間で協調して認証を行う仕組みである場合、クライアントからの資格情報を次のプロキシへ中継してもよい（MAY）です。

  Proxy-Authentication-Info = #auth-param

ただし Authentication-Info と異なり、Proxy-Authentication-Info ヘッダーフィールドはレスポンスチェーン上の次の外向きクライアントにのみ適用されます。これは、あるプロキシを選択したクライアントだけがその認証に必要な資格情報を持つ可能性が高いためです。しかし、同一管理ドメイン内で複数のプロキシが使われる構成では、資格情報がユーザーエージェントによって生成され階層を通して渡されることが一般的であり、その場合は Proxy-Authentication-Info が転送されているかのように見えます。

Proxy-Authentication-Info は、認証スキームが明示的に許可する場合にトレーラーフィールド（Section 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 桁より多く生成してはなりません（MUST NOT）。ユーザーによるこれらの値の設定も同様に制限されるべきです。

多くのこれらのヘッダーフィールドは、指定された場合に未指定の値を選択するワイルドカード値（"*"）を定義します。ワイルドカードが存在しない場合、フィールド内で明示的に言及されていない値は受け入れ不可能と見なされます。Vary 内では、ワイルドカード値は分散が無制限であることを意味します。

"Accept" ヘッダーフィールドは、ユーザーエージェントがレスポンスのメディア型に関する好みを指定するために使用できます。例えば、インライン画像を要求する場合のようにリクエストが特定の小さな型の集合に限定されることを示すために Accept を使用できます。

サーバがレスポンスで送信する場合、Accept は同じリソースへの将来のリクエストでどのコンテンツ型が好まれるかについての情報を提供します。

  Accept = #( media-range [ weight ] )

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

アスタリスク "*" 文字はメディア型を範囲にグループ化するために用いられ、"*/*" はすべてのメディア型を示し、"type/*" はその type のすべてのサブタイプを示します。media-range にはその範囲に適用されるメディアタイプパラメータを含めることができます。

各 media-range の後に、適用可能なメディアタイプパラメータ（例：charset）および相対的な重みを示すオプションの "q" パラメータ（Section 12.4.2）を続けることができます。

以前の仕様では重みパラメータの後に追加拡張パラメータが現れることを許していましたが、accept extension 文法（accept-params, accept-ext）は複雑で実務で用いられていなかったため除去され、新しいヘッダーフィールドで展開する方が容易です。重みを送信する送信者は "q" を最後に送ることが望ましい（SHOULD）。受信者はパラメータ順に関係なく "q" という名前のパラメータを重みとして処理すべきです（SHOULD）。

例：

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 を送ってほしい」となります。

メディア範囲はより具体的なメディア範囲や特定のメディア型によって上書きされ得ます。ある型に複数のメディア範囲が適用される場合、最も具体的な参照が優先されます。例えば：

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

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

与えられた型に関連付けられるメディアタイプの品質係数は、その型に一致する最高優先度のメディア範囲を見つけることで決定されます。例えば：

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" ヘッダーフィールドは、テキストレスポンスの文字セットに関するユーザーエージェントの好みを示すために送信され得ます。例えば、より包括的または特殊用途の文字セットを理解できるユーザーエージェントは、それらの文字セットで情報を表現できるオリジンサーバにその能力を示すことができます。

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

文字セット名は Section 8.3.2 で定義されています。ユーザーエージェントは各文字セットに品質値を関連付けてユーザーの相対的好みを示してもよい（MAY）（Section 12.4.2参照）。例：

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

Accept-Charset に特別値 "*" が含まれている場合、フィールド内で他に言及されていないすべての文字セットと一致します。

"Accept-Encoding" ヘッダーフィールドは、コンテンツコーディング（Section 8.4.1）の使用に関する好みを示すために使用できます。

ユーザーエージェントがリクエストで送信する場合、Accept-Encoding はレスポンスで受け入れ可能なコンテンツコーディングを示します。

サーバがレスポンスで送信する場合、Accept-Encoding は同じリソースへの将来のリクエストにおいてどのコンテンツコーディングが好まれるかについての情報を提供します。

"identity" トークンは「エンコーディングなし」の同義語として使用され、エンコーディングが望まれない場合を伝えます。

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

各 codings 値にはそのエンコーディングに対する優先度を表す品質値（重み）を関連付けることができます（Section 12.4.2）。Accept-Encoding 内のアスタリスク "*" はフィールド内で明示的に列挙されていない任意の利用可能なコンテンツコーディングと一致します。

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 ヘッダーフィールドがない場合、任意のコンテンツコーディングはユーザーエージェントにとって受け入れ可能と見なされます。
2. 表現にコンテンツコーディングが無い場合、それはデフォルトで受け入れ可能ですが、Accept-Encoding ヘッダーフィールドが "identity;q=0" または "*;q=0" を示しており、かつ "identity" に対するより具体的なエントリが存在しない場合は除外されます。
3. 表現のコンテンツコーディングが Accept-Encoding フィールド値に列挙されているコンテンツコーディングの一つである場合、そのエントリの qvalue が 0 でない限り受け入れ可能です（Section 12.4.2 に定義される通り、qvalue が 0 は「受け入れ不可」を意味します）。

表現は複数のコンテンツコーディングで符号化され得ます。しかし、多くのコンテンツコーディングは同じ目的（例：データ圧縮）を達成する代替手段です。同じ目的を持つ複数のコンテンツコーディングの間で選択する場合、最も高い非ゼロ qvalue を持つ受け入れ可能なコーディングが優先されます。

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

レスポンスに Accept-Encoding ヘッダーフィールドが含まれている場合、それは対応するリクエストでそのリソースが受け入れたかったコンテンツコーディングを示します。フィールド値の評価はリクエスト時と同様です。

この情報は対応するリクエスト固有であることに注意してください；同一サーバ上の他のリソースでサポートされるエンコーディングの集合は異なり得、時間と共に変化したりリクエストの他の側面（例えばリクエストメソッド）に依存したりします。

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

Accept-Encoding の最も一般的な使用例は、クライアントによる楽観的なコンテンツコーディングの使用に対して 415 で応答する場合のレスポンスです。しかしながら、このヘッダーフィールドは将来のやり取りを最適化するために、クライアントにコンテンツコーディングがサポートされていることを示すためにも使用できます。例えば、リクエストコンテンツが大きく圧縮が正当化されるがクライアントが失敗した場合、リソースは 2xx (Successful) レスポンスにそれを含めることがあります。

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

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

各 language-range に対して品質値を関連付け、ユーザーがその範囲で指定された言語に対してどれだけ好むかの推定を表現できます（Section 12.4.2を参照）。例：

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

は「デンマーク語を優先するが、英国英語や他の英語も受け入れる」という意味になります。

一部の受信者は、品質値が等しいタグに対してリスト中の順序を降順優先度の指示として扱いますが、この挙動は信頼できません。互換性を高めるため、多くのユーザーエージェントは各言語タグに固有の品質値を割り当てつつ、品質の降順で列挙することがあります。言語優先リストの追加議論は Section 2.3 of [RFC4647] を参照してください。

マッチングについては、いくつかのマッチング方式が Section 3 of [RFC4647] に定義されています。実装は要件に最適なマッチング方式を提供できます。Basic Filtering 方式（[RFC4647]、Section 3.3.1）は以前の HTTP 定義と同一です。

ユーザーの言語設定を毎回のリクエストで完全に送信することはプライバシー期待に反する場合があります（Section 17.13）。

可読性は個々のユーザーに大きく依存するため、ユーザーエージェントは言語優先設定をユーザーが制御できるようにする必要があります（ユーザーエージェント自体の設定やシステム設定に委ねるなど）。そのような制御をユーザーに提供しないユーザーエージェントは Accept-Language を送信してはなりません（MUST NOT）。

レスポンスの "Vary" ヘッダーフィールドは、メソッドとターゲット URI を除いて、どのリクエストメッセージの部分がこのレスポンスの内容選択に影響を与え得るかを記述します。

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

Vary フィールド値はワイルドカード "*" か、選択ヘッダーフィールドとして動作した可能性のあるリクエストフィールド名のリストのいずれかです。選択のためのヘッダーフィールドは本仕様で定義されたものに限りません。

メンバー "*" を含むリストは、リクエストの他の側面（例えばクライアントのネットワークアドレスなどメッセージ構文外の要素）もレスポンス表現の選択に寄与した可能性があることを示します。受信者はこのレスポンスが後のリクエストに適切かどうかを判定できず、リクエストをオリジンサーバに転送する必要があるかもしれません。プロキシは Vary の値に "*" を生成してはなりません（MUST NOT）。

例えば、次を含むレスポンスは

Vary: accept-encoding, accept-language

は、オリジンサーバがこのレスポンスの表現を選択する際にリクエストの Accept-Encoding および Accept-Language ヘッダーフィールド（またはそれらの欠如）を決定要因として用いた可能性があることを示します。

1. キャッシュ受信者に対し、このレスポンスを後のリクエストに用いるのは、元のリクエストと同じリストされたヘッダーフィールド値を持つ場合に限る、またはオリジンサーバが再利用を検証した場合に限ることを通知すること（Section 4.1 of [CACHING] を参照）。言い換えれば、Vary は新しいリクエストが保存済みのキャッシュエントリにマッチするために必要なキャッシュキーを拡張します。

2. ユーザーエージェント受信者に対し、このレスポンスがコンテンツ交渉（Section 12）の対象であったこと、並びにリストされたヘッダーフィールドに別の値が提供された場合に異なる表現が将来のリクエストで送られ得ることを通知すること。

オリジンサーバは、レスポンス内容を後続リクエストに対して選択的に再利用してほしい場合、キャッシュ可能なレスポンスに対して Vary ヘッダーフィールドを生成することが望ましい（SHOULD）です。一般に、これはレスポンス内容が選択ヘッダーフィールドで表現された好みに合わせて調整されている場合に該当します。例えばオリジンサーバがリクエストの Accept-Language に基づいてレスポンスの言語を選択した場合です。

Vary は、コンテンツ選択における分散がキャッシュのパフォーマンス影響よりも重要でないとオリジンサーバが判断する場合には省略され得ます。特に再利用がキャッシュレスポンスディレクティブによって既に制限されている時などです（Section 5.2 of [CACHING] を参照）。

Authorization フィールド名を Vary に送る必要はありません。なぜならそのフィールドの定義により異なるユーザーに対するレスポンスの再利用は禁止されているからです（Section 11.6.2）。同様に、レスポンス内容がネットワーク領域によって選択または影響されているが、オリジンサーバが受信者が別の領域に移動してもキャッシュされたレスポンスを再利用してほしいと考える場合、オリジンサーバはそのような分散を Vary に示す必要はありません。

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

オリジンサーバは If-Match のエンティティタグを比較する際に強比較関数を使用しなければなりません（Section 8.8.3.2）。これはクライアントが表現データにいかなる変更があってもメソッドの適用を防止することを意図しているためです（MUST）。

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

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

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

オリジンサーバが表現を選択し、かつ If-Match ヘッダーフィールドを含むリクエストを受け取った場合、オリジンサーバはメソッドを実行する前に Section 13.2MUST）。

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

If-Match 条件を評価したオリジンサーバは、その条件が false と評価された場合に要求されたメソッドを実行してはなりません（MUST NOT）。代わりに、オリジンサーバは条件付きリクエストが失敗したことを示すために 412 (Precondition Failed) で応答してもよい（MAY）。あるいは、要求が選択された表現に既に適用されているように見える状態変更操作である場合、オリジンサーバは 2xx (Successful) で応答してもよい（つまり、ユーザーエージェントが prior response を失ったなどの理由でその変更が成功したことを認識していない可能性がある）。

変更要求が既に適用されていると見なされる場合に成功レスポンスを返すことは多くの作成系ユースケースで効率的ですが、非常に類似した変更要求を複数のユーザーエージェントが互いに協調せずに行う場合にはリスクを伴います。例えば、複数のユーザーエージェントが共通リソースにセマフォのように書き込む（非原子的なインクリメントなど）と衝突して重要な状態遷移を失う可能性があります。そのようなリソースに対しては、オリジンサーバは安全でないメソッドの失敗した前提条件に対して 412 を送出することを厳格に行う方が良いでしょう。他の場合では、成功レスポンスから ETag フィールドを除外することがユーザーエージェントに GET を次のリクエストとして行わせ、リソースの現在の状態に関する混乱を排除することを促すかもしれません。

クライアントは If-Match ヘッダーフィールドを GET リクエストに送信して、選択された表現が一致しない場合に 412 (Precondition Failed) 応答を望むことを示すことができますが（MAY）、これはレンジリクエスト（Section 14）でのみ有用であり、新しい表現を望まない場合に以前受け取った部分的表現を完成させるために使われます。レンジリクエストでクライアントが新しい表現を好む場合は If-Range（Section 13.1.5）の方が適しています。

キャッシュや仲介者は If-Match を無視してもよい（MAY）——その相互運用性機能はオリジンサーバにのみ必要なためです。

一覧値に "*" と他の値（他の "*" のインスタンスを含む）を含む If-Match ヘッダーフィールドは構文的に無効であり（生成してはならない）、相互運用性も期待できません。

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

受信者は If-None-Match のエンティティタグを比較する際に弱比較関数を使用しなければなりません（Section 8.8.3.2）。弱いエンティティタグは表現データに変化があってもキャッシュ検証に用いられる可能性があるためです（MUST）。

  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 リクエストで使用され、キャッシュされた情報を最小限のトランザクションオーバーヘッドで効率的に更新することを可能にします。クライアントがエンティティタグを持つ1つ以上の保存済みレスポンスを更新したい場合、クライアントは GET リクエストを行う際にこれらエンティティタグの一覧を含む If-None-Match を生成するべきです（SHOULD）。これにより受信サーバは選択された表現が一致する場合に 304 (Not Modified) を返すことができます。

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

オリジンサーバが表現を選択し、かつ If-None-Match ヘッダーフィールドを含むリクエストを受け取った場合、オリジンサーバはメソッドを実行する前に Section 13.2 に従って If-None-Match 条件を評価しなければなりません（MUST）。

1. If フィールド値が "*" の場合、オリジンサーバがターゲットリソースの現在の表現を持っているならば条件は false です。
2. If フィールド値がエンティティタグの一覧である場合、一覧中のどれかのタグが選択された表現のエンティティタグと一致するならば条件は false です。
3. それ以外の場合、条件は true です。

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

受信した If-None-Match ヘッダーフィールドのキャッシュ処理に関する要求は Section 4.3.2 of [CACHING] に定義されています。

"*" と他の値（別の "*" を含む）を含む一覧値を持つ 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 を無視しなければなりません（MUST）。If-None-Match の条件は If-Modified-Since の条件に対するより正確な置換と見なされ、両者が組み合わされるのは If-None-Match を実装しない古い仲介者との相互運用のためだけです。

受信者は、受信した If-Modified-Since フィールド値が有効な HTTP-date でない場合、そのヘッダーフィールドを無視しなければなりません（複数メンバーがある場合やリクエストメソッドが GET または HEAD でない場合も無視する）（MUST）。

受信者は、リソースに変更日時が利用できない場合、If-Modified-Since を無視しなければなりません（MUST）。

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

If-Modified-Since は通常二つの目的で使用されます：1) エンティティタグを持たないキャッシュ表現の効率的な更新、2) 最近変更されたリソースに取得の範囲を限定するため。

キャッシュ更新に使用される場合、キャッシュは典型的に保存済みメッセージの Last-Modified ヘッダーフィールドの値を If-Modified-Since のフィールド値生成に用います。この動作はクロックが同期していない場合やサーバが正確なタイムスタンプ一致のみを尊重する場合に最も相互運用的です。ただし、キャッシュは保存メッセージに Last-Modified が含まれない場合に cached message の Date や受信時のクライアントの時計に基づいてフィールド値を生成することがあります。

最近の時間窓に取得を限定するために使用される場合、ユーザーエージェントは自身の時計または以前のレスポンスでサーバから受け取った Date ヘッダーフィールドに基づいて If-Modified-Since を生成します。選択された表現の Last-Modified に基づく正確なタイムスタンプ一致を選ぶオリジンサーバは、指定されたウィンドウ内に変化したもののみにデータ転送を限定するようユーザーエージェントを助けることはできません。

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

1. 選択された表現の最終更新日時がフィールド値で提供された日付より前か等しい場合、条件は false です。
2. それ以外の場合、条件は true です。

If-Modified-Since 条件を評価したオリジンサーバは、条件が false と評価された場合に要求されたメソッドを実行すべきではありません（SHOULD NOT）。代わりに、オリジンサーバは以前にキャッシュされたレスポンスの識別または更新に有用なメタデータのみを含む 304 (Not Modified) を生成することが望ましい（SHOULD）。

受信した If-Modified-Since のキャッシュ処理に関する要件は Section 4.3.2 of [CACHING] に定義されています。

"If-Unmodified-Since" ヘッダーフィールドは、選択された表現の最終更新日時がフィールド値に提供された日付より前または等しいことを条件としてリクエストメソッドを適用します。このフィールドは、ユーザーエージェントが表現のエンティティタグを持たない場合に If-Match と同じ目的を果たします。

  If-Unmodified-Since = HTTP-date

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

受信者はリクエストに If-Match が含まれている場合、If-Unmodified-Since を無視しなければなりません（MUST）。If-Match の条件は If-Unmodified-Since の条件に対するより正確な置換と見なされ、両者が組み合わされるのは古い仲介者との相互運用のためだけです。

受信者は If-Unmodified-Since のフィールド値が有効な HTTP-date でない場合（複数日付の一覧に見える場合を含む）、そのフィールドを無視しなければなりません（MUST）。

受信者はリソースに変更日時が利用できない場合、If-Unmodified-Since を無視しなければなりません（MUST）。

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

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

オリジンサーバが表現を選択し、かつ If-Unmodified-Since を If-Match なしで含むリクエストを受け取った場合、オリジンサーバはメソッドを実行する前に Section 13.2 に従って If-Unmodified-Since 条件を評価しなければなりません（MUST）。

1. 選択された表現の最終更新日時がフィールド値で提供された日付より前または等しい場合、条件は true です。
2. それ以外の場合、条件は false です。

If-Unmodified-Since 条件を評価したオリジンサーバは、その条件が false と評価された場合に要求されたメソッドを実行してはなりません（MUST NOT）。代わりに、オリジンサーバは条件付きリクエストが失敗したことを示すために 412 (Precondition Failed) で応答してもよい（MAY）。あるいは、要求が選択された表現に既に適用されているように見える場合、オリジンサーバは 2xx (Successful) で応答してもよい（ユーザーエージェントが prior response を失った等の理由で変更がすでに成功している可能性があるため）。

変更要求が既に適用されていると見なされる場合に成功レスポンスを返すことは多くのユースケースで効率的ですが、協調しない複数のユーザーエージェントが非常に類似した変更要求を行う場合にはリスクがあります。そのような場合、オリジンサーバは安全でないメソッドの失敗した前提条件に対して 412 を厳格に送る方が良いでしょう。

クライアントは If-Unmodified-Since を GET リクエストで送信して、選択された表現が変更されている場合に 412 (Precondition Failed) を望むことを示せます（MAY）。しかしこれはレンジリクエスト（Section 14）でのみ有用であり、部分的に受け取った表現を完成させたい場合に限られます。レンジリクエストでクライアントが新しい表現を好む場合は If-Range（Section 13.1.5）が適しています。

キャッシュや仲介者は If-Unmodified-Since を無視してもよい（MAY）——その相互運用性機能はオリジンサーバにのみ必要なためです。

"If-Range" ヘッダーフィールドは、If-Match や If-Unmodified-Since に類似する特殊な条件付きリクエストメカニズムを提供しますが、バリデータが一致しない場合に Range ヘッダーフィールドを無視するよう受信者に指示し、その結果 412 (Precondition Failed) ではなく新しい selected representation の転送を行わせます。

クライアントが表現の部分的コピーを持ち、完全な最新コピーを得たい場合、Range ヘッダーフィールドを条件付き GET と共に使用できます（If-Unmodified-Since と/または If-Match のいずれかまたは両方）。しかし、前提条件が表現の変更により失敗すると、クライアントは全体の現在表現を取得するために二度目のリクエストを行わなければなりません。

"If-Range" ヘッダーフィールドはクライアントがその二回目のリクエストを「ショートサーキット」できるようにします。非公式にはその意味は次の通りです：表現が変更されていなければ私が Range で要求している部分を送ってください；そうでなければ表現全体を送ってください。

  If-Range = entity-tag / HTTP-date

有効な entity-tag は、最初の三文字を調べることで有効な HTTP-date と区別できます（DQUOTE で始まるかどうかで判別）。

クライアントは Range ヘッダーフィールドを含まないリクエストで If-Range を生成してはなりません（MUST NOT）。サーバは Range ヘッダーフィールドを含まないリクエストで受信した If-Range を無視しなければなりません（MUST）。また、ターゲットリソースが Range リクエストをサポートしない場合に受信した If-Range ヘッダーフィールドはオリジンサーバが無視しなければなりません（MUST）。

クライアントは弱いとマークされたエンティティタグを含む If-Range を生成してはなりません（MUST NOT）。また、If-Range に HTTP-date を含めてはなりません（MUST NOT）、ただし対応する表現に対するエンティティタグを持たない場合で、その日付が Section 8.8.2.2 で定義される強いバリデータである場合は例外です。

サーバは Range リクエストで If-Range を受け取った場合、メソッドを実行する前に Section 13.2 に従って条件を評価しなければなりません（MUST）。

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

1. 提供された entity-tag バリデータが選択された表現の ETag フィールド値と強比較関数によって正確に一致する場合、条件は true です（Section 8.8.3.2）。
2. それ以外の場合、条件は false です。

If-Range ヘッダーフィールドの受信者は、If-Range 条件が false と評価された場合に Range を無視しなければなりません（MUST）。そうでない場合、受信者は要求どおりに Range を処理することが望まれます（SHOULD）。

If-Range の比較は正確一致によることに注意してください。これはバリデータが HTTP-date の場合でも同様であり、If-Unmodified-Since の評価で用いられる「以前か等しい」比較とは異なります。

以下に除外されている場合を除き、受信したリクエスト前提条件は、受信者キャッシュまたはオリジンサーバが通常のリクエストチェックを正常に実行した後かつリクエストコンテンツ（ある場合）を処理する直前に評価しなければなりません（MUST）。サーバは、もしそれらの前提条件を無くして同じリクエストに対して処理前に返すレスポンスが 2xx (Successful) または 412 (Precondition Failed) 以外のステータスコードであるならば、受信したすべての前提条件を無視しなければなりません。言い換えれば、重大な処理が発生する前に検出できるリダイレクトや失敗は前提条件の評価より優先されます。

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

プロトコル拡張は、前提条件が評価される条件やその評価結果の帰結を変更することがあります。例えば immutable cache 指示子（[RFC8246] によって定義）は、キャッシュが新鮮なレスポンスを保持している場合に条件付きリクエストの転送を行わないように指示します。

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

リクエストに複数の条件付きリクエストヘッダーフィールドが存在する場合、どの順序でフィールドを評価するかが重要になります。実務では、本ドキュメントで定義されたフィールドは単一の論理的順序で一貫して実装されています。というのも、「失われた更新」対策はキャッシュ検証より厳格な要件を持ち、検証済みキャッシュは部分的レスポンスより効率的であり、エンティティタグは日付バリデータより正確であると想定されるからです。

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

   • 真であれば、ステップ 3 に進みます
   • 偽であれば、状態変更リクエストが既に成功していると判断できない限り 412 (Precondition Failed) で応答します（詳細は Section 13.1.1 を参照）

2. 受信者がオリジンサーバであり If-Match が存在せず、かつ If-Unmodified-Since が存在する場合、If-Unmodified-Since 前提条件を評価します：

   • 真であれば、ステップ 3 に進みます
   • 偽であれば、状態変更リクエストが既に成功していると判断できない限り 412 (Precondition Failed) で応答します（詳細は Section 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 が selected representation に適用可能であれば 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 excluding comma)

ranges-specifier が示された range-unit に対して無効または未定義の range-spec を含む場合、その ranges-specifier は無効です。

有効な ranges-specifier は、示された range-unit によって定義されるとおり、少なくとも一つの満たし得る（range-spec）を含む場合に satisfiable と見なされます。そうでなければその ranges-specifier は unsatisfiable です。

"bytes" レンジ単位は、表現データのオクテット列のサブレンジを表現するために使用されます。各バイトレンジは、表現データの先頭（int-range）または末尾（suffix-range）に相対的なオフセットとして整数レンジで表されます。バイトレンジは other-range 指定子を使用しません。

int-range の first-pos 値はレンジ内の最初のバイトのオフセットを与えます。last-pos 値はレンジ内の最後のバイトのオフセットを与えます；つまり指定されたバイト位置は包含的です。バイトオフセットはゼロから始まります。

表現データにコンテンツコーディングが適用されている場合、各バイトレンジはデコード後の基底バイト列ではなく、エンコードされたバイト列に関して計算されます。

• 最初の 500 バイト（バイトオフセット 0-499、包含）：

  bytes=0-499
  

• 二番目の 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
  

• 二番目の 500 バイト（500-999）を表す他の有効だが標準的でない指定例：

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

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

選択された表現の長さがゼロの場合、GET リクエストにおける range-spec の唯一の satisfiable 形は、非ゼロの suffix-length を持つ suffix-range です。

バイトレンジ構文では、first-pos、last-pos、および suffix-length はオクテットの10進数で表現されます。コンテンツの長さに事前定義された上限がないため、受信者は非常に大きな10進数に備え、整数変換によるオーバーフローでの解析エラーを防止しなければなりません（MUST）。

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

リクエストに Expect ヘッダーフィールドが含まれ、その中に 100-continue 期待がある場合、100 レスポンスはサーバがリクエスト本文の送信を望んでいることを示します（Section 10.1.1 を参照）。クライアントはリクエストの送信を続け、100 レスポンスは破棄すべきです。

リクエストに Expect ヘッダーフィールドが含まれておらず、100-continue 期待がない場合、クライアントはこの中間レスポンスを単に破棄できます。

101 (Switching Protocols) ステータスコードは、サーバがクライアントの要求（Upgrade ヘッダーフィールド）に基づきこの接続で使用するアプリケーションプロトコルの変更に同意し、それに従うことを示します。サーバは、どのプロトコルがこのレスポンスの後に適用されるかを示す Upgrade ヘッダーフィールドをレスポンスで生成しなければなりません（MUST）。

サーバは、プロトコル切替が有利な場合にのみ同意することが想定されます。例えば、古いバージョンより新しい HTTP バージョンに切り替えることや、リアルタイム・同期プロトコルに切り替えることが有利な場合があります。

CONNECT に対するレスポンスを除き、200 レスポンスはメッセージコンテンツを含むことが期待されます（メッセージフレーミングが明示的にゼロ長であることを示していない限り）。成功時にコンテンツ無しを好むことを示すリクエストの側面がある場合、オリジンサーバは代わりに 204 (No Content) を送るべきです。CONNECT の場合、成功結果はトンネルであり、200 レスポンスヘッダ部の直後にトンネルが始まるためコンテンツはありません。

200 レスポンスはヒューリスティックにキャッシュ可能です；つまり、メソッド定義や明示的なキャッシュ制御で別途指示されていない限り（Section 4.2.2 of [CACHING]を参照）。

GET または HEAD に対する 200 レスポンスでは、オリジンサーバは選択された表現の利用可能なバリデータフィールド（Section 8.8）を送ることが望ましく（SHOULD）、強いエンティティタグと Last-Modified 日付の両方が好ましいです。

状態変更メソッドに対する 200 レスポンスでは、レスポンスで送信されたバリデータフィールド（Section 8.8）は、リクエストの適用結果として形成された新しい表現の現在のバリデータを伝えます。PUT メソッド（Section 9.3.4）にはそのようなバリデータ送信を妨げる追加要件があることに注意してください。

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

201 レスポンスのコンテンツは通常、作成されたリソースを記述しリンクします。レスポンスで送信されたバリデータフィールド（Section 8.8）は、リクエストにより作成された新しい表現の現在のバリデータを伝えます。PUT メソッド（Section 9.3.4）にはそのようなバリデータ送信を妨げる追加要件があることに注意してください。

202 (Accepted) ステータスコードは、リクエストが処理のために受け入れられたが、処理は完了していないことを示します。リクエストは最終的に実行される場合もあれば実行されない場合もあります（実際の処理時に拒否される可能性があります）。HTTP には非同期処理からステータスコードを再送する仕組みはありません。

202 レスポンスは意図的にコミットしない性質を持ちます。サーバがプロセス（例えば日次バッチ処理）を受け入れる一方で、ユーザーエージェントの接続を処理完了まで維持することを要求しないために存在します。レスポンスに含める表現は、リクエストの現在の状態を説明し、ステータス監視を指す（あるいは埋め込む）べきです。

203 (Non-Authoritative Information) ステータスコードは、リクエストは成功したが、封入されたコンテンツがオリジンサーバの 200 (OK) レスポンスのものから変換プロキシにより修正されていることを示します（Section 7.7）。このステータスコードは、変換が適用されたことをプロキシが受信者に通知し、後続のコンテンツに関する判断に影響を与える可能性がある場合に使われます。例えば、そのコンテンツに対する将来のキャッシュ検証要求は同じリクエスト経路（同じプロキシ経由）でのみ有効かもしれません。

203 レスポンスはヒューリスティックにキャッシュ可能です（メソッド定義や明示的なキャッシュ制御で別途指示されていない限り）。

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

例えば、PUT リクエストに対して 204 ステータスコードが返され、レスポンスに ETag フィールドが含まれている場合、PUT は成功しており、ETag フィールド値はそのターゲットリソースの新しい表現のエンティティタグを含みます。

204 レスポンスは、サーバがターゲットリソースへのアクションを正常に適用したことを示しつつ、ユーザーエージェントが現在の「ドキュメントビュー」から離れる必要がないことを意味します。サーバはユーザーエージェントがインターフェースに従って成功を示す表現を表示し、新しいメタデータをアクティブな表現に適用することを期待します。

例えば、文書編集インタフェースの「保存」アクションに対応して 204 がよく使われます。保存後も文書は編集可能なままであり、ユーザーは作業を続けられます。また分散バージョン管理など自動データ転送が多いインタフェースでも頻繁に使用されます。

204 レスポンスはヘッダ部の終端で終了し、本文やトレーラを含めることはできません。

204 レスポンスはヒューリスティックにキャッシュ可能です（例外はメソッド定義や明示的なキャッシュ制御による）。

205 (Reset Content) ステータスコードは、サーバがリクエストを履行し、ユーザーエージェントに対してそのリクエストを送らせた「ドキュメントビュー」をオリジンサーバから受け取った元の状態にリセットするよう望んでいることを示します。

このレスポンスは、ユーザがデータ入力（フォーム、メモ帳、キャンバス等）を行い、その入力をリクエストで送信してから入力メカニズムを次の入力のためにリセットするという一般的なデータ入力ユースケースをサポートすることを意図しています。

205 ステータスコードは追加のコンテンツが提供されないことを意味するため、サーバは 205 レスポンスでコンテンツを生成してはなりません（MUST NOT）。

206 (Partial Content) ステータスコードは、サーバがターゲットリソースに対するレンジリクエストを満たしており、選択された表現の一部（1つ以上）を転送していることを示します。

レンジリクエストをサポートするサーバは通常要求されたすべてのレンジを満たそうと試みますが、サーバ側の一時的な理由（利用不能、キャッシュ効率、負荷分散など）により要求されたデータの一部しか送らない場合があります。206 レスポンスは自己記述的であるため、クライアントは要求が部分的にしか満たされていない場合でも理解できます。

クライアントは 206 レスポンスの Content-Type および Content-Range フィールドを検査して、どの部分が封入されているか、追加の要求が必要かどうかを判断しなければなりません（MUST）。

206 レスポンスを生成するサーバは、下位節で要求されるヘッダーフィールドに加えて、同じリクエストに対する 200 (OK) レスポンスで送られるであろうフィールドを、該当する場合には生成しなければなりません：Date、Cache-Control、ETag、Expires、Content-Location、および Vary（該当する場合）。（MUST）

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

If-Range ヘッダーフィールドを伴うリクエストに対して 206 レスポンスを生成する送信者は、クライアントが既に prior response を持っているため、他の表現ヘッダーフィールドを生成すべきではない（SHOULD NOT）場合があります。そうでない場合は、同じリクエストに対する 200 (OK) レスポンスで送られるであろう全ての表現ヘッダーフィールドを生成しなければなりません（MUST）。

206 レスポンスはヒューリスティックにキャッシュ可能です（明示的なキャッシュ制御で別途指示されていない限り）。

300 (Multiple Choices) ステータスコードは、ターゲットリソース が複数の表現を持ち、それぞれにより具体的な識別子があり、代替案に関する情報が提供されていることを示します。ユーザー（またはユーザーエージェント）が提供された識別子のいずれかにリクエストをリダイレクトして好ましい表現を選択できるようにする、つまりサーバはユーザーエージェントにリアクティブ交渉を行わせたいという意図です（Section 12参照）。

サーバに優先する選択肢がある場合、サーバは優先選択の URI リファレンスを含む Location ヘッダーフィールドを生成するべきです（SHOULD）。ユーザーエージェントは自動リダイレクトにその Location 値を使ってもよい（MAY）。

HEAD 以外のメソッドに対しては、サーバは 300 レスポンスのコンテンツに表現メタデータと URI リファレンスの一覧を含め、ユーザーやエージェントが最も適切なものを選べるようにするべきです（SHOULD）。ユーザーエージェントは提供されたメディアタイプを理解していれば、その一覧から自動的に選択することができます（MAY）。自動選択のための具体的フォーマットは本仕様で定義されていません。

300 レスポンスはヒューリスティックにキャッシュ可能です（例外はメソッド定義や明示的なキャッシュ制御）。

301 (Moved Permanently) ステータスコードは、ターゲットリソース に新しい恒久的な URI が割り当てられ、将来そのリソースへの参照はサーバが送った新しい URI のいずれかを使うべきであることを示します。サーバはリンク編集能力を持つユーザーエージェントに対し、ターゲット URI の参照を恒久的に置換することを示唆できますが、通常はユーザーエージェントがリンク編集を行っていない限り無視されます。

サーバは新しい恒久的 URI のために優先された URI リファレンスを含む Location ヘッダーフィールドを生成するべきです（SHOULD）。ユーザーエージェントは自動リダイレクトにその Location を使ってもよい（MAY）。通常、サーバのレスポンスコンテンツは新しい URI への短いハイパーテキスト注記を含みます。

301 レスポンスはヒューリスティックにキャッシュ可能です（例外はメソッド定義や明示的なキャッシュ制御）。

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

サーバは異なる URI の参照を含む Location を生成するべきです（SHOULD）。ユーザーエージェントは自動リダイレクトに Location 値を使ってもよい（MAY）。レスポンスコンテンツは通常短いハイパーテキスト注記を含みます。

303 (See Other) は、サーバがユーザーエージェントを Location ヘッダーフィールドで示される別のリソースへリダイレクトしていることを示します。これは元のリクエストに対する間接的な応答を提供することを意図しています。ユーザーエージェントはその URI をターゲットにした取得リクエスト（HTTP を使うなら GET または HEAD）を行い、最終的に得られた結果を元のリクエストへの応答として提示できます。Location に示された新しい URI はターゲット URI と同等と見なされません。

このステータスコードは任意の HTTP メソッドに適用されます。主に POST の出力を別のリソースへリダイレクトするために使われ、POST の応答に相当する情報を別のリソースとして識別・ブックマーク・キャッシュ可能にするために使用されます。

GET リクエストに対する 303 レスポンスは、オリジンサーバがターゲットリソースの表現を HTTP で転送できないことを示すが、Location に示されたリソースはターゲットリソースの記述的なリソースであり、そのリソースへの取得が受信者にとって有用な表現をもたらす可能性があることを意味します。

HEAD リクエストへの応答を除き、303 レスポンスの表現は Location と同じ URI への短いハイパーテキスト注記を含むべきです。

304 (Not Modified) ステータスコードは、条件付き GET または HEAD リクエストが受信され、その条件が false と評価されたために、もし条件がなければ 200 (OK) になったであろうことを示します。言い換えれば、クライアントが既に有効な表現を持っているため、オリジンサーバは表現の転送を行う必要がなく、クライアントに保存済み表現を利用するよう指示しているのです。

• Content-Location, Date, ETag, および Vary
• Cache-Control および Expires（[CACHING] を参照）

304 レスポンスの目的は受信者が既にキャッシュ表現を持っている場合に情報転送を最小化することにあるため、送信者は上に列挙したフィールド以外の表現メタデータを生成すべきでない（SHOULD NOT）。ただしキャッシュ更新を導く目的で存在するメタデータ（例：エンティティタグがない場合の Last-Modified）は有用です。

304 を受け取ったキャッシュの処理要件は Section 4.3.4 of [CACHING] に定義されています。もし条件付きリクエストがアウトバウンドクライアント（独自のキャッシュを持つユーザーエージェント等）から発生しており、共有プロキシがその条件付き GET を受け取った場合、プロキシは 304 をそのクライアントへ転送すべきです（SHOULD）。

304 レスポンスはヘッダ部の終端で終了し、本文やトレーラを含めることはできません。

305 (Use Proxy) ステータスコードは以前のバージョンで定義され、現在は非推奨です。

306 ステータスコードは以前の仕様で定義されましたが現在は使われておらず、予約されています。

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

サーバは Location を生成するべきです（SHOULD）。ユーザーエージェントは自動リダイレクトにその Location を使ってもよい（MAY）。レスポンスは通常短いハイパーテキスト注記を含みます。

308 (Permanent Redirect) ステータスコードは、ターゲットリソースに新しい恒久的 URI が割り当てられ、将来の参照はその新しい URI を使うべきであることを示します。サーバはリンク編集能力を持つユーザーエージェントに対し参照の恒久的置換を示唆できますが、通常は無視されます。

サーバは優先される新しい恒久的 URI を含む Location を生成するべきです（SHOULD）。ユーザーエージェントは自動リダイレクトにその値を使ってもよい（MAY）。レスポンスコンテンツは通常新しい URI への短いハイパーテキスト注記を含みます。

308 レスポンスはヒューリスティックにキャッシュ可能です（例外はメソッド定義や明示的なキャッシュ制御）。

400 (Bad Request) は、サーバがクライアントエラー（不正なリクエスト構文、無効なメッセージフレーミング、欺瞞的なリクエストルーティングなど）によりリクエストを処理できないか拒否することを示します。

401 (Unauthorized) は、ターゲットリソースに対する有効な認証資格情報が欠如しているためリクエストが適用されなかったことを示します。401 レスポンスを生成するサーバは、少なくともそのリソースに適用可能な1つ以上のチャレンジを含む WWW-Authenticate ヘッダーフィールドを送らなければなりません（MUST）。

もしリクエストに認証資格情報が含まれていた場合、401 はそれらの資格情報での認可が拒否されたことを示します。ユーザーエージェントは新しいまたは置き換えた Authorization を付けてリクエストを繰り返すことができます（MAY）。もし 401 レスポンスが前回と同じチャレンジを含み、ユーザーエージェントが既に少なくとも一度認証を試みている場合、ユーザーエージェントは通常診断情報を含むため囲まれた表現をユーザーに提示すべきです（SHOULD）。

402 (Payment Required) は将来の使用のために予約されています。

403 (Forbidden) は、サーバがリクエストを理解したが履行を拒否していることを示します。サーバが拒否の理由を公開したい場合、その理由をレスポンスコンテンツに記述できます（存在する場合）。

もしリクエストに認証資格情報が含まれていた場合、サーバはそれらがアクセス付与に不十分だと見なします。クライアントは同じ資格情報で自動的にリクエストを繰り返してはなりません（SHOULD NOT）。クライアントは新しいあるいは別の資格情報でリクエストを繰り返してもよい（MAY）。ただし、資格情報とは無関係の理由でリクエストが禁止されることもあります。

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

404 (Not Found) は、オリジンサーバがターゲットリソースの現在の表現を見つけられなかったか、それが存在することを開示したくないことを示します。404 はこの欠如が一時的か恒久的かを示しません。条件が恒久的であるとサーバが知っている場合は 410 (Gone) を使う方が望ましいです。

404 レスポンスはヒューリスティックにキャッシュ可能です（例外はメソッド定義や明示的なキャッシュ制御）。

405 (Method Not Allowed) は、リクエスト行で受け取ったメソッドがオリジンサーバには知られているが、ターゲットリソースではサポートされていないことを示します。オリジンサーバは 405 レスポンスでそのターゲットリソースが現在サポートするメソッドの一覧を含む Allow ヘッダーフィールドを生成しなければなりません（MUST）。

405 レスポンスはヒューリスティックにキャッシュ可能です（例外はメソッド定義や明示的なキャッシュ制御）。

406 (Not Acceptable) は、ターゲットリソースがリクエストで受け取ったプロアクティブ交渉ヘッダーフィールドに従ってユーザーエージェントにとって受け入れ可能な現在の表現を持たず、サーバがデフォルト表現を供給することを望まない場合に示されます。

サーバは利用可能な表現特性と対応するリソース識別子の一覧を含むコンテンツを生成するべきです（SHOULD）。ユーザーエージェントはその一覧から最適な選択を自動的に行ってもよい（MAY）。ただしその自動選択の標準は本仕様で定義されていません（Section 15.4.1参照）。

407 (Proxy Authentication Required) は 401 に類似しますが、クライアントがこのリクエストにプロキシを使用するために認証する必要があることを示します。プロキシはそのプロキシに適用可能なチャレンジを含む Proxy-Authenticate を送らなければなりません（MUST）。クライアントは新しいまたは置き換えた Proxy-Authorization を付けてリクエストを繰り返してもよい（MAY）。

408 (Request Timeout) は、サーバが待機する時間内に完全なリクエストメッセージを受信できなかったことを示します。

もしクライアントに未送信のリクエストがある場合、クライアントはそのリクエストを繰り返してもよい（MAY）。現在の接続が使用不可能であれば（例：HTTP/1.1 で要求デリミテーションが失われた場合）、新しい接続が使用されます。

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

競合は PUT リクエストに対して発生しやすく、例えばバージョニングを用いている場合に PUT される表現が第三者の以前のリクエストによる変更と衝突しているときに 409 が使われます。こうした場合、レスポンス表現は差分をマージするための情報を含むことが多いです。

410 (Gone) は、オリジンサーバでターゲットリソースへのアクセスがもはや利用できず、この状態が恒久的である可能性が高いことを示します。オリジンサーバがその条件が恒久的かどうかを判断できない場合は 404 (Not Found) を使うべきです。

410 レスポンスはウェブ保守の助けとして意図されており、リソースが意図的に利用不可であり外部リンクの削除を望むことを受信者に通知します。これは期間限定のプロモーションや、もはや組織に属さない個人のリソースに一般的です。恒久的に利用不可なすべてのリソースに 410 を付ける必要はなく、保持期間もサーバ所有者の裁量に委ねられます。

410 レスポンスはヒューリスティックにキャッシュ可能です（例外はメソッド定義や明示的なキャッシュ制御）。

411 (Length Required) は、サーバが Content-Length を定義せずにリクエストを受け入れないことを示します。クライアントは有効な Content-Length を追加してリクエストを繰り返してもよい（MAY）。

412 (Precondition Failed) は、リクエストヘッダーフィールドで示された1つ以上の条件がサーバ上で評価されたときに false になったことを示します（Section 13参照）。このレスポンスはクライアントが現在のリソース状態に前提条件を置き、予期しない状態でメソッドが適用されるのを防ぐことを可能にします。

413 (Content Too Large) は、リクエスト本文がサーバが処理することを望むまたは処理可能なサイズを超えているため、サーバがリクエストを処理することを拒否していることを示します。サーバはプロトコルバージョンが許す場合、リクエストを終了してもよいし、さもなければ接続を閉じてもよい（MAY）。

その状態が一時的である場合、サーバは Retry-After ヘッダーフィールドを生成してクライアントに再試行可能な時刻を示すべきです（SHOULD）。

414 (URI Too Long) は、ターゲット URI がサーバが解釈することを望む長さを超えているためにサーバがリクエストを処理することを拒否していることを示します。この稀な状況は、POST を誤って長いクエリ情報を伴う GET に変換した場合や、無限リダイレクトループに陥った場合、または攻撃の一部として長い URI を送る試みがある場合に起こります。

414 レスポンスはヒューリスティックにキャッシュ可能です（例外はメソッド定義や明示的なキャッシュ制御）。

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

形式の問題は、リクエストの示す Content-Type または Content-Encoding に起因するか、データを直接検査した結果による場合があります。

もし問題がサポートされていないコンテンツコーディングに起因する場合、Accept-Encoding レスポンスヘッダーフィールドを用いて、リクエストで受け入れられたであろうコーディングを示すべきです。

一方、原因がサポートされていないメディアタイプであれば、Accept レスポンスヘッダーフィールドを用いて、リクエストで受け入れられたであろうメディアタイプを示すことができます。

416 (Range Not Satisfiable) は、リクエストの Range ヘッダーフィールドに含まれるレンジ集合が受理されなかったことを示します。これは要求されたレンジのどれも満たし得ない場合や、クライアントが過度に多くの小さなまたは重複するレンジを要求した場合（サービス拒否攻撃の可能性）に起こります。

各レンジ単位は、そのレンジ集合が満たし得るための要件を定義します。例えば、Section 14.1.2 はバイトレンジ集合が満たし得るための条件を定義しています。

サーバがバイトレンジ要求に対して 416 を生成する場合、選択された表現の現在の長さを示す Content-Range を生成することが望ましい（SHOULD）。

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

417 (Expectation Failed) は、リクエストの Expect ヘッダーフィールドに示された期待が、少なくとも1つのインバウンドサーバで満たされなかったことを示します。

RFC2324 は 4 月 1 日の RFC であり、HTTP の濫用を風刺したものです。その中でアプリケーション固有の 418 ステータスコードがジョークとして定義されましたが、広く展開されすぎたため将来の用途には使えない状態になっています。

したがって 418 は IANA HTTP Status Code Registry で予約されています。将来状況により再割り当てが必要になれば変更され得ます。

421 (Misdirected Request) は、リクエストがそのターゲット URI に対して権威ある応答を生成できないサーバに向けられたことを示します。オリジンサーバやゲートウェイは、設定された origin と一致しないターゲット URI や、接続コンテキストと一致しないターゲット URI を拒否するために 421 を返します。

421 を受け取ったクライアントは、要求メソッドが冪等であるか否かにかかわらず、別の接続（例えばターゲットリソースの origin に特化した新規接続）や代替サービスを使ってリクエストを再試行してもよい（MAY）。

プロキシは 421 を生成してはなりません（MUST NOT）。

422 (Unprocessable Content) は、サーバがリクエストコンテンツのメディアタイプを理解しており（したがって 415

426 (Upgrade Required) は、サーバが現在のプロトコルでリクエストを実行することを拒否し、クライアントが別のプロトコルへアップグレードしたときには実行する可能性があることを示します。サーバは 426 レスポンスで要求されるプロトコルを示す Upgrade ヘッダーフィールドを送らなければなりません（MUST）。

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

This service requires use of the HTTP/3.0 protocol.

500 (Internal Server Error) は、サーバがリクエストの処理を妨げる予期せぬ条件に遭遇したことを示します。

501 (Not Implemented) は、サーバがリクエストを満たすために必要な機能をサポートしていないことを示します。サーバがリクエストメソッドを認識せず、どのリソースに対してもサポートできない場合に適切な応答です。

501 レスポンスはヒューリスティックにキャッシュ可能です（例外はメソッド定義や明示的なキャッシュ制御）。

502 (Bad Gateway) は、サーバがゲートウェイやプロキシとして動作中に、要求を履行しようとした際にアクセスした上流サーバから無効なレスポンスを受け取ったことを示します。

503 (Service Unavailable) は、サーバが一時的な過負荷やスケジュールされたメンテナンスにより現在リクエストを処理できないことを示します。サーバは Retry-After ヘッダーフィールドを送って、クライアントが再試行可能な目安時間を示してもよい（MAY）。

504 (Gateway Timeout) は、サーバがゲートウェイやプロキシとして動作中に、要求を完了するためにアクセスする必要がある上流サーバから適時なレスポンスを受け取れなかったことを示します。

505 (HTTP Version Not Supported) は、サーバがリクエストで使われた HTTP のメジャーバージョンをサポートしないか、サポートを拒否することを示します。サーバは 505 レスポンスのために、そのバージョンがサポートされない理由とサーバがサポートする他のプロトコルを説明する表現を生成するべきです（SHOULD）。

"Hypertext Transfer Protocol (HTTP) Method Registry" は IANA により https://www.iana.org/assignments/http-methods で管理されており、method 名を登録します。

• Method Name (see Section 9)
• Safe ("yes" or "no", see Section 9.2.1)
• Idempotent ("yes" or "no", see Section 9.2.2)
• Pointer to specification text

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

標準化されたメソッドは汎用的であり、特定のメディアタイプやリソース種別、アプリケーションだけに適用されるべきではありません。したがって、新しいメソッドは単一のアプリケーションやデータ形式に特化した文書ではなく、より一般的な文書で登録されることが望まれます。直交する技術は直交的に仕様化されるべきです。

メッセージ解析（Section 6）はメソッドのセマンティクスから独立している必要があるため（HEAD に対する応答を除く）、新しいメソッドの定義は解析アルゴリズムを変更したり、要求または応答メッセージ上のコンテンツの存在を禁止したりすることはできません。新しいメソッド定義は、Content-Length ヘッダーフィールドの値を "0" に要求することで、ゼロ長コンテンツのみを許容することを指定できることに留意してください。

同様に、新しいメソッドは CONNECT（CONNECT）や OPTIONS（OPTIONS）で許可されるホスト:ポートやアスタリスク形式のリクエストターゲットを使用することはできません（Section 7.1）。ターゲット URI は完全な絶対形式が必要であり、つまりリクエストターゲットを絶対形式で送るか、他のメソッドと同様にリクエストコンテキストからターゲット URI を再構成する必要があります。

新しいメソッド定義は、そのメソッドが安全か（Section 9.2.1）、冪等か（Section 9.2.2）、キャッシュ可能か（Section 9.2.3）、要求コンテンツにどのようなセマンティクスが結び付けられるか（ある場合）、ヘッダーフィールドやステータスコードのセマンティクスにどのような細則を与えるかを示す必要があります。新しいメソッドがキャッシュ可能である場合は、キャッシュがどのように、どの条件でレスポンスを格納して後続の要求を満たすために使用できるかを説明するべきです。新しいメソッドが条件付きにできるかどうか（Section 13.1）を記述し、条件が偽であった場合にサーバがどのように応答するかを示すべきです。同様に、新しいメソッドが部分応答のセマンティクス（Section 14.2）に利用され得る場合は、それについても文書化するべきです。

"Hypertext Transfer Protocol (HTTP) Status Code Registry" は IANA により https://www.iana.org/assignments/http-status-codes で管理され、status code 番号を登録します。

• Status Code (3 digits)
• Short Description
• Pointer to specification text

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

既存のステータスコードで定義されていないレスポンスのセマンティクスを表現する必要がある場合、新しいステータスコードを登録できます。ステータスコードは汎用的であり、特定のメディアタイプやリソース種別、HTTP の特定の利用に限定されるべきではありません。したがって、新しいステータスコードは単一のアプリケーションに特化した文書ではなく、より一般的な文書で登録されることが望ましいです。

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

まだ広く展開されていない新しいステータスコードの提案は、コード番号を早期に割り当てることを避け、代わりに "4NN" や "3N0" .. "3N9" のような表記を使って提案されるステータスコードのクラスを示すべきです。これは番号を早まって消費しないためです。

新しいステータスコードの定義は、そのステータスコードを含むレスポンスを引き起こすリクエスト条件（例えば、リクエストヘッダーフィールドやメソッドの組合せ）と、必要なレスポンスヘッダーフィールド（どのフィールドが必須か、どのフィールドがセマンティクスを変更するか、新しいステータスコードと共に使われたときにどのフィールドのセマンティクスがさらに細かく規定されるか）に関する説明を含めるべきです。

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

新しい最終ステータスコードの定義は、それがヒューリスティックにキャッシュ可能かどうかを指定するべきです。注：明示的なフレッシュネス情報を持つ最終ステータスコードのレスポンスはキャッシュ可能です。ステータスコードがヒューリスティックにキャッシュ可能と定義されていれば、明示的なフレッシュネス情報なしでもキャッシュ可能です。同様に、ステータスコードの定義は must-understand キャッシュ指示子が使用された場合のキャッシュ挙動に制約を置くことができます。詳細は [CACHING] を参照してください。

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

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

誰でも HTTP フィールドの登録を要求できます。新しい HTTP フィールドを作成する際の考慮点については Section 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], Section 4.6 を参照）。

Field name:

要求されるフィールド名。MUST は Section 5.1 で定義された field-name 構文に従うこと、かつ SHOULD は英数字とハイフン ('-') のみを使い、先頭文字を英字とすることが推奨されます。

Status:

"permanent", "provisional", "deprecated", または "obsoleted".

Specification document(s):

フィールドを仕様化する文書への参照。可能ならその文書を取得するための URI を含めることが望ましい。暫定登録の場合は任意だが推奨されます。関連する節を示すことも可能ですが必須ではありません。

Comments:

予約済みエントリ等に関する追加情報。

専門家はコミュニティと協議のうえ、登録簿に収集する追加フィールドを定義できます。

標準で定義された名前は "permanent" ステータスを持ちます。その他の名前も専門家が使用されていると判断すれば "permanent" として登録できます。その他は "provisional" として登録すべきです。

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

未登録の名前が広く展開され、そうでなければタイムリーに登録される見込みがないと専門家が判断する場合、第三者（専門家を含む）がその名前を登録できることに注意してください。

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

• どの条件でそのフィールドが使用できるか（例：応答のみ、要求または応答のすべてのメッセージ、特定のリクエストメソッドへの応答のみ、等）。
• フィールドのセマンティクスが特定のリクエストメソッドやステータスコードのような文脈によってさらに精緻化されるかどうか。
• 伝達される情報の適用範囲。デフォルトではフィールドは関連付けられたメッセージにのみ適用されますが、いくつかの応答フィールドはリソースのすべての表現、リソース自体、あるいはそれより広い範囲に適用されるよう設計されています。応答フィールドの適用範囲を拡大する仕様は、コンテンツネゴシエーション、適用期間、場合によってはマルチテナントサーバ配置の問題について慎重に検討する必要があります。
• 仲介者がフィールドの値を挿入、削除、または変更できる条件。
• そのフィールドがトレーラで許容されるかどうか（デフォルトでは許容されません。Section 6.5.1 を参照）。
• そのフィールド名を Connection ヘッダーフィールドに列挙すべきかどうか（すなわち hop-by-hop にするかどうか）についての適合性（Section 7.6.1 を参照）。
• フィールドがプライバシー関連データの開示など追加のセキュリティ上の考慮事項を導入するかどうか。

• そのフィールド名を Vary 応答ヘッダーフィールドに列挙することが適切かどうか（例：オリジンサーバのコンテンツ選択アルゴリズムで使われる場合。Section 12.5.5 を参照）。
• PUT リクエストで受信した際にそのフィールドを保存すべきかどうか（Section 9.3.4 を参照）。
• セキュリティ上の懸念からリダイレクトを自動的に行う際にそのフィールドを削除すべきかどうか（Section 15.4 を参照）。

"Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" はチャレンジやクレデンシャルで使用される認証スキームの名前空間を定義します。https://www.iana.org/assignments/http-authschemes で管理されています。

• Authentication Scheme Name
• Pointer to specification text
• Notes (optional)

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

• HTTP 認証はステートレスであると想定されます：要求を認証するために必要な情報はすべてリクエスト内で提供されるべきであり、サーバが過去のリクエストを記憶することに依存すべきではありません。基盤となる接続に基づく認証は本仕様の範囲外であり、接続が認証済みユーザー以外によって使用され得ないことを保証するための措置が取られていない限り、根本的に問題があります（Section 3.3 を参照）。

• 認証パラメータ "realm" は保護領域を定義するために予約されています（Section 11.5）。新しいスキームはその定義と矛盾する方法で realm を使用してはなりません（MUST NOT）。

• "token68" 記法は既存の認証スキームとの互換性のために導入され、チャレンジまたはクレデンシャルにつき一度だけ使用できます。したがって新しいスキームは将来の拡張が不可能にならないように、代わりに auth-param 構文を使用することが望ましいです。

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

  Note: "realm" パラメータの値構文が quoted-string に制限されていることは設計上の誤りであり、新しいパラメータでは繰り返すべきではありません。

• 新しいスキームの定義は不明な拡張パラメータの扱いを定義するべきです。一般に、後方互換性の観点から "must-ignore" ルールは "must-understand" より好ましく、そうでなければレガシー受信者の存在下で新しいパラメータを導入するのが困難になります。さらに、新しいパラメータを定義する方針（仕様を更新する、あるいはこの登録簿を使う等）を記述するのが良いです。

• 認証スキームは、それがオリジンサーバ認証（WWW-Authenticate を用いる）で使用可能か、プロキシ認証（Proxy-Authenticate を用いる）で使用可能かを文書化する必要があります。

• Authorization ヘッダーフィールドに格納されるクレデンシャルはユーザーエージェント固有であり、したがってそれらはリクエスト内で出現する範囲で HTTP キャッシュに対して "private" キャッシュ応答指示子と同様の効果を持ちます（Section 5.2.2.7 of [CACHING] を参照）。

  したがって、Authorization ヘッダを用いない（例えば新しく定義したヘッダを使う）認証スキームは、応答がキャッシュされないように明示的に禁止する必要があります（例："private" のようなキャッシュ応答指示子を必須にするなど）。

• Authentication-Info, Proxy-Authentication-Info、または他の認証関連の応答ヘッダーフィールドを使用するスキームは、関連するセキュリティ考慮事項を検討し文書化する必要があります（Section 17.16.4 を参照）。

"HTTP Range Unit Registry" はレンジ単位名の名前空間を定義し、それらに対応する仕様を参照します。https://www.iana.org/assignments/http-parameters で管理されています。

• Name
• Description
• Pointer to specification text

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

ページ、セクション、レコード、行、時間などのフォーマット固有の境界のような他のレンジ単位は、アプリケーション固有の目的で HTTP で利用可能ですが、実務ではあまり使われません。代替レンジ単位の実装者は、それらがコンテンツコーディングや汎用の仲介者とどのように機能するかを検討するべきです。

"HTTP Content Coding Registry" は IANA により https://www.iana.org/assignments/http-parameters/ で管理され、content-coding 名を登録します。

• Name
• Description
• Pointer to specification text

コンテンツコーディングの名前は、転送コーディングの名前と重複してはなりません（"HTTP Transfer Coding Registry" https://www.iana.org/assignments/http-parameters/ を参照）、ただしエンコーディング変換が同一である場合は例外です（Section 8.4.1 の圧縮コーディングなど）。

この名前空間に値を追加するには IETF Review が必要であり（Section 4.8 of [RFC8126] を参照）、MUST は Section 8.4.1 で定義されたコンテンツコーディングの目的に合致しなければなりません。

新しいコンテンツコーディングは可能な限り自己記述的であるべきであり、オプションのパラメータはコーディングフォーマット内で検出可能にし、転送中に失われる可能性のある外部メタデータに依存すべきではありません。

HTTP 認証フレームワークは資格情報の機密性を維持する単一のメカニズムを定義しているわけではなく、各認証スキームが送信前に資格情報をどのようにエンコードするかを定義します。この柔軟性は将来のスキーム開発に役立ちますが、独自に機密性を提供しない既存スキームやリプレイ攻撃に十分対抗できないスキームの保護には不十分です。さらに、サーバがユーザーごとに固有の資格情報を期待する場合、その交換は資格情報内の内容が機密であってもユーザーを識別する効果を持ちます。

HTTP はフィールドの機密伝送を提供するために基盤となるトランスポートあるいはセッションレベルの接続のセキュリティ特性に依存しています。個々のユーザー認証に依存するサービスは、資格情報を交換する前に secured な接続を要求します（参照: Section 4.2.2）。

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

• 長期間アイドル状態だったクライアントで、サーバがクライアントに対して資格情報の再入力を促したい場合。
• ページ上の「ログアウト」や「コミット」ボタンのようなセッション終了の表示を含むアプリケーションで、サーバ側がそれ以降クライアントが資格情報を保持する理由がないと「知っている」場合。

資格情報をキャッシュするユーザーエージェントは、ユーザーが制御して簡単にキャッシュ済み資格情報を破棄できる仕組みを提供することが推奨されます。

"realm" 機構のみに依存して保護領域を確立する認証スキームは、オリジンサーバ上のすべてのリソースに対して資格情報を曝露することになります。あるリソースで認証済みのクライアントは同じオリジンの他のリソースに対して同じ認証資格情報を使用できるため、別のリソースが他のリソースの認証資格情報を収集する可能性が生じます。

これは、オリジンサーバが同一オリジンで複数の当事者のためにリソースをホストする場合に特に問題となります（参照: Section 11.5）。緩和策としては、認証資格情報への直接アクセスを制限する（つまり Authorization リクエストヘッダの内容を利用可能にしない）ことや、各当事者ごとに異なるホスト名（またはポート番号）を使用して保護領域を分離することが含まれます。

暗号化されていないチャンネルで送信される応答に情報を追加することは、セキュリティとプライバシーに影響を与える可能性があります。Authentication-Info および Proxy-Authentication-Info ヘッダーフィールドの存在自体が HTTP 認証が使用されていることを示します。追加情報は認証スキーム固有のパラメータの内容によってさらなる情報を露出する可能性があり、これらのスキームの定義において考慮される必要があります。