What is it?

The IWS client transport library is an HTTP client library. Previously, the library did not attempt to decompress HTTP response payloads that were returned with a Content-Encoding header. The Content-Encoding header indicates the encoding applied to the response payload and identifies the compression algorithm used to represent the message body.

Support has been added to enable the IWS client transport library to automatically decompress HTTP response payloads encoded using the gzip (RFC 1952) or deflate (RFC 1950) compression formats.

Previous Behavior
When a server returned an HTTP response that included a Content-Encoding header, the IWS client transport library handled the response based on the payload content type and the payload response conversion option (UTF-8 to job CCSID).

Binary Response Payloads
If the response payload content type is binary and the Content-Encoding header indicates compression:

• By default, no decompression is performed, and the raw compressed payload is returned to the application.
• If the application explicitly indicates that data conversion should be performed, the data was converted without going to the process of decompressing the data, which corrupted the data received by the application. 

Examples of binary content types include:

• application/pdf
• image/jpeg
• application/octet-stream

Textual Response Payloads
If the response payload content type was textual and the Content-Encoding header indicates compression:

• If data conversion is enabled (by default it is), conversion was performed which corrupted the data received by the application. 
• If data conversion is disabled, the payload was returned unchanged, the application received the raw compressed data.

Examples of textual content types include:

• application/json
• application/xml
• text/plain

New Decompression Support
When making an HTTP request, the IWS client transport library will work as before and will not add an Accept-Encoding HTTP header advertising support for the gzip and deflate compression formats.  However, some servers will not send compressed data unless the HTTP header with a value of "Accept-Encoding: gzip, deflate" is received.  Thus, it may be a good idea to set the header within your application if dealing with large payloads. 

If the server responds with a Content-Encoding header indicating that the response payload is compressed, the IWS client transport library can transparently decompress the payload before returning it to the application. The behavior depends on the response payload content type and the value of the decompression option (AXISC_PROPERTY_DECOMPRESS_PAYLOAD). The decompression option can be set to 'true' or 'false'.  By default, the decompression option is set to 'false'.

Binary Response Payloads
If the response payload content type is binary and the Content-Encoding header indicates compression:

• By default, no decompression is performed, and the raw compressed payload is returned to the application.
• If the application explicitly indicates that data conversion should be performed then the payload is decompressed - independent of what the decompression option is set to - and the data is converted before being returned to the application.  
• If the decompression option is set to 'true', the payload is decompressed before being returned to the application.

Textual Response Payloads
If the response payload content type is textual and the Content-Encoding header indicates compression:

• If data conversion is enabled (by default it is), the payload is decompressed and then converted before being returned to the application.
• If data conversion is disabled, the application will receive the raw compressed payload unchanged, unless the decompression option is set to 'true', in which case the payload will be decompressed before being returned to the application.

Error Handling
If the IWS client transport library determines that decompression is required and the Content-Encoding header specifies a compression format that is not supported, an error is returned.

If the response does not include a Content-Encoding header, no decompression is attempted.

Why use it?

Availability

The support is enabled in the following PTFs:
V7R6M0 SJ08780
V7R5M0 SJ08781
V7R4M0 SJ08782
V7R3M0 SJ08783