26

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?

Jason Sundram
  • 12,225
  • 19
  • 71
  • 86
jdorfman
  • 781
  • 2
  • 10
  • 21
  • Possible duplicate of [What does vary:accept-encoding mean?](https://stackoverflow.com/questions/7848796/what-does-varyaccept-encoding-mean) – Jonathan Hall Aug 22 '19 at 15:36
  • Since this question was asked an additional possible compression method (brotli) has made the header more relevant. – anotherfred Dec 08 '21 at 14:51

1 Answers1

26

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?

Community
  • 1
  • 1
Kyle Rush
  • 284
  • 3
  • 2
  • 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. – usr Jan 26 '13 at 20:52
  • 5
    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. – sajal Jan 26 '13 at 21:15
  • @sajal 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). – usr Jan 26 '13 at 21:23
  • 3
    @jdorfman 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. – C.O. Dec 01 '15 at 19:03