The DEFLATE output filter that allows output from
your server to be compressed before being sent to the client over
the network.
The gzip encoding is the only one supported to ensure complete compatibility
with old browser implementations. The deflate encoding is not supported,
please check the zlib's documentation
for a complete explanation.
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.
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.
Compression is implemented by the DEFLATE
filter. The following directive
will enable compression for documents in the container where it
is placed:
If you want to restrict the compression to particular MIME types
in general, you may use the
DEFLATE filter is always inserted after RESOURCE
filters like PHP or SSI. It never touches internal subrequests.
force-gzip,
set via The INFLATE filter into
the output filter chain using
This Example will uncompress gzip'ed output from example.com, so other filters can do further processing with it.
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.
Since
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 a note for logging. type can be one of:
InputOutputRatiooutput/input * 100)
in the note. This is the default, if the type argument
is omitted.Thus you may log it this way:
The Transfer-Encoding set to Chunked), with the
side effect of not setting any Content-Length HTTP header. This is particularly
important when httpd works behind reverse caching proxies or when httpd is configured with
Content-Length header might not be cached.
The
The
The
The value must between 1 (less compression) and 9 (more compression).
The
Append the compression method onto the end of the ETag, causing compressed and uncompressed representations to have unique ETags. This has been the default since 2.4.0, but prevents serving "HTTP Not Modified" (304) responses to conditional requests for compressed content.
Don't change the ETag on a compressed response. This was the default prior to 2.4.0, but does not satisfy the HTTP/1.1 property that all representations of the same resource have unique ETags.
Remove the ETag header from compressed responses. This prevents some conditional requests from being possible, but avoids the shortcomings of the preceding options.
The
The
The