The DEFLATE output filter that allows output from
your server to be compressed before being sent to the client over
the network.
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
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