You can now configure Open Liberty (18.104.22.168+) to compress HTTP responses. Compressing the sizes of HTTP responses reduces bandwidth which, in turn, decreases the time taken for HTTP clients to get responses. Open Liberty first determines whether the response should be compressed then, if so, checks whether there is an encoding algorithm to perform the compression that is supported by the HTTP client.
Determining whether a response should be compressed
When Open Liberty is configured to compress HTTP responses, it first determines whether it should compress a response by checking the headers in the response:
If the response is not already encoded, it will be considered for compression. If the response is already encoded, no further attempts are made to encode the body.
If the body of the response is
2048bytes or larger, it can be compressed. If it is smaller than
2048bytes, it is too small to benefit from compression and no attempt will be made to compress it.
If the type of content in the response body is in the list of types configured in the Open Liberty server as being valid candidates for compression, it can be compressed. Otherwise, no attempt will be made to compress it.
If Open Liberty determines that the response should be compressed, it then verifies whether there is an acceptable algorithm available to compress it.
Verifying whether a response can be compressed
The Open Liberty server can use the
identity encoding algorithms to compress responses before returning them to the HTTP client that made the request. However, an HTTP client does not necessarily support all these encoding algorithms, so the client can indicate which algorithms it supports and even which algorithm it prefers to be used.
Open Liberty chooses which algorithm to use according to the following criteria, which it evaluates in order until an encoding algorithm is identified that is supported by both the HTTP client and the Open Liberty server:
The value of the
The value for this header in the response indicates the desired encoding algorithm.
The server’s preferred algorithm
A preferred algorithm can be configured in the Open Liberty server using the
serverPreferredAlgorithmattribute. The value indicated by this attribute is used as long as the
Accept-Encodingheader in the HTTP request indicates that this algorithm is supported by the client, regardless of whether the client has indicated in the
Accept-Encodingheader that it prefers other algorithms more.
The HTTP client’s preferred algorithm
The HTTP client can indicate which algorithms are supported and its preferred algorithms in the
Accept-Encodingheader of the HTTP request. The
Accept-Encodingheader specifies which algorithms the HTTP client supports or does not support, and can also indicate order of preference (its quality; from
0.000 - 1.000, where
0.000means the algorithm is not supported by the client) for each encoding algorithm.
The encoding algorithms listed in the
Accept-Encodingheader are sorted in descending order by the server and each value is evaluated until a valid encoding is found. The highest ranked valid algorithm is chosen. If the
gzipalgorithm is tied among the highest ranked, it is chosen as the algorithm to use. If there are no explicitly named encoding algorithms, and an asterisk (
*) is used,
gzipis used if possible. If
gzipcannot be used,
deflateis used. If both are declared as unsupported by means of a quality value of
0.000, no content encoding algorithm is chosen.
For example, assuming the
$WSZIPheader and the server’s preferred algorithm are not specified:
The HTTP client can specify the preferred encoding algorithm as
gzipby giving it the highest quality value:
Accept-Encoding: deflate;q=0.5, gzip;q=1.0
The HTTP client can specify multiple encoding algorithms with the highest quality value. In such cases, the server picks the
gzipalgorithm if possible:
Accept-Encoding: deflate;q=1.0, gzip;q=1.0
The HTTP client may also indicate all encodings are supported. As the
gzipalgorithm is supported, the server chooses it:
The HTTP client can specify the
gzipalgorithm is not supported. In this case, the
deflatealgorithm is used instead.
Accept-Encoding: gzip;q=0, *
The HTTP client can specify it does not support either the
deflatealgorithms. In this case, no compression algorithm will be chosen.
Accept-Encoding: gzip;q=0, deflate;q=0, *
If an appropriate encoding algorithm is not found, or if the encoding algorithm is
identity, no compression is attempted.
Additionally, as the
Accept-Encoding header influences the Open Liberty’s process for selecting and representing the response, a
Vary header with the value of
Accept-Encoding is also added to the response. This header informs cache intermediaries that this response’s content may change in a subsequent request if the
Accept-Encoding header changes. The header is added regardless of whether the response is ultimately compressed or not, as long as compression is configured in the
Try it out
To use HTTP response compression, configure the
server.xml with a new element called
<compression>. You can configure compression for individual HTTP endpoints or for all endpoints at once. See Compression Options (compression) for more details of the attributes.
Configuring compression for individual HTTP endpoints:
<httpEndpoint id="defaultHttpEndpoint" httpPort="9080" httpsPort="9443"> <compression serverPreferredAlgorithm="deflate|gzip|x-gzip|zlib|identity|none"> <types>+application/*</types> <types>-text/plain</types> </compression> </httpEndpoint>
Configuring compression for all HTTP endpoints:
<httpEndpoint id="defaultHttpEndpoint" httpPort="9080" httpsPort="9443" compressionRef="myCompressionID"> </httpEndpoint> <httpEndpoint id="otherHttpEndpoint" httpPort="9081" httpsPort="9444" compressionRef="myCompressionID"> </httpEndpoint> <compression id="myCompressionID" serverPreferredAlgorithm="deflate|gzip|x-gzip|zlib|identity|none"> <types>+application/*</types> <types>-text/plain</types> </compression>
types attribute in the examples adds all application content types and removes the
text/plain content type from the
With this new
<compression> configuration option, you can configure Open Liberty to compress HTTP responses before returning them to clients. This reduces bandwidth and the time taken for HTTP clients to get responses.