SP2 HTTP Compression

HTTP compression reduces file size by using algorithms to eliminate redundant data. Most common Web-related file types can safely be compressed. HTTP compression uses the industry standard GZIP and Deflate algorithms, which are built into Windows 2000 Server and later operating systems and Internet Explorer version 4 and later versions. These algorithms compress static files, and optionally perform on-demand compression of dynamically generated responses before sending them over the network. These same algorithms are again used to decompress the static files and dynamic responses on an HTTP 1.1 supported client. A client that is configured to use HTTP 1.1 will request compressed content from a Web server. Web servers indicate in their responses whether they support compression.

HTTP compression in ISA Server is a global HTTP policy setting. It applies to all HTTP traffic that passes through ISA Server to or from a specified network or network object, rather than to traffic handled by a specific rule. HTTP compression is provided by two Web filters:

• Compression Filter. This filter is responsible for compression and decompression of HTTP requests and responses. This filter has a high priority, and is high in the ordered list of Web filters. This is because the filter is responsible for decompression. If you choose to enable inspection of compressed content, decompression must take place before any other Web filters inspect the content.
• Caching Compressed Content Filter. This filter is responsible for caching of compressed content and serving a request from the compressed content in the cache. This filter has the lowest priority, and is low in the ordered list of Web filters, because caching can take place after all other filters have handled the content.

Do not change the default priority and order settings of these filters.

HTTP compression also provides a range compression feature, which is described in Range Compression in this document.

Range Compression

Range compression is the compression of a specific portion of Web content. Range compression is required to support legacy Portable Document Format (PDF) file readers that do not have built-in compression support.

Because Internet Information Services (IIS) does not support range compression, do not allow range compression on the network that includes a server running IIS. However, because ISA Server does support range compression, you may want to enable it between two ISA Server computers.

For example, if you have a Web server in the main office, you would disable range compression on the Internal network for the main office, but enable it on the External network for the main office and for the branch offices, so that range compression takes place between the offices.

By default, ISA Server does not compress a range request. To support compression of range requests, ISA Server uses a new property per network element that indicates if range compression is allowed. If range compression is enabled, ISA Server requests range compression. When receiving a compressed range response, ISA Server always decompresses it. When returning a range response to the client that asked for compression, ISA Server compresses the data before transferring it to the client.

The following diagram describes the compression and range behavior in ISA Server 2004 SP2.

The following describes the compression and range behavior in ISA Server 2004 SP2:

• The client requests range compression.
• The configuration in the branch office does not allow the client to request compression. However, ISA Server in the branch office is configured to request compression and range compression and therefore sends a range compression request to the main office.
• ISA Server in the main office gets the request. Because its client (ISA Server in the branch office) is allowed to request compression, ISA Server sends the request to the Web server. However, because ISA Server in the main office is configured to not allow requests for range compression, the response from the Web server contains the uncompressed range.
• When ISA Server in the main office gets the response, it returns it to ISA Server in the branch office. Because the request from ISA Server in the branch office asked for compression, ISA Server in the main office compresses the data before transferring it to the branch office.
• ISA Server in the branch office receives the response. The response is a compressed range response. ISA Server decompresses it, and transfers it uncompressed to the client in the branch office.

Range compression is not enabled through ISA Server Management. The administrator has to edit the configuration .xml file manually and set the CompressRange flag. The process for doing this is provided in Configuring Minimum Size Packet and Range Compression in this document.

ISA Server Cache and Compression

ISA Server cache and compression work together to provide more efficient serving of compression requests. Note the following about how cache and compression work together:

• Content is cached in one of three formats:
  • Compressed. Content is requested in compressed format and cached in compressed format.
  • Uncompressed. Content is requested in uncompressed format and cached in uncompressed format.
  • Uncompressed and Incompressible. If a client requests compressed content, and it arrives at the cache uncompressed, it is stored in the cache as incompressible. The next time the request for the same compressed content is received, ISA Server recognizes that the content is incompressible, and serves it from the cache uncompressed rather than from the Internet. Content that is inspected is also stored as uncompressed and incompressible.
• After content is cached, it will continue to be served from the cache even if you change the compression status in the cache rule. For example, if you initially enable content inspection of compressed content, that content is stored in the cache as uncompressed and incompressible. ISA Server compresses the content before serving it to the client (if the client requested compressed content). If you disable content inspection, the content will still be served from the cache. In this case, ISA Server will continue to compress the content for clients that requested compressed content, rather than storing compressed content in the cache and serving it to clients. This can affect ISA Server performance in serving the requests. If you want compression configuration changes to be reflected in the cached content, you must first clear the cache.

To clear the cache, disable the cache through ISA Server Management, and then delete the cache storage file, such as Dir1.cdat (the default name of the ISA Server cache file). There is a cache file in the Urlcache folder on each drive that is configured for caching. After you delete the cache file, enable the cache in ISA Server Management.

There is also a sample script that describes how to clear the cache programmatically. For information, see the document Deleting Cache Contents at the Microsoft TechNet Web site.

Content Types and Compression

In general, some Web servers, when responding to a request, do not accurately provide the content type in the response header. For example, a response may include a Microsoft Office PowerPoint 2003 (.ppt) file, but the response header may indicate that the content is plain text. When an Internet Explorer client receives this type of response in compressed format, it cannot interpret the response, and the user will see meaningless characters on the monitor. If the response is received uncompressed, Internet Explorer can interpret it, and the user can open and view the content. However, if the client requests compression, and the Web server replies with uncompressed content, ISA Server compresses the content, and Internet Explorer cannot interpret it. In this case, the client must request uncompressed content (by changing the compression setting in the browser) to view it.

[Topic Last Modified: 12/16/2008]