メインコンテンツへスキップ

Go Proposal Weekly Digest

Go言語のproposal更新を毎週お届け

#80058accepted

net/http: add MethodQuery constant

ステータス変更: likely_accept accepted

要約

AIによる要約であり、誤りを含む場合があります。

概要

net/http パッケージに、新しいHTTPメソッド QUERY を表す定数 MethodQuery を追加するproposalです。既存の MethodGet、MethodPost などと同様のパターンで、標準ライブラリ内で QUERY メソッドをコンパイル時にチェックされた定数として扱えるようにします。

ステータス変更

likely_accept → accepted
2026年8月20日に「likely accept」と判定された後、1週間の議論を経ても反対意見（コンセンサスの変化）が見られなかったため、2026年8月26日に正式にacceptedとなりました。実装CL（CL 822384）も既に提出されています。

技術的背景

現状の問題点

HTTPの QUERY メソッドは RFC 10008 で新たに標準化された、安全（safe）かつ冪等（idempotent）でありながらリクエストボディを持てるメソッドです。GET（ボディを持てない）とPOST（安全でも冪等でもない）の間を埋める存在として、複雑なクエリや大きなリクエストボディを扱う用途に適しています。しかし net/http にはこのメソッドに対応する定数がなく、開発者は生の文字列 "QUERY" を使わざるを得ませんでした。なお、このメソッドは以前 SEARCH（#29894）として提案されていましたが、標準化前に QUERY へと改名された経緯があります。

提案された解決策

net/http/method.go に以下の定数を追加します。

const MethodQuery = "QUERY"

これは MethodPatch（RFC 5789由来）と全く同じパターンを踏襲するものです。なお、Content-Lengthの扱いやリダイレクト時の挙動といった QUERY メソッド固有のセマンティクスについては、本proposalの範囲外とし、必要であれば別途議論するとされています。

これによって何ができるようになるか

http.NewRequest やルーティング定義などで QUERY メソッドを扱う際、タイプミスの心配がない定数を利用できるようになります。特にRFC 10008のメソッド名は大文字小文字を区別するため（QUERy と QUERY はサーバー側で別物として扱われうる）、定数を使うことでこうしたタイポによる不具合を防げます。また、grpc-gatewayなどのAPIツール・コード生成系がQUERYメソッドをより自然にサポートできるようになります。

コード例

// Before: 生の文字列を使う
req, err := http.NewRequest("QUERY", url, body)
// After: 定数を使う
req, err := http.NewRequest(http.MethodQuery, url, body)

議論のハイライト

  • 定数追加の是非：@neild らは「文字列定数は値そのものが名前と同じ情報しか持たず、math.Pi のような意味のある定数とは異なる」として消極的な立場を示しました。@apparentlymart はさらに踏み込み、「今後新規メソッド定数の追加は一切凍結し、net/http/v2 では全廃すべき」と主張しましたが、賛同は限定的でした。
  • 一貫性の観点からの反論：@EyJunge1 は「MethodPatch は同様の後発RFCで追加された前例であり、QUERY だけを除外するとv1内で一貫性を欠き、かえって利用者を混乱させる」と反論し、多くの支持（8 thumbs up）を得ました。
  • 線引き基準の議論：どのメソッドを定数化すべきかの基準について、@aclements は「RFCがある」「IANAレジストリにある」だけでは基準として不十分と指摘。最終的に @neild が「最新のHTTP RFC（RFC 9110）に記載されている、またはhttpbisの後続RFCでStatusが『Proposed Standard』以上のもの」という基準を提案し、QUERY（RFC 10008、Proposed Standard）はこれに合致するとされました。
  • 将来の自動承認ポリシー：この基準に基づき、今後同様の条件を満たす新規HTTPメソッドが登場した場合は自動的に承認する運用も検討されましたが、頻度が低いため正式なポリシー化は見送られ、「次に同様の提案が出た際に改めて考慮する」との結論になりました。
  • コンパイル時チェックの価値：@aclements は最終的に「定数にはコンパイル時にチェックされるという多少のポジティブな価値がある」と評価し、これがlikely acceptからacceptedへの決定打の一つとなりました。

関連リンク