[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-
: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。
→安全
(各 method の定義 : 省略)
(各 method の定義 : 省略)
[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