Я пытаюсь понять заголовок ответа «Vary: Accept-Encoding».
Я заметил, что заголовок ответа «Vary: Accept-Encoding» появляется для некоторых изображений в инструментах разработчика для нашего приложения, но некоторые изображения не имеют этого заголовка ответа.
Когда я пытался использовать тот же URL-адрес изображения в браузере, не видя заголовка «Vary: Accept-Encoding».
Почему этот заголовок отображается только для выбранных изображений в нашем приложении? Какие могут быть возможности?
Нет, при просмотре приложения я не вижу никаких изменений в изображении.
Я бы рекомендовал прочитать разделы RFC 7231, касающиеся согласования содержимого и кодирования сжатия.

Этот заголовок может возвращать либо Tomcat, либо приложение. Если Tomcat применяется, например, Кодировка gzip, тогда важно ответить Vary: Accept-Encoding, потому что, если клиент не указывает, что он поддерживает gzip, тогда исходный сервер (веб-сервер), прокси и т. д. Должны отвечать другим типом данных.
Если клиент запрашивает /myapp/something и объявляет, что он готов принимать только ответы с кодировкой gzip, то /myapp/something действительно должен возвращать только ответ в кодировке identity или gzip или отвечать с ответом 412.
Заголовок Vary действительно для прокси. Он сообщает прокси-серверу, что клиенты на другой стороне могут получить другой ответ, если у них разные значения Accept-Encoding в заголовках запросов. Итак, если два клиента запрашивают один и тот же ресурс, но один говорит Accept-Encoding: identity,gzip, а другой говорит Accept-Encoding: identity,compress, они (вероятно) получат два ответа, и прокси-сервер должен понимать, что важен не только URL-адрес, но и такжеAccept-Encoding из клиент, который должен управлять любым кэшированием, которое может понадобиться прокси.
а) он всегда мог вернуть не закодированный (несжатый) вариант. (б) заменить «прокси» на «кеш» - может быть на стороне клиента ...
Хм. Полезные данные не отличаться для некоторых изображений?