 |  | | |
| ||||||
 |  |  |  | | ||||||
 | ||||||||||
 |  | choose a product: | | |
| | httpZip & Compression Tools Evaluation Guide There are three initial questions most users have when evaluating an HTTP compression tool like httpZip:
In order to receive compressed content, the browser must inform the server that it is capable of decoding such content. It does this by sending the Accept-Encoding HTTP request header, specifying which compression algorithms it can handle: gzip or deflate or both.When the Accept-Encoding header is present, the response becomes a candidate for compression. However, depending on a variety of other conditions, it still might not be safe or worthwhile to compress this particular response, or to do so at the maximum level. Therefore, serious compression tools like httpZip employ several additional tests. In the case of httpZip, these tests are based on a variety of configuration settings:
All of these httpZip configuration settings can be inspected or changed in the Advanced Configuration Preferences section of the httpZip property sheet. back to top  How can I tell when compression is happening? Our free online Compress Check tool is a good place to start. While you could trust httpZip's (or some other product's) own reporting mechanism, a better way to answer both of these questions is to look at the conversation between a browser and a server at the HTTP level. Since browsers generally do not display protocol-level data, you will need a tool that lets you see what the browser usually keeps hidden. Fortunately, there are a number of options here:
In common with other compression tools, httpZip adds a Content-Encoding header to compressed responses, which lets the browser know that it must decompress what follows using a particular algorithm: back to top How can I tell how much compression I am getting? While httpZip and some of its competitors have logging and reporting mechanisms that will give this information, it is always a good idea to be able to verify gains from compression independently. Fortunately, this is easy to do once you are able to inspect the HTTP traffic between client and server. The Content-Length header gives the length of the HTTP message's entity body in bytes. This header is always present in compressed responses, and is usually present in uncompressed responses as well. In a compressed response, it should have a value smaller than when the same file was requested without compression (either because compression was not enabled on the server-side, or because the Accept-Encoding header was not sent in that particular request): Naturally, for a complete evaluation one would also want to test the behavior of different HTTP compression tools under load and stress, in order to determine whether the compression savings seen in single-request testing like this would hold up when the Web server is handling the traffic expected in the production environment. We hope that your evaluation of httpZip, the leading compression tool for Microsoft IIS Web servers, goes very well -- let us know where we can help! back to top | | 
| | |
 | |||||
 | |||||
|
| ||||
