Найти в Дзене
День-дребедень

Vary HTTP заголовок

Добрый день, коллеги! Сегодня поговорим об HTTP заголовке Vary. Точнее говорить будет Nicolas Frankel, а я лишь переведу оригинальную статью. Задача, описанная в статье мне показалась довольно интересной. И так ... Два года назад я реализовывал кэширование на стороне сервера. Идея состояла в кэшировании ранее вычисленных результатов, чтобы уменьшить нагрузку на серверную часть. Стандарт HTTP предлагает заголовок Cache-Control для определения стратегии кэширования или иными словами в какой момент времени сервер должен начать "игноририовать" ранее закешированные данные. А теперь представим себе следующий сценарий: клиент запрашивает некий ресур GET /book/1 и получает следующий ответ HTTP/1.1 200 OK
Content-Type: application/json
{
"id": 1,
"title": "Notre-Dame de Paris"
} Результаты ответа успешно сохранены в кеше на серверной стороне в JSON формате. Следующим запросом мы обратимся к тому же ресурсу, но уже в формате XML (предварительно выставив значение заголовка Accept в applicati
Оглавление

Добрый день, коллеги! Сегодня поговорим об HTTP заголовке Vary. Точнее говорить будет Nicolas Frankel, а я лишь переведу оригинальную статью. Задача, описанная в статье мне показалась довольно интересной. И так ...

В чем же проблема ?

Два года назад я реализовывал кэширование на стороне сервера. Идея состояла в кэшировании ранее вычисленных результатов, чтобы уменьшить нагрузку на серверную часть. Стандарт HTTP предлагает заголовок Cache-Control для определения стратегии кэширования или иными словами в какой момент времени сервер должен начать "игноририовать" ранее закешированные данные.

А теперь представим себе следующий сценарий: клиент запрашивает некий ресур GET /book/1 и получает следующий ответ

HTTP/1.1 200 OK
Content-Type: application/json

{
"id": 1,
"title": "Notre-Dame de Paris"
}

Результаты ответа успешно сохранены в кеше на серверной стороне в JSON формате. Следующим запросом мы обратимся к тому же ресурсу, но уже в формате XML (предварительно выставив значение заголовка Accept в application/xml ). В качестве ответа получим ранее закешированный результат в формате JSON, что несомненно "взрывает" клиентский код, который ожидает ответ в Xml формате :-(

Решаем проблему

Для решения данной проблемы нам нужен многосоставной ключ и как вы уже догадываетесь именно заголовок Vary нам в этом поможет. В этом заголовке перечисляются все измерения, используемые в составном ключе. Давайте взглянем на пример ответа ниже

HTTP/1.1 200 OK
Content-Type: application/json
Content-Language: en
Vary: Accept

{
"id": 1,
"title": "Notre-Dame de Paris"
}

Значение заголовка Vary указывает на то, что ключ для кешированного значения будет не только URL запроса, а пара URL + MIME type из Accept заголовка запроса.

Таким образом, возвращаясь к примерам запросов, описанных выше, в нашем кеше будут храниться два значения с ключами соотвествующим book/1 + application/json и book/1 + application/xml и тем самым мы будем получать закешированные ответы в нужном формате.

Стоит отметить, что заголовок Vary имеет более общее назначение. Cогласано RFC 9110 Vary используется в случае, когда ответ зависит от того или иного набора значений заголовков запроса. Vary и определяет список этих заголовков запроса.

Заголовок Vary позволяет также строить более сложный многосоставной ключ, например

HTTP/1.1 200 OK
Content-Type: application/json
Content-Language: en
Vary: Accept, Accept-Encoding


{
"id": 1,
"title": "Notre-Dame de Paris"
}

Здесь уже ключ формируется по значению URL + Accept + Accept-Encoding заголовки.