Кратко

  • RFC 9111 разрешает объединять промахи в один пересылаемый запрос лишь при условии, что ответ допустимо повторно использовать для соответствующих запросов.
  • Для каждого ожидающего отдельно проверяются цель, метод, поля Vary, авторизация и правила кэширования.

Представим заведомо гипотетический пограничный шлюз. Два GET-запроса к одному URI приходят почти одновременно. Один анонимный, другой содержит Authorization и ожидает представление для конкретной учётной записи. Шлюз назначает первый ведущим, один раз обращается к источнику и раздаёт один 200 OK обоим. Нагрузка снижается, но решение, необходимое второму запросу, исчезает внутри оптимизации.

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

Условие существенно, потому что одного сходства URI недостаточно. Целевой URI должен совпадать, метод сохранённого ответа должен разрешать повторное использование, поля, названные Vary, должны соответствовать, а условия no-cache — выполняться. Ответ также должен быть свежим, разрешённым к выдаче устаревшим либо успешно проверенным. Объединение меняет число обращений к источнику, но не эти условия для каждого запроса.

Vary предоставляет часть решения. RFC 9110 говорит, что это поле называет компоненты запроса, которые могли повлиять на выбор представления, и расширяет ключ кэша для последующего сопоставления. RFC 9111 определяет сравнение, включая нормализацию и отсутствие поля. Vary со значением * никогда не совпадает. Оно не превращает ожидающие запросы в один, а даёт основание различать их.

Authorization делает границу наглядной. RFC 9111 запрещает общему кэшу повторно использовать сохранённый ответ на запрос с Authorization для последующих запросов, если только подходящая директива Cache-Control не разрешает это и её требования не выполнены. Не всякая группа проходит аутентификацию. Смысл в том, что раздача не может обгонять обычные правила повторного использования.

Поэтому опасно измерять только «сэкономленные запросы к источнику». Успех ведущего доказывает, что одна транзакция получила ответ. Он не доказывает одинаковые поля выбора, ограничения авторизации, свежесть и право использования у всех следующих. При различиях отдельная пересылка означает правильность, а не расточительство.

Сохранить ресурсы и доказательства поможет квитанция выпуска объединённой группы. Это предложенная здесь редакционная конструкция контроля, а не объект протокола IETF. Квитанция связывает ведущий и каждый ожидающий запрос, фиксирует ответ и сохранённый объект, нормализует метод и цель, сравнивает Vary, проверяет Authorization и Cache-Control, затем записывает выдачу либо отдельную пересылку для каждого запроса.

Так роли остаются различимыми: объединение совместно использует получение, а выдача ответа остаётся индивидуальным решением. Платформа может считать сэкономленную работу, не записывая недопустимую раздачу в успешные попадания кэша.

Источники