Using compression with HTTP and SOAP nodes

Background information

The HTTP transport supports the sending of compressed data. Specific HTTP header fields are used to indicate that the data is compressed, and which compression technique was used for the compression. When an HTTP client makes an HTTP request, it can specify that it accepts a compressed response, and also which types of compressed data it accepts. The three compression techniques supported by the HTTP transport are GZIP, deflate, and compress.

The Accept-Encoding field is used in an HTTP request to indicate which encodings are accepted in a response message to the request. This field is used to specify the values of gzip, deflate, compress and identity, which are not case-sensitive. A value of identity indicates that the data must not be compressed. A wildcard of * indicates that any encoding is accepted. The Accept-Encoding field can also be empty, indicating that no encoding is accepted.

The Content-Encoding header field indicates the encoding that is applied to the data and it can contain the tokens of gzip, deflate, and compress, but not identity. When data is compressed for an HTTP message, the Content-Encoding field contains the name of the compression technique that was used, enabling the recipient to identify the compression scheme and correctly decompress the message data.

The TE header field is used in a request header to indicate which extension transfer encodings it will accept in the response. This is similar to the Accept-Encoding field.

The Transfer-Encoding field is similar to the Content-Encoding field, except that it is a property of the message and not of the entity. The Transfer-Encoding field is primarily used to indicate that a response message is chunked. It is possible to receive a Transfer-Encoding header that indicates other transfer encodings such as "chunked, gzip". In this case the gzip applies to the transfer of the data, not the actual data itself.

HTTP compression in IBM Integration Bus

IBM® Integration Bus supports compression and decompression with the HTTP and SOAP nodes using the Accept-Encoding and Content-Encoding fields as follows:

• In a request node, such as an HTTPRequest or SOAPRequest node, if you select the property to allow compressed responses, the broker sets the Accept-Encoding field on the outbound request.
• When compressing a request, the request nodes set the Content-Encoding header field to indicate that the data is compressed. When receiving a response, the request nodes check the Content-Encoding field to determine if the response is compressed. Multiple values in the header field indicate that the data has been compressed more than once using multiple compression functions.
• When receiving a request, the input nodes check the contents of the Content-Encoding field to determine if the contents of the message are compressed. In response and input nodes, a Content-Encoding value of x-gzip is treated as gzip.
• IBM Integration Bus supports only the gzip and deflate compression encodings; the compress encoding is not supported.
• Compression and decompression is handled only through the Accept-Encoding and Content-Encoding header fields; the TE and Transfer-Encoding header fields are not supported.

When compressing a request HTTP message, the node checks the Content-Encoding field to determine if the message data is already compressed. If the data is already compressed in the specified scheme then no further compression is needed. However, if the existing data is already compressed in an encoding that is not specified in the node properties, the node further compresses the compressed bit stream using the encoding specified in the node properties. The value of the Content-Encoding field is updated to indicate the additional encoding applied to the data. For example, a Content-Encoding value of deflate,gzip indicates that the message should be first decompressed using deflate and then further decompressed using gzip.

The HTTP and SOAP nodes do not support quality values in the Accept-Encoding field, which allow a user to specify a preferred weighting of compression types for responses. Any quality values in the Accept-Encoding field are ignored.

Using HTTP compression with the HTTP and SOAP nodes

The request nodes can request and process compressed responses. You can configure the request nodes to indicate that compression in responses is allowed, and the node automatically decompresses a compressed response. The Accepts-Encoding header is set to indicate that GZIP and deflate compression techniques are accepted. If the Accept-Encoding header is already set, the node does not override it.

If the request or the AsyncResponse nodes receive a GZIP or deflate compressed response, it is decompressed and any header indication that the message is compressed is removed. If the nodes receive an invalid compressed response or an unrecognized compression function, an exception is raised indicating that the data could not be decompressed.

The request nodes can also send compressed requests. You can configure the node to specify which compression technique is used for the compressed requests that it sends. The value of the Content-Encoding header is set to indicate the compression that is used. You can override this value in the local environment for an individual message. If you override the local environment with a value that is not recognized by the node, the existing node value for Use compression is used.