z/TPF HTTP server - data compression

The z/TPF HTTP server supports compression of the entity body for the server responses by using the zlib software library.

If you enable the z/TPF HTTP server to compress the size of HTTP response messages, the amount of time that the server needs to send the response is decreased because of the reduced network bandwidth and the increased throughput. For TLS enabled servers, the amount of encrypted data is reduced by compressing the responses, which results in reduced processing time for the responses.

The z/TPF HTTP server supports the gzip and deflate compression options that are provided by the zlib software library. Data compression is not supported for HTTP 1.0 protocol sessions.
  • If your z/TPF system is running on an IBM® z15® or later processor, you can use hardware or software compression, which depends on the value of the COMPSIZEHW and COMPSIZESW parameters that you specified in the z/TPF HTTP server configuration file and the size of the body.
    • If you set the COMPSIZEHW parameter to 0, hardware compression is disabled.
    • If you set the COMPSIZESW parameter to 0, software compression is disabled.
    • If you specify valid values for both parameters, hardware compression is used.

    When the size of the server responses decreases, the compression performance tends to decrease. You can specify the COMPSIZEHW and COMPSIZESW parameters to control the minimum size that the body of a response must be for the system to compress the body in hardware or software.

  • If your z/TPF system is running on a processor that is older than IBM z15, only software compression is available.
The HTTP client requests compression of the entity body that is returned by the z/TPF HTTP server by including an Accept-Encoding: header in the HTTP request. When the client specifies compression options in the header, the client uses a quality value up to 3 decimal places, in the range 0 - 1, to indicate the preference level for each compression option of the client. The client can use the following settings in the Accept-Encoding: header as needed:
  • The client can specify the gzip and deflate compression options.
  • If the client does not expect data compression in certain conditions, it can specify the identity encoding value.
  • If the client accepts all compression options, it can specify an asterisk (*).
When the z/TPF HTTP server receives the Accept-Encoding: header from the client, the server parses the header and determines whether the body of the response can be compressed and which compression option to use.
  • If the client indicates its preference for a specific compression option with the quality values, the server chooses the compression option that has the highest quality value.
  • If the client has no preference for a specific compression option, the server chooses the first compression option that is specified by the COMP parameter in the server configuration file.
Then, the server includes the option in a Content-Encoding: header that is sent back to the client in the response.

If the server cannot compress the data as requested by the client, the server includes the identity encoding value in the Content-Encoding: header unless the Accept-Encoding: header indicates that the identity encoding value is not acceptable to the client. In that case, the server responds with a 406 status code instead of a Content-Encoding: header.

If the HTTP server application includes a Content-Encoding: header in its response, the z/TPF HTTP server assumes that the application already compressed the data or does not want the data to be compressed, and the server does not conduct any additional compression. For example, the application might determine that the body that is sent back to the client will not compress well. In that case, the application would add a Content-Encoding: header with the identity encoding value to prevent the z/TPF HTTP server from attempting to compress the body.

Upon receiving the data, the HTTP client can read the Content-Encoding: header to determine whether the body of the response was compressed and can be decompressed by using the specified compression option in the header, if necessary.

In the following examples, an HTTP client sends different Accept-Encoding: headers to a z/TPF HTTP server and receives different Content-Encoding: headers in response.
#Server HTTPS443 configures in its server configuration file:
.
.
.
COMP-gzip,deflate
COMPSIZEHW-4096
COMPSIZESW-4096                         

HTTP client                                                                                      HTTP server HTTPS443
Accept-Encoding: deflate; q=1, gzip; q=1------------------------------------>
                                                               <---------------------------------Content-Encoding: gzip                  
Accept-Encoding: deflate; q=1.0, gzip; q=0.5-------------------------------->
                                                               <---------------------------------Content-Encoding: deflate                                               
Accept-Encoding: identity; q=1.0, gzip; q=0, deflate; q=0------------------->
                                                               <---------------------------------Content-Encoding: identity