Комитет IETF придал HTTP-методу `QUERY` статус «Предложенного стандарта» — 18 июня 2026 г. в 08:10:44.720
Комитет IETF придал HTTP-методу `QUERY` статус «Предложенного стандарта» Инженерный комитет IETF (Internet Engineering Task Force) придал HTTP-методу `QUERY` статус `«Предложенного стандарта»` (Proposed Standard). Для этого выпустили спецификацию `RFC 10008` («The HTTP QUERY Method»). Статус «Предложенный стандарт» означает, что спецификация прошла определённый этап обсуждения и одобрения в сообществе, и теперь её можно реализовывать и использовать на практике. Однако это ещё не финальный, «окончательный» стандарт — процесс развития продолжается. Зачем нужен QUERY? Идея в том, чтобы создать метод, который объединит сильные стороны GET и POST. * `Как GET:` QUERY является безопасным — он не предназначен для изменения состояния ресурса на сервере. * `Как POST:` в запросе QUERY можно передавать данные прямо в теле запроса (а не в URI, как в GET). Это удобно, когда нужно отправить сложный или объёмный запрос — в URI есть практические лимиты на длину, а в теле запроса их нет. Подобный подход даёт возможность передавать большой объём параметров в запросе, превышающий лимит на размер параметров в методе GET (8000 байт). # GET-запрос GET /feed?q=foo&limit=10&sort=-published HTTP/1.1 Host: example.org # QUERY-запрос QUERY /feed HTTP/1.1 Host: example.org Content-Type: application/x-www-form-urlencoded q=foo&limit=10&sort=-published Отправленные через метод QUERY параметры не отражаются в логах серверов, что с одной стороны затрудняет анализ запросов и диагностику проблем, но с другой стороны даёт возможность скрыть конфиденциальные данные из логов прокси-серверов. При этом QUERY ещё и идемпотентен (idempotent): его можно безопасно повторять или перезапускать (например, при сбоях связи), не опасаясь побочных эффектов. Это открывает возможности для автоматического повтора запросов и кэширования результатов. `Пример использования:` отправка запроса к Web API, который возвращает данные в JSON или XML, или работа с бэкендом, генерирующим контент. Что ещё важно знать * В спецификации описан заголовок `Accept-Query`. С его помощью сервер может в ответе сообщить клиенту, какие форматы данных (медиа-типы) поддерживаются для запросов QUERY. Например: `Accept-Query: application/jsonpath, application/sql;charset="UTF-8"`. * Ответ на запрос QUERY `можно кэшировать`. При этом ключ кэша должен учитывать содержимое тела запроса. * В ответе сервер может использовать заголовки `Content-Location` (указывает URI ресурса с результатами запроса) или ``Location`` (для перенаправления). * Для проверки, поддерживает ли сервер QUERY, можно использовать метод OPTIONS. * Среди возможных кодов ответа: 415 (Unsupported Media Type), 400 (Bad Request), 422 (Unprocessable Content), 406 (Not Acceptable). https://mailarchive.ietf.org/arch/msg/ietf-announce/uNaYyRDGKjyOn_KDT2JaGLlm9fE/