Compression filter

Purpose

Compression is the process of reducing data size for storage or transmission. In addition to compressing data, you may need to expand or decompress data to its original form. This filter can accomplish these tasks for you. The Compression filter operates as a wrapper for the PlanetJ CompressingFilter. 

General filter information

Filter name: compression

Filter configuration: compression.cfg.xml

Released: version 2.7.0

Prerequisites

Required headers: The Compression filter has no required request headers.

Required preceding filters: The Compression filter has no required preceding filters.

Standard filter order:  When you set the order of Repose filters, place the Content Normalization filter before any filter that looks at the request body.

Basic compression configuration

Configure the Compression filter by editing the compression.cfg.xml.

Configurable parameters

XML schema definition

Example configuration

The compression.cfg.xml file contains the following elements and attributes. Add the filter to your Repose deployment through the system model configuration.

ElementAttribute

Required/

Optional

Description
<content-compression>-RequiredSpecifies the sub-elements and attributes to define your compression configuration.
<compression>-RequiredSpecifies the compression configuration.

compression-threshold

Optional

Specifies the minimum size, in bytes, of the response that will be compressed. If the response size is less than the specified compression-threshold size, then the response is not compressed and is sent to the client unmodified. If there are 0 bytes, compression always begins immediately. The default size is 1024 bytes.

exclude-content-types

Optional

If specified, the value is treated as a space separated list of content-type's (e.g. text/html text/xml). The filter will not attempt to compress responses which specify one of these values as its content-type. Since the content-type of the response is not known at the time it is applied, the filter disables compression if after the content-type is set, the filter determines compression is not required.

exclude-user-agent-patterns

Optional

If specified, this filter will not compress responses whose requests have a User-Agent header value that matches one of the regular expressions in this list.

This attribute is DEPRECATED and will be removed in a future release.

include-content-typesOptional

If specified, the value is treated as a space separated list of content-type's (e.g. text/html text/xml). The filter will only attempt to compress responses which specify one of these values as its content-type. Since the content-type of the response is not known at the time it is applied, the filter disables compression if after the content-type is set, the filter determines compression is not required.

include-user-agent-patterns

Optional

If specified, this filter will only compress responses whose requests have a User-Agent header value that matches one of the regular expressions in this list.

This attribute is DEPRECATED and will be removed in a future release.

Configurations that are not included

The following configurations of the CompressingFilter are not exposed through the Repose Configuration.

  • includePathPatterns/excludePathPatterns - Path matching per filter can be configured through the 'uri-regex' attribute of the filter declaration within the sytem-model.cfg.xml file.
  • javaUtilLogger - Filter logs will be printed through the Repose system logs
  • jakartaCommonsLogger - Filter logs will be printed through the Repose system logs

 Supported compressions

Currently the Repose Compression filter supports these compression schemes.

  • gzip
  • x-gzip
  • deflate
  • identity (no compression)

Unsupported compressions

Currently the Repose Compression filter does not support these compression schemes which the CompressingFilter supports.

  • compress
  • x-compress

Preventing XXE injection

The Compression filter can aid with the prevention of XXE injection by decompressing a compressed request body before it passes to the Translation filter. One of the features of the Translation filter is to prevent XXE injection through the request body. Normally, the Translation filter is sufficient unless the API that Repose sits in front of accepts compressed data from their users. The Translation filter cannot comprehend compressed data so a decompressor is needed to mitigate XXE injections through compressed data.

 

Sample system-model.cfg.xml Filter List

With this set up, the Compression filter will decompress the request body (when it receives a compressed request) which will allow the Translation filter to clear the request of any malicious XML entities.

Compression filter error scenario

  • The Compression filter returns a 400 error response code if the request body is not in the format specified in the Content-Encoding header (ZipException) or if the request body terminates in an unexpected manner (EOFException) while decompressing.
  • The Compression filter returns a 500 error response code on any other IOException or ServletException.

Request headers

The Compression filter does not create any request headers.

The Compression filter will remove the "Content-Encoding" and "Accept-Encoding" headers from a request before forwarding the request to the origin service. This feature encapsulates compression within Repose so that the origin service may operate unaware of any compression that occurs.

Compression filter process

Depending on your need, you can configure the Repose Compression filter to either compress, decompress, or pass the request data that it receives from the client before sending it to the origin service. The Compression filter then compresses, decompresses, or passes the response data that it receives from the origin service before sending it back to the client. A typical Compression filter decision flow is summarized in the drawing below:  

  Request/response lifecycle for the compression filter