HTTP Request Compression
When Integration Server is acting as an HTTP client and if user has a large set of data to compress, then user can use the pub.compress:compressData service to compress the data. While executing the service, user can define any supported compression scheme to compress the data. When client sends the HTTP request, it must define the Content-Encoding HTTP header as gzip or deflate. This indicates which compression scheme the client has used to compress the request payload.
When Integration Server is acting as an HTTP server and supports the HTTP compression where the server configuration parameter, watt.server.http.request.supportCompression is set as true; after receiving the HTTP request, Integration Server uses the same compression scheme mentioned in Content-Encoding to decompress the data before sending the data for further processing.
If the HTTP request contains multiple algorithm schemes in Content-Encoding, the HTTP server uses the first valid compression scheme mentioned. Consider the following examples of HTTP headers containing multiple algorithm schemes.
Content-Encoding: deflate, gzip
In this case, Integration Server uses the deflate compression scheme.
Content-Encoding: <UnSupportedType>, gzip
In this case, Integration Server uses the gzip compression scheme.
Content-Encoding: deflate, <UnSupportedType>
In this case, Integration Server uses the deflate compression scheme.
Content-Encoding: <UnSupportedType>, <UnSupportedType>
In this case, Integration Server ignores the HTTP request.
Example of an HTTP request compression: