This topic provides information on file compression and how output from your server is compressed before being sent to the client over the network.
Compressed output is transferred to requesting client browsers at a higher rate of speed than noncompressed output. This decreases the amount of data that the server needs to send over the network and improves network performance and response times.
Compression and decompression is implemented by the DEFLATE filter, located in Module mod_deflate. The DEFLATE filter is always inserted after RESOURCE filters like PHP or SSI. It never touches internal subrequests. See Apache HTTP Server Version 2.0 Documentation for additional information and examples on configuring the Apache server to use compression.
When the DEFLATE filter is used, a LoadModule is required in order to recognize the associated directives.
LoadModule deflate_module /QSYS.LIB/QHTTPSVR.LIB/QZSRCORE.SRVPGM
Files can be compressed by the server before output to the client. The server can be configured to only compress files which are located in specific containers or globally. Directive SetOutputFilter enables compression for files in the container where it is placed. For example:
SetOutputFilter DEFLATE
Files being compressed can also be restricted to specific MIME types. In order to configure the server to restrict compression based on MIME types, the AddOutputFilterByType directive should be used. For example, to enable compression only for the HTML files located in a specific directory:
<Directory "/your-server-root/htdocs"> AddOutputFilterByType DEFLATE text/html </Directory>
Compressed files require decompression before they can be used. A filter is necessary for decompressing a GZIP compressed request body. The DEFLATE filter is required in the input filter chain and is set by using the SetInputFilter or the AddInputFilter. For example:
<Location /dav-area> SetInputFilter DEFLATE </Location>
Requests containing a Content-Encoding: GZIP header are automatically decompressed. The Content-Length header specifies the length of incoming data from the client, not the byte count of the decompressed data stream. The actual length of the data will be greater than the Content-Length header indicates after the decompression has been done.
Proxy servers receive a Vary: Accept-Encoding HTTP response header to identify that a cached response should be sent only to clients that send the appropriate Accept-Encoding request header. The response header prevents compressed content from being sent to a client that cannot support it.
Dependencies on special exclusions, for example, the User-Agent header, can be specified with an addition to the Vary header. The Vary header must be manually configured in order to alert proxies of the additional restrictions. For example, where the addition of the DEFLATE filter depends on the User-Agent, the following Very header should be added:
Header append Vary User-Agent
If compression depends on information other than request headers, set the Vary header with a value of "*". The "*" prevents compliant proxies from caching entirely. For example:
Header set Vary *