この頁では、HTTPリクエストの性質を決定するための「HTTPメソッド」について、HTTP/1.1の仕様書や関連仕様書などをもとに解説します。
HTTPは、HTTPクライアントからのリクエストと、それに対するHTTPサーバからのレスポンスというメッセージの送受信によって成立しています。 このうち、リクエストについては、RFC 2616のsection 5に、以下のように規定されています。
クライアントからサーバへのリクエストメッセージには、リソースに適用されるメソッド、リソースの識別子、使用するプロトコルのバージョンが最初の行に含まれる。
Request = Request-Line ; Section 5.1 *(( general-header ; Section 4.5 | request-header ; Section 5.3 | entity-header ) CRLF) ; Section 7.1 CRLF [ message-body ] ; Section 4.3
(※) このような表記方法のことを、考案者（J.W. Backus, Peter Naur）の名をとって、BNFと言います。 RFC 2616では、オリジナルのBNFを拡張した「拡張BNF」と呼ばれるフォーマットが使用されています。 詳細は、section 2をご覧下さい。
上記を読み解くと、Requestというデータは、以下のような構成になることがわかります。
Request-Lineが必ず1つ存在しgeneral-header, request-header, entity-headerのいずれかの後にCRLF）という組が0個以上存在し（※）CRLFが必ず1つ存在するmessage-bodyはオプショナルである(※) ただし、HTTP/1.1リクエストの場合、Hostヘッダが必ず含まれなければならないので、正確にはこの記述では不十分となります。
このうち、先頭のRequest-Lineについては、“;”によってコメントされているように、section 5.1に記述されています。
リクエストラインは、メソッドトークンに始まり、リクエストURI とプロトコルバージョンが後に続き、
CRLFで終了する。 要素はSPによって分けられる。 最後のCRLFシーケンス以外には、CRもLFも許されない。Request-Line = Method SP Request-URI SP HTTP-Version CRLF
これによると、Request-Lineというものは、Method, SP, Request-URI, SP, HTTP-Version, CRLFが順番に1つずつ並べられているということがわかります。
すなわち、HTTPリクエストの1行目は、それぞれが空白文字（SP）で区切られた、HTTPメソッド, リクエストURI, HTTPバージョンから成るということになります。
さて、HTTPメソッドについては、RFC 2616のsection 5.1.1に記述されています。
メソッドトークンは、 Request-URI により識別されるリソースに働きかけるためのメソッドを示す。 メソッドは大文字・小文字を区別する。
Method = "OPTIONS" ; Section 9.2 | "GET" ; Section 9.3 | "HEAD" ; Section 9.4 | "POST" ; Section 9.5 | "PUT" ; Section 9.6 | "DELETE" ; Section 9.7 | "TRACE" ; Section 9.8 | "CONNECT" ; Section 9.9 | extension-method extension-method = token
メソッドとは、リクエストURIと組み合わせて使用されるもので、そのURI先にあるリソースに対してどのように振る舞って欲しいかを働きかけるためのもので、HTTP/1.1では8つのメソッドが定義されています。 しかし、メソッドは拡張できるように設計されているので、例えばWebDAVでは上記以外の様々なメソッドが提案されています。
HTTP のメソッドには、安全{safe} なメソッドと冪等{idempotent} なメソッドという概念があります。
安全{safe} なメソッドについては、section 9.1.1 に記述されています。
実装者は、インターネット上における相互動作においてはソフトウェアがユーザを表しているという事を認識すべきであり、ユーザがそれら自身や他のものに対して予測しない意図を持つようなあらゆる動作に気がつく事ができるように注意すべきである。
特に、GET と HEAD メソッドはその動作にリソースの回収以上の意味を持つべきではないという慣習が確立されている。 これらのメソッドは、"安全{safe}" だと考えるべきである。 これによって、ユーザエージェントがそれ以外の、例えば POST, PUT, DELETE のようなメソッドを特別な方法で表す事ができるようになり、ユーザにひょっとしたら安全でない動作が要求されているかもしれないという事実を認識させる。
本質的に、サーバが GET リクエストを実行した結果として副作用を起こさないという事を保証するのは不可能であり、事実、いくつかの動的なリソースはそれが特徴であると考えている。 ここで特に区別すべきなのは、ユーザが副作用を要求しなかったという事であり、それゆえにそれらに対しては責任をもてない。
例えば、POST や PUT メソッドでは、クライアントが「特定のリソースをサーバに送る」事を前提にしています。 これは、サーバ上のリソース状態を変更する事であり、よってこれらを使用する場合は多少なりともセキュリティを考慮する必要があると考えるべきです。
これに対し、GET と HEAD メソッドは、本来の「リソースの回収」以上の意味を持つべきではないと考えられています。 よって、これらの使用は上記のメソッドと比較して安全であると考えられます。
但し、実際には GET メソッドを利用して CGI を作動させる事も可能であり、これらのメソッドが完全に安全であると言い切る事はできません。 しかし、このような場合は、セキュリティに責任を持つべきなのはサーバ側であり、クライアント側に責任はないという事が述べられています。
(※) 逆に、サーバにとって安全な POST メソッドがあるかもしれません。 このような場合、オリジンサーバは、そのリクエストは繰り返しても安全という意味で Safe: yes というレスポンスヘッダを送る事ができるという仕組みが RFC 2310 で提案されました。 但し、この仕組みを実装しているサーバはほとんどないでしょう。
冪等{idempotent} なメソッドについては、section 9.1.2 に記述されています。
メソッドは、(エラーや期限切れ発行とは別に) 同一のリクエストの N > 0 の副作用が単一のリクエストにおけるものと同じであるような際には "冪等{idempotence}" の性質を持つ事もできる。 GET, HEAD, PUT, DELETE 各メソッドはこの性質を共有する。 また、OPTIONS と TRACE 各メソッドは副作用を持つべきではないし、本来冪等であるものである。
しかしながら、たとえその順序にて実行される全てのメソッドが冪等であったとしても、いくつかのリクエストの順番は冪等ではない。 (もし全体の順序中のある一つを実行しても、その順序の全体、または一部分を再実行した際に結果は常に変わらないという事になるのであれば、順序は冪等である。) 例えば、同じ順序でもその結果が後に修正される値に依存するのであれば、順序は冪等ではない。
副作用を持たない順序は、(同時に起こる動作は同じリソースの一組{set} 上に実行されている事は無い、との条件で) 定義によって冪等である。
「冪等」の概念は、HyperText Transfer Protocol Design Issues 中の Idempotent ? という節で表れます。
もう一つの選択はプロトコルを冪等にするかどうかである。 すなわち、サーバがクライアントについての状態情報を保持する必要があるかどうかである。 (例えば、NFS プロトコルは冪等であるが、FTP や NNTP プロトコルは冪等ではない。) FTP の場合、状態情報は、毎回確立する必要がある認証や、基本的にそうする必要がないカレントディレクトリや転送モードから成る。 ここで提案されるプロトコルは冪等である。
例えば、ブラウザからある HTML ファイルに GET リクエストを行ったとします。 この場合、その HTML 文書がブラウザに出力されるでしょう。 この時、もう一度同じファイルに同じ GET リクエストを行ったとしたら、その結果はどうなるでしょうか? その結果は、当然先程と同じ文書が、同じようにブラウザに出力される事でしょう。 一般に「同じデータについて何度操作が行なわれても、同じ結果になるような操作」の事を冪等な操作と言います。 すなわち、リソースを取得するための GET、リソースに関するヘッダを取得するための HEAD、リソースをアップロードするための PUT、リソースを削除するための DELETE 等は、同じメソッドを何度繰り返しても同様な結果を返すはずなので、これらは冪等なメソッドであると言えます。
但し、複数の冪等なメソッドを組み合わせた結果が常に冪等になるとは限りません。 これは例えば、ある URI に対して「GET してから PUT する」のと「PUT してから GET する」事の違いを思い浮かべて頂ければご理解いただけると思います。
一方、POST メソッドは、その設計思想においてデータの投稿、すなわち「書き込み」を念頭においているので、これは冪等なメソッドではありません。 例えば、あるファイルに文字列 "abc" を書き込むとします。 これを二度繰り返せば、ファイルには当然 "abcabc" と書き込まれている筈であり、従って「書き込む」という処理は冪等ではないのです。 よって、POST が書き込む事を念頭においている以上、これは冪等ではないメソッドと見なすべきでしょう。
(※) 実際には「結果的に冪等にならない GET」や「結果的に冪等になる POST」というものは、リソース次第ではあり得ることです。 しかし、これらはあくまで個々の特別な場合であり、あくまで「メソッドの性質」を言い表すには適切ではないということです。
ここからは、HTTP/1.1 にて定義されている各メソッドについてそれぞれ見ていきましょう。
GETメソッドは、HTTP/0.9で定義された唯一のメソッドで、またHTTPでは最も使用されるメソッドです。 HTTP/1.1アプリケーションは、GETメソッドをサポートしなければいけません。 GETメソッドについては、RFC 2616のsection 9.3に記述されています。
GET メソッドは、 Request-URI で識別される (エンティティ形式の) 情報ならなんでも回収する事を意味する。 もし、 Request-URI がデータ生産プロセス{data-producing process} を参照するのであれば、それはレスポンスのエンティティとして返されるであろうとして生産されるデータであり、もしそのテキストがプロセスの出力として生じるのでなければ、プロセスのソーステキストではない。
GETリクエストに対するレスポンスメッセージは、HTML文書や画像ファイルなどの静的なファイルの場合、サーバ上のファイルがそのまま返されます。 それに対し、たとえばCGIを実行させるリソースへリクエストした場合、レスポンスはCGIのソーステキストではなく、CGIによって生成されたリソースとなります。
GETリクエストは、最も頻繁に使用されるメソッドなので、特殊なリクエスト方法が容易されています。 これらの使用により、帯域や通信時間の節約ができます。 引き続き、section 9.3をご覧ください。
リクエストメッセージに If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, If-Range のいずれかのヘッダフィールドを含んでいる場合、GET メソッドの意味論は条件付き GET に変わる。 条件付き GET メソッドは、エンティティがその条件付きヘッダフィールドによって表される状況下でのみ転送されるようにリクエストする。 条件付き GET メソッドは、キャッシュされるエンティティに複数のリクエストを要求する事や、クライアントによってすでに保持されているデータを転送する事無く清新できるようにする事で、不必要なネットワークの使用を減らそうというものである。
GETリクエストでは、ネットワーク資源の節約のために、リソースの取得に「条件」をつけることができます。 リクエスト時にIf-Modified-Sinceヘッダなどの条件指定ヘッダを加えることで、このリクエストは条件付きGETリクエスト{Conditional GET Request}になります。 条件付きGETリクエストによって、キャッシュを有効活用できるようになり、帯域や通信時間の節約ができます。
リクエストメッセージに Range ヘッダフィールドを含んでいる場合、GET メソッドの意味論は "部分的 GET" に変わる。 部分的 GET は、section 14.35 で示されるように、転送されるエンティティの一部のみを要求する。 部分的 GET メソッドは、クライアントによって既に保持されているデータを転送する事無くエンティティを部分的に取得させて、完全なものにできるようにする事で、不必要なネットワークの使用を減らそうというものである。
また、リクエストヘッダにRangeヘッダなどの範囲指定ヘッダを加えることで、このリクエストは範囲リクエスト（部分的GETリクエスト）になります。 範囲リクエストによって、クライアントが既に所有しているリソースの一部を有効活用できるので、こちらも帯域や通信時間の節約ができます。
HTTP/1.1アプリケーションは、GETメソッドだけでなく、HEADメソッドもサポートしなければいけません。 HEADメソッドについては、RFC 2616のsection 9.4に記述されています。
HEAD メソッドは、サーバがレスポンスにおいてメッセージボディを返してはならない事を除けば GET と同一である。 HEAD リクエストへのレスポンスにおける HTTP ヘッダに含まれる外部情報は、GET リクエストへのレスポンスで送られる情報と同一であるべきである。 このメソッドは、エンティティボディ自身を転送する事なしにリクエストによって意味されるエンティティに付いての外部情報を得るために使用される。 このメソッドは、ハイパーテキストリンクの正当性、アクセス可能性、最近の修正のテストのために、しばしば使用される。
HEADリクエストに対するレスポンスでは、レスポンスヘッダはGETリクエストに対するものと同じになるはずですが、レスポンスボディが含まれてはいけません。
POSTメソッドはHTTP/1.0からサポートされたメソッドで、現在ほとんどのHTTPサーバでサポートされています。 section 9.5をご覧ください。
POST メソッドは、サーバがリクエストライン内の Request-URI により識別されるリソースへの新しい従属{subordinate} として、リクエストに同封されるエンティティを受け入れる事を要求するために使用される。 POST は以下の機能のカバーするための画一的メソッドとして設計されている。
- 既存リソースの注釈
- 掲示板、ニュースグループ、メーリングリスト、あるいはその類の記事グループへのメッセージの投稿
- フォーム提出の結果のような、データ処理プロセス {data-handling process} へのデータブロックの供給
- 追加動作を通したデータベースの拡張
POST メソッドによって実行される実際の機能はサーバによって決定され、通常は Request-URI に依存する。 ポストされたエンティティは、ファイルがディレクトリに従属し、ニュース記事がそれがポストされたニュースグループに従属し、レコードがそのデータベースに従属しているという事と同じ形で、その URI に従属する。
POST メソッドによって実行される動作は、URI によって識別されうるリソースという結果にはならないかもしれない。 この場合、200 (OK) か 204 (No Content) が適切なレスポンスステータスであり、それはレスポンスが結果を記述したエンティティを含んでいるかどうかに依存する。
リソースがオリジンサーバで既に生成されている場合、レスポンスは 201 (Created) であり、リクエストのステータス、新しいリソースへの参照、Location ヘッダ (section 14.30) を記述したエンティティを含むべきである。
POSTメソッドは、エンティティボディを転送するために使います。 GETでもエンティティボディを転送することができますが、GETよりも大量のデータを転送することができます。 この時、エンティティボディのメディアタイプとしては、一般的に以下のようなものを利用します。
GETはほぼすべての場合「リソースの取得(GET)」という目的のためだけに利用されますが、POSTはそれよりも「自由度の高い」メソッドとして、たとえば「リソースの生成や削除」といった本来の用途にも利用されています。 これは、歴史的な経緯で、昔はHTTPメソッドがGETとPOSTしかなく、その場合にリソースの生成や削除を行おうとすれば、POSTしかメソッドがなかったからです。 この時、たとえばCGIなどのサーバサイド技術を利用して、リクエストボディを「操作コマンド」とみなし、リソースの生成や削除といったことを行っていました。
その後、PUTやDELETEといった、より目的に即したメソッドがHTTP/1.1にて定義されたのですが、すでに世の中のWebアプリケーションの多くが上記の考え方によって設計されており、ほとんどの場合はその設計を模倣したため、今でもPOSTは様々な用途に利用されています。
POSTは、GETと違い、レスポンスボディを取得することが目的ではないので、レスポンスボディが存在しない場合もあります。 その場合、ステータスコードは204 (No Content) を返します。
PUTメソッドは、HTTP/1.0からサポートされたメソッドで、section 9.6にて記述されています。
PUT メソッドは、同封されたエンティティを供給される Request-URI の元に保存するように要求する。 Request-URI が既に存在するリソースを参照している場合は、同封されるエンティティはオリジンサーバにあるそれの修正版とみなされるべきである。 Request-URI が既存のリソースを指していない場合に、その URI がリクエストしているユーザエージェントによって新しいリソースとして定義する事ができる時は、オリジンサーバはその URI にリソースを作成できる。 新しいリソースが作成された場合、オリジンサーバは 201 (Created) レスポンスをもってユーザエージェントに知らせなければならない。 既存のリソースが更新された場合は、リクエストが成功し終了した事を示すために 200 (OK) か 204 (No Content) のいずれかのレスポンスコードを送るべきである。 もし、リソースがそのリクエスト URI に作成、あるいは更新されなかった時は、問題の本質を反映する適切なエラーレスポンスが与えられるべきである。 エンティティを受ける側は、理解できなかったり実装していないようないかなる Content-* ヘッダ (例えば Content-Range 等) も無視してはならず、そのような場合には 501 (Not Implemented) レスポンスを返さなければならない。
(中略)
リクエスト POST と PUT とでの根本的な違いは、 Request-URI の意味の違いをもたらす。 POST リクエストにおける URI は、同封されたエンティティを処理するであろうリソースを識別する。 リソースは、データ受諾プロセス{data-accepting process} か、ある別のプロトコルへのゲートウェイ、あるいは注釈を受け入れる分割されたエンティティであろう。 それに対して、PUT リクエストにおける URI は、リクエストとともに同封されたエンティティを識別する。 しかし、ユーザエージェントがリソースにその URI を割り当てるつもりであっても、サーバはそのリクエストをある別のリソースへと割り当てようとしてはならない。 そのリクエストを別の URI に申しこむように要求する時は、サーバは 301 (Moved Permanently) レスポンスを返さなければならない。 この時、ユーザエージェントはそのリクエストをリダイレクトするかどうかに関して決める事ができる。
PUTは、ローカルにあるファイルをサーバに転送するためのメソッドです。 PUTリクエストを受けたサーバは、 リクエストURIに示された場所にリソースを生成しようとします。 この時、新規に生成した場合は201レスポンスを、また既存のリソースを更新した場合は200か204のレスポンスをそれぞれ返します。
「サーバ上にリソースを生成する」という意味では、たとえばCGIなどの技術を利用すればPOSTメソッドによってもリソースを生成することができますが、この場合各リクエストにおけるリクエストURIの意味は完全に異なります。 POSTの場合、リクエストURIは「リクエストを処理する場所」を指しますが、PUTでは「リソースが生成される場所」を指します。 その意味で、HTTPのPUTメソッドは「FTPのPUTメソッド」と同様であるということができます。
PUTはHTTP/1.0から定義されているメソッドですが、セキュリティの観点からGETやPOSTほど広くは利用されていません（※）。 利用できないサーバでは、ステータスコード501を返さなければいけません。
（※） リクエストを送るサーバで、このメソッドが利用かどうかは、OPTIONSで確認できます。
DELETEメソッドは、PUTの逆で、リソースの削除を要求するメソッドです。 section 9.7をご覧下さい。
DELETE メソッドは、オリジンサーバが Request-URI により識別されるリソースを削除する事を要求する。 このメソッドは、オリジンサーバにおいて人間の手 (あるいは別の方法) によって上書きされているかもしれない。 例えオリジンサーバから返されたステータスコードは動作がうまく完了したという事を示していたとしても、クライアントはその操作が実行された事は保証されない。 しかしそのレスポンスが与えられた場合に、サーバがそのリソースを削除したり、アクセスできない場所へ移動したりしようとしていないのであれば、成功を示すべきではない。
成功したレスポンスは、もしレスポンスがステータスで表しているエンティティを含んでいるなら 200 (OK)、もし動作がまだ行われていないなら 202 (Accepted)、もし動作は行われたが、レスポンスにエンティティを含んでいないなら 204 (No Content) であるべきである。
もし、リクエストがキャッシュを通り抜けたり、 Request-URI が現在キャッシュされている一つ以上のエンティティとして識別されるなら、これらのエンティティは新鮮でないものとして扱われるべきである。 このメソッドのレスポンスはキャッシュできない。
DELETEも、PUTと同様にHTTP/1.0から定義されているメソッドですが、セキュリティの観点からGETやPOSTほど広くは利用されていません（※）。 利用できないサーバは、ステータスコード501を返さなければいけません。
（※） リクエストを送るサーバで、このメソッドが利用かどうかは、OPTIONSで確認できます。
OPTIONS メソッドは、HTTP/1.1 からサポートされたメソッドで、 Request-URI 先にあるリソースへの通信オプションを訪ねるためのメソッドで、その詳細は section 9.2 に記述されています。
OPTIONS メソッドは、 Request-URI によって識別されるリクエスト/レスポンス連鎖上で利用可能な通信オプションについての情報のためのリクエストを表す。 クライアントは、このメソッドはを使ってリソースアクションを暗に意味したりリソース回収を初期化する事なしに、リソースやサーバの能力に関するオプションや必要条件を決定する事ができる。
このメソッドへのレスポンスはキャッシュ可能ではない。
(中略)
もし、 Request-URI がアスタリスク ("*") なら、OPTIONS リクエストは特定のリソースへというよりも全体としてサーバへ適用する意思を示す。 サーバのコミュニケーションオプションは典型的にリソースに依存するので、"*" リクエストは、まるで "ping" や "no-op" のように使われるのみで、すなわちサーバの能力をテストするする事をクライアントに許可する以上には意味を持たない。 例えば、これはプロクシに HTTP/1.1 に従っているか (あるいはその機能が欠けているか) をテストするために使われる。
もし、 Request-URI が アスタリスクでなければ、OPTIONS リクエストはそのリソースと通信する時に利用可能なオプションのみを尋ねる。
このメソッドは、 Request-URI のリソースがどんなメソッドをサポートしているかを調べるために使われます。 例えば、以下のようなリクエストを送ったとします。
OPTIONS /resource HTTP/1.1 Host: www.studyinghttp.net
すると、以下のようなレスポンスが返されるでしょう。
HTTP/1.1 200 OK Date: Sat, 28 Sep 2002 03:36:17 GMT Server: Apache/1.3.20 Content-Length: 0 Allow: GET, HEAD, OPTIONS, TRACE Connection: close
このように、Allow ヘッダによってこのリソースに対して利用可能なメソッドが列挙されます。
また、特定のリソースでは無く、そのサーバ全体の能力を尋ねたい場合は Request-URI に "*" を使います。
TRACE メソッドは、特定のサーバに接続し、そこからループバックを起こすために使うメソッドです。 section 9.8 をご覧下さい。
TRACE メソッドは、リクエストメッセージのアプリケーション層のループバックを遠隔的に発動するために使用される。 リクエストの最後の受信者は、200 (OK) レスポンスのエンティティボディとして、そのメッセージをクライアントにそのまま送り返すべきである。 最後の受信者とは、オリジンサーバ、もしくはリクエストで Max-Forwards (section 14.31) 値がゼロ (0) であったものを受け取った最初のプロクシかゲートウェイである。 TRACE リクエストはエンティティを含んではならない。
TRACE を使って、クライアントはリクエスト連鎖の反対側では何が受け取られているのかを見る事や、テストや診断情報のためのデータを使用する事ができる。 これはリクエスト連鎖のトレースとして動作するので、Via ヘッダフィールド (section 14.45) の値が特に重要である。 Max-Forwards ヘッダフィールドを使用する事で、クライアントにリクエスト連鎖の大きさに制限を与える事ができ、これは無限ループ上でメッセージを転送するプロクシ連鎖をテストするために有用である。
もしリクエストが妥当ならば、レスポンスは
"message/http"という Content-Type と一緒に、エンティティボディとしてリクエストメッセージの全体を含むべきである。 このメソッドのレスポンスはキャッシュされてはならない。
例えば、以下のようなリクエストを送ったとします。
TRACE / HTTP/1.1 Host: www.studyinghttp.net Max-Forwards: 5
TRACE の場合、Max-Forwards ヘッダに注目する必要があります。 この場合、クライアントとオリジンサーバの間のプロクシ (ゲートウェイ) が
が、それぞれレスポンスボディを作成します。
TRACE メソッドの一番の目的は、オリジンサーバが受け取るリクエストを見る事です。 特にプロクシの動作を確認する事は重要です。 どんなプロクシが稼動しているかは Via ヘッダを見る事で解ります。
(※) HTTP/1.1 プロクシは、転送の際に Via ヘッダを付加する事が必須となっています (section 14.45)。
CONNECT メソッドは、プロクシにトンネリングを要求するためのメソッドです。
この仕様書では、(例えば SSL トンネリング等の) トンネルとなるように動的に切り換える事ができるプロクシが使用する時のために CONNECT というメソッド名を予約する。
CONNECT メソッドは、プロクシにトンネル接続の確立を要求する。 リクエストラインの Request-URI の部分は、常に URI 一般構文 (訳注: RFC 2396) によって定義されるような 'authority' であり、リクエストされるコネクションの目的地となるホスト名とポート番号とをコロンで区切ったものである。
CONNECT server.example.com:80 HTTP/1.1 Host: server.example.com:80もちろん CONNECT と共に他の HTTP メカニズムも使用する事ができるが、エンドトゥエンドでのプロトコル Upgrade リクエストは除かれる。 何故なら、トンネルは最初に確立されなければならないからである。
例えば、プロクシ認証はトンネルを作成する
authorityを確立するために使用されるかもしれない:CONNECT server.example.com:80 HTTP/1.1 Host: server.example.com:80 Proxy-Authorization: basic aGVsbG86d29ybGQ=
CONNECT リクエストに対する成功 (2xx) レスポンスは、プロクシがリクエストされたホストとポートに接続を確立したという事、及び現在の接続をサーバへの接続をトンネリングするものへ切り換えたという事を示す。
そのプロクシからリクエストされるオリジンサーバへ到達するには、他のプロクシを経なければならない場合もあるかもしれない。 この場合、最初のプロクシは、その authority へトンネルを要求するために、その次のプロクシへ CONNECT リクエストを送信すべきである。 プロキシは、その authority への直接、あるいはトンネルでの接続が確立しない限り、いかなる 2xx ステータスコードも返してはならない。
自身に向けられた CONNECT リクエストを受信したオリジンサーバは、接続が確立した事を示すために 2xx ステータスコードを返す事ができる。
CONNECT は、SSL 等のプロトコルで暗号化されたものをトンネルさせるために使うメソッドです。 SSL は Netscape Communications 社によって提案された技術で、OSI 参照モデルではトランスポート層 (第 4 層) にあたります。 現在、SSL は Netscape 社以外の HTTP アプリケーションにも実装されており、また SSL 3.0 を基に若干の改良が加えられた TLS 1.0 が RFC 2246 として提案されています。
プロクシがトンネルを確立すると、その後のリクエストに関しては一切関知しません。 そのため、認証が必要なプロクシの場合は、CONNECT リクエストに Proxy-Authorization を含めなければなりません。
PATCHメソッドは、サーバに既存のリソースを修正するために、エンティティにパッチをあてる、すなわち差分のみを更新することにより、リソース全体の更新を容易にするためのメソッドとして、HTTP/1.1仕様書の初版であるRFC 2068にて提案されました。
PATCHメソッドは、そのエンティティがリクエストURIによって識別されるリソースのオリジナルバージョンと、PATCH動作が適用された後のリソースに望まれる内容との差分のリストを含んでいることを除いて、PUTと類似している。 差分のリストはエンティティのメディアタイプ（例えば、“application/diff”）によって定義されるフォーマットにおけるものであり、リソースのオリジナルバージョンを望まれるバージョンに変換するために必要な変更をサーバが再生成できるような十分な情報を含まなければならない。
しかしながら、PATCHメソッドはサーバ上のリソースを書き換えるためのメソッドであり、セキュリティ上の理由からRFC 2068発行後もほとんど実装されることはありませんでした。 そのため、HTTP/1.1の仕様書がRFC 2616に更新される際に、PATCHメソッドについての記述は削除されました。 RFC2616のsection 19.6.3をご覧下さい。
この仕様書の前のバージョンではPATCH, LINK, UNLINK各メソッドが定義されていたが、これは一般には実装されていない。 RFC 2068参照。
こうして、一度は仕様書上から消えたPATCHメソッドですが、2010年3月にRFC 5789が発行され、その中で初期のアイデアよりも厳密に規定されて復活しました。
本仕様書は、新たなHTTP/1.1 [RFC2616]メソッドである、PATCHメソッドを定義する。 これは、リソースに対して部分的な修正を適用するために使用される。
新たなメソッドは、相互互換性を改善し、エラーを排除するために必要である。 既にPUTメソッドが、完全に新たな本体{body}をもってリソースを上書きするために定義されているが、このメソッドでは部分的な変更を行うために再利用することはできない。 一方、その操作の結果として、プロクシやキャッシュ、さらにクライアントやサーバでさえも、混乱させるかもしれない。 また、既にPOSTメソッドも使用されているが、広い相互互換性はない（人々にとって、パッチフォーマットのサポートを発見するための標準的な道のりはない）。 PATCHは、初期のHTTP仕様書にて言及されていたが、完全には定義されていなかった。
PATCHメソッドが再び議論されることとなった理由として、近年ではWebを単なる「大規模なリソース配布のためのシステム」としてではなく、「遠隔・複数人によってリソースを管理するためのシステム」として利用したいというニーズが出てきましたことが考えられます。 そうなると、たとえば100MByteもある大きなサイズのリソースに対して、わずか50バイトの修正を行いたい時に、既存のHTTPメソッドだけでは物足りません。 たとえば、PUTを使うとしても、一度きりならばまだよいですが、これが修正を頻繁に行うということであれば、毎回100MByteを再転送することになり、非常に効率が悪いです。 また、POSTで50バイトを送るようにして、サーバ側でそのような「差分を組み込む」ための仕組みを作ったとしても、転送データ上は「50バイトのメッセージボディを持つPOSTリクエスト」でしかなく、それらのリクエスト/レスポンスに関して、 プロクシのような中継者や、キャッシュについての考慮などが別途必要になってきます。
新たに提案されたPATCHメソッドでは、HTTP上でメッセージボディが「パッチを当てるためのもの」であることを明確にします。 ただし、RFC 5789では、「パッチのフォーマット」についての具体的な規定はありません。 これは、たとえば「XML文書へのパッチあて」と「バイナリファイルへのパッチあて」では全く違う仕組みが必要になりますし、そのような仕組みについての議論はHTTPという転送プロトコルの範疇を超えるからです。
（※） RFC 5789上では、PATCHの運用例などは、すべて架空のメディアタイプで記述されており、パッチフォーマットのメディアタイプなど、具体的な記述については一切記されていません。
LINKとUNLINKという二つのメソッドについては、HTTP/1.1の一つ前のバージョンであるHTTP/1.0の仕様書であるRFC 1945にて既に提案されていました。
LINKメソッドは、Request-URIによって識別される既存のリソースと他の既存のリソースとの間に一つ以上のリンク関係を確立する。
UNLINKメソッドは、Request-URIによって識別される既存のリソースの一つ以上のリンク関係を削除する。
このメソッドは、あるリソースとその他のリソースに関連付けを行う/やめるためのメソッドであり、他のメソッドと違って、具体的にクライアント/サーバ間でリソースのやり取りを行うためのものではありません。 WWWにおける各リソース（元々はHTML文書を想定）は、書籍などと異なり、それぞれが独立して存在しているため、これを「一連の文書」として括るための仕組みが必要だったのです。
しかし、RFC 2616では「ほとんど利用されていないメソッドである」という理由で、仕様書から削除されてしまいました。 また、LINKメソッドと同じような狙いを持つLinkヘッダも、同じくRFC 2616にて廃案となってしまいました。
（※） ただし、この仕組みを考える元となったHTML文書には、<link>という要素があります。 この仕組みは、HTML文書と他のリソース（CSSファイルや、JavaScriptコードなど）を関連付けるために、広く利用されています。
WebDAV について定義している仕様書の最新版は、HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV) です。 その Section 9 (HTTP Methods for Distributed Authoring) では、以下のメソッドについて記述されています。
プロパティ - リソースについての記述された情報を含む名前/値の組と定義されていますが、このメソッドはそのプロパティ (PROPerty) を取得 (FIND) するためのメソッドです。
また、これ以外にも WebDAV では様々なメソッドが提案されています。 そのため、IANA では IANA HTTP Method Registry を作り、メソッド名を一括で管理する事にしています。
(※) IANA HTTP Method Registry に登録される予定のメソッドは以下の通りです。
| メソッド名 | 安全か | 参照 |
|---|---|---|
| ACL | no | [RFC3744], Section 8.1 |
| BASELINE-CONTROL | no | [RFC3253], Section 12.6 |
| CHECKIN | no | [RFC3253], Section 4.4 and [RFC3253], Section 9.4 |
| CHECKOUT | no | [RFC3253], Section 4.3 and [RFC3253], Section 8.8 |
| COPY | no | [RFC4918], Section 9.8 |
| LABEL | no | [RFC3253], Section 8.2 |
| LINK | no | [RFC2068], Section 19.6.1.2 |
| LOCK | no | [RFC4918], Section 9.10 |
| MERGE | no | [RFC3253], Section 11.2 |
| MKAKTIVITY | no | [RFC3253], Section 13.5 |
| MKCALENDAR | no | [RFC4791], Section 5.3.1 |
| MKCOL | no | [RFC4918], Section 9.3 |
| MKREDIRECTREF | no | [RFC4437], Section 6 |
| MKWORKSPACE | no | [RFC3253], Section 6.3 |
| MOVE | no | [RFC4918], Section 9.9 |
| ORDERPATCH | no | [RFC3648], Section 7 |
| PATCH | no | [RFC2068], Section 19.6.1.1 |
| PROPFIND | yes | [RFC4918], Section 9.1 |
| PROPPATCH | no | [RFC4918], Section 9.2 |
| REPORT | yes | [RFC3253], Section 3.6 |
| SEARCH | yes | [RFC5323], Section 2 |
| UNCHECKOUT | no | [RFC3253], Section 4.5 |
| UNLINK | no | [RFC2068], Section 19.6.1.3 |
| UNLOCK | no | [RFC4918], Section 9.11 |
| UPDATE | no | [RFC3253], Section 7.1 |
| UPDATEREDIRECTREF | no | [RFC4437], Section 7 |
| VERSION-CONTROL | no | [RFC3253], Section 3.5 |
HTTP 拡張フレームワークとは、HTTP を拡張をする場合に、それまでは「拡張を定義するための標準の枠組み」というものが無かったので、HTTP についての共通拡張メカニズムを示したもので、An HTTP Extension Framework として RFC にまとめられました。
HTTP 拡張フレームワークでは、強制的リクエスト {mandatory request}と呼ばれるメソッドが利用できます。 RFC 2774 の section 5 をご覧下さい。
HTTP リクエストは、少なくとも一つの強制的拡張宣言を (Man あるいは C-Man ヘッダフィールドを使って) 含む場合に強制的リクエストと呼ばれる。 強制的リクエストのメソッド名は "M-" が前に置かれなければならない。 例えば、クライアントは以下のような HTTP PUT リクエストにおいて、拘束権利の取り扱いの強制{the binding rights-management constraints} を表す事ができる。
M-PUT /a-resource HTTP/1.1 Man: "http://www.copyright.org/rights-management"; ns=16 16-copyright: http://www.copyright.org/COPYRIGHT.html 16-contributions: http://www.copyright.org/PATCHES.html Host: www.w3.org Content-Length: 1203 Content-Type: text/html <!doctype html ...強制的リクエストを受け入れるこの仕様書に従った最終受信者は、以下に順挙されている動作を行う事によってそのリクエストを処理しなければならない。
- 全ての強制的拡張宣言を (ホップバイホップ、エンドトゥエンド共に) 識別する。すなわち、サーバは HTTP メッセージの処理の結果に影響を受ける事無しに選択的宣言を無視できる。
- 1) にて識別された確認された全ての拡張を調べ、それらがこのメッセージのためにサポートされているかどうか決定する。サポートされていない場合、510 (Not Extended) ステータスコードを返す (section 7 参照)。
- 2) が 510 (Not Extended) ステータスコードを引き起こさない場合、HTTP/1.1 [5] やそれ以降のバージョンの HTTP にて定義されるように拡張された、あるいは既存の HTTP メソッド名の意味論{semantics} によってリクエストを処理する。 HTTP メソッド名は "M-" メソッド名接頭辞を無視する事によって得られる事ができる。
- 3) における評価を満足し、強制的リクエストを満たす場合、サーバはsection 5.1 にて定義されたように応答しなければならない。サーバは、リクエストにおける全ての強制的拡張宣言を理解し、それに従わなければリクエストを満たしてはならない。
HTTP 拡張フレームワークの使用は、SOAP 1.1 仕様書の Section 6 にて見る事ができます。
SOAP メッセージは、SOAP HTTP リクエストの存在と意図を識別するために HTTP 拡張フレームワークと共に使用する事ができる。
拡張フレームワークと通常の HTTP のどちらを使用するかは、通信の当事者のポリシーと能力の問題である。 クライアントは、強制的拡張宣言{mandatory extension declaration} と "M-" HTTP メソッド名接頭辞を使用する事によって HTTP 拡張フレームワークの使用を強要できる。 サーバは、510 "Not Extended" という HTTP ステータスコードを使用する事によって、HTTP 拡張フレームワークの使用を強要できる。 すなわち、一度の余分な通信を行う事で、一方は他方のポリシーを検出し、それに従って行動できる。
HTTP 拡張フレームワークを使用すると、クライアントは、通常の HTTP メソッドに「強制的 {mandatory}」という意味の "M-" という接頭辞をつける事によって、その処理を強制する事ができます。 通常の HTTP リクエストの場合、その処理の判断についてはサーバがする事になりますが、強制的リクエストの場合は、リクエスト内容に不備のない限りは、クライアントからの要求に従わなければなりません。 また、リクエスト内容に不備のある場合や、サーバが特に HTTP 拡張フレームワークを使用させたい場合は、510 レスポンスを返す事でそれをクライアントに通知する事ができます。 また、そもそも強制的 HTTP リクエストが解釈できない場合は 501 を返します。
(※) 但し、SOAP 1.2 仕様書からは、HTTP 拡張フレームワークの使用部分は削除されています。
, All Rights Reserved.
