Эволюция HTTP для современного веба

Поле Cache-Control в заголовке ответа от Хабра

Кто двигает научно-технический прогресс? Учёные, которые шлифуют термоядерный синтез, чтобы человечество могло отказаться от ископаемого топлива. Предприниматели, которые финансируют марсианскую программу и разработку новых ракет. И, конечно, инженеры рабочей группы HTTPbis, которые совершенствуют протокол передачи гипертекста.

Прямо сейчас в разработке находится несколько спецификаций для новых полей HTTP в заголовках запросов и ответов, которые сделают нашу жизнь гораздо лучше во многих отношениях — в кешировании контента, в управлении обратными прокси, а также в установке гибких квот на количество запросов к серверу. О чём ещё можно мечтать? Перечислим некоторые из планируемых улучшений, с максимально кратким пояснением.

Статус промежуточных кешей

Новые поля в заголовке ответа HTTP: Cache-Status и таргетированный Cache-Control упростят кеширование статического контента. Поле Cache-Status определяет новое поле заголовка ответа HTTP со стандартизированным синтаксисом и семантикой для всех уровней кеширования, а Cache-Control — это список прямых инструкций кеширования, которые задаются сервером для запросов и ответов. В новой таргетированной версии можно будет задавать эти инструкции конкретной системе, а не всем уровням кеша на пути пакета, как раньше.

Примеры

Cache-Status: ExampleCache; fwd=uri-miss; collapsed=?0

Age: 1800
Cache-Control: max-age=600
CDN-Cache-Control: max-age=3600

Первая версия таргетированного Cache-Control опубликована в июле 2021 года, а Cache-Status предложен ещё в 2018 году, сейчас обсуждается уже 10-я версия черновика.

Коды состояния CDN и прокси

Спецификация Proxy-Status предлагает ввести новое поле в заголовке ответа для отображения статуса промежуточных узлов (прокси) на пути пакета, чтобы лучше понимать причины ошибок.

Этот протокол тоже вводится для лучшего соответствия реалиям современного интернета, где между клиентом и сервером стало много «посредников», таких как CDN и обратные прокси.

Как правило, эти посредники перенаправляют запросы к серверу, а затем ответы обратно клиенту. Но если ошибка возникает до того, как получен ответ от сервера, этот ответ часто генерируется самим прокси.

HTTP показывает такие ошибки с помощью кодов состояния типа 502 Bad Gateway и 504 Gateway Timeout. Но для облегчения отладки нужно более подробно сообщать клиенту о произошедшем. Кроме того, прокси иногда хотят передать с проходящим мимо пакетом дополнительную информацию о своей работе.

Параметры и коды ошибок прокси для поля ответа перечислены в спецификациях. Стандартом также предусмотрена регистрация в будущем и новых параметров Proxy-Status.

Примеры

HTTP/1.1 429 Too Many Requests
Proxy-Status: r34.example.net; error=http_request_error, ExampleCDN

Proxy-Status: cdn.example.org; next-hop=backend.example.org:8001;
next-protocol=h2; received-status=200;
details="Malformed response header: space before colon"

Стандарт в разработке с февраля 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 с разными квотами на доступ к определённым разделам сайта и даже конкретным поисковым запросам, см. примеры ниже.

Примеры

Запрос:

 GET /items/123 HTTP/1.1
Host: api.example

Ответ:

 HTTP/1.1 200 Ok
Content-Type: application/json
acme-RateLimit-DayLimit: 5000
acme-RateLimit-HourLimit: 1000
RateLimit-Limit: 5000
RateLimit-Remaining: 100
RateLimit-Reset: 36000

{"hello": "world"}

Запрос:

 GET /items/123 HTTP/1.1
Host: api.example

Ответ:

 HTTP/1.1 200 Ok
Content-Type: application/json
RateLimit-Limit: 10, 100;w=60
Ratelimit-Remaining: 9
Ratelimit-Reset: 50

{
"status": 200,
"detail": "Just slow down without waiting."
}

Запросы и ответы:

GET /books/123 ; service-limit=4, remaining: 3, status=200
GET /books?author=WuMing ; service-limit=4, remaining: 1, status=200
GET /books?author=Eco ; service-limit=4, remaining: 0, status=429

Это предложение тоже обсуждается довольно давно: с сентября 2019 года, последняя версия опубликована в ноябре 2021-го.

Контрольные суммы

В новые поля дайджестов HTTP (Digest Fields) заголовков запроса и ответа предполагается записывать контрольную сумму некоего набора параметров. На основании этой контрольной суммы получатель сможет проверить цельность этих данных. Сами по себе поля не защищают содержимое пакетов от изменения, но в сочетании с цифровыми подписями могут выполнять эту задачу.

Предполагается, что дайджесты идут на смену устаревшему заголовку Content-MD5, который играл роль механизма обеспечения цельности данных до HTTP/1.1, а также стандарту последовавшему за ним стандарту RFC3230.

Итак, новое поле Digest содержит значения одной или нескольких контрольных сумм для набора параметров, вместе с указанием используемого алгоритма.

Пример

 Digest: sha-256=4REjxQ4yrqUVicfSKYNO/cF9zNj5ANbzgDZt3/h3Qxo=,
sha-512=WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+TaPm
AbwAgBWnrIiYllu7BNNyealdVLvRwE\nmTHWXvJwew==

Аналогично, поле Content-Digest содержит значения контрольных сумм для содержимого пакетов (контента).

Предлагаются также поля Want-Digest и Want-Content-Digest в запросах с указанием предпочтений по параметрам контрольной суммы в ответных пакетах.

Примеры

 Want-Digest: sha-256
Want-Digest: sha-512;q=0.3, sha-256;q=1, unixsum;q=0
Want-Content-Digest: sha-256
Want-Content-Digest: sha-512;q=0.3, sha-256;q=1, unixsum;q=0

Эти спецификации близки к окончательному утверждению. Обсуждение ведётся с мая 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 продолжает развиваться. Разработчики браузеров, серверного софта и других инструментов участвуют в этом, а иногда внедряют экспериментальную поддержку новых заголовков на ранней стадии, до их официального утверждения. Такая ранняя обкатка помогает уточнить и оформить стандарты в окончательном виде.