The DEFLATE
output filter that allows output from
your server to be compressed before being sent to the client over
the network.
This is a simple sample configuration for the impatient.
The following configuration, while resulting in more compressed content, is also much more complicated. Do not use this unless you fully understand all the configuration details.
Compression is implemented by the DEFLATE
filter. The following directive
will enable compression for documents in the container where it
is placed:
Some popular browsers cannot handle compression of all content
so you may want to set the gzip-only-text/html
note to
1
to only allow html files to be compressed (see
below). If you set this to anything but 1
it
will be ignored.
If you want to restrict the compression to particular MIME types
in general, you may use the
For browsers that have problems even with compression of all file
types, use the no-gzip
note for that particular browser so that no compression will be
performed. You may combine no-gzip
with gzip-only-text/html
to get the best results. In that case
the former overrides the latter. Take a look at the following
excerpt from the configuration example
defined in the section above:
At first we probe for a User-Agent
string that
indicates a Netscape Navigator version of 4.x. These versions
cannot handle compression of types other than
text/html
. The versions 4.06, 4.07 and 4.08 also
have problems with decompressing html files. Thus, we completely
turn off the deflate filter for them.
The third \b
means
"word boundary") in the User-Agent
Header and turn off
the restrictions defined before.
DEFLATE
filter is always inserted after RESOURCE
filters like PHP or SSI. It never touches internal subrequests.
The DEFLATE
filter into
the input filter chain using
Now if a request contains a Content-Encoding:
gzip
header, the body will be automatically decompressed.
Few browsers have the ability to gzip request bodies. However,
some special applications actually do support request
compression, for instance some WebDAV clients.
If you evaluate the request body yourself, don't trust
the Content-Length
header!
The Content-Length header reflects the length of the
incoming data from the client and not the byte count of
the decompressed data stream.
The Vary:
Accept-Encoding
HTTP response header to alert proxies that
a cached response should be sent only to clients that send the
appropriate Accept-Encoding
request header. This
prevents compressed content from being sent to a client that will
not understand it.
If you use some special exclusions dependent
on, for example, the User-Agent
header, you must
manually configure an addition to the Vary
header
to alert proxies of the additional restrictions. For example,
in a typical configuration where the addition of the DEFLATE
filter depends on the User-Agent
, you should add:
If your decision about compression depends on other information
than request headers (e.g. HTTP version), you have to set the
Vary
header to the value *
. This prevents
compliant proxies from caching entirely.
The
If you want to extract more accurate values from your logs, you can use the type argument to specify the type of data left as note for logging. type can be one of:
Input
Output
Ratio
output/input * 100
)
in the note. This is the default, if the type argument
is omitted.Thus you may log it this way:
The
The
The
The
The value must between 1 (less compression) and 9 (more compression).