Compressed Content Encoding

Overview

The API Gateway supports HTTP content encoding for the gzip and deflate compressed content encodings. This enables the API Gateway to compress files and deliver them to clients (for example, web browsers) and to back-end servers. For example, HTML, text, and XML files can be compressed to approximately 20% to 30% of their original size, thereby saving on server traffic. Compressing files causes a slightly higher load on the server, but this is compensated by a significant decrease in client connection times to the server. For example, a client that takes six seconds to download an uncompressed XML file might only take two seconds for a compressed version of the same file.

In the Policy Studio, an Input Encodings list specifies the content encodings that the API Gateway can accept from peers, and an Output Encodings list specifies the content encodings that the API Gateway can apply to outgoing messages. You can configure these settings globally, per remote host, or per listening interface.

Encoding of HTTP Responses

Content encoding of HTTP responses is negotiated using the Accept-Encoding HTTP request header. This enables a client to indicate its willingness to receive a particular encoding in this header. The server can then choose to encode the response with one of these client-supported encodings, and indicate this with the Content-Encoding header.

When the API Gateway is acting as a client communicating with a server, it uses the currently configured Input Encodings list to format the Accept-Encoding header sent to the server, thereby requesting the server to apply one of these encodings to it. If the server decides to apply one of these encodings, the API Gateway automatically inflates the compressed response when it is received.

When acting as a server, the API Gateway selects an output encoding from the intersection of what the client specified in its Accept-Encoding header, and the currently configured Output Encodings, and applies that encoding to the response.

Encoding of HTTP Requests

Because a request arrives unsolicited from a client to a server, there is not normally a chance to negotiate the server's ability to process any optional features, so the automatic negotiation provided by the Accept-Encoding header is not available.

When acting as a client, the API Gateway selects the first configured encoding from the Output Encodings list to encode its request to the server. If the server fails to accept this encoding, it most likely responds with an HTTP 415 error, and the API Gateway treats this as a general HTTP error. Therefore, if the server is unable to accept content encodings, the API Gateway must be configured not to send them to that particular server.

By default, the API Gateway always accepts any supported encoding from clients, regardless of settings. For example, if a client sends gzipped content, the API Gateway inflates it regardless of configured settings.

Delimiting the End of an HTTP Message

HTTP sessions can encode a number of request/response pairs. The rules for delimiting the end of each message and the start of the next one are well defined, but complex due to requirements for historical compatibility, and poor support from HTTP entities.

HTTP Requests

There are two ways to delimit the end of an HTTP request:

  • A Content-Length header in the request indicates to the server the exact length of the payload entity following the HTTP headers, and can be used by the receiving server to locate the end of that entity.

  • Alternatively, an HTTP/1.1 server should accept chunked transfer encoding, which precedes each chunk of the entity with a length, until a zero-length chunk indicates the end.

The benefit of using chunked transfer encoding is that the client does not need to know the length of the transmitted entity when it sends HTTP request headers (unlike when inserting a Content-Length header). Because the API Gateway compresses the requests on the fly, it is prohibitively expensive to calculate the content length before compressing the body. As a result, outbound content encoding is only supported when talking to HTTP/1.1 servers that support chunked transfer encoding.

[Note] Note

All HTTP/1.1 servers are required to support chunked transfer encoding, but unfortunately some do not, so you can use Remote Host settings to configure whether a destination is capable of supporting the chunked encoding in HTTP/1.1, regardless of its advertised HTTP protocol version. For more details, see the topic on Configure remote host settings.

HTTP Responses

For HTTP responses, the server has three options for delimiting the end of the entity. The two mentioned above, and also the ability to close the HTTP connection after the response is transmitted. The receiving client can then infer that the entire message has been received due to the normal end of the TCP/IP session. When content encoding responses, the API Gateway avoids using Content-Length headers in the response, and uses chunked encoding or TCP/IP connection closure to indicate the end of the response. This means that content encoding of responses is supported for HTTP/1.0 or HTTP/1.1 clients.

Configuring Content Encoding

In the Policy Studio, you can configure HTTP content encodings in the Content Encodings dialog. You can configure the following settings globally per API Gateway instance, per remote host, or per listening interface:

Input Encodings Specifies the content encodings that the API Gateway can accept from peers.
Output Encodings Specifies the content encodings that the API Gateway can apply to outgoing messages.


The available content encodings include gzip and deflate. By default, the content encodings configured in the Default Settings are used, which apply at the API Gateway instance level. The default is no content encodings. You can also override this settings at the HTTP interface and Remote Host levels.

Configuring Content Encodings

To configure content encodings, perform the following steps in the Content Encodings dialog:

  1. Deselect the Use Default setting.

  2. Select the content encoding(s) that you wish to configure in the Available Content Encodings list on the left.

  3. Click the > or >> button to move the content encoding(s) to the Content Encodings list on the right, which displays the active settings. You can also double-click a content encoding to move it to the right or left.

  4. Click OK. This displays the configured encoding(s) in the Input Encodings or Output Encodings field (for example, gzip, deflate).

Configuring No Content Encodings

Alternatively, to configure no content encodings, deselect the Use Default setting, and click OK. This displays None in the Input Encodings or Output Encodings field.

[Note] Note

You can select the Use Default setting to switch to the Default Settings without losing your original content encoding selection.

Further Information

For more details on the different levels at which you can configure content encodings in the Policy Studio, see the following topics:

For more details on HTTP content encoding, see HTTP RFC 2616:

http://www.w3.org/Protocols/rfc2616/rfc2616.html