Кратко

  • В RFC 9218 Priority и PRIORITY_UPDATE являются входными данными для приоритизации, а не гарантией порядка обработки или передачи.
  • Сервер, посредник, браузер и система измерения отвечают за разные части результата; наблюдение одного сигнала не объединяет эти полномочия.

У RFC 9218 есть важное достоинство: он не выдаёт переносимый синтаксис за переносимую политику. Поле Priority — это end-to-end сигнал, выражающий взгляд конечной точки на то, как следует приоритизировать HTTP-ответы. Кадр PRIORITY_UPDATE в HTTP/2 и HTTP/3 несёт набор параметров для конкретной цели, но действует hop-by-hop. Уже это различие не позволяет считать значение, увиденное у клиента, описанием каждой последующей очереди.

Спецификация прямо допускает, что серверы HTTP/2 и HTTP/3 планируют одновременные данные ответов любым выбранным ими способом. Они могут игнорировать клиентские сигналы приоритета и всё же успешно обслуживать HTTP-ответы. Сигналы заголовка и кадра — лишь предложения для процесса приоритизации; они не гарантируют определённого порядка обработки или передачи одного ответа относительно другого.

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

Посредник добавляет ещё один разрыв в цепочке. Он может передать исходный заголовок без изменений. Он может оставить заголовок и направить следующему hop иной PRIORITY_UPDATE. Он может заменить или добавить заголовок и тем самым переопределить исходный клиентский сигнал для следующих получателей. Для утверждения о политике origin-сервера нужны записи именно этого участка, а не только исходный сетевой след.

В HTTP/3 нужно отдельно учитывать время. Порядок между потоками не гарантирован; обновление может прийти раньше потока запроса, к которому относится. Получатель может хранить наиболее новое обновление, но объём ресурсов для такого хранения ограничивается локальной политикой реализации. Поэтому отправленный кадр не служит журналом того, когда решение стало возможным и было ли оно принято.

Ответ сервера не превращает предположение в подтверждение. RFC 9218 запрещает клиенту понимать наличие либо отсутствие поля Priority в ответе как признание того, что приоритизация произошла. А финальный HTTP-ответ говорит о завершении HTTP-сообщения, но не о порядке зависимых ресурсов, выполнении кода, компоновке страницы, условиях устройства или восприятии пользователя.

Правильная доказательная лестница короче и надёжнее: выраженное значение; получение и изменение на каждом hop; локальное слияние и решение очереди; доставка байтов; измеренный итог в браузере. Пробел на одной ступени не следует заполнять красивым полем с другой ступени.

Источники