HTTP Content Compression

The Virtual Traffic Manager can compress an HTTP response when it sends it to the remote client. This can reduce your bandwidth usage, and speed up the delivery of large Web pages to clients with slow connections.

Not all browsers can receive compressed content; those which do specify this in the HTTP request headers. The Virtual Traffic Manager compresses content only for those browsers which are able to decompress it.

Some Web servers are also able to compress content, so it may be more efficient to spread this work across your Web servers instead of using the Virtual Traffic Manager for this purpose. However, enabling compression on both should not cause any problems.

Clicking the Content Compression link on the Virtual Servers > Edit page shows you settings for content compression. You can choose whether to enable compression; which MIME file types to compress; and the size of documents that should be compressed.

If you offer large files for download from your site, it may be sensible to pre-compress them rather than have a server do this each time they are requested.

The Virtual Traffic Manager can compress HTTP responses if the request contains an “Accept-Encoding: gzip” header. The Virtual Traffic Manager checks the request before and after running TrafficScript rules; if the header is present in either case, the Virtual Traffic Manager will compress the content.

For example, you can configure a rule to remove the Accept-Encoding header from a request. In this case, the back-end server will never send a compressed response (because it never sees the header), but the Virtual Traffic Manager will compress the response from the back-end server if the remote client supports compression. This technique can be used to offload all compression tasks from the back-end server onto the Virtual Traffic Manager.

You can also control whether the Virtual Traffic Manager compresses content using the http.compress.enable() and http.compress.disable() TrafficScript functions.