compression algo <algorithm> ...

compression type <mime type> ...

compression offload

Enable HTTP compression.

可用位置 :

参数:

• algo is followed by the list of supported compression algorithms.
• type is followed by the list of MIME types that will be compressed.
• offload makes haproxy work as a compression offloader only (see notes).

The currently supported algorithms are :

• identity this is mostly for debugging, and it was useful for developing the compression feature. Identity does not apply any change on data.

• gzip applies gzip compression. This setting is only available when support for zlib or libslz was built in.

• deflate same as "gzip", but with deflate algorithm and zlib format. Note that this algorithm has ambiguous support on many browsers and no support at all from recent ones. It is strongly recommended not to use it for anything else than experimentation. This setting is only available when support for zlib or libslz was built in.

• raw-deflate same as "deflate" without the zlib wrapper, and used as an alternative when the browser wants "deflate". All major browsers understand it and despite violating the standards, it is known to work better than "deflate", at least on MSIE and some versions of Safari. Do not use it in conjunction with "deflate", use either one or the other since both react to the same Accept-Encoding token. This setting is only available when support for zlib or libslz was built in.

Compression will be activated depending on the Accept-Encoding request header. With identity, it does not take care of that header.

If backend servers support HTTP compression, these directives will be no-op: haproxy will see the compressed response and will not compress again. If backend servers do not support HTTP compression and there is Accept-Encoding header in request, haproxy will compress the matching response.

The "offload" setting makes haproxy remove the Accept-Encoding header to prevent backend servers from compressing responses. It is strongly recommended not to do this because this means that all the compression work will be done on the single point where haproxy is located. However in some deployment scenarios, haproxy may be installed in front of a buggy gateway with broken HTTP compression implementation which can't be turned off.

In that case haproxy can be used to prevent that gateway from emitting invalid payloads. In this case, simply removing the header in the configuration does not work because it applies before the header is parsed, so that prevents haproxy from compressing. The "offload" setting should then be used for such scenarios. Note: for now, the "offload" setting is ignored when set in a defaults section.

Compression is disabled when:

• the request does not advertise a supported compression algorithm in the "Accept-Encoding" header
• the response message is not HTTP/1.1
• HTTP status code is not 200
• response header "Transfer-Encoding" contains "chunked" (Temporary Workaround)
• response contain neither a "Content-Length" header nor a "Transfer-Encoding" whose last value is "chunked"
• response contains a "Content-Type" header whose first value starts with "multipart"
• the response contains the "no-transform" value in the "Cache-control" header
• User-Agent matches "Mozilla/4" unless it is MSIE 6 with XP SP2, or MSIE 7 and later
• The response contains a "Content-Encoding" header, indicating that the response is already compressed (see compression offload)

Note: The compression does not rewrite Etag headers, and does not emit the Warning header.

Examples :

compression algo gzip
compression type text/html text/plain