9. メソッド (Methods)

9.1. 概要 (Overview)

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

リクエストメソッドのセマンティクスは、リクエストに存在する一部のヘッダーフィールドのセマンティクスによってさらに特殊化される場合があります（これらの追加のセマンティクスがメソッドと競合しない場合）。たとえば、クライアントは条件付きリクエストヘッダーフィールド（セクション13.1）を送信して、リクエストされたアクションをターゲットリソースの現在の状態に依存させることができます。

HTTPは、分散オブジェクトシステムへのインターフェースとして使用できるように設計されています。リクエストメソッドは、リモートメソッド呼び出しが識別されたオブジェクトに送信される方法とよく似た方法で、ターゲットリソースに適用されるアクションを呼び出します。

method = token

メソッドトークンは大文字と小文字を区別します。これは、大文字と小文字を区別するメソッド名を持つオブジェクトベースのシステムへのゲートウェイとして使用される可能性があるためです。慣例により、標準化されたメソッドはすべて大文字のUS-ASCII文字で定義されます。

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

この仕様は、HTTPで一般的に使用される多数の標準化されたメソッドを定義しており、次の表で概説されています。

メソッド名	説明	セクション
GET	ターゲットリソースの現在の表現を転送する。	9.3.1
HEAD	GETと同じですが、レスポンスコンテンツを転送しない。	9.3.2
POST	リクエストコンテンツに対してリソース固有の処理を実行する。	9.3.3
PUT	ターゲットリソースのすべての現在の表現をリクエストコンテンツで置き換える。	9.3.4
DELETE	ターゲットリソースのすべての現在の表現を削除する。	9.3.5
CONNECT	ターゲットリソースによって識別されるサーバーへのトンネルを確立する。	9.3.6
OPTIONS	ターゲットリソースの通信オプションを記述する。	9.3.7
TRACE	ターゲットリソースへのパスに沿ってメッセージループバックテストを実行する。	9.3.8

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

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

この仕様の範囲外の追加のメソッドが、HTTPで使用するために指定されています。そのようなすべてのメソッドは、セクション16.1で説明されているように、「ハイパーテキスト転送プロトコル（HTTP）メソッドレジストリ」内に登録されるべきです。

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

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

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

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

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

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

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

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

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

リクエストメソッドは、そのメソッドを使用した複数の同一リクエストのサーバーへの意図された効果が、単一のそのようなリクエストの効果と同じである場合、「冪等」であると見なされます。この仕様で定義されたリクエストメソッドのうち、PUT、DELETE、および安全なリクエストメソッドは冪等です。

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

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

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

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

一部のクライアントは、よりリスクの高いアプローチを採用し、自動再試行が可能な場合を推測しようとします。たとえば、クライアントは、レスポンスのいかなる部分も受信される前に基礎となるトランスポート接続が閉じられた場合、特にアイドル状態の永続的な接続が使用された場合に、POSTリクエストを自動的に再試行する可能性があります。

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

9.2.3. メソッドとキャッシング (Methods and Caching)

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

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

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

9.3.1. GET

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

GETは情報検索の主要なメカニズムであり、ほとんどすべてのパフォーマンス最適化の焦点です。各重要なリソースのURIを生成するアプリケーションは、これらの最適化から利益を得ながら、他のアプリケーションによる再利用を可能にし、Webのさらなる拡大を促進するネットワーク効果を生み出すことができます。

リソース識別子をリモートファイルシステムのパス名と考え、表現をそのようなファイルの内容のコピーであると考えるのは魅力的です。実際、多くのリソースはそのように実装されています（関連するセキュリティ上の考慮事項についてはセクション17.3を参照）。ただし、実際にはそのような制限はありません。

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

クライアントは、リクエストにRangeヘッダーフィールド（セクション14.2）を送信することにより、GETのセマンティクスを「範囲リクエスト」に変更し、選択された表現の一部のみの転送を要求できます。

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

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

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

9.3.2. HEAD

HEADメソッドはGETと同じですが、サーバーはレスポンスでコンテンツを送信してはなりません (MUST NOT)。HEADは、表現データを転送せずに、選択された表現に関するメタデータを取得するために使用されます。多くの場合、ハイパーテキストリンクをテストしたり、最近の変更を見つけたりするために使用されます。

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

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

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

9.3.3. POST

POSTメソッドは、リクエストに含まれる表現を、リソース自身の特定のセマンティクスに従って処理することをターゲットリソースに要求します。たとえば、POSTは次の機能（その他も含む）に使用されます：

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

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

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

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

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

9.3.4. PUT

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

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

オリジンサーバーは、PUT表現がターゲットリソースに対して構成された制約と一致していることを検証すべきです (SHOULD)。たとえば、オリジンサーバーがURIに基づいてリソースの表現メタデータを決定する場合、オリジンサーバーは、成功したPUTリクエストで受信されたコンテンツがそのメタデータと一致していることを確認する必要があります。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を介して提供されるインターフェース以外に定義していません。リソース状態がどのように「保存」されるか、そのようなストレージがリソース状態の変更の結果としてどのように変更される可能性があるか、またはオリジンサーバーがリソース状態を表現にどのように変換するかも定義していません。一般的に言えば、リソースインターフェースの背後にあるすべての実装の詳細は、サーバーによって意図的に隠されています。

これは、オリジンサーバーが識別子をリソースに関連付ける方法を決定する方法にまで及びます。オリジンサーバーは、ターゲットURIをリソースにマッピングする責任を単独で負い、したがってそのリソースの作成、変更、または破棄について単独で責任を負います。ターゲットURIの形式とオリジンサーバーによって管理される内部状態との間に必要な関係はなく、URIはサーバーの実装の詳細に精通していないクライアントに対して不透明になります。

オリジンサーバーは、リクエストの表現データが適用されたコンテンツに変換せずに保存された場合（つまり、リソースの新しい表現データがPUTリクエストで受信されたコンテンツと同一である場合）を除き、PUTへの成功したレスポンスでバリデーターフィールド（セクション8.8）（ETagやLast-Modifiedフィールドなど）を送信してはなりません (MUST NOT)。この要件により、ユーザーエージェントは、送信した（およびメモリに保持している）表現がPUTの結果であることを知ることができ、したがってオリジンサーバーから再度取得する必要がありません。レスポンスで受信された新しいバリデーターは、偶発的な上書きを防ぐために、将来の条件付きリクエストに使用できます（セクション13.1）。

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

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

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

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

PUTリクエストへのレスポンスはキャッシュ可能ではありません。成功したPUTリクエストがターゲットURIに対して1つ以上の保存されたレスポンスを持つキャッシュを通過する場合、それらの保存されたレスポンスは無効化されます（[CACHING]のセクション4.4を参照）。

9.3.5. DELETE

DELETEメソッドは、ターゲットリソースとその現在の機能との関連付けを削除することをオリジンサーバーに要求します。実際には、このメソッドは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リクエストで受信されたコンテンツには一般的に定義されたセマンティクスがなく、リクエストの意味やターゲットを変更することはできず、リクエストスマグリング攻撃の可能性があるため、一部の実装がリクエストを拒否して接続を閉じる可能性があります（[HTTP/1.1]のセクション11.2）。クライアントは、以前に（インバンドまたはアウトオブバンドで）そのようなリクエストに目的があり、適切にサポートされることが示されたオリジンサーバーに直接行われる場合を除き、DELETEリクエストでコンテンツを生成すべきではありません (SHOULD NOT)。オリジンサーバーは、HTTP通信の参加者がリクエストチェーン上の仲介者を認識していないことが多いため、コンテンツを受信するために私的な合意に依存すべきではありません (SHOULD NOT)。

DELETEリクエストへのレスポンスはキャッシュ可能ではありません。成功したDELETEリクエストがターゲットURIに対して1つ以上の保存されたレスポンスを持つキャッシュを通過する場合、それらの保存されたレスポンスは無効化されます（[CACHING]のセクション4.4を参照）。

9.3.6. CONNECT

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

CONNECTは、プロキシへのリクエストでのみ使用することを目的としています。CONNECTリクエストを送信するクライアントは、request-targetの権限形式（セクション7.1）を送信しなければなりません (MUST)。つまり、request-targetは、コロンで区切られたトンネル宛先のホストとポート番号のみで構成されます。たとえば：

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

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

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

オリジンサーバーは、CONNECTリクエストを受け入れ、そうすることを選択した場合、トンネルの一端として参加することができます (MAY)。おそらくネットワークセキュリティまたはファイアウォールポリシーに関連する正当な理由のためです。その場合、オリジンサーバーは接続を終了し（クライアントから直接受信された場合）、リクエストメッセージ全体をブラインド転送されるデータとして扱い、そのデータを識別されたリスニングサービスに転送できます。あるいは、オリジンサーバーは、リクエストメッセージを自分自身の構成に適用されることを意図しているかのように処理することができます。これにより、送信トラフィックに対するファイアウォールの制限が回避されます（ソースと宛先の両方のクライアント/サーバーペアが同じシステム管理者によって制御されていると仮定）。いずれの場合も、オリジンサーバーは、ブラインド転送された場合にセキュリティまたは操作に影響を与える可能性があるため、そのようなCONNECTのリクエストメッセージに基づいてアクセス制御を適用することができます (MAY)。

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

CONNECTリクエストメッセージにはコンテンツがありません。CONNECTリクエストの後に送信されたデータの解釈は、使用されているHTTPのバージョンに固有です。HTTP/1.1でのCONNECTの詳細については、[HTTP/1.1]のセクション9.3.6を参照してください。

CONNECTリクエストへのレスポンスはキャッシュ可能ではありません。

9.3.7. OPTIONS

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

request-targetとしてアスタリスク（「」）を持つOPTIONSリクエスト（セクション7.1）は、特定のリソースではなく、サーバー全般に適用されます。サーバーの通信オプションは通常、リソースに依存するため、「」リクエストは、「ping」または「no-op」タイプのメソッドとしてのみ有用です。クライアントがサーバーの機能をテストできるようにする以外、何もしません。たとえば、これを使用して、プロキシのHTTP/1.1準拠（またはその欠如）をテストできます。

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

OPTIONSへの成功したレスポンスを生成するサーバーは、サーバーによって実装され、ターゲットリソースに適用可能なオプション機能を示す可能性のあるヘッダーフィールド（Allowなど）を送信すべきです (SHOULD)。この仕様で定義されていない潜在的な拡張も含まれます。レスポンスコンテンツがある場合、機械または人間が読める表現で通信オプションを説明することもあります。そのような表現の標準形式はこの仕様では定義されていませんが、HTTPの将来の拡張によって定義される可能性があります。

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

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

OPTIONSリクエストへのレスポンスはキャッシュ可能ではありません。

9.3.8. TRACE

TRACEメソッドは、リクエストメッセージのリモート、アプリケーションレベルのループバックを要求します。リクエストの最終受信者は、以下で説明するいくつかのフィールドを除いて、受信したメッセージをクライアントに返すべきです (SHOULD)。これは、Content-Typeが「message/http」（[HTTP/1.1]のセクション8.3.1）である200（OK）レスポンスのコンテンツとして行われます。最終受信者は、オリジンサーバーまたはリクエスト内でMax-Forwards値がゼロ（0）を受信した最初のサーバーです（セクション7.6.2）。

クライアントは、レスポンスによって開示される可能性のある機密データを含むヘッダーフィールドをTRACEリクエストで生成してはなりません (MUST NOT)。たとえば、ユーザーエージェントが保存されたユーザー認証情報[HTTP-AUTH]またはCookie[COOKIE]をTRACEリクエストで送信するのは愚かです。リクエストの最終受信者は、レスポンスコンテンツを生成する際に、機密データを含む可能性が高いリクエストヘッダーフィールドを除外すべきです (SHOULD)。

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

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

TRACEリクエストへのレスポンスはキャッシュ可能ではありません。