Overview
|
The Enterprise Gateway supports HTTP content encoding for the gzip and deflate
compressed content encodings. This enables the Enterprise 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 Enterprise Gateway can accept from peers, and an Output Encodings list specifies the
content encodings that the Enterprise 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 Enterprise 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 Enterprise Gateway automatically inflates the
compressed response when it is received.
When acting as a server, the Enterprise 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 Enterprise 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
Enterprise Gateway treats this as a general HTTP error. Therefore, if the server is unable to accept
content encodings, the Enterprise Gateway must be configured not to send them to that particular server.
By default, the Enterprise Gateway always accepts any supported encoding from clients, regardless of
settings. For example, if a client sends gzipped content, the Enterprise 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 Enterprise 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:
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 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 Enterprise 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 remote host, or per listening interface:
Input Encodings |
Specifies the content encodings that the Enterprise Gateway can accept from
peers. |
Output Encodings |
Specifies the content encodings that the Enterprise 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. You can
override this setting at the HTTP interface and Remote Host levels.
Configuring Content Encodings
To configure content encodings, perform the following steps in the Content
Encodings dialog:
- Unselect the Use Default setting.
- Select the content encoding(s) that you wish to configure in the
Available Content Encodings list on the left.
- Click the > or >> button to move
the content encoding(s) to the Content Encodings list on
the right. You can also double-click a content encoding to move it to
the right or left.
- 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, unselect the Use Default
setting, and click OK. This displays None in the Input
Encodings or Output Encodings field.
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
|
|