Topics

See also

Compression and TLS

Some web applications are vulnerable to an information disclosure
attack when a TLS connection carries deflate compressed data. For more
information, review the details of the "BREACH" family of attacks.

This is a simple configuration that compresses common text-based content types.

Compress only a few types

Compression and TLS

Some web applications are vulnerable to an information disclosure
attack when a TLS connection carries deflate compressed data. For more
information, review the details of the "BREACH" family of attacks.

If you want to restrict the compression to particular MIME types
in general, you may use the AddOutputFilterByType directive. Here is an example of
enabling compression only for the html files of the Apache
documentation:

Note

The mod_deflate module also provides a filter for
inflating/uncompressing a gzip compressed response body. In order to activate
this feature you have to insert the INFLATE filter into
the output filter chain using SetOutputFilter or AddOutputFilter, for example:

The mod_deflate module also provides a filter for
decompressing a gzip compressed request body . In order to activate
this feature you have to insert the DEFLATE filter into
the input filter chain using SetInputFilter or AddInputFilter, for example:

<Location /dav-area>
SetInputFilter DEFLATE
</Location>

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.

Note on Content-Length

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 mod_deflate module sends a 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:

Header append Vary User-Agent

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 DeflateFilterNote directive
specifies that a note about compression ratios should be attached
to the request. The name of the note is the value specified for
the directive. You can use that note for statistical purposes by
adding the value to your access log.

The DeflateInflateRatioLimit directive
specifies the maximum ratio of deflated to inflated size of an
inflated request body. This ratio is checked as the body is
streamed in, and if crossed more than
DeflateInflateRatioBurst times, the request
will be terminated.

Notice:This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.