HTTP наконец получает метод QUERY — безопасный, кэшируемый запрос с телом

Что именно стандартизирует RFC 10008

RFC 10008, опубликованный в 2026-м как Proposed Standard авторства Юлиана Решке, Джеймса М. Снелла и Майка Бишопа, определяет новый метод HTTP: QUERY. Версия в одно предложение из спецификации: QUERY «требует, чтобы целевой ресурс обработал вложенное содержимое безопасным и идемпотентным образом, а затем ответил результатом этой обработки».

Он существует, чтобы закрыть пробел, который все обходили. GET кладёт параметры в URL, где пределы длины не определены и всё попадает в логи доступа. POST может нести тело произвольного размера, но не несёт обещания безопасности — прокси не знает, изменил ли POST /search что-либо, поэтому запрос нельзя ни повторить, ни кэшировать. QUERY проходит между: он безопасен и идемпотентен как GET, поэтому его можно свободно повторять, и несёт параметры в теле запроса как POST. Ответы кэшируемы, а ключ кэша обязан включать содержимое запроса — кэши могут нормализовать семантически незначимые различия перед формированием ключа.

Рабочая группа также явно отвергла очевидный сокращённый путь. Как поясняет RFC, GET-с-телом «всерьёз рассматривался рабочей группой IETF, но в итоге был отвергнут в пользу создания нового метода QUERY» — вплоть до исторических проблем совместимости и строгого соответствия архитектурным определениям HTTP.

Возражение, которое уже хоронило эту идею

Самый заплюсованный технический комментарий в треде был не восторгом, а предупреждением, укоренённым в истории:

«QUERY по духу существует почти два десятилетия как метод SEARCH в WebDAV, и на практике его всегда убивали посредники. Куча прокси, WAF и балансировщиков либо срезают тело у методов, которых не узнают, либо отвергают запрос целиком… Пока поддержка на шлюзах и CDN реальна, а не только на бумаге, прагматичным выбором остаётся POST с заголовком, помечающим тело как часть ключа кэша». — комментатор, ссылающийся на RFC 5323, WebDAV SEARCH

Второй инженер ударил по самой истории с кэшированием, назвав её слабым местом спецификации:

«Крайне странно включать тело запроса в ключ кэша. Это ещё и подразумевает неограниченный и управляемый пользователем ключ кэша… во враждебном сценарии — значит, сбить кэш будет тривиально». — комментатор, разбирающий поверхность атаки на ключ кэша

И более простой вопрос дизайна всплывал снова — зачем вообще целый новый глагол:

«Разве не достаточно просто навесить etag на POST-запросы? Если я правильно понимаю, серверу приходится держать состояние, чтобы обеспечить идемпотентность». — комментатор, предлагающий альтернативу ETag-на-POST

«Я годами шлю тела запросов с GET»

Под скепсисом шло течение облегчения от тех, кто импровизировал это вечно. «Я никогда не был фанатом создания эндпоинтов POST /search при работе с серьёзными API», — написал один. Основатель, строящий инструменты для разработчиков, уже давно гнул правила:

«Я уже годами шлю тело запроса вместе с методом GET». — мейнтейнер logdy.dev

Другой разработчик сообщил, что выкатил метод QUERY в прод задолго до стандартизации, в паре с заголовками Range для пагинации: «Ого, это всё ещё не стандарт? Я уже годами строю на методе QUERY». Даже имя вызвало гримасу — «query» и так означает HTTP-запрос вообще, и комментатор отметил, что один заголовок RFC сбил его с толку при первом чтении.

Чистая спецификация в ожидании, пока подтянется инфраструктура

Глагол хорошо определён и решает реальные проблемы: тела запросов, слишком большие для URL, и чтения, что сегодня маскируются под POST. Вердикт треда уже оптимизма RFC. QUERY будет ровно настолько полезен, насколько решат позволить ему прокси, WAF, CDN и балансировщики между клиентом и сервером, — а в прошлый раз, когда индустрия это пробовала, middlebox-ы победили. Спецификация — лёгкая часть; развёртывание — часть на десятилетие.