Vary: which request headers change the response

A cache stores responses under a key. By default that key is the method and the URL, so if the server produced different bodies for the same URL, the cache cannot tell them apart and will hand the wrong one to somebody. Vary adds the named request headers to the key, so a compressed and an uncompressed copy, or an English and a French copy, are stored and matched separately.

Accept-Encoding is the case nearly every site needs. Without it, a cache that stored a gzipped body can serve those bytes to a client that never asked for compression, which arrives as unreadable output rather than as an error. Most reverse proxies add the header for you when they compress, which is precisely why it is easy to forget when you compress in the application instead.

Every header you list divides the cache. Accept-Language across a dozen locales is manageable, but Vary: User-Agent creates a variant per browser build string, which in practice means almost no reuse at all. If the response really does depend on the user agent, decide the variant on the server and encode it in the URL instead.

Vary: Cookie is the quiet one. It is technically correct for a personalised page, but as almost every visitor has a different cookie, the effective hit rate at a shared cache falls to zero. For personalised responses, Cache-Control: private is usually the honest answer rather than a Vary that pretends the response is shareable.