4. Request Methods (リクエストメソッド)

4.1. Overview (概要)

リクエストメソッドトークンは、リクエストセマンティクスの主要なソースです。これは、クライアントがこのリクエストを行った目的と、クライアントが成功した結果として期待するものを示します。

リクエストメソッドのセマンティクスは、リクエストに存在する場合、いくつかのヘッダーフィールドのセマンティクスによってさらに特化される可能性があります (Section 5)。ただし、これらの追加のセマンティクスがメソッドと競合しない場合に限ります。たとえば、クライアントは条件付きリクエストヘッダーフィールド (Section 5.2) を送信して、リクエストされたアクションをターゲットリソースの現在の状態に依存させることができます ([RFC7232])。

method = token

HTTPは、もともと分散オブジェクトシステムへのインターフェースとして使用できるように設計されました。リクエストメソッドは、識別されたオブジェクトに対して定義されたメソッドを呼び出すとセマンティクスが適用されるのと同じように、ターゲットリソースにセマンティクスを適用するものと想定されていました。メソッドトークンは大文字と小文字を区別します。これは、大文字と小文字を区別するメソッド名を持つオブジェクトベースのシステムへのゲートウェイとして使用される可能性があるためです。

分散オブジェクトとは異なり、HTTPの標準化されたリクエストメソッドはリソース固有ではありません。統一インターフェースは、ネットワークベースのシステムにおいてより良い可視性と再利用性を提供するためです [REST]。一度定義されると、標準化されたメソッドは、任意のリソースに適用される場合に同じセマンティクスを持つべきです。ただし、各リソースは、これらのセマンティクスが実装されているか許可されているかを自分で決定します。

本仕様は、HTTPで一般的に使用される多数の標準化されたメソッドを定義しています。次の表に概説されています。慣例により、標準化されたメソッドはすべて大文字のUS-ASCII文字で定義されます。

Method	Safe (安全)	Idempotent (冪等)	Description (説明)
GET	Yes	Yes	ターゲットリソースの現在の表現を転送します。
HEAD	Yes	Yes	GETと同じですが、ステータス行とヘッダーセクションのみを転送します。
POST	No	No	リクエストペイロードに対してリソース固有の処理を実行します。
PUT	No	Yes	リクエストペイロードでターゲットリソースのすべての現在の表現を置き換えます。
DELETE	No	Yes	ターゲットリソースのすべての現在の表現を削除します。
CONNECT	No	No	ターゲットリソースによって識別されるサーバーへのトンネルを確立します。
OPTIONS	Yes	Yes	ターゲットリソースの通信オプションを記述します。
TRACE	Yes	Yes	ターゲットリソースへのパスに沿ってメッセージループバックテストを実行します。

すべての汎用サーバーは、GETメソッドとHEADメソッドをサポートしなければなりません (MUST)。他のすべてのメソッドはオプションです (OPTIONAL)。

本仕様の範囲外の追加のメソッドが、HTTPでの使用のために標準化されています。このようなすべてのメソッドは、Section 8.1で定義されているように、IANAが管理する"Hypertext Transfer Protocol (HTTP) Method Registry"に登録されるべきです。

ターゲットリソースによって許可されるメソッドのセットは、Allowヘッダーフィールド (Section 7.4.1) にリストできます。ただし、許可されるメソッドのセットは動的に変更される可能性があります。認識されていない、またはオリジンサーバーによって実装されていないリクエストメソッドが受信された場合、オリジンサーバーは501 (Not Implemented) ステータスコードで応答すべきです (SHOULD)。オリジンサーバーが認識しているがターゲットリソースに対して許可されていないリクエストメソッドが受信された場合、オリジンサーバーは405 (Method Not Allowed) ステータスコードで応答すべきです (SHOULD)。

4.2. Common Method Properties (共通メソッドプロパティ)

4.2.1. Safe Methods (安全なメソッド)

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

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

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

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

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

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

4.2.2. Idempotent Methods (冪等メソッド)

そのメソッドでサーバーに対して複数の同一リクエストを行った場合の意図された効果が、単一のそのようなリクエストの効果と同じである場合、リクエストメソッドは"冪等" (idempotent) であると見なされます。本仕様で定義されているリクエストメソッドのうち、PUT、DELETE、および安全なリクエストメソッドは冪等です。

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

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

4.2.3. Cacheable Methods (キャッシュ可能なメソッド)

リクエストメソッドは、それらへの応答を将来の再利用のために保存することが許可されていることを示すために"キャッシュ可能" (cacheable) として定義できます。具体的な要件については [RFC7234] を参照してください。一般に、現在の応答または権威ある応答に依存しない安全なメソッドは、キャッシュ可能として定義されます。本仕様では、GET、HEAD、およびPOSTをキャッシュ可能として定義していますが、圧倒的多数のキャッシュ実装はGETとHEADのみをサポートしています。

4.3. Method Definitions (メソッド定義)

4.3.1. GET

GETメソッドは、ターゲットリソースの現在選択されている表現の転送を要求します。GETは情報取得の主要なメカニズムであり、ほとんどすべてのパフォーマンス最適化の焦点です。したがって、人々がHTTPを介して識別可能な情報を取得することについて話すとき、彼らは一般的にGETリクエストを行うことを指しています。

リソース識別子をリモートファイルシステムのパス名と考え、表現をそのようなファイルの内容のコピーと考えるのは魅力的です。それは間違っています。GETに応答して返される表現は、必ずしもオリジンサーバーが保存するリソースの内容だけではありません。代わりに、それらは (コンテンツネゴシエーションを介して) 選択され、リクエストに応じてその場で生成されます。

GETリクエストメッセージ内のペイロードには定義されたセマンティクスがありません。GETリクエストでペイロードボディを送信すると、一部の既存の実装がリクエストを拒否する可能性があります。

GETリクエストへの応答はキャッシュ可能です。キャッシュは、Cache-Controlヘッダーフィールド ([RFC7234] の Section 5.2) で特に示されていない限り、それを使用して後続のGETおよびHEADリクエストを満たすことができます (MAY)。

4.3.2. HEAD

HEADメソッドはGETと同一ですが、サーバーは応答でメッセージボディを送信してはなりません (MUST NOT) (つまり、応答はヘッダーセクションの終わりで終了します)。サーバーは、HEADリクエストへの応答として、GETの場合に送信されていたであろう同じヘッダーフィールドを送信すべきです (SHOULD)。ただし、ペイロードヘッダーフィールド (Section 3.3) は省略できます (MAY)。このメソッドは、表現データを転送せずに選択された表現に関するメタデータを取得するために使用でき、ハイパーテキストリンクの有効性、アクセス可能性、および最近の変更をテストするためによく使用されます。

HEADリクエストメッセージ内のペイロードには定義されたセマンティクスがありません。HEADリクエストでペイロードボディを送信すると、一部の既存の実装がリクエストを拒否する可能性があります。

HEADリクエストへの応答はキャッシュ可能です。キャッシュは、Cache-Controlヘッダーフィールド ([RFC7234] の Section 5.2) で特に示されていない限り、それを使用して後続のHEADリクエストを満たすことができます (MAY)。HEAD応答は、以前にキャッシュされたGET応答にも影響を与える可能性があります。[RFC7234] の Section 4.3.5 を参照してください。

4.3.3. POST

POSTメソッドは、ターゲットリソースが、リソース自体の特定のセマンティクスに従って、リクエストに含まれる表現を処理することを要求します。たとえば、POSTは以下の機能 (および他の機能) に使用されます:

• HTMLフォームに入力されたフィールドなど、データ処理プロセスにデータのブロックを提供する;

• 掲示板、ニュースグループ、メーリングリスト、ブログ、または類似の記事グループにメッセージを投稿する;

• オリジンサーバーによってまだ識別されていない新しいリソースを作成する; および、

• リソースの既存の表現にデータを追加する。

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

POSTリクエストの正常な処理の結果として、オリジンサーバー上に1つ以上のリソースが作成された場合、オリジンサーバーは、作成された主要なリソースの識別子を提供するLocationヘッダーフィールド (Section 7.1.2) と、リクエストのステータスを記述し、新しいリソースを参照する表現を含む201 (Created) 応答を送信すべきです (SHOULD)。

POSTリクエストへの応答は、明示的な新鮮度情報 ([RFC7234] の Section 4.2.1 を参照) が含まれている場合にのみキャッシュ可能です。ただし、POSTキャッシングは広く実装されていません。オリジンサーバーがクライアントがPOSTの結果を後のGETで再利用できる方法でキャッシュできるようにしたい場合、オリジンサーバーは、結果と、POSTの有効なリクエストURIと同じ値を持つContent-Locationヘッダーフィールド (Section 3.1.4.2) を含む200 (OK) 応答を送信できます (MAY)。

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

4.3.4. PUT

PUTメソッドは、ターゲットリソースの状態を、リクエストメッセージペイロードに含まれる表現によって定義された状態で作成または置き換えることを要求します。特定の表現のPUTが成功すると、同じターゲットリソースに対する後続のGETで、200 (OK) 応答で同等の表現が送信されることが示唆されます。ただし、ターゲットリソースは他のユーザーエージェントによって並行して操作される可能性があるため、または後続のGETを受信する前にオリジンサーバーによる動的処理の対象となる可能性があるため、そのような状態変更が観察可能であるという保証はありません。成功した応答は、オリジンサーバーによる処理時にユーザーエージェントの意図が達成されたことのみを意味します。

ターゲットリソースに現在の表現がなく、PUTが正常に1つを作成した場合、オリジンサーバーは201 (Created) 応答を送信することでユーザーエージェントに通知しなければなりません (MUST)。ターゲットリソースに現在の表現があり、その表現が含まれる表現の状態に従って正常に変更された場合、オリジンサーバーは、リクエストの正常完了を示すために200 (OK) または204 (No Content) 応答を送信しなければなりません (MUST)。

オリジンサーバーは、PUT表現が、PUTによって変更できない、または変更されないターゲットリソースに対してサーバーが持つ制約と一致していることを検証すべきです (SHOULD)。これは、オリジンサーバーがGET応答で表現メタデータの値を設定するためにURIに関連する内部構成情報を使用する場合に特に重要です。PUT表現がターゲットリソースと一致しない場合、オリジンサーバーは、表現を変換するかリソース構成を変更してそれらを一致させるか、表現が適切でない理由を説明するのに十分な情報を含む適切なエラーメッセージで応答すべきです (SHOULD)。409 (Conflict) または415 (Unsupported Media Type) ステータスコードが推奨され、後者はContent-Type値の制約に固有です。

たとえば、ターゲットリソースが常に"text/html"のContent-Typeを持つように構成されており、PUTされている表現が"image/jpeg"のContent-Typeを持っている場合、オリジンサーバーは次のいずれかを行うべきです:

a. 新しいメディアタイプを反映するようにターゲットリソースを再構成する;

b. 新しいリソース状態として保存する前に、PUT表現をリソースと一致する形式に変換する; または、

c. ターゲットリソースが"text/html"に制限されていることを示す415 (Unsupported Media Type) 応答でリクエストを拒否し、おそらく新しい表現の適切なターゲットとなる別のリソースへのリンクを含める。

HTTPは、PUTメソッドがオリジンサーバーの状態にどのように影響するかを、ユーザーエージェントリクエストの意図とオリジンサーバー応答のセマンティクスによって表現できる範囲を超えて正確に定義していません。リソースがその言葉のいかなる意味でも何であるかを、HTTPを介して提供されるインターフェース以外に定義していません。リソース状態が どのように"保存"されるか、またはそのような保存がリソース状態の変更の結果としてどのように変更される可能性があるか、またはオリジンサーバーがリソース状態を表現に変換する方法を定義していません。一般的に言えば、リソースインターフェースの背後にあるすべての実装の詳細は、サーバーによって意図的に隠されています。

オリジンサーバーは、PUTへの成功した応答で、ETagやLast-Modifiedフィールドなどのバリデータヘッダーフィールド (Section 7.2) を送信してはなりません (MUST NOT)。ただし、リクエストの表現データがボディに変換を適用せずに保存された場合 (つまり、リソースの新しい表現データがPUTリクエストで受信した表現データと同一である場合) で、かつバリデータフィールド値が新しい表現を反映している場合を除きます。この要件により、ユーザーエージェントは、メモリ内の表現ボディがPUTの結果として最新のままであることを知ることができるため、オリジンサーバーから再度取得する必要がなく、応答で受信した新しいバリデータを将来の条件付きリクエストに使用して、意図しない上書きを防ぐことができます (Section 5.2)。

POSTメソッドとPUTメソッドの根本的な違いは、含まれる表現の異なる意図によって強調されます。POSTリクエストのターゲットリソースは、リソース自体のセマンティクスに従って含まれる表現を処理することを意図していますが、PUTリクエストの含まれる表現は、ターゲットリソースの状態を置き換えるものとして定義されています。したがって、PUTの意図は冪等であり、中間者に対して可視ですが、正確な効果はオリジンサーバーのみが知っています。

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

ターゲットリソースに適用されたPUTリクエストは、他のリソースに副作用を持つ可能性があります。たとえば、記事には"現在のバージョン"を識別するためのURI (リソース) があり、それは各特定のバージョンを識別するURI (ある時点で現在のバージョンリソースと同じ状態を共有していた異なるリソース) とは別です。"現在のバージョン"URIに対するPUTリクエストが成功すると、ターゲットリソースの状態を変更することに加えて、新しいバージョンリソースが作成される可能性があり、関連するリソース間にリンクが追加される可能性もあります。

特定のターゲットリソースでPUTを許可するオリジンサーバーは、Content-Rangeヘッダーフィールド ([RFC7233] の Section 4.2) を含むPUTリクエストに対して400 (Bad Request) 応答を送信しなければなりません (MUST)。ペイロードは、完全な表現として誤ってPUTされた部分的なコンテンツである可能性が高いためです。部分的なコンテンツの更新は、より大きなリソースの一部と重複する状態を持つ個別に識別されたリソースをターゲットにするか、部分的な更新用に特別に定義された別のメソッド (たとえば、[RFC5789] で定義されているPATCHメソッド) を使用することで可能です。

PUTメソッドへの応答はキャッシュ可能ではありません。成功したPUTリクエストが、有効なリクエストURIに対して1つ以上の保存された応答を持つキャッシュを通過する場合、それらの保存された応答は無効化されます ([RFC7234] の Section 4.4 を参照)。

4.3.5. DELETE

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

ターゲットリソースに1つ以上の現在の表現がある場合、それらはオリジンサーバーによって破棄される場合と破棄されない場合があり、関連するストレージは回収される場合とされない場合があります。これは完全にリソースの性質とオリジンサーバーによる実装に依存します (これは本仕様の範囲外です)。同様に、リソースの他の実装の側面は、DELETEの結果として非アクティブ化またはアーカイブする必要がある場合があります。たとえば、データベースまたはゲートウェイ接続などです。一般に、オリジンサーバーは、削除を実行するための所定のメカニズムを持つリソースに対してのみDELETEを許可すると想定されます。

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

DELETEメソッドが正常に適用された場合、オリジンサーバーは、アクションが成功する可能性が高いがまだ実行されていない場合は202 (Accepted) ステータスコード、アクションが実行され、これ以上の情報を提供する必要がない場合は204 (No Content) ステータスコード、またはアクションが実行され、応答メッセージにステータスを説明する表現が含まれている場合は200 (OK) ステータスコードを送信すべきです (SHOULD)。

DELETEリクエストメッセージ内のペイロードには定義されたセマンティクスがありません。DELETEリクエストでペイロードボディを送信すると、一部の既存の実装がリクエストを拒否する可能性があります。

DELETEメソッドへの応答はキャッシュ可能ではありません。DELETEリクエストが、有効なリクエストURIに対して1つ以上の保存された応答を持つキャッシュを通過する場合、それらの保存された応答は無効化されます ([RFC7234] の Section 4.4 を参照)。

4.3.6. CONNECT

CONNECTメソッドは、受信者がリクエストターゲットによって識別される宛先オリジンサーバーへのトンネルを確立し、成功した場合、その後、トンネルが閉じられるまで、両方向でパケットをブラインド転送するように動作を制限することを要求します。トンネルは通常、1つ以上のプロキシを介して端末間の仮想接続を作成するために使用され、その後TLS (トランスポート層セキュリティ, [RFC5246]) を使用して保護できます。

CONNECTは、プロキシへのリクエストでの使用のみを目的としています。自身に対するCONNECTリクエストを受信したオリジンサーバーは、接続が確立されたことを示すために2xx (Successful) ステータスコードで応答できます (MAY)。ただし、ほとんどのオリジンサーバーはCONNECTを実装していません。

CONNECTリクエストを送信するクライアントは、権限形式のリクエストターゲット ([RFC7230] の Section 5.3) を送信しなければなりません (MUST)。つまり、リクエストターゲットは、コロンで区切られたトンネル宛先のホスト名とポート番号のみで構成されます。たとえば、

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

受信側プロキシは、リクエストターゲットに直接接続するか、別のプロキシを使用するように構成されている場合は、CONNECTリクエストを次のインバウンドプロキシに転送することでトンネルを確立できます。2xx (Successful) 応答は、送信者 (およびすべてのインバウンドプロキシ) が、成功した応答のヘッダーセクションを終了する空行の直後にトンネルモードに切り替えることを示します。その空行の後に受信されたデータは、リクエストターゲットによって識別されるサーバーからのものです。成功した応答以外の応答は、トンネルがまだ形成されておらず、接続がまだHTTPによって管理されていることを示します。

トンネル中間者がいずれかの側が接続を閉じたことを検出すると、トンネルは閉じられます。中間者は、閉じた側から来た未処理のデータを反対側に送信しようと試み (MUST)、両方の接続を閉じ、その後、配信されずに残っているデータを破棄しなければなりません。

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

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

任意のサーバーへのトンネルの確立には重大なリスクがあります。特に、宛先がWebトラフィックを意図していないよく知られた、または予約されたTCPポートである場合はそうです。たとえば、"example.com:25"へのCONNECTは、プロキシがSMTPトラフィック用の予約ポートに接続することを示唆します。許可されている場合、プロキシをだましてスパムメールをリレーさせる可能性があります。CONNECTをサポートするプロキシは、その使用を既知のポートの限定されたセットまたは安全なリクエストターゲットの構成可能なリストに制限すべきです (SHOULD)。

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

CONNECTリクエストメッセージ内のペイロードには定義されたセマンティクスがありません。CONNECTリクエストでペイロードボディを送信すると、一部の既存の実装がリクエストを拒否する可能性があります。

CONNECTメソッドへの応答はキャッシュ可能ではありません。

4.3.7. OPTIONS

OPTIONSメソッドは、ターゲットリソースで使用可能な通信オプションに関する情報を、オリジンサーバーまたは介在する中間者のいずれかで要求します。このメソッドにより、クライアントは、リソースアクションを暗示することなく、リソースに関連するオプションおよび/または要件、またはサーバーの機能を決定できます。

リクエストターゲットとしてアスタリスク ("") を持つOPTIONSリクエスト ([RFC7230] の Section 5.3) は、特定のリソースではなく、サーバー全体に適用されます。サーバーの通信オプションは通常リソースに依存するため、""リクエストは"ping"または"no-op"タイプのメソッドとしてのみ有用です。これは、クライアントがサーバーの機能をテストできるようにすること以外は何もしません。たとえば、これはプロキシのHTTP/1.1適合性 (または適合性の欠如) をテストするために使用できます。

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

OPTIONSへの成功した応答を生成するサーバーは、サーバーによって実装され、ターゲットリソースに適用可能なオプション機能を示す可能性のあるヘッダーフィールド (たとえば、Allow) を送信すべきです (SHOULD)。これには、本仕様で定義されていない潜在的な拡張も含まれます。応答ペイロード (もしあれば) は、機械または人間が読める表現で通信オプションを記述する場合もあります。本仕様では、そのような表現の標準形式は定義されていませんが、HTTPの将来の拡張によって定義される可能性があります。応答でペイロードボディが送信されない場合、サーバーは値"0"のContent-Lengthフィールドを生成しなければなりません (MUST)。

クライアントは、リクエストチェーン内の特定の受信者をターゲットにするために、OPTIONSリクエストでMax-Forwardsヘッダーフィールドを送信できます (MAY) (Section 5.1.2 を参照)。プロキシは、Max-Forwardsフィールドを持つリクエストが受信された場合を除き、リクエストを転送する際にMax-Forwardsヘッダーフィールドを生成してはなりません (MUST NOT)。

ペイロードボディを含むOPTIONSリクエストを生成するクライアントは、表現メディアタイプを記述する有効なContent-Typeヘッダーフィールドを送信しなければなりません (MUST)。本仕様ではそのようなペイロードの使用を定義していませんが、HTTPの将来の拡張では、OPTIONSボディを使用してターゲットリソースについてより詳細なクエリを行う可能性があります。

OPTIONSメソッドへの応答はキャッシュ可能ではありません。

4.3.8. TRACE

TRACEメソッドは、リクエストメッセージのリモートアプリケーションレベルのループバックを要求します。リクエストの最終受信者は、受信したメッセージを (以下に説明するいくつかのフィールドを除いて) 200 (OK) 応答のメッセージボディとして、Content-Typeを"message/http" ([RFC7230] の Section 8.3.1) としてクライアントに反射すべきです (SHOULD)。最終受信者は、オリジンサーバー、またはリクエストでMax-Forwards値がゼロ (0) を受信した最初のサーバーです (Section 5.1.2)。

クライアントは、応答によって開示される可能性のある機密データを含むヘッダーフィールドをTRACEリクエストで生成してはなりません (MUST NOT)。たとえば、ユーザーエージェントがTRACEリクエストで保存されたユーザー資格情報 [RFC7235] またはcookie [RFC6265] を送信するのは愚かです。リクエストの最終受信者は、応答ボディを生成する際に、機密データを含む可能性のあるリクエストヘッダーフィールドを除外すべきです (SHOULD)。

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

クライアントは、TRACEリクエストでメッセージボディを送信してはなりません (MUST NOT)。

TRACEメソッドへの応答はキャッシュ可能ではありません。

---