- 28,310
- 46
- 8 Ноя 2022
Один термин (идемпотентность) определяет будущее веб-запросов.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1200/675;margin-bottom:2rem;overflow:hidden">
У сложных поисковых запросов появился собственный способ общаться с сервером. Инженерный совет Интернета (IETF) утвердил новый метод HTTP под названием QUERY, который позволит передавать большие наборы условий без гигантских адресов и неподходящего для такой задачи метода POST.
Новый метод описан в стандарте RFC 10008. QUERY передаёт параметры запроса в его содержимом, как POST, но при этом считается безопасным и идемпотентным. Последний термин означает, что запрос, отправленный повторно, не должен менять результат или вызывать нежелательные действия. Сервер может получить QUERY один раз или несколько раз, не создавая новые записи и не списывая деньги повторно.
До сих пор для поиска обычно применяли GET. Параметры добавлялись прямо в адрес после вопросительного знака. Такой подход хорошо работает для простых запросов, но вложенные фильтры, сортировка, диапазоны дат и другие условия быстро превращают адрес в длинную и неудобную строку.
Единого предела длины адреса нет. Стандарт рекомендует поддерживать не менее 8000 октетов, однако слишком длинную строку может отклонить браузер, сервер, межсетевой экран или другое промежуточное оборудование. Кроме того, параметры из адреса могут попасть в историю браузера, журналы сервера и закладки, из-за чего конфиденциальные данные рискуют утечь.
Разработчики обходили ограничения с помощью POST, помещая сложные условия в содержимое запроса, часто в формате JSON. Такой способ широко используют программные интерфейсы, включая GraphQL . Проблема в том, для чего изначально предназначен POST: протокол не считает его безопасным и идемпотентным, поскольку запрос может создать или изменить данные на сервере.
Поэтому прокси-серверы, сети доставки содержимого и шлюзы не могут без дополнительных сведений сохранять ответы POST в кэше или автоматически повторять запрос после обрыва соединения. QUERY явно сообщает промежуточным системам, что операция только запрашивает данные и не меняет состояние ресурса. Благодаря этому ответы можно кэшировать , а неудачные запросы повторять автоматически.
Чтобы новый метод стали поддерживать повсеместно, потребуется время. Обычные формы HTML пока работают только с GET и POST, а незнакомые запросы могут отклонять прокси-серверы, балансировщики нагрузки, сети доставки содержимого, межсетевые экраны и веб-платформы.
Серверные инструменты уже начинают поддерживать новый метод. Node.js добавляет QUERY в модуль HTTP, язык Go позволяет отправлять произвольные методы, а платформа Laravel уже умеет принимать такие запросы. Разработчики ожидают, что сначала QUERY освоят серверы и средства разработки, затем веб-платформы, а браузеры и программный интерфейс fetch подключатся позднее.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1200/675;margin-bottom:2rem;overflow:hidden">
У сложных поисковых запросов появился собственный способ общаться с сервером. Инженерный совет Интернета (IETF) утвердил новый метод HTTP под названием QUERY, который позволит передавать большие наборы условий без гигантских адресов и неподходящего для такой задачи метода POST.
Новый метод описан в стандарте RFC 10008. QUERY передаёт параметры запроса в его содержимом, как POST, но при этом считается безопасным и идемпотентным. Последний термин означает, что запрос, отправленный повторно, не должен менять результат или вызывать нежелательные действия. Сервер может получить QUERY один раз или несколько раз, не создавая новые записи и не списывая деньги повторно.
До сих пор для поиска обычно применяли GET. Параметры добавлялись прямо в адрес после вопросительного знака. Такой подход хорошо работает для простых запросов, но вложенные фильтры, сортировка, диапазоны дат и другие условия быстро превращают адрес в длинную и неудобную строку.
Единого предела длины адреса нет. Стандарт рекомендует поддерживать не менее 8000 октетов, однако слишком длинную строку может отклонить браузер, сервер, межсетевой экран или другое промежуточное оборудование. Кроме того, параметры из адреса могут попасть в историю браузера, журналы сервера и закладки, из-за чего конфиденциальные данные рискуют утечь.
Разработчики обходили ограничения с помощью POST, помещая сложные условия в содержимое запроса, часто в формате JSON. Такой способ широко используют программные интерфейсы, включая GraphQL . Проблема в том, для чего изначально предназначен POST: протокол не считает его безопасным и идемпотентным, поскольку запрос может создать или изменить данные на сервере.
Поэтому прокси-серверы, сети доставки содержимого и шлюзы не могут без дополнительных сведений сохранять ответы POST в кэше или автоматически повторять запрос после обрыва соединения. QUERY явно сообщает промежуточным системам, что операция только запрашивает данные и не меняет состояние ресурса. Благодаря этому ответы можно кэшировать , а неудачные запросы повторять автоматически.
Чтобы новый метод стали поддерживать повсеместно, потребуется время. Обычные формы HTML пока работают только с GET и POST, а незнакомые запросы могут отклонять прокси-серверы, балансировщики нагрузки, сети доставки содержимого, межсетевые экраны и веб-платформы.
Серверные инструменты уже начинают поддерживать новый метод. Node.js добавляет QUERY в модуль HTTP, язык Go позволяет отправлять произвольные методы, а платформа Laravel уже умеет принимать такие запросы. Разработчики ожидают, что сначала QUERY освоят серверы и средства разработки, затем веб-платформы, а браузеры и программный интерфейс fetch подключатся позднее.
- Источник новости
- www.securitylab.ru
