After reading about how gzip compression works it got me thinking. If the Origin and Proxy server (CDN) both support gzip is adding a Vary: Accept-Encoding
header necessary?
Is Vary: Accept-Encoding overkill?
Possible duplicate of What does vary:accept-encoding mean? –
Polytechnic
Since this question was asked an additional possible compression method (brotli) has made the header more relevant. –
Helminthiasis
The Vary: Accept-Encoding
header has more to do with caching than compression. When the Vary: Accept-Encoding
header is present, it tells the client that the file can be cached/is the same whether or not the client requests compression.
If for some reason the client has an uncompressed version of the file in its cache, it will know not to subsequently request a compressed version of it again and instead to just use the uncompressed file from the cache.
More here: What does vary:accept-encoding mean?
But is not specifying the header strictly safe, or is it a protocol violation? Maybe it only happens to work in 99% of the cases which is not enough. –
Ching
It is not a protocol violation to not specify it. Specifying means u simply state to upstream proxies to maintain separate caches based on accept-encoding request header. Like Kyle said... just replace "client" with a "upstream proxy" (isp, corporate network, etc). So you have the risk of serving uncompressed version to end user that supports gzip, and vice versa. –
Calyptra
@Calyptra yes protocol violation was the wrong term. I meant "the system does not work as a whole". And according to your explanation this seems to be the case. The header is not optional (you're right). –
Ching
@Laurettalaurette please un-Accept this anwer. It is plain wrong. All the header is telling the client that the content will stay the same for the same Accept-Encoding specifications on a future HTTP request. See comments on the response of the answer to the question linked to. –
Polished
© 2022 - 2024 — McMap. All rights reserved.