Mod deflate » History » Revision 42
mod_deflate (since lighttpd 1.4.42) enables output compression of responses. (Content-Encoding)
Output compression reduces the network load and can improve the overall throughput of the webserver. All major http-clients support compression by announcing it in the Accept-Encoding header. This is used to negotiate the most suitable compression method. We support deflate, gzip, bzip2, brotli (since 1.4.56), and zstd (since 1.4.59).
deflate (RFC1950, RFC1951) and gzip (RFC1952) depend on zlib.
brotli (RFC7932) is supported in most popular browsers.
bzip2 is only supported by lynx and some other console text-browsers, and is no longer recommended; brotli or gzip should be preferred.
Since lighttpd 1.4.56, mod_deflate subsumes and replaces mod_compress. mod_deflate can compress static and dynamic responses, while mod_compress could compress only static files.
deflate.cache-dir (since 1.4.56) is the location under which to store cache of compressed files.
deflate.allowed-encodings lists the encodings from which the server will select. Since lighttpd 1.4.60, the ordering of this list is preserved and the server selects the first encoding from this list which matches a value in the client request Accept header.
deflate.max-compress-size is the largest response size that will be compressed.
deflate.min-compress-size is the smallest response size that will be compressed.
deflate.max-loadavg is max system loadavg before bypassing compression (since 1.4.43)
deflate.params configures encoder-specific tunables. It is strongly recommended to omit
deflate.params and to use lighttpd defaults unless you test your changes for positive effect. (FYI: the parameters are named to directly map to the names in the C headers of the encoder libraries)
deflate.compression-level (deprecated) is compression level or quality tuning for the underlying compressor. (deprecated; use deflate.params (since 1.4.60) for encoder-specific values)
man gzip (1..9);
man bzip2 (1..9);
man -s 3brotli encode.h (0..11)
Lighttpd does not automatically purge old/stale cache entries. You are required to handle this through, for example, a scheduled cron job that deletes files older than 10 days:
find /path/to/deflate/cache -type f -mtime +10 | xargs -r rm. The
deflate.cache-dir directory is organized using your URL structure, so you can purge specific paths on different schedules according to your needs.
For dynamic responses, you must purge cached responses from the cache according to your freshness criteria.
mod_deflate currently does not stream compressed content in chunks. This affects very large dynamic responses, or dynamic responses sent in chunks with large time lapses between chunks. If the entire response is not ready when the response header is sent, mod_deflate does not compress the response. (e.g. dynamic response from backend and
server.stream-response-body is set > 0) While mod_deflate does not handle this use case, the backend producing the streaming response is able to apply an appropriate Content-Encoding itself (instead of mod_deflate).
deflate.cache-dir, if set, contains cached output of static files, but does not cache dynamic responses unless the response contains an ETag response header. (dynamic responses, if eligible, are still compressed by mod_deflate before the response is sent to the client.) The same limitation applies to static files if you have disabled ETags (
static-file.etags = "false").
mod_deflate must be listed after mod_setenv in
server.modules if mod_setenv might be used to force setting "Content-Encoding" response header.