[506] HTTP および派生プロトコルにおける要求メソッドrequest methodは、当該要求によって鯖に対して求めている操作の種類を表します。 メソッドは短い英数字列 (通常は大文字) によって表されます。

仕様書

意味

[525] 要求メソッドは、要求の意味を表すものであり、 クライアントが要求を行った目的と、 成功した場合にクライアントが期待する挙動を示したものです。 >>524

[13] 標準化されるメソッドは一般的なもので、特定の MIME型や資源の種類、 応用に限定されるものではなく、どんな資源にも適用可能であろうものとされています。 >>8

[14] WebDAV という特定の応用でしか使えなそうな要求メソッドが沢山登録されていますが、 一応汎用的に使える定義になっているという建前なのでしょう...

[15] HEAD の場合を除き、 HTTPメッセージの構文解析は要求メソッドとは独立したもの >>8 で、 新たなメソッドでメッセージ本体を無しとするなどの変更は行えないとされています。

構文

[522] メソッドの名前は、 字句です >>521, >>524。

  1. 字句

大文字と小文字

[3] HTTP >>521, >>524 でも RTSP でも SIP でも、 大文字・小文字を区別します。

[49] とはいえ実装は区別しないものも多いみたいです。

[514] XHR は9種類のメソッドについてASCII大文字・小文字不区別、それ以外について区別するとしています >>513。

[48] HTTPメソッドと関係が深い HTML の form 要素の method<form method> 属性 (や formmethod 属性) では、 大文字・小文字不区別です。

[526] 区別する理由を、 大文字と小文字を区別するメソッド名を用いるオブジェクトベースのシステムへの関門として用いられることがあるから >>524、と HTTP の仕様書は説明していますが、 HTTP のメソッドはそのようなシステムで普通オブジェクトに適用できるメソッドほど種類も豊富ではありませんし、 HTTP のメソッドはオブジェクトごとに自由に追加するものではないことを特徴にしているわけですから、 本当にそんな根拠で大文字と小文字を区別しないことにする理由があるのか怪しいところです。[26] HTTP 派生プロトコルの1つである S-HTTP は明記していませんが、 規定されている Secure メソッドを使った例に SECURE としているところがあり、 大文字・小文字不区別としているようです。

[44] IE11 の IE5 モードで

xhr=new ActiveXObject("Microsoft.XMLHTTP");xhr.open ("foo", "/");xhr.send()

を実行するとHTTPメソッドは fooのまま。 大文字化されるのは get, post, put。 delete や head, connect, options は大文字化されない。 trace は大文字・小文字のどの組合せでも例外。

少し変えて

xhr=new XMLHttpRequest;xhr.open ("foo", "/");xhr.send()

にすると「引数が無効です」例外で open が失敗。 失敗しないで実行できるのは get, post, put, delete, head, options のみ。 大文字化されるのはやはり最初の3つだけ。 trace, connect も大文字・小文字のどの組合せでも例外。

[46] IE11 の IE11 モードだと ActiveXObject の方の挙動は同じ (大文字化も同じ)、 XMLHttpRequest の方はその他メソッドでも例外にならない (ただし connect, trace は例外) & delete, head, options も大文字化される。

[45] IE5 モードがどれだけ IE5 当時の挙動に近いのかはわからないが (そもそも IE5 当時に new XMLHttpRequest はない)、 何も考えずに知ってるものは全部大文字化してたという単純な話でもなさそう。

  • [5] HTTP methods, Web browsers and XMLHttpRequest - Anne’s Weblog ( 版) http://annevankesteren.nl/2007/10/http-method-support

[510] >>5 は XHR の仕様策定時点での各Webブラウザーの XHR におけるメソッドの大文字と小文字についての調査結果です。

[50] この辺によると、 fetch の仕様検討時点で整理することも考えられたものの、 XHR 以来の仕様を踏襲するのが妥当と判断されたようです。 なおこの時代でもまだWebブラウザーの XHR の挙動差が残っていた模様。

[51] Fetch APIは「PATCH」だけ大文字と小文字の挙動が異なる, https://zenn.dev/neet/articles/de54e08de01c22#%E3%81%AA%E3%81%9C-xhr-%E3%81%AF-patch-%E3%82%92%E6%AD%A3%E8%A6%8F%E5%8C%96%E3%81%97%E3%81%AA%E3%81%8B%E3%81%A3%E3%81%9F%E3%81%AE%E3%81%8B

[52] >>51 この記事は

XMLHttpRequest は Microsoft が Internet Explorer 5.0 で独自に実装した機能が元になっており、開発時点で最新版の HTTP の仕様では、標準メソッドとして PATCH が定義されていなかったこと、のちの 2010 年に PATCH が標準化されたことを確かめました。

と IE5 の挙動の理由を当時の HTTP 仕様に求めていますが、 この記事がいう 「IE5 が RFC 2616 を実装していた」 は必ずしも正確ではありません (IE5 が対応していた機能の集合と RFC 2616 にある機能の集合は重なるだけで、 どちらがどちらの部分集合でも超集合でもありません)。 >>44 >>5 のように RFC 2616 にある HEAD を大文字化しないので、 この説明は成り立ちません。

[53] そもそも RFC 2616 の先代の RFC 2068 に一応 PATCH は定義されています。

[54] >>51

自分のリサーチでは「XHR の側で正規化を定義して、fetch では一切の正規化をしない」というようにしなかった理由が「API 間の一貫性」以外に見つけられなかった。

その理由は >>538 あたり.

[55] Webサーバーも古いものは大文字・小文字不区別のことがよくありました。

[56] GeT や get のようなメソッドを定める仕様書が存在しない、 という点を除けば、 サーバーが GeT や get を GET を同じように処理したとしても、 相互運用性上それほど問題にはなりません。 (相手あってこそのクライアントがそれをやると相互運用性の問題になりますが、 サーバーは自サーバーの挙動を自ら決められる立場だからです。)

長さ

[523] メソッド名に長さの上限は設けられていません。

[403] 実装しているどのメソッドよりも長いメソッド名を受信した鯖は、 501 を返すべきです >>521。

[503] メソッドを含む要求行全体では、 最低でも8000オクテットの要求行には対応するべき >>521 とされています。 (ほとんどは要求対象となるURLの長さでしょう。)

M-

[27] RFC 2774 は必須の要求であることを表すために要求メソッドの接頭辞 M- を使っています。

M-* 参照。

[16] RFC 7231 は、 M- から始まる要求メソッドは RFC 2774 で使われているので新規登録を避けるよう >>8 述べています。

[17] 現在 M- から始まるメソッド名は IANA に登録されていないようです。

PEP-

[28] 同様に PEP は PEP- を接頭辞として予約していました >>29。

  • [29] PEP - an Extension Mechanism for HTTP ( 版) http://www.w3.org/TR/WD-http-pep#_Toc404743957

[30] こちらは RFC 7231 は何も言及していません。

性質と分類

[11] 要求メソッドによって要求や応答の性質や処理方法が異なることがあります。

文脈

[23] 要求メソッドは次の場面で用いられます。

:method 擬似ヘッダー (HTTP)

[34] HTTP/2 要求の疑似ヘッダー :method は、 要求メソッドを表します >>32。 HTTP/1.1 以下の要求行の要求メソッドに相当します。 要求には丁度1つだけ含まれなければなりません >>32。 含まれない要求は、奇形です >>32。

[35] Chrome はなぜか :method がなくてもエラーにしません。 (他の擬似ヘッダーは奇形とします。)

[36] Firefox はなぜか :method がないとストリームエラー REFUSED_STREAM を無限に(?)送信し続けます。

[38] >>36 :method が PUT のように不適切なときもそうなるようです。

[37] Chrome も Firefox も、 :method が複数あってもエラーとはしません。

処理

[531] 鯖は、要求で指定されたメソッドに従って処理を試み、 その結果をメソッドの定義に従って応答としてクライアントに送信します。

[527] 一般目的の鯖は、 GET と HEAD は少なくても実装しなければなりません >>524。

[528] どのような鯖が一般目的ではないのかは不明です。 現実には一般目的っぽい鯖であっても、 HEAD が実装されていないことがあります。[534] 実装しなければならないからといって、すべての対象資源で 2xx を返さなければならないわけではありません。例えばある URL を GET した時はもちろん 404 を返したり、 405 を返したりしても構いません。[2] 更に、ある対象資源がどの要求メソッドも実装しないことがあり得て良いようです。 Allow: が空になることが認められています。

[532] 起源鯖は、要求メソッドを認識できないか、実装していない時は、 501 応答を返すべきです >>524。

[533] 起源鯖は、要求メソッドを知っているものの、対象資源に対して認めていない時は、 405 応答を返すべきです >>524。

[39] nginx は小文字を含む要求メソッドの要求を受け取ったら、 要求行を受信した時点で (ヘッダーの末尾を待たずに) 400 応答を返して接続HTTP接続を閉じます。

[40] Apache は小文字の get や head のような要求メソッドでも、 大文字とみなします。

[41] 未知の要求メソッドの時、 nginx も Apache も、 reverse proxy として動作しているならそのまま上流に送るようです。 ファイルシステムから返す時、 nginx は 405 を返し、 Apache は GET として動作するようです。

[42] HTTP/0.9 も参照。

メソッド一覧の提示

[530] 起源鯖は、対象資源が対応している要求メソッドの一覧を Allow: ヘッダーで示すことができます。 このヘッダーは 405 応答では必須ですが、 それ以外の応答でも使うことができます。

[12] 起源鯖は、 CORS において対象資源についての要求に用いることができるメソッドの一覧を Access-Control-Allow-Methods: ヘッダーで示すことができます。

メソッドの一覧

[31] HTTP の要求メソッドは数多ありますが、実用上意味があるのは GET、POST、HEAD、 CONNECT のみです。宗教上の理由により Web API の一部は PUT や DELETE を使うこともあります。その他の要求メソッドは HTTP 以外のプロトコルのものか、限られた用途でのみ使われているものや提案されたものの普及しなかったものです。

[1] HTTP および派生プロトコルのメソッドの一覧
request-methodプロトコル
ACKSIP ([RFC 2543], [IANAREG])
ACLHTTP
ANNOUNCERTSP ([RFC 2326])
BASELINE-CONTROLHTTP
BCOPYHTTP
BDELETEHTTP
BEGINQ4S
BINDHTTP
BMOVEHTTP
BPROPFINDHTTP
BPROPPATCHHTTP
BREWHTTP ([RFC 2324])
BROWSEHTTP ([Gripes])
BWIDTHQ4S
BYESIP ([RFC 2543], [IANAREG])
CANCELSIP ([RFC 2543], [IANAREG]),Q4S
CHECKINHTTP
CHECKOUTHTTP
CONNECTHTTP ([RFC 2616] 予約)
COPYHTTP ([RFC 2518])
DELETEHTTP ([RFC 2068], [RFC 2616]; [RFC 2518])
DESCRIBERTSP ([RFC 2326])
X-MS-ENUMATTSHTTP
GETHTTP ([HTTP/0.9], [RFC 1945], [RFC 2068], [RFC 2616]; [RFC 2518], [RFC 2324])
GET_PARAMETERRTSP ([RFC 2326])
GET-WITH-BODYHTTP
HEADHTTP ([RFC 2068], [RFC 2616]; [RFC 2518])
INFOSIP ([RFC 2976], [IANAREG])
INVITESIP ([RFC 2543], [IANAREG])
LABELHTTP
LINKHTTP ([RFC 2068] 参考)
LOCKHTTP (RFC 2518)
M-*HTTP ([RFC 2774])
M-GETHTTP ([RFC 2774])
M-POSTHTTP
M-PUTHTTP ([RFC 2774])
M-SEARCHSSDP
MDELETEHTTP (URIQA)
MERGEHTTP
MGETHTTP (URIQA)
MPUTHTTP (URIQA)
MESSAGESIP ([RFC 3428], [IANAREG])
MKACTIVITYHTTP
MKCALENDARHTTP (RFC 4791)
MKCOLHTTP ([RFC 2518])
MKREDIRECTREFHTTP
MKWORKSPACEHTTP
MOVEHTTP ([RFC 2518])
NOTIFYHTTP, SIP, SSDP
OPTIONSHTTP ([RFC 2068], [RFC 2616]), RTSP ([RFC 2326]), SIP ([RFC 2543], [IANAREG])
ORDERPATCHHTTP
PATCHHTTP ([RFC 2068] 参考)
PAUSERTSP ([RFC 2326])
PEPHTTP
PEP-*HTTP
PEP-PUTHTTP
PINGQ4S
PLAYRTSP ([RFC 2326])
POLLHTTP
POSTHTTP ([RFC 2068], [RFC 2616], [RFC 2324]))
PRACKSIP ([RFC 3262], [IANAREG])
PRI
PROPFINDHTTP ([RFC 2324], [RFC 2518])
PROPPATCHHTTP ([RFC 2518])
PUTHTTP ([RFC 2068], [RFC 2616]; [RFC 2518])
Q4S-ALERTQ4S
READYQ4S
RECORDRTSP ([RFC 2326])
REDIRECTRTSP ([RFC 2326])
REFERSIP ([RFC 3315], [IANAREG])
REBINDHTTP
REGISTERSIP ([RFC 2543], [IANAREG])
REPORTHTTP (RFC 4791)
RPC_IN_DATAHTTP
RPC_OUT_DATAHTTP
SEARCHHTTP (ワーム)
SecureS-HTTP
SETUPRTSP ([RFC 2326])
SET_PARAMETERRTSP ([RFC 2326])
SHOWMETHODHTTP
SOURCE
SPACEJUMPHTTP
SSTP_DUPLEX_POSTHTTP
SUBSCRIBEHTTP, SIP
TEARDOWNRTSP ([RFC 2326])
TEXTSEARCHHTTP
TRACEHTTP ([RFC 2068], [RFC 2616])
TRACKHTTP
UNBINDHTTP
UNCHECKOUTHTTP
UNLINKHTTP ([RFC 2068] 参考)
UNLOCKHTTP ([RFC 2518])
UNSUBSCRIBEHTTP
UPDATEHTTP, SIP
UPDATEREDIRECTREFHTTP
VERSION-CONTROLHTTP
WHENHTTP ([RFC 2324])

[57] CATP のもの CATPメソッド

参考文献

  • [511] List of HTTP methods (verbs) — Anne’s Blog ( 版) http://annevankesteren.nl/2007/10/http-methods
  • [512] WebDAV Methods ( 版) http://msdn.microsoft.com/en-us/library/aa142917.aspx

IANA 登録簿

[529] メソッドは、 IANA に登録するべきought toです >>524。

[4] HTTP、RTSP、SIP でメソッド名は共通するものもありますが、 それぞれ別個の IANA登録簿が用意されています。

[507] HTTP と RTSP は当初登録簿がありませんでしたが、次第に整備されてゆきました。 HTTP の登録簿は RFC 7231 で新設されました。

[10] HTTP の登録簿では、名前と出典の他に、安全なメソッドか否か、 冪等メソッドか否かも登録することになっています >>8。

データ

[520] メソッドの一覧とそれぞれの特性をまとめたデータが

にあります。

歴史

HTTP/0.9

[25] HTTP/0.9 では GET のみ認められていました >>24。

HTTP/0.9 も参照。
  • [24] RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0 ( 版) http://tools.ietf.org/html/rfc1945#section-4.1

HTTP/1.0

  • [517] HTTP: A protocol for networked information: Predefined Methods ( 版) http://www.w3.org/Protocols/HTTP/Methods.html
  • [518] RFC 1945

HTTP/1.1

[502] RFC 1945 (HTTP/1.0); RFC 2068・2616 (HTTP/1.1) 5.1.1 Method

The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.

Method 字句は、 Request-URI で識別される資源に施される方式を示します。方式は大文字・小文字を区別します。

{1945}

  •        Method         = "GET"                    ; Section 8.1
                      | "HEAD"                   ; Section 8.2
                      | "POST"                   ; Section 8.3
                      | extension-method

{2068}

  •           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
                         | extension-method

{2616}

  •        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

The list of methods acceptable allowed by a specific resource can change dynamically; the client is notified through the return code of the response if a method is not allowed on a resource. be specified in an Allow header field (section 14.7). The return code of the response always notifies the client whether a method is currently allowed on a resource, since the set of allowed methods can change dynamically. {1945,2068} Servers {2616} An origin server should SHOULD return the status code 405 (Method Not Allowed) if the method is known by the original server but not allowed for the requested resource, and 501 (not implemented Not Implemented) if the method is unrecognized or not implemented by the original server. {2068} The list of methods known by a server can be listed in a Public response-header field (section 14.35).

ある資源に認められる方式の目録は Allow 頭欄に指定されます。 応答の復帰符号は方式が現在資源について認められているかどうかを常にクライアントに通知します。 認められる方式の集合は動的に変わり得るからです。 起源サーバーは、方式を起源サーバーが知っているがその要求された資源には認めない場合には 405 (方式不認可) 状態符号を、起源サーバーが方式が認識できないか実装していない場合は 501 (未実装) 状態符号を返すべきです。サーバーが知っている方式の目録は Public 応答頭欄で列挙できます。

{1945} The methods commonly used by HTTP/1.0 applications are fully defined in Section 8.

HTTP/1.0 応用が広く使っている方式は8章で完全に定義しています。

The methods GET and HEAD MUST be supported by all general-purpose servers. All other methods are optional OPTIONAL; however, if the above methods are implemented, they MUST be implemented with the same semantics as those specified in section 9.

方式 GET および HEAD にすべての一般目的サーバーは対応しなければなりません。 他のすべての方式は任意選択です。しかし、 上の方式を実装する場合は、9章で規定する意味と同じに実装しなければなりません。

注: 注記なき変更点は 1945 → 2068 の変更。

[6] RFC 1945 (HTTP/1.0) 8.; RFC 2068・2616 (HTTP/1.1) 9 Method Definitions

The set of common methods for HTTP/1.0 HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed to share the same semantics for separately extended clients and servers.

HTTP の共通の方式 (method) の集合を次に定義します。 この集合は拡張可能ではありますが、追加の方式は別々の拡張されたクライアントやサーバーで同じ意味を共有しているとは仮定できません。

The Host request-header field (section 14.23) MUST accompany all HTTP/1.1 requests.

Host 要求頭欄はすべての HTTP/1.1 要求に伴わなければなりません。

RFC 2068・2616 (HTTP/1.1) 9.1 Safe and Idempotent Methods

→安全

RFC 1945 (HTTP/1.0) 9.1〜; RFC 2068・2616 (HTTP/1.1) 9.2〜

(各 method の定義 : 省略)

RFC 1945 (HTTP/1.0) D.1; RFC 2068 (HTTP/1.1) 19.6.1 Additional Request Methods

(各 method の定義 : 省略)

[7] RFC 2616 (HTTP/1.1) 19.6.3 (抜粋)

The PATCH, LINK, UNLINK methods were defined but not commonly implemented in previous versions of this specification. See RFC 2068 [33].

この仕様書の以前の版で PATCH, LINK, UNLINK 方式が定義されていましたが、広くは実装されていません。 RFC 2068 参照。

RFC 723x

[19] RFC 2616 の改訂である RFC 7231 で HTTP 要求メソッドの IANA登録簿が初めて整備されました。

[20] RFC 723x 以外の従来の RFC で規定されていた要求メソッドは RFC 7237 により登録されています >>18。

  • [519] draft-ietf-httpbis-method-registrations-13 - Initial Hypertext Transfer Protocol (HTTP) Method Registrations ( ( 版)) http://tools.ietf.org/html/draft-ietf-httpbis-method-registrations-13
  • [18] RFC 7237 - Initial Hypertext Transfer Protocol (HTTP) Method Registrations ( 版) https://tools.ietf.org/html/rfc7237
[21] M-* メソッド群は登録されていないようです。[22] RFC 化されていないメソッドは登録されていないようです。

関連

[535] form 要素の method 属性は、元々は HTTP のメソッドから派生したものですが、 現在では必ずしも HTTP のメソッドとは対応しないものになっています。

歴史

[539] RFC 3507 - Internet Content Adaptation Protocol (ICAP) ( ( 版)) http://tools.ietf.org/html/rfc3507#section-4.3.2

[540] HTTP: A protocol for networked information: Predefined Methods ( ( 版)) http://www.w3.org/Protocols/HTTP/Methods.html

[43] Access-Control-Expose-Headers: * can be interpreted in two ways · Issue #548 · whatwg/fetch () https://github.com/whatwg/fetch/issues/548