HTTP Response Compression
When Integration Server is working as an HTTP client and the client is expecting a large set of data as a response from the HTTP server, then client can request the server to compress the data before responding back to the client. When client sends the HTTP request with the Accept-Encoding HTTP header as gzip or deflate, this indicates which compression scheme the server can use to compress the response payload.
When Integration Server is acting as an HTTP server and supports the HTTP compression where the server configuration parameter, watt.server.http.response.supportCompression is set as true; while sending the HTTP response, Integration Server defines the Content-Encoding HTTP header as gzip or deflate. This indicates which compression scheme the server has used to compress the data.
Integration Server acting as an HTTP client receives the compressed response from the server and user can use the pub.compress:decompressData service to decompress the data. The service uses the same compression scheme mentioned in the HTTP header to decompress the data.
If the HTTP request contains multiple algorithm schemes in Accept-Encoding, the HTTP server uses the first valid compression scheme mentioned. Consider the following examples of HTTP headers containing multiple algorithm schemes.
Accept-Encoding: deflate, gzip
In this case, Integration Server uses the deflate compression scheme.
Accept-Encoding: <UnSupportedType>, gzip
In this case, Integration Server uses the gzip compression scheme.
Accept-Encoding: deflate, <UnSupportedType>
In this case, Integration Server uses the deflate compression scheme.
Accept-Encoding: <UnSupportedType>, <UnSupportedType>
In this case, Integration Server responds with the uncompressed data.
Examples of an HTTP response compression: