[506] HTTP および派生プロトコルにおける要求メソッドは、当該要求によって鯖に対して求めている操作の種類を表します。 メソッドは短い英数字列 (通常は大文字) によって表されます。
[525] 要求メソッドは、要求の意味を表すものであり、 クライアントが要求を行った目的と、 成功した場合にクライアントが期待する挙動を示したものです。 >>524
[13] 標準化されるメソッドは一般的なもので、特定の MIME型や資源の種類、 応用に限定されるものではなく、どんな資源にも適用可能であろうものとされています。 >>8
[15] HEAD
の場合を除き、 HTTPメッセージの構文解析は要求メソッドとは独立したもの
>>8 で、
新たなメソッドでメッセージ本体を無しとするなどの変更は行えないとされています。
[522] メソッドの名前は、 字句です >>521, >>524。
[3] HTTP >>521, >>524 でも RTSP でも SIP でも、 大文字・小文字を区別します。
[49] とはいえ実装は区別しないものも多いみたいです。
[514] XHR は9種類のメソッドについてASCII大文字・小文字不区別、それ以外について区別するとしています >>513。
[48]
HTTPメソッドと関係が深い HTML の form
要素の method
属性 (や formmethod
属性) では、
大文字・小文字不区別です。
Secure
メソッドを使った例に
SECURE
としているところがあり、
大文字・小文字不区別としているようです。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
はない)、
何も考えずに知ってるものは全部大文字化してたという単純な話でもなさそう。
[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
XMLHttpRequest は Microsoft が Internet Explorer 5.0 で独自に実装した機能が元になっており、開発時点で最新版の HTTP の仕様では、標準メソッドとして PATCH が定義されていなかったこと、のちの 2010 年に PATCH が標準化されたことを確かめました。
と IE5 の挙動の理由を当時の HTTP 仕様に求めていますが、
この記事がいう
「IE5 が RFC 2616 を実装していた」
は必ずしも正確ではありません
(IE5 が対応していた機能の集合と RFC 2616 にある機能の集合は重なるだけで、
どちらがどちらの部分集合でも超集合でもありません)。
>>44 >>5
のように RFC 2616 にある HEAD
を大文字化しないので、
この説明は成り立ちません。
自分のリサーチでは「XHR の側で正規化を定義して、fetch では一切の正規化をしない」というようにしなかった理由が「API 間の一貫性」以外に見つけられなかった。
その理由は >>538 あたり.
[55] Webサーバーも古いものは大文字・小文字不区別のことがよくありました。
[403] 実装しているどのメソッドよりも長いメソッド名を受信した鯖は、
501
を返すべきです >>521。
[503] メソッドを含む要求行全体では、 最低でも8000オクテットの要求行には対応するべき >>521 とされています。 (ほとんどは要求対象となるURLの長さでしょう。)
M-
#✎[27] RFC 2774 は必須の要求であることを表すために要求メソッドの接頭辞
M-
を使っています。
M-*
参照。[16] RFC 7231 は、 M-
から始まる要求メソッドは
RFC 2774 で使われているので新規登録を避けるよう >>8 述べています。
PEP-
#✎[11] 要求メソッドによって要求や応答の性質や処理方法が異なることがあります。
:method
擬似ヘッダー (HTTP)#✎[34] HTTP/2 要求の疑似ヘッダー :method
は、
要求メソッドを表します >>32。 HTTP/1.1 以下の要求行の要求メソッドに相当します。
要求には丁度1つだけ含まれなければなりません >>32。
含まれない要求は、奇形です >>32。
[35] Chrome はなぜか :method
がなくてもエラーにしません。
(他の擬似ヘッダーは奇形とします。)
[36] Firefox はなぜか :method
がないとストリームエラー
REFUSED_STREAM
を無限に(?)送信し続けます。
[531] 鯖は、要求で指定されたメソッドに従って処理を試み、 その結果をメソッドの定義に従って応答としてクライアントに送信します。
[527] 一般目的の鯖は、 GET
と HEAD
は少なくても実装しなければなりません >>524。
2xx
を返さなければならないわけではありません。例えばある URL
を GET
した時はもちろん 404
を返したり、 405
を返したりしても構いません。[532] 起源鯖は、要求メソッドを認識できないか、実装していない時は、
501
応答を返すべきです >>524。
[533] 起源鯖は、要求メソッドを知っているものの、対象資源に対して認めていない時は、
405
応答を返すべきです >>524。
[39] nginx は小文字を含む要求メソッドの要求を受け取ったら、
要求行を受信した時点で (ヘッダーの末尾を待たずに)
400
応答を返して接続を閉じます。
[40] Apache は小文字の get
や head
のような要求メソッドでも、
大文字とみなします。
[41] 未知の要求メソッドの時、 nginx も Apache も、
reverse proxy として動作しているならそのまま上流に送るようです。
ファイルシステムから返す時、 nginx は 405
を返し、
Apache は GET
として動作するようです。
[530] 起源鯖は、対象資源が対応している要求メソッドの一覧を
Allow:
ヘッダーで示すことができます。
このヘッダーは 405
応答では必須ですが、
それ以外の応答でも使うことができます。
[12] 起源鯖は、 CORS において対象資源についての要求に用いることができるメソッドの一覧を
Access-Control-Allow-Methods:
ヘッダーで示すことができます。
[31] HTTP の要求メソッドは数多ありますが、実用上意味があるのは
GET
、POST
、HEAD
、
CONNECT
のみです。宗教上の理由により Web API
の一部は PUT
や DELETE
を使うこともあります。その他の要求メソッドは HTTP
以外のプロトコルのものか、限られた用途でのみ使われているものや提案されたものの普及しなかったものです。
request-method | プロトコル |
---|---|
ACK | SIP ([RFC 2543], [IANAREG]) |
ACL | HTTP |
ANNOUNCE | RTSP ([RFC 2326]) |
BASELINE-CONTROL | HTTP |
BCOPY | HTTP |
BDELETE | HTTP |
BEGIN | Q4S |
BIND | HTTP |
BMOVE | HTTP |
BPROPFIND | HTTP |
BPROPPATCH | HTTP |
BREW | HTTP ([RFC 2324]) |
BROWSE | HTTP ([Gripes]) |
BWIDTH | Q4S |
BYE | SIP ([RFC 2543], [IANAREG]) |
CANCEL | SIP ([RFC 2543], [IANAREG]),Q4S |
CHECKIN | HTTP |
CHECKOUT | HTTP |
CONNECT | HTTP ([RFC 2616] 予約) |
COPY | HTTP ([RFC 2518]) |
DELETE | HTTP ([RFC 2068], [RFC 2616]; [RFC 2518]) |
DESCRIBE | RTSP ([RFC 2326]) |
X-MS-ENUMATTS | HTTP |
GET | HTTP ([HTTP/0.9], [RFC 1945], [RFC 2068], [RFC 2616]; [RFC 2518], [RFC 2324]) |
GET_PARAMETER | RTSP ([RFC 2326]) |
GET-WITH-BODY | HTTP |
HEAD | HTTP ([RFC 2068], [RFC 2616]; [RFC 2518]) |
INFO | SIP ([RFC 2976], [IANAREG]) |
INVITE | SIP ([RFC 2543], [IANAREG]) |
LABEL | HTTP |
LINK | HTTP ([RFC 2068] 参考) |
LOCK | HTTP (RFC 2518) |
M-* | HTTP ([RFC 2774]) |
M-GET | HTTP ([RFC 2774]) |
M-POST | HTTP |
M-PUT | HTTP ([RFC 2774]) |
M-SEARCH | SSDP |
MDELETE | HTTP (URIQA) |
MERGE | HTTP |
MGET | HTTP (URIQA) |
MPUT | HTTP (URIQA) |
MESSAGE | SIP ([RFC 3428], [IANAREG]) |
MKACTIVITY | HTTP |
MKCALENDAR | HTTP (RFC 4791) |
MKCOL | HTTP ([RFC 2518]) |
MKREDIRECTREF | HTTP |
MKWORKSPACE | HTTP |
MOVE | HTTP ([RFC 2518]) |
NOTIFY | HTTP, SIP, SSDP |
OPTIONS | HTTP ([RFC 2068], [RFC 2616]), RTSP ([RFC 2326]), SIP ([RFC 2543], [IANAREG]) |
ORDERPATCH | HTTP |
PATCH | HTTP ([RFC 2068] 参考) |
PAUSE | RTSP ([RFC 2326]) |
PEP | HTTP |
PEP-* | HTTP |
PEP-PUT | HTTP |
PING | Q4S |
PLAY | RTSP ([RFC 2326]) |
POLL | HTTP |
POST | HTTP ([RFC 2068], [RFC 2616], [RFC 2324])) |
PRACK | SIP ([RFC 3262], [IANAREG]) |
PRI | |
PROPFIND | HTTP ([RFC 2324], [RFC 2518]) |
PROPPATCH | HTTP ([RFC 2518]) |
PUT | HTTP ([RFC 2068], [RFC 2616]; [RFC 2518]) |
Q4S-ALERT | Q4S |
READY | Q4S |
RECORD | RTSP ([RFC 2326]) |
REDIRECT | RTSP ([RFC 2326]) |
REFER | SIP ([RFC 3315], [IANAREG]) |
REBIND | HTTP |
REGISTER | SIP ([RFC 2543], [IANAREG]) |
REPORT | HTTP (RFC 4791) |
RPC_IN_DATA | HTTP |
RPC_OUT_DATA | HTTP |
SEARCH | HTTP (ワーム) |
Secure | S-HTTP |
SETUP | RTSP ([RFC 2326]) |
SET_PARAMETER | RTSP ([RFC 2326]) |
SHOWMETHOD | HTTP |
SOURCE | |
SPACEJUMP | HTTP |
SSTP_DUPLEX_POST | HTTP |
SUBSCRIBE | HTTP, SIP |
TEARDOWN | RTSP ([RFC 2326]) |
TEXTSEARCH | HTTP |
TRACE | HTTP ([RFC 2068], [RFC 2616]) |
TRACK | HTTP |
UNBIND | HTTP |
UNCHECKOUT | HTTP |
UNLINK | HTTP ([RFC 2068] 参考) |
UNLOCK | HTTP ([RFC 2518]) |
UNSUBSCRIBE | HTTP |
UPDATE | HTTP, SIP |
UPDATEREDIRECTREF | HTTP |
VERSION-CONTROL | HTTP |
WHEN | HTTP ([RFC 2324]) |
[529] メソッドは、 IANA に登録するべきです >>524。
[4] HTTP、RTSP、SIP でメソッド名は共通するものもありますが、 それぞれ別個の IANA登録簿が用意されています。
[10] HTTP の登録簿では、名前と出典の他に、安全なメソッドか否か、 冪等メソッドか否かも登録することになっています >>8。
[25] HTTP/0.9 では GET
のみ認められていました >>24。
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
acceptableallowed by aspecificresource canchange 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 servershouldSHOULD 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 implementedNot 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
optionalOPTIONAL; 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 の変更。
The set of common methods for
HTTP/1.0HTTP/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
要求に伴わなければなりません。
→安全
(各 method の定義 : 省略)
(各 method の定義 : 省略)
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 参照。
[19] RFC 2616 の改訂である RFC 7231 で HTTP 要求メソッドの IANA登録簿が初めて整備されました。
[20] RFC 723x 以外の従来の RFC で規定されていた要求メソッドは RFC 7237 により登録されています >>18。
[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