Кто двигает научно-технический прогресс? Учёные, которые шлифуют термоядерный синтез, чтобы человечество могло отказаться от ископаемого топлива. Предприниматели, которые финансируют марсианскую программу и разработку новых ракет. И, конечно, инженеры рабочей группы HTTPbis, которые совершенствуют протокол передачи гипертекста.
Прямо сейчас в разработке находится несколько спецификаций для новых полей HTTP в заголовках запросов и ответов, которые сделают нашу жизнь гораздо лучше во многих отношениях — в кешировании контента, в управлении обратными прокси, а также в установке гибких квот на количество запросов к серверу. О чём ещё можно мечтать? Перечислим некоторые из планируемых улучшений, с максимально кратким пояснением.
Новые поля в заголовке ответа HTTP: Cache-Status и таргетированный Cache-Control упростят кеширование статического контента. Поле Cache-Status определяет новое поле заголовка ответа HTTP со стандартизированным синтаксисом и семантикой для всех уровней кеширования, а Cache-Control — это список прямых инструкций кеширования, которые задаются сервером для запросов и ответов. В новой таргетированной версии можно будет задавать эти инструкции конкретной системе, а не всем уровням кеша на пути пакета, как раньше.
Первая версия таргетированного Cache-Control опубликована в июле 2021 года, а Cache-Status предложен ещё в 2018 году, сейчас обсуждается уже 10-я версия черновика.
Спецификация Proxy-Status предлагает ввести новое поле в заголовке ответа для отображения статуса промежуточных узлов (прокси) на пути пакета, чтобы лучше понимать причины ошибок.
Этот протокол тоже вводится для лучшего соответствия реалиям современного интернета, где между клиентом и сервером стало много «посредников», таких как CDN и обратные прокси.
Как правило, эти посредники перенаправляют запросы к серверу, а затем ответы обратно клиенту. Но если ошибка возникает до того, как получен ответ от сервера, этот ответ часто генерируется самим прокси.
HTTP показывает такие ошибки с помощью кодов состояния типа 502 Bad Gateway и 504 Gateway Timeout. Но для облегчения отладки нужно более подробно сообщать клиенту о произошедшем. Кроме того, прокси иногда хотят передать с проходящим мимо пакетом дополнительную информацию о своей работе.
Параметры и коды ошибок прокси для поля ответа перечислены в спецификациях. Стандартом также предусмотрена регистрация в будущем и новых параметров Proxy-Status.
Стандарт в разработке с февраля 2019 года, последняя восьмая версия черновика опубликована в октябре 2021-го.
Смысл нового поля RateLimit в заголовке HTTP заключается в том, чтобы установить стандартный механизм для передачи сообщений об ограничениях на количество запросов (usage quota).
Как это происходит сейчас? Если веб-служба получает чрезмерное количество запросов из одного источника, то может вернуть ответ с кодом ошибки 429 Too Many Requests или 503 Service Unavailable. По текущему стандарту, в этом ответе есть поле Retry-After, в котором указан временной интервал, через который рекомендуется обратиться со следующим запросом. Но это не очень удобно. Сейчас сервер не имеет возможности сообщить клиенту самый главный параметр — допустимое количество запросов за определённый промежуток времени, чтобы ошибки 4хх или 5хх не возникали так часто.
Спецификации определяют синтаксис трёх полей: RateLimit-Limit с указанием общего лимита, RateLimit-Remaining с указанием оставшегося лимита на количество запросов в текущем интервале времени и RateLimit-Reset с указанием количества секунд до окончания этого интервала. Собственно, последнее поле похоже на существующее сейчас значение Retry-After.
Такие определения полей позволяют внедрять сложные политики, включая различные интервалы времени и динамические квоты.
Возможна установка значения service-limit с разными квотами на доступ к определённым разделам сайта и даже конкретным поисковым запросам, см. примеры ниже.
Это предложение тоже обсуждается довольно давно: с сентября 2019 года, последняя версия опубликована в ноябре 2021-го.
В новые поля дайджестов HTTP (Digest Fields) заголовков запроса и ответа предполагается записывать контрольную сумму некоего набора параметров. На основании этой контрольной суммы получатель сможет проверить цельность этих данных. Сами по себе поля не защищают содержимое пакетов от изменения, но в сочетании с цифровыми подписями могут выполнять эту задачу.
Предполагается, что дайджесты идут на смену устаревшему заголовку Content-MD5, который играл роль механизма обеспечения цельности данных до HTTP/1.1, а также стандарту последовавшему за ним стандарту RFC3230.
Итак, новое поле Digest содержит значения одной или нескольких контрольных сумм для набора параметров, вместе с указанием используемого алгоритма.
Аналогично, поле Content-Digest содержит значения контрольных сумм для содержимого пакетов (контента).
Предлагаются также поля Want-Digest и Want-Content-Digest в запросах с указанием предпочтений по параметрам контрольной суммы в ответных пакетах.
Эти спецификации близки к окончательному утверждению. Обсуждение ведётся с мая 2019 года, последний черновик draft-ietf-httpbis-digest-headers-07 опубликован в ноябре 2021-го.
HTTP Client Hints можно перевести как «подсказки клиента». Суть в следующем. По существующим стандартам клиент отправляет серверу строку user agent, на основании которой предполагает получить от сервера некоторый ответ. Но на практике клиент часто воздерживается от указания реального юзер-агента, потому что не имеет понятия, как сервер будет использовать эту информацию. Есть опасения в связи с приватностью, фингерпринтингом и т. д. То есть клиент просто опасается выдать лишние данные.
Так вот, по новому стандарту сервер включает в заголовок ответа поле Accept-CH — своеобразное разъяснение, как будут использоваться «подсказки клиента», вместе с инструкциями по их составлению:
Accept-CH: Sec-CH-UA-Platform-Version
Получив конкретно такие инструкции, клиент может сгенерировать для сервера подходящий юзер-агент с указанием только того, что требуется:
Sec-CH-UA: "Examplary Browser"; v="73", ";Not?A.Brand"; v="27"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"
Sec-CH-UA-Platform-Version: "14.0.0"
Этот процесс называется «проактивные переговоры по контенту» (proactive content negotiation).
Примеры использования Client Hints для юзер-агента можно посмотреть в неофициальном черновике User-Agent Client Hints.
Стандарт HTTP Client Hints уже принят в экспериментальном статусе как RFC 8942.
Как видим, протокол HTTP продолжает развиваться. Разработчики браузеров, серверного софта и других инструментов участвуют в этом, а иногда внедряют экспериментальную поддержку новых заголовков на ранней стадии, до их официального утверждения. Такая ранняя обкатка помогает уточнить и оформить стандарты в окончательном виде.
habr.com
Прямо сейчас в разработке находится несколько спецификаций для новых полей HTTP в заголовках запросов и ответов, которые сделают нашу жизнь гораздо лучше во многих отношениях — в кешировании контента, в управлении обратными прокси, а также в установке гибких квот на количество запросов к серверу. О чём ещё можно мечтать? Перечислим некоторые из планируемых улучшений, с максимально кратким пояснением.
Статус промежуточных кешей
Новые поля в заголовке ответа HTTP: Cache-Status и таргетированный Cache-Control упростят кеширование статического контента. Поле Cache-Status определяет новое поле заголовка ответа HTTP со стандартизированным синтаксисом и семантикой для всех уровней кеширования, а Cache-Control — это список прямых инструкций кеширования, которые задаются сервером для запросов и ответов. В новой таргетированной версии можно будет задавать эти инструкции конкретной системе, а не всем уровням кеша на пути пакета, как раньше.
Первая версия таргетированного Cache-Control опубликована в июле 2021 года, а Cache-Status предложен ещё в 2018 году, сейчас обсуждается уже 10-я версия черновика.
Коды состояния CDN и прокси
Спецификация Proxy-Status предлагает ввести новое поле в заголовке ответа для отображения статуса промежуточных узлов (прокси) на пути пакета, чтобы лучше понимать причины ошибок.
Этот протокол тоже вводится для лучшего соответствия реалиям современного интернета, где между клиентом и сервером стало много «посредников», таких как CDN и обратные прокси.
Как правило, эти посредники перенаправляют запросы к серверу, а затем ответы обратно клиенту. Но если ошибка возникает до того, как получен ответ от сервера, этот ответ часто генерируется самим прокси.
HTTP показывает такие ошибки с помощью кодов состояния типа 502 Bad Gateway и 504 Gateway Timeout. Но для облегчения отладки нужно более подробно сообщать клиенту о произошедшем. Кроме того, прокси иногда хотят передать с проходящим мимо пакетом дополнительную информацию о своей работе.
Параметры и коды ошибок прокси для поля ответа перечислены в спецификациях. Стандартом также предусмотрена регистрация в будущем и новых параметров Proxy-Status.
Стандарт в разработке с февраля 2019 года, последняя восьмая версия черновика опубликована в октябре 2021-го.
Ограничение на количество запросов
Смысл нового поля RateLimit в заголовке HTTP заключается в том, чтобы установить стандартный механизм для передачи сообщений об ограничениях на количество запросов (usage quota).
Как это происходит сейчас? Если веб-служба получает чрезмерное количество запросов из одного источника, то может вернуть ответ с кодом ошибки 429 Too Many Requests или 503 Service Unavailable. По текущему стандарту, в этом ответе есть поле Retry-After, в котором указан временной интервал, через который рекомендуется обратиться со следующим запросом. Но это не очень удобно. Сейчас сервер не имеет возможности сообщить клиенту самый главный параметр — допустимое количество запросов за определённый промежуток времени, чтобы ошибки 4хх или 5хх не возникали так часто.
Спецификации определяют синтаксис трёх полей: RateLimit-Limit с указанием общего лимита, RateLimit-Remaining с указанием оставшегося лимита на количество запросов в текущем интервале времени и RateLimit-Reset с указанием количества секунд до окончания этого интервала. Собственно, последнее поле похоже на существующее сейчас значение Retry-After.
Такие определения полей позволяют внедрять сложные политики, включая различные интервалы времени и динамические квоты.
Возможна установка значения service-limit с разными квотами на доступ к определённым разделам сайта и даже конкретным поисковым запросам, см. примеры ниже.
Это предложение тоже обсуждается довольно давно: с сентября 2019 года, последняя версия опубликована в ноябре 2021-го.
Контрольные суммы
В новые поля дайджестов HTTP (Digest Fields) заголовков запроса и ответа предполагается записывать контрольную сумму некоего набора параметров. На основании этой контрольной суммы получатель сможет проверить цельность этих данных. Сами по себе поля не защищают содержимое пакетов от изменения, но в сочетании с цифровыми подписями могут выполнять эту задачу.
Предполагается, что дайджесты идут на смену устаревшему заголовку Content-MD5, который играл роль механизма обеспечения цельности данных до HTTP/1.1, а также стандарту последовавшему за ним стандарту RFC3230.
Итак, новое поле Digest содержит значения одной или нескольких контрольных сумм для набора параметров, вместе с указанием используемого алгоритма.
Аналогично, поле Content-Digest содержит значения контрольных сумм для содержимого пакетов (контента).
Предлагаются также поля Want-Digest и Want-Content-Digest в запросах с указанием предпочтений по параметрам контрольной суммы в ответных пакетах.
Эти спецификации близки к окончательному утверждению. Обсуждение ведётся с мая 2019 года, последний черновик draft-ietf-httpbis-digest-headers-07 опубликован в ноябре 2021-го.
HTTP Client Hints
HTTP Client Hints можно перевести как «подсказки клиента». Суть в следующем. По существующим стандартам клиент отправляет серверу строку user agent, на основании которой предполагает получить от сервера некоторый ответ. Но на практике клиент часто воздерживается от указания реального юзер-агента, потому что не имеет понятия, как сервер будет использовать эту информацию. Есть опасения в связи с приватностью, фингерпринтингом и т. д. То есть клиент просто опасается выдать лишние данные.
Так вот, по новому стандарту сервер включает в заголовок ответа поле Accept-CH — своеобразное разъяснение, как будут использоваться «подсказки клиента», вместе с инструкциями по их составлению:
Accept-CH: Sec-CH-UA-Platform-Version
Получив конкретно такие инструкции, клиент может сгенерировать для сервера подходящий юзер-агент с указанием только того, что требуется:
Sec-CH-UA: "Examplary Browser"; v="73", ";Not?A.Brand"; v="27"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"
Sec-CH-UA-Platform-Version: "14.0.0"
Этот процесс называется «проактивные переговоры по контенту» (proactive content negotiation).
Примеры использования Client Hints для юзер-агента можно посмотреть в неофициальном черновике User-Agent Client Hints.
Стандарт HTTP Client Hints уже принят в экспериментальном статусе как RFC 8942.
Как видим, протокол HTTP продолжает развиваться. Разработчики браузеров, серверного софта и других инструментов участвуют в этом, а иногда внедряют экспериментальную поддержку новых заголовков на ранней стадии, до их официального утверждения. Такая ранняя обкатка помогает уточнить и оформить стандарты в окончательном виде.
Эволюция HTTP для современного веба
Поле Cache-Control в заголовке ответа от Хабра Кто двигает научно-технический прогресс? Учёные, которые шлифуют термоядерный синтез , чтобы человечество могло отказаться от ископаемого топлива....
habr.com