HttpZip speeds up Web sites and applications hosted on IIS by safely and efficiently applying standard HTTP compression methods. By replacing the native HTTP compression mechanism that comes with IIS, httpZip is able to provide enhanced control and compatibility for this key Web acceleration technology, as well as numerous additional features not found in IIS native compression.
Installation and Activation
httpZip consists of the following major program components:
- An ISAPI filter (zip_isapi.dll) which is written in fast-executing native code that is loaded by, and implements all httpZip functionality within, the IIS worker process instances (w3wp.exe).
- A 100% managed code graphical user interface called the httpZip Settings Manager (httpZip.exe), which enables users with administrator rights to configure httpZip for any site on the server.
- In Server 2008 deployments only: A pair of managed assemblies (httpZipServer and httpZipClient) that allow authorized users to access httpZip's configuration options both locally and remotely, within the standard IIS user interface (IIS Manager).
The System Requirements for httpZip are as follows:
- A compatible version of IIS and Windows:
- IIS 7.5 / Server 2008 R2 with Service Pack 1
- IIS 7 / Server 2008 with Service Pack 2
- IIS 6 / Server 2003 (all editions) with Service Pack 2
- Compatible hardware:
- x86 (32-bit)
- x64 (64-bit)
- Required runtimes:
- .Net Framework 2.0 (or later)
- Visual C++ 2005 SP1 Runtime
- For best results, IIS 6.0 should be in its default isolation mode (Worker Process Isolation Mode) rather than in IIS 5.0 isolation (compatibility) mode.
- For IIS 7.x / Server 2008 installations, the following IIS Role Service must be installed:
httpZip uses a single installer for both 32-bit and 64-bit installations, on both Server 2003 and Server 2008. The installer determines which type of operating system is in use before installing the appropriate files. In addition, the installer is capable of detecting, and optionally installing, any missing runtime packages required by httpZip.
Depending on the current configuration of your IIS server(s), there are runtime prerequisites that might be missing or out of date when httpZip is installed. The two most common are:
- .Net Framework 2.0 (or better)
- Visual C++ 2005 SP1
When the httpZip installer detects that a runtime prerequisite is missing or out of date, it asks the user if an outbound Internet connection is available. (As a security best practice many production Web servers are not permitted to initiate HTTP connections.) If a connection is available, then the required files will be downloaded automatically. If a connection is not available, then the installer will provide instructions for downloading the necessary files from another computer. If it proves necessary to interrupt the installation in order to download files manually, the installer can either be left open in the meantime or else cancelled and rerun once the files are available locally.
Trial and Activation
When first installed httpZip defaults to trial mode. While in trial mode, you will be presented with an activation screen each time you launch the httpZip Settings Manager:
You may continue to use httpZip in trial mode for up to 30 days, during which time all of its features will be fully functional. At the end of the trial period, httpZip will cease functioning, but your IIS server will continue to run normally.
Any time during the trial period, or after that period has ended, you can choose to activate httpZip, thereby continuing (or, if the trial has ended, restoring) full functionality. Activation always requires the prior purchase of a httpZip license from www.port80software.com, or the purchase of an additional activation if you already own a httpZip license and are seeking to activate an additional server. Once you have a valid license, there are several options for completing the activation:
- If your IIS server is permitted to initiate outbound SSL (HTTPS) connections on port 443, you can activate online, using the appropriate radio button on the httpZip activation screen (see above).
- If your server is prevented for security reasons from making outbound connections, you can instead use email-based activation. This is available in the form of a text link on the bottom of the activation screen (again, see above).
- Lastly, if your server is prevented from making outbound connections, but it is a Windows 2008 Server that you manage remotely with IIS Manager, from a machine that can make outbound connections, then you can activate httpZip online with IIS Manager, instead of using the standard activation screen. (See the topic Activating Remotely Using IIS Manager, below.)
Using the Settings Manager
The httpZip Settings Manager will launch automatically following a successful installation of httpZip. It can also be launched at any time using either the shortcut in the Port80/httpZip program group in the Windows Start Menu, or simply by double-clicking on the file httpZip.exe in the httpZip installation directory (by default C:\Program Files\Port80\httpZip). Here is what the Settings Manager looks like when it first appears:
Turning httpZip On and Off
From the Settings Manager you can quickly enable or disable httpZip compression for any site by simply highlighting the name of that site in the tree view and clicking the radio button labeled "Off" or "On", as desired, followed by the Apply button. Notice that the status bar at the top of the right pane, and the icon representing the site in the tree control, both turn green to indicate that httpZip is in the "On" state or red to indicate that it is in the "Off" state for a particular site. The status message ("Compression for Default Web Site is On" or "Off") also changes.
If after disabling httpZip compression for a single site, you select any other site from the tree view, you will notice that the status bar's color and message will change to indicate that compression is still "On" for these other sites. This does not mean however that it is necessary to configure httpZip on a site-by-site basis. To manage the settings of several sites simultaneously, or to customize the settings for any site or group of sites, you can use httpZip's profile feature.
Using httpZip Profiles
httpZip configuration settings are managed through the use of profiles. A profile is simply a particular combination of httpZip configuration settings, which can be applied to one or more (or all) sites on a server. httpZip has three default profiles: High, Low, and Optimal, each of which represents a different default combination of httpZip settings. All three default profiles are designed to achieve httpZip's acceleration and bandwidth reduction goals, but with a slightly different set of trade-offs in each case:
- The High profile emphasizes the maximum amount of response size reduction possible, compressing more responses more aggressively than the other profiles. The trade offs for this are higher CPU utilization overall, plus a marginal increase in the possibility that compression might cause an unforeseen problem with page rendering somewhere on the site.
- The Low profile emphasizes the least CPU-intensive uses of compression, and those least likely to create any unforeseen page rendering issues.
- The Optimize profile is intended to strike a reasonable balance between response size reduction on the one hand, and CPU utilization and page rendering safety on the other. It aims to provide a trade-off that is suitable for the most typical cases.
To see the detailed configuration settings for a particular profile, highlight that profile in the tree view and click through the four tab groups, each represented by a button on the graphical button bar in the right pane. As you will see, each tab group has a different set of tabs associated with it. The settings you will see on these tabs are explained in detail in the following sections of this help file.
Note that you cannot edit the settings for any of the default profiles--they are read-only by design, so that the original default settings for each profile will always be available should you want to return a site to that state. You may use a single profile for all sites, or any combination of profiles for any number of sites.
And in addition to the three default profiles discussed above, you can create and use any number of custom profiles--again with one or many sites assigned to each. Custom profiles are useful when you want to achieve a particular combination settings to use with one or more sites, that none of the default profiles happens to provide.
Determining Which Profile a Site is Using
The profile in use for a given site is always indicated in two ways:
- The site will be listed under the profile it is using in the tree view and, when the site is highlighted in the tree; and
- When the site is highlighted in the tree, the name of the profile it is using will be shown in the pull-down menu located in the right pane, immediately below the red/green status bar.
Controlling Multiple Sites Using a Single Profile
When httpZip is first installed, all Web sites on the server will initially inherit their settings from the Optimal profile. Just as with sites, httpZip compression can be turned On and Off for individual profiles as well. Because of this, you can quickly turn httpZip off (or on) for all sites in a default installation by highlighting the Optimal profile in the tree view and using the On/Off radio buttons on the status bar. Notice in the following screen shot that the Optimal profile is selected in the tree view, the status bar is reporting the profile's status, and all of the Web sites under the profile have inherited its current "Off" state, as indicated by the red spheres next to the individual site names:
Changing a Site's Profile
To change a Web site's profile (and therefore the httpZip settings for that site) right-click the site in the tree view and select the new profile from the context menu:
Alternatively, you can highlight the site in the tree view and select the name of the new profile from the pull-down profile selector menu:
In either case, after you have made the change, the node in the tree representing the site should have moved under the appropriate profile, indicating that the site is now inheriting its settings from that profile:
Using a Custom Profile to Change Specific Settings
You can customize any site's settings by creating a custom profile. To do this, right-click the site in the tree view and select the Customize menu option from the context menu (or select Customize from the pull-down profile selector menu in the right pane):
In either case, you will be asked to give the new profile a name. This will be the new profile's permanent name in the tree view and in the right-click and pull-down menus that allow sites to be moved from one profile to another:
After you click OK on the New Profile dialog, the newly created profile will appear in the tree view and the site will now be associated with that profile:
All of the individual settings for this site can now be changed. Initially, the new profile (and thus the site you placed under it) will have the same settings that the site was inheriting previously. Whenever you make and save a change for this site's settings, that change will now be saved to the newly-created profile as well. (You can also make the changes to the profile directly, by highlighting it, rather than the site, in the tree view.)
Once a custom profile has been created using a single site, you can move additional sites to it in the same way you would move them to one of the default profiles. In this way, you can first test a custom profile using a single site and then, when you are satisfied with its behavior, have as many sites as you wish start using the new profile:
Once created, custom profiles (just like default profiles) need not have any sites associated with them. You can archive a custom profile for later use simply by moving all of its sites (including the site originally used to create the profile) to other profiles. If you do not think you will ever use a particular custom profile again, you can also permanently delete an archived profile by highlighting it in the tree view and clicking the "Remove" button that will appear in the profile bar whenever a custom profile has no sites associated with it:
Once you have created a custom profile, you are ready to customize httpZip settings for one or more sites using that profile. httpZip's settings are clustered in four "settings groups", each represented by a large button on the button strip in the right pane of the Settings Manager, under the status and profile bars. For detailed information about a particular settings group, see the correspondingly-named section of this help document: Compression Settings, Caching Configuration, Compression Exclusions, or Logging and Reporting.
Saving or Abandoning Changes
Note that after making any changes on the httpZip Settings Manager, you must press either the "Apply" or the "OK" button in order for the changes to take effect. OK dismisses the Settings Manager dialog, Apply does not. Click "Cancel" to abandon any changes and exit the Settings Manager.
Using IIS Manager to Administer httpZip
In the case of IIS 7.x (Server 2008) installations, httpZip provides an alternative user interface that is embedded directly in IIS Manager. Since IIS Manager is itself a standalone component that can securely connect to and administer IIS 7.x servers (assuming a properly authenticated and authorized user), this alternative allows for remote configuration of httpZip's settings as well.
To access this alternative user interface, simply open IIS Manager, select the Web site whose httpZip settings you wish to configure, find the Port80 Software section in the Features View area, and click on the httpZip logo:
This will bring up, in the center pane of IIS Manager, the same user interface controls that you find in the tab groups of the httpZip Settings Manager.:
There are a small number of differences to keep in mind between this IIS Manager user interface and httpZip's own Settings Manager user interface:
- There is no right-click menu option in the IIS Manager's list of sites, for moving sites between different httpZip profiles, or customizing a site's httpZip profile. Instead, you must use the profile menu pull-down selector at the top of the Features View area (see the screen shot above, in which the "Optimal" profile is selected).
- The IIS Manager also lacks a way to remove unused httpZip profiles. Profiles must be removed using the httpZip Settings Manager.
- Also in contrast to the httpZip Settings Manager, where tab groups are represented by a graphical button strip just above the tab area, here in the IIS Manager they are represented by text links in the Action pane on right of the screen, as shown below. Simply click the text links to change between the different tab groups:
- Lastly, as you can also see in the above screen shot, the Apply and Cancel buttons that are used to save or abandon changes made to httpZip's settings, are also located in the Actions pane (just above the tab group links), rather than below the tab area, as is the case of the httpZip Settings Manager.
With the exception of these few points, httpZip's IIS Manager interface is intended to be a complete substitute for the httpZip Settings Manager and you should be able to use the latter to carry all httpZip administration tasks, whether connected to the IIS 7.x Server locally or remotely.
Activating Remotely Using IIS Manager
If httpZip has not yet been activated, then the controls required for activation can also be accessed though the IIS Manager. To bring up the activation wizard, simply click the "httpZip Activation" link, below the tab group links in the Action pane:
An important feature of this method of activating httpZip is that it works even if you are using IIS Manager to connect to an IIS 7.x server remotely. Thus if the server on which httpZip is installed does not have the outbound HTTPS access normally required for online activation, you still may be able to activate httpZip online (rather than via email) by using a remotely-connected instance of IIS Manager to carry out the activation instead.
In this activation scenario, provided that the machine on which you are running IIS Manager has the ability to make outbound connections, it will act as a forward proxy, making the necessary secure connection to Port80 Software's activation service on behalf of the IIS 7.x server.
The Compression Settings Tab Group
The Compressing Settings tab group contains the controls required for telling httpZip what and how much to compress. These controls are organized into four tabs: Content Types, Compression Levels, Stream Data and Minification:
The Content Types Tab
The content type of an HTTP response (represented by the value in the
Content-Type HTTP header) is the means HTTP uses to let servers tell browsers what to do with the response data (for instance, whether to treat it like markup, or like script code, or like an image). The content type of an HTTP response is therefore a far more accurate and dependable way of deciding whether or not to compress that response, than relying on the file extension in the URL, which may or may not reflect the underlying content type (and may not even be present in all URLs).
The settings on this tab determine which types of files httpZip will and will not compress based on the content type of the response. Content types are essentially MIME (Multipurpose Internet Mail Extension) types, meaning they have a hierarchical structure composed of a top-level type and a sub-type, separated by a slash, like so:
And here are some examples of content (or MIME) types that are commonly seen in Web pages:
To capture this structure, httpZip uses a tree of parent nodes (representing the top-level MIME types such as "text") and child nodes (representing the MIME sub-types such as "html"). Compression is set to "On" or "Off" for each parent and child node in the tree:
The way the logic works here is that the setting for a parent node can be overridden by the setting for a child node, if one is present. Otherwise, the particular content type inherits the setting of its parent type.
For example, given a response having the header
Content-Type: application/newtype, httpZip, configured as in the above screen shot, would not compress that response. This is because although there is no entry in the tree corresponding exactly to this hypothetical new MIME type, there is an entry for the top-level MIME type "application", and it is set to OFF. So that is the setting that would be applied.
Also note that the setting for the MIME type "application/pdf" has been changed from ON to OFF, and that this would have the same effect as removing it from the list altogether.
To change a setting to ON (or OFF) simply click on its ON (or OFF) button. In addition to changing settings for existing types, you can also add new types (either top-level ones or sub-types), and delete any type that you do not need, using the controls provided on the right side of the tab.
The Compression Levels Tab
The standard HTTP compression methods allow for different levels of compression to be applied to a given set of data. The greater the compression level, the smaller the resulting data will be (other things being equal).
You may be wondering why httpZip does not simply apply the maximum compression possible, in all cases. The reason is that there is a rather sharp trade-off between how much to compress the data, and the CPU resources required to do it. The higher the compression level for a given amount and type of data, the more it will cost in CPU cycles. By adjusting compression levels for different types of resources httpZip can manage this trade-off in the most optimal way.
The "Compression Levels" tab allows different compression levels to be assigned for different types resources. But notice something interesting in the screen shot below: While httpZip uses MIME type to decide whether or not to compress a response to begin with, it then uses file extension to decide how much to compress that same response. Why is a different approach used here?
The answer is that assigning compression level based on file extension is helpful because it allows dynamic files and static files to be treated differently, even when they result in responses that have the same MIME type (as when "text/html" content, for example, is served from both .html and .aspx files).
This becomes important because static files can usually be cached after being compressed, and the compressed version thus reused, while the dynamic files must usually be recompressed each time they are requested (a costly process in CPU terms). By assigning different compression levels to different file extensions, httpZip can mitigate the CPU overhead associated with compressing the dynamic files, while still achieving maximum compression for the static files.
As you can see in the above screen shot, the controls on the Compression Levels tab allow the compression level to be adjusted, for each file extension, on a scale of 1 to 9. 1 represents the least amount of compression (the smallest size reduction) and also the least CPU utilitization. 9 represents of course the maximum of both size reduction and CPU cost. In addition to using the pull down selector to set levels, you can also add new file extensions to the list, or delete unused ones, using the buttons provided in the lower right corner of the tab.
The Stream Data Tab
The controls on this tab are rather advanced, and they are primarily intended to provide additional options for how httpZip handles the compression of streamed responses. Understanding these options requires some background knowledge of HTTP streaming:
Many HTTP responses are of a known size when they are sent. Such responses always include a header called
Content-Length giving the size of the response in bytes. Browsers in turn rely on this header to know when they have reached the end of the response data. But what about the case of stream data? The final size of any data stream is, by definition, not known when the stream begins to be sent. How do browsers and other user agents know when the end of a data stream has been reached?
There are two ways that HTTP servers can inform HTTP user agents that the end of a data stream has been reached. The original (HTTP 1.0) way was for the server to simply terminate the underlying connection when done sending the stream. The telltale for this is the
Connection: close header in the HTTP response. While this method works, it also sacrifices the efficiencies associated with persistent connections.
To overcome this trade-off, HTTP 1.1 introduced a new way to signal the end of a stream, indicated by the header
Transfer-Encoding: chunked in the response. With chunked encoding, the individual parts of the stream ("chunks") each carry a bit of extra data giving their individual sizes, and the last one is always a "null chunk", signaling the end of the stream. This allows the underlying connection to remain open after the end of the stream.
By default, when httpZip encounters streamed data it compresses the stream while leaving its form unchanged. Thus, an HTTP 1.0 stream remains an HTTP 1.0 style stream (with a closed connection) and a chunked-encoded stream remains chunked-encoded. The only change httpZip makes, is to resize the parts of the stream, to make sure each is large enough to be efficiently compressed. This is usually the best way to apply compression to stream data.
There may however be cases when it is desirable to remove the streaming and buffer the entire response before compressing it. This can, in principle, increase the amount of compression (reduce the final size of the response). In addition, buffered responses can optionally be cached after compression, whereas streamed responses can not be. The trade-offs are that the first byte will be delayed, and any features dependent on the stream itself (such as a page that incrementally updates what is shown the user as it loads) will cease working as expected.
If you wish to experiment with buffering streams and then compressing the result, the two radio button controls on this tab will let you do so (see the screen shot below). Note: The signal that these buffer-then-compress options are working is that responses that previously would have had
Connection: close or
Transfer-Encoding: chunked headers will now have a
Content-Length: header instead, containing the size of the entire compressed response, in bytes.
The final control on this tab is a special case, in that it does not affect stream data, but rather all those responses that are not streamed--either because they always had a known content length, or because httpZip is buffering them before compressing them, and generating its own
Content-Length header in the process.
For responses falling into either of these categories, you can choose the "Use deflate compression instead of gzip whenever possible" option. For httpZip to send compressed data in a standards-compliant way, the browser or other HTTP user agent must ask for it, which it does by issuing an HTTP header like this with the request:
Accept-Encoding: gzip, deflate
Translating from HTTP into plain English, this says "I can accept this response in compressed form, using either the gzip or the deflate compression method." Browsers are not required to say that they can accept both compression methods, but they generally will do so. This leaves the choice of which method to use up to the server.
The two compression methods are very similar and, in fact, gzip is nothing but deflate with a small amount of additional data added to increase the chances of the entire response being received and reflated correctly. By default httpZip will favor sending gzip whenever possible, since the size difference is very minor in exchange for the extra data integrity checking. But for non-streamed responses you can choose to use deflate instead, assuming the browser has requested it as well as gzip.
The Minification Tab
The Minification tab can be used to configure httpZip's optional minification features. These features provide integrated reduction and normalization of the client side code space, prior to HTTP compression. By preprocessing the source code in various ways (removing linear white space and comments, lowercasing tag names) final response size after compression can be further reduced. Additional savings of up to 10% are possible, in certain cases.
Note: Runtime minification of this kind can be quite costly in terms of CPU cycles, and so the trade-off for the increased size reduction may or may not always be favorable. Use these features with caution. For this same reason, httpZip restricts the application of minification options in a variety of ways. Very large files, stream data, or responses that are not cached after being compressed, are all excluded from minification.
The Caching Configuration Tab Group
The Caching Configuration tab group contains the controls required for managing httpZip's built-in, in-memory compressed content cache. These controls are organized into the following four tabs: General Settings, Cache By Type, Exclude By Path and Dynamic Caching:
The General Settings Tab
The controls on this tab govern the overall behavior of httpZip's compressed content cache:
In addition to allowing caching to be enabled or disabled for all sites in the profile, this tab provides two additional configuration options:
- While cached resources are always invalidated (removed from the cache) when the original file changes on disk, they can also be invalidated when they reach their freshness lifetimes, as explicitly given in an HTTP
Cache-Control header. By default httpZip's cache honors any freshness lifetimes so specified. You can however disable this behavior and have httpZip's cache invalidation rely only on a change in the file.
- Since for performance reasons httpZip caches compressed content in memory, rather than on disk, it may be useful in certain circumstances to limit the amount of data it can cache. For instance, if the server is already short of virtual memory, adding httpZip's cache to the memory load could result in paging, defeating the purpose of in-memory caching. The size limit is not enabled by default since on most modern HTTP servers there is ample virtual memory to spare.
Lastly, and quite importantly, this tab includes a button for clearing the in-memory cache.
The Cache By Type Tab
The list on this tab determines which file types will be cached after they are compressed. As with Compression Levels (and for similar reasons) httpZip uses the file extension in the URL as a heuristic for determining whether or not to cache the compressed output:
In most cases, this list will consist entirely of file extensions that are mapped to static file types in IIS. Dynamic file types may be added however, if you wish to employ httpZip's Dynamic Caching feature.
The Exclude By Path Tab
The list on this tab is useful when you need to make finer-grained distinctions between what httpZip should or should not cache than would be possible using file extensions alone. By adding a file path to this list, that file will be excluded from httpZip caching even if its extension is in the Cache By Type list:
Similarly, a folder path added to this list will exempt all the files in that folder, and in any of its subfolders, from caching. (Note that the list does not, however, affect the compression decision in any way; files and folders listed here will still be compressed, if they are otherwise qualified candidates for compression.)
The Dynamic Caching Tab
While httpZip does not cache dynamically-compressed content by default, it is possible to make such content cachable by adding the appropriate file extension to the Cache By Type list. In such cases, the Dynamic Caching feature will usually be required as well, to ensure that users receive the appropriate content.
Because dynamic content is by definition subject to change without the associated file changing on disk, caching it is normally only desirable when such change is limited to a fixed set of variations. If a dynamic page is unique for every visitor, or every time it is viewed, caching its output makes no sense. But if a dynamic page only has a limited number of stable variations, then caching those variations might make sense. Examples of this might be pages in a content management system, or on a site that functions as an online catalogue.
To make dynamic caching work, we must be able to determine when we are dealing with variations on the page, for which unique copies need to be cached. The compressed content cache in httpZip provides two ways to identify these variations--using the query string or using a cookie value:
When caching based on unique query string, any change in the query string part of the URL will result in a new variation of the page being added to the httpZip compressed content cache. Subsequent requests for the page having that same query string in the URL, will be served that specific cached version. These URLs, for instance, would all produce unique cached copies:
The behavior when caching based on unique cookie value is similar, except that here you must first specify which cookie will be monitored for changes that signal unique page variations. This is done by enter the cookie name in the text box provided. This normally will not be a session cookie (pages that change based on session produce far too many variations to be worth caching), but rather a cookie that classifies users into broad groups, as in the following example, which assumes that a cookie called "usertheme" has been specified for Dynamic Caching:
Lastly, it is possible to use both unique query strings and unique cookie values simultaneously. In that case, httpZip will make unique cached versions of a page when either the query string or the value of the specified cookie changes, meaning the number of possible cached variations will be the product of the number possible with each method alone. Combining the above two examples, for instance, would make for a maximum of nine possible variations of this page in the httpZip cache (3 query string variations x 3 cookie value variations = 9 variations total).
The Compression Exclusions Tab Group
The Compression Exclusions tab group contains the controls required for excluding particular user agents or resources from compression. These controls are organized into the following four tabs: By Browser, By Path, By Protocol and By Size:
The By Browser Tab
The controls on this tab allow specific browsers (or other user agents) to be excluded from compression for specific MIME types. As such, the exclusions made on this tab are dependent on the MIME-based compression settings found on the Content Types tab. A browser exclusion added to a particular MIME type here, will disable compression that would otherwise have been applied to responses of that type.
You can of course add new exclusions to any MIME type in this list (both top-level MIMEs and MIME sub-types). To do so, you must first choose the MIME from the pull-down selector (note that only those types that already exist in the Content Types list will be available here). You must also provide a friendly "Browser Name", which can be whatever you wish, and more importantly, the specific "Search String" that httpZip will look for in the browser's
User-Agent header. If the search string occurs anywhere in the
User-Agent header of the requesting browser, compression will be selectively disabled for that particular MIME type.
The By Path Tab
The list on this tab allows particular files or groups of files to be excluded from compression:
Just as with the Exclude By Path tab in the Caching Configuration tab group, this exclusion list supports both full file paths as well as folder paths--in which case all subfolders are also excluded from compression. In addition, you can use the asterisk wildcard character (*) to match any number of path characters. This is demonstrated in the list defaults, where the wildcard is used to exclude such things as all .exe and .rar files from being compressed, regardless of their location on disk:
The By Protocol Tab
The By Protocol tab lets compression be selectively disabled based on certain protocol-level characteristics of the HTTP request. There are two general types: exlusions based on HTTP version, and exclusions based on the HTTP Accept-Encoding header.
HTTP Version Exclusions
The first two options provided are to exclude HTTP 1.0 requests and/or requests that are routed through HTTP 1.1 proxies. Both of these exclusions can be useful when a network-related group of browsers is having difficulty rendering compressed content correctly. In such cases the problem sometimes lies neither with the server nor with the browser, but rather with a misbehaving proxy server that is improperly handling the compressed content. Excluding HTTP 1.0 user agents and/or self-identifying HTTP 1.1. proxies can sometimes alleviate such issues.
The Accept-Encoding header options concern a basic requirement for receiving compressed content, namely that the browser send (and any intermediaries forward) a correctly-formed HTTP Accept-Encoding header specifying the compression scheme(s) acceptable to the browser.
Unfortunately a number of security products and proxy servers deface the Accept-Encoding header to avoid having to deal with compressed content, effectively excluding up to 15% of Web users from the benefits of compression. Beginning with version 4.2.0, httpZip corrects for this case by accepting the common variations of the defaced Accept-Encoding header, for any sites in the Optimal profile.
While this should normally be a safe option, you can instead require an exact match for the Accept-Encoding header. This is the default setting for sites in the Low profile, and it effectively reverts httpZip to the default behavior for all sites, prior to version 4.2.0. It is the safest option for those worried about avoiding a bad user experience at all costs.
Certain intermediaries may strip the Accept-Encoding header from the request entirely. By clearing the "Require Accept-Encoding header" checkbox, you can permit compressed content to be sent in such cases as well. This is the default behavior for all sites in the High profile. Note that this option is higer-risk in that at least some end-users may get compressed content that their browsers cannot in fact handle.
The By Size Tab
Attempting to compress responses that are too small or too large can be counter-productive: too small, and the size reduction may be trivial, even negative; too large, and the CPU cost could be prohibitive. Accordingly, the controls on the By Size tab allow compression to be limited to responses above a certain minimum size, and below a certain maximum size (note that these are pre-compression sizes):
One caveat to keep in mind is that these limits only apply to responses of a known size, meaning responses that include a
Content-Length header. For streamed responses (both HTTP 1.0 style streaming and HTTP 1.1 style chunked transfer encoding) the limits are not needed. Instead, httpZip's stream handling algorithm internally ensures an efficient size for each part of the stream.
The Logging and Reporting Tab Group
For determining the savings being achieved through compression, httpZip includes a comprehensive Web-based reporting mechanism backed by high-performance, in-memory logging. The Logging and Reporting tab group contains all the controls required for administering httpZip's logs and reports. These controls are organized into the following three tabs: Reporting, Logs, and Report IPs:
Before delving into the details of how the httpZip reporting mechanism is administered, let's take a look at the reports themselves:
Using the httpZip Reports
The httpZip reports track the amount of bandwidth savings achieved through compression, on both a per-page and a site-wide basis. The reporting mechanism makes use of httpZip logs which are stored in memory. The report itself consists of an HTML page called report.htm that is created (or recreated) whenever a user makes a request for a URL of the form:
When report.htm is requested (and httpZip is running with reporting enabled) the data in the site's log is used to populate the data fields in the report page. Here is an example of how the how the result should appear:
Notice that the report page includes both site-wide compression data, as well as page-specific data for each page that has been compressed since the log was last recycled. To see an updated version of the report, you need only to refresh the report page in the browser.
The Reporting Tab
The Reporting tab is primarily used to enable or disable the Web-based reports:
In addition to enabling and disabling reporting, you can use the "Go" button on this tab to launch the report page locally, in the default browser. This can be useful for quickly checking whether the report is working. Note however that the hostname that httpZip will try to use in this case may or may not be appropriate for locally accessing the site, depending on how DNS and IIS are each configured (for instance, the hostname may resolve to a public IP that is not bound directly to the Web server--or it may not resolve at all).
Lastly, the path given in the text box labeled "Location of the report snapshot" is useful primarily in case you wish to retrieve that snapshot. This will be a copy of the last-requested and last-generated version of the report. Since this snapshot contains the data values that were generated when the report was requested, it provides a way for that data to be exported to another computer and viewed locally, without having to give that computer permission to request the Web-based report directly.
The Logs Tab
The Logs tab controls the in-memory logs that are consumed by the Web-based reports:
The most important control here is probably the Clear Log button, whose function is fairly obvious. Two points are worth noting however: this is one of the few controls in httpZip that does not require an Apply or OK button press; and it is also one of the few that always affects a specific site rather than all sites in the currently-selected profile.
In addition to clearing the log immediately using the Clear Log button, one can also use the controls on this tab to schedule the logs to be cleared ("refreshed") after a certain interval.
The Report IPs Tab
Since you may not wish to allow the Web-based report to be viewed by every user of your site, httpZip affords the ability to restrict access to the report to specific IPs:
When the Permit All checkbox is cleared, only the IPs explicitly added to this list will be allowed access to the report page. Note that httpZip automatically populates the list with the loopback address and any addresses it finds bound to the computer at install time.
Controlling httpZip with In-Page Directives
httpZip provides in-page directives to enable programmatic control over basic compression and cache settings. These directives allow any application server or server-side scripting environment to override the configuration settings in the Settings Manager. This facility can be useful for treating dynamic pages differently than static pages, or for singling out particular dynamic files for special treatment, depending on their content or their role in an application.
To use the in-page directives a developer simply injects an HTTP header named "httpZip" into the HTTP response using whatever mechanism the application server or server-side scripting environment provides for doing this. The value portion of the injected header will contain the in-page directive for httpZip to execute. Thus, in ASP.NET you might have code such as the following:
In place of
directive-name you would substitute the desired directive. The available in-page directives, and their meanings, are as follows:
|This setting will cause the response to be minified (to have linear white space and comments removed, and tags lowercased), but not compressed.
|This setting will cause the response to be compressed, but without minification.
|This setting will both minify and compress the response.
|This setting will ensure that httpZip does nothing to the response; it will neither minify nor compress.
|This setting will force the response to be compressed, overriding any compression restrictions that might otherwise have applied.
|This setting will force the response to be compressed and minified, overriding any restrictions that might otherwise have applied.
|This setting will force the response to be compressed and cached, overriding any compression and caching restrictions that might otherwise have applied.
|This setting will force the response to be compressed, minified, and cached, overriding any restrictions that might otherwise have applied.
|This setting will override any caching restrictions and cache the response (assuming it is compressed).
|This setting will cause the response to be compressed using the deflate method, if eligible.