As written, the configurations does this:
If the client can gunzip and a pre-gzipped version of the requested file exists, then send the gzipped file with appropriate headers, including a
I think this neglects a (today possibly very niché?) case: A client without gunzip capabilities will be served the uncompressed version (so far so good), but without a
Vary:header. Consequently, if the first request via a proxy comes from such a client, the proxy will store the uncompressed version only. Any later gunzip-capable client using that proxy will be served the uncompressed cached version becaause the proxy is not aware of existing variations. (The again, it is not unlikely that the proxy may be so kind to gzip the content on-the-fly).
So it seems that the attempt to reduce server load by using pre-compressed versions instead of always compressing on-the-fly might lead to some proxies having to do the on-the-fly compression instead.
Q1: Are these observations correct?
Q2: If so, should the configuration rather be amended by something that amounts to
If the client cannot gunzip and a pre-gzipped version of the requested file exists, then send the original file (of course)1, but also add a
Q3: Come to think of it, it may be the case that client and server agree on a more obscure compression method (let's call it foobarzip) and so
mod-deflate might decide that foobarzip'ing the pre-compressed file is worth the effort - which leads to the delivery of foobarzip'ed gzip'ed content with the
Content-encoding:gzip header being overwritten by
Content-encoding:foobarzip so that the client will consider this as foobarzip'ed content without intermediary gzip and desaster strikes?