HTTP QUERYにはRFC 10008があるが、実装はほとんどない

HTTPに検索のための新しいメソッドが加わりました。IETFは2026年6月、httpbisワーキンググループのProposed Standard（提案標準）としてRFC 10008「The HTTP QUERY Method」を公開しました。その3か月後の2026年9月、本番環境への導入完了を発表したプロジェクトは一つもないとInfoQが報じました。

このメソッドはJulian Reschke氏、James M. Snell氏、Mike Bishop氏が執筆しました。APIを書く開発者なら誰でも一度は回避策を講じたことのある問題を解決するために存在します。

GETとPOSTの間にある隙間

検索リクエストは二つのことを同時に求めますが、これまでHTTPはどちらか一方を選ばせてきました。

GETは安全（safe）です。つまりサーバー上の何も変えません。冪等（idempotent）なので、クライアントは影響を気にせず再試行でき、キャッシュも可能です。難点は、求めるものすべてをURLに収めなければならないことです。長いフィルターは長さの制限に突き当たり、サーバーのアクセスログに残り、入れ子構造はエンコードしづらいのです。

POSTは任意のサイズと形のボディを運べます。しかし安全でも冪等でもないと定義されているため、キャッシュはこれを飛ばし、クライアントは安全に再試行できず、経路上のあらゆるものは何かが変更されたと想定しなければなりません。

QUERYは両者の有用な半分ずつを取り入れます。RFCはこれを、「リクエストターゲットが同梱されたコンテンツを安全かつ冪等な方法で処理し」、その結果を返すものとして定義しています。安全で冪等、キャッシュ可能で、しかもリクエストボディを持ちます。RFCはその想定用途を、「伝えるデータがリクエストのURIにエンコードするには大きすぎる」場合だと説明しています。

いくつかの規則が付随します。Content-Typeは必須です。「Content-Typeリクエストフィールドが...欠けている、あるいはリクエストのコンテンツと矛盾している場合、サーバーはそのリクエストを失敗させなければならない（MUST）」。サーバーはAccept-Queryヘッダーで、受け付けるクエリ形式を知らせることができます。条件付きリクエストは、標準のHTTP検証ヘッダーで機能します。

キャッシュこそ正しく作るべき部分

ボディを持つメソッドをキャッシュ可能にすることが、RFCが解かなければならない難問です。キャッシュは通常URLをキーにしますが、QUERYリクエストの意味はボディの中にあります。

RFC 10008の答えは、キャッシュキーにリクエストのコンテンツ全体と関連するメタデータを含めなければならない、というものです。ボディを無視するキャッシュは、ある検索の結果を別の検索に返してしまいます。

RFCはまた、サーバーが代わりに結果のURLを返すことも認めています。結果にURIを割り当ててContent-LocationやLocationでそれを指すか、処理が間接的に行われる場合は303リダイレクトを使えます。これによりクライアントは、共有もブックマークも通常のキャッシュもできる素朴なGETを手にします。

ここではセキュリティが両方向に働きます。クエリをURLからボディへ移すことはプライバシーの改善です。RFCが指摘するように、URIはリクエストのコンテンツより「ログに記録される可能性が高い」からです。しかし上記の逃げ道は、それを帳消しにしかねません。仕様は、結果のURIは元のクエリの「機密性のある部分を含まないように選ぶべきである（SHOULD）」と述べています。ブラウザーはさらに一つ制約を加えます。QUERYはsafelisted（安全とみなされる）メソッドではないため、クロスオリジンのリクエストはCORSのプリフライトを引き起こします。

実際に出荷したのは誰か

ここで標準と実践が分かれます。InfoQは対応状況を、完了した作業ではなく追跡中の作業として挙げています。

プロジェクト	InfoQによる状況
Rustのhttpクレート	対応をマージ済み
.NET	Issueで追跡中
Axum	Issueで追跡中
Quarkus	Issueで追跡中
Bruno	Issueで追跡中

いずれも本番導入の日付を発表していません。InfoQの見立ては「実際の普及はおそらく年単位で測られることになる」というものです。メソッドは、経路上のクライアント、サーバー、プロキシ、キャッシュのすべてが理解して初めて使えるようになるからです。InfoQはQUERYを、GETやPOSTの置き換えではなく任意で加えられる追加物として位置づけています。

開発者にとっての意味

検索エンドポイントを書き直さないでください。メソッドを知らない中間装置に出会ったQUERYリクエストは、ただ失敗します。クライアントとサーバーの間のすべてのホップを、あなたが制御しているわけではありません。

今日役に立つ動きはもっと小さなものです。自分のエンドポイントのどれが「変装したQUERY」なのかを見極めることです。サーバー上の何も変えないPOST /searchこそ、このメソッドが存在する理由となったパターンです。それを知っておくのに今はコストがかからず、いずれ来る移行を再設計ではなく名前の変更で済ませられます。

クライアントライブラリ、サーバーフレームワーク、プロキシ、キャッシュを保守しているなら、計算は変わります。普及の時間軸が描いているボトルネックは、あなた自身だからです。RFCのキャッシュキー要件は最も誤って実装されやすい部分であり、そこを誤れば、あるユーザーの検索結果を別のユーザーに返すことになります。

安全性の主張については一つ注意があります。QUERYが安全で冪等であることは、ハンドラーが守らなければならない約束であって、メソッドが強制するものではありません。QUERYハンドラーの中で状態を変更するサーバーを止めるものは何もありません。もしそうすれば、経路上のすべての再試行とすべてのキャッシュが、見つけにくいバグになります。