What is the difference between httpZip and ZipEnable?
httpZip provides ISAPI-based HTTP compression for IIS 4/5/6.0 on Windows NT/2000/2003 Web servers, while ZipEnable is a configuration tool to manage and safely deploy the built-in compression engine in IIS 6.0 on Windows Server 2003.
There are many flavors of IIS, and Port80 Software covers HTTP compression on all Microsoft Web servers. Compression does not exist natively on IIS 4, so httpZip is the perfect solution for a Windows NT performance boost. On IIS 5, httpZip replaces the flawed and limited ISAPI compression option, overcoming known IIS 5 browser incompatibilities and configuration bugs for a supercharged Windows 2000 Web server.
With the launch of Windows Server 2003 and IIS 6.0, Port80 Software recognized that Microsoft made compression functionality a priority and evaluated IIS 6.0's native compression. IIS 6.0 ships with a robust compression engine built into the core Web server code, allowing for safe and fast HTTP compression with almost zero resource penalties. As part of the core Web server code, IIS 6.0 native compression processes files faster than any ISAPI filter, making it the fastest HTTP compression solution available on any Windows platform.
Port80 Software recommends IIS 6.0 native compression managed with our ZipEnable tool, the only solution for browser compatibility and configuration of IIS 6.0 built-in compression. Browser compatibility sensing is vital -- without it, you may send compressed content to a browser that cannot decompress it, generating an error for the end user in rendering the file or possibly crashing their browser. Make sure to turn on ZipEnable's browser compatibility checking feature (in Advanced Settings) to compress confidently on IIS 6.0.
The idea of a GUI interface to manage IIS 6.0's "under the hood" metabase settings evolved out of what httpZip customers appreciate most: configurability. While you can control IIS 6.0 compression settings programmatically by editing the intricate metabase, there is no detailed graphical user interface provided for IIS 6.0 compression configuration or a wizard to help you get started. Port80 Software, leveraging experience with compression and IIS, built ZipEnable as a low cost tool for safe deployment and management of IIS 6.0 built-in compression.
Sometimes, you will need to use httpZip on IIS 6.0 for HTTP compression, as the built-in compression engine in Windows Server 2003 does not cover every scenario or have all the features you may want in a compression solution. Learn more about when to leverage httpZip compression to accelerate IIS 6.0 Web servers.
Is ZipEnable a "Lite" version of httpZip?
No. ZipEnable is a management tool for IIS 6.0's built-in compression engine, while httpZip is a ISAPI compression tool itself for IIS 4, 5, 5,1 and 6.0. You will not get any compression functionality from ZipEnable -- the tool is designed to expose the knobs of IIS 6.0 compression so that you can quickly and safely tune HTTP compression on Windows Server 2003 -- and so you can compress content with confidence that all browsers will decompress the response.
When should I use httpZip instead of IIS 6.0 built-in compression? I heard that it was fixed now...
In general, you should use the integrated compression functionality built into IIS 6.0 on Windows Server 2003 for compression, managed and safely deployed by ZipEnable. However, there are some important cases in which you will not be able to get the job done with IIS 6.0's native compression engine -- and where you should use httpZip and ISAPI-based compression on IIS 6.0:
- Controlling compression timing collisions with other ISAPI filters or DLLs: You cannot adjust when IIS 6.0 built-in compression takes place in the request/response life cycle. As such, you may have a third party ISAPI filter operating on a request that collides with IIS 6.0 native compression to produce a broken or uncompressed page. Alternatively, as an ISAPI filter, the timing of httpZip compression can be adjusted (in IIS Manager, Properties, ISAPI Filters) to correct this issue. This will affect you if you are running Akamai's Content Distribution Network (CDN), any ISAPI filters such as third party URL rewriters, Java platforms such as BEA WebLogic, IBM WebSphere, Tomcat or any other application server or program that modifies URLs with a DLL or ISAPI filter.
- Caching of dynamic compressed files: httpZip's compression cache avoids needless recompression to conserve CPU resources and serve previously compressed pages faster. You can do this for static files on IIS 6.0, but there is no compression cache for dynamic files like ASP, ASP.NET, ColdFusion, Perl, PHP, and JSP. If you have dynamic files with unique query strings or cookies and infrequently updated content (like a press release or text in a content management system), take advantage of httpZip's compression cache for dynamic files. If your dynamic pages do not have unique query string or cookie values, do not use this option.
- Reporting: httpZip provides a complete view into compression and bandwidth savings via HTML reports, whereas there is no reporting in IIS 6.0 native compression. Here's a tip to do reporting manually -- add an IIS log entry for Bytes Sent (in IIS Manager, Properties, Web Site, Enable logging, Properties, Advanced, then enable logging for Bytes Sent (sc-bytes)), then compare this data against the original file sizes for ad hoc reporting.
- Controlling compression by MIME type: IIS 6.0 built-in compression uses the file extension and/or location to determine whether a file should be compressed or not. If you need to control HTTP compression by MIME (for example, if you have an application file like ASP or an ISAPI filter that is outputting content with different MIMEs), httpZip's granular controls for compression by MIME type are the only way to accomplish this on IIS 6.0.
- Easy migration and settings transfers (to new server or between virtual servers): IIS 6.0 built-in compression does not allow you to import or export settings from one Web server to another, or to copy settings from one tuned virtual server or Web site to another for compression. This can be easily accomplished with httpZip.
- Optional code optimization for better savings: httpZip offers optional HTML and CSS code optimization, which can reduce file sizes by an additional 5% to 10% prior to compression, based on w3compiler technology. IIS 6.0 native compression and other Microsoft products do not offer this technology.
- Support for decompression on clients running Symantec's Norton Internet Security software: httpZip is one of the few compression solutions on the market that can handle browsers running in conjunction with Norton Internet Security. IIS 6.0 will not compress requests from browsers on clients also running Norton Internet Security, so httpZip is the ideal solution here. Learn more.
What is the difference between global and site level compression on IIS 6.0?
IIS 6.0 compression for static and dynamic files can be applied globally to every virtual server (site) on an IIS Web server. These settings can be managed in the ZipEnable Global Properties tab. IIS 6.0 compression also offers a new feature to control compression granularly for individual virtual servers (sites) at the directory and file levels, and ZipEnable provides a convenient tree view interface so that you can control HTTP compression at any node of the site.
What is the difference between static and dynamic compression on IIS 6.0?
Dynamic compression refers to the compression encoding of any file that does require server-side processing in a scripting environment like ASP, ColdFusion, and PHP. By default, IIS 6.0 is set to compress dynamic files with these file extensions when dynamic compression is enabled: .asp, .dll, and .exe.
The ZipEnable Configuration Wizard provides additional static and dynamic file extension options that can be selected when the tool is run. These file extensions are not part of the default set of extensions in IIS 6.0 compression, but based on Port80 Software's experience, they are good candidates for compression. The wizard provides .js and .css as extra file extension options for static compression, and, for dynamic compression, the wizard provides .cfm and .php as extra file extension options. Keep in mind that you may designate any file type you wish to be a candidate for compression using ZipEnable's Global Properties tab.
What are the Gzip and Deflate schemes/algorithms used for compression in IIS 6.0?
There are two basic types of compression algorithms that most modern browsers accept and can decompress: Gzip and Deflate. IIS 6.0 built-in compression applies these schemes or algorithms to files in order to reduce their size, the compressed files are sent from the Web server, and the client browser then decompresses and renders the files.
Gzip (GNU zip) is a compression utility designed for much better compression and freedom from patented algorithms. Gzip reduces the size of the named files using Lempel-Ziv coding (LZ77).
Deflate is a smart algorithm that adapts the way it compresses data to the actual data itself. This lossless deflate compression algorithm is based on two other compression algorithms: Huffman encoding and LZ77 compression.
When should I use the Gzip or Deflate compression scheme?
There is little difference between the two schemes, although Gzip is more widely used for HTTP compression and is given higher priority by default in IIS 6.0 built-in compression. Technically, Gzip uses the Deflate algorithm and a 10 byte header with an 8 byte footer and a 32 bit checksum. We suggest you try them both to see which produces the best compression results with your site's code.
How do I exclude files from compression with ZipEnable?
You can use ZipEnable to set allowable groups of files for compression by their file extensions. Under the Global Properties tab, select Configure for static or dynamic compression, select a scheme tab (Gzip or Deflate), and then select Configure under File Extensions. This launches a window where you can add, edit, and delete file extensions for compression - any file extension not listed will be excluded from compression.
How do I use the Site Level Properties tree view tool and the Persistent Overrides option?
The biggest advantage of using ZipEnable to manage IIS 6.0 built-in compression is its ease of configuration at a granular level. The Site Properties tab will display a list of virtual servers or sites on your IIS Web server. Select a virtual server, and the site's file structure will be displayed in the tree view interface below, similar to the Windows Explorer interface. You can quickly toggle static and dynamic compression for directories or individual files by selecting Yes and No in the appropriate column or by using the following hot keys: "s" for static or "d" for dynamic.
You can make the process of setting granular compression even easier by using ZipEnable's Persistent Overrides option. The Persistent Overrides option allows you to alter the default inheritance relationship between parent and child nodes in the Site Level Properties tree view. By default, when a parent node's compression status is changed, its subordinate child nodes inherit the new compression status of that parent node. With the Persistent Overrides option turned on, a child node will maintain a Yes or No status for compression as you have set it, despite any changes made to parent node compression settings. Inheritance for a particular file is indicated by an asterisk (*) next to the Yes/No setting for that file in the tree view interface under Site Level Properties. You can turn on Persistent Overrides (in Settings > Site Level) and then go to the Site Level Properties tab to make by-node compression settings.
What should I know about managing IIS 6.0's compression Cache Settings in Advanced Settings?
When you compress a file, there is minor processing penalty. Like all good compression solutions, IIS 6.0 is designed with a cache for compressed content. The first time a file that is eligible for compression is requested by a browser, the page is served uncompressed, and then the internal IIS 6.0 compression engine places the file in a queue for compression. Once compressed, a copy of the compressed file is stored in the compression cache, and the next time the file is requested, it is served from the cache compressed (as long as the resource has not been modified in the meantime).
By selecting Settings > Global > Advanced Settings and then the Cache Settings tab, ZipEnable provides administration over the location that IIS 6.0 stores it's compression cache, the size of the compression cache, and the number of files to delete from the cache once it reaches maximum set limits (limiting cache size is not recommended, as it can incur extra processing time).
What do these other Compression Exclusions control in Advanced Settings?
If you are going to serve HTTP compressed content, you want to make sure that the client browser or proxy receiving the files can indeed accept and/or decompress the content. To deal with these edge cases in which clients may not be compression-aware, IIS 6.0 built-in compression offers three exclusions administered by ZipEnable:
- Compression for HTTP 1.0 User Agents: Do you have users with older browsers like Internet Explorer 4.X or Netscape 4.X? If so, you may want to use this exclusion so that compressed content is not sent to these HTTP 1.0 browsers. Modern browsers built after 1996 to the HTTP 1.1 specification support compression with the capacity to decompress content (Internet Explorer and Netscape 5 and higher, Mozilla, Opera, etc.). This exclusion is disabled by default in IIS 6.0 compression.
- Compression for Requests through Proxies: This exclusion is available because some proxy server vendors do not adhere to the HTTP 1.1 specification for compressed content, and thus you can run into a similar inability to handle compressed content. Test compression with your proxy server (if you use one) to see if you should use this exclusion or not. This exclusion is disabled by default in IIS 6.0 compression.
- Compression for Range Requests: HTTP 1.1 allows a client to request that only part (a range) of a requested file be included within the server response. In these partial request scenarios, the specification does not clarify compression status in range requests, so if you send compressed content in response to a range request, you may be sending compressed content to a browser that can not decompress it. This exclusion is enabled by default in IIS 6.0 compression.
Each of these Compression Exclusions can be managed in ZipEnable by selecting by selecting Settings > Global > Advanced Settings and then the Compression Exclusions tab.
Why should I set a priority for the Gzip and Deflate Compression Schemes?
Certain resource requests from browsers might contain both schemes in the Accept-Encoding header that defines what type of encoded or compressed content the browser can accept and decompress. IIS 6.0 built-in compression determines which compression scheme to use when compressing a response by choosing the scheme with the highest priority. You can manage the priority of Gzip and Deflate compression schemes in ZipEnable by selecting Settings > Global > Advanced Settings and then the Compression Schemes tab.
What are these other Miscellaneous Compression settings?
There are a few other advanced IIS 6.0 built-in compression settings that can be controlled with ZipEnable:
- I/O Buffer Size: This ZipEnable setting specifies the size of the buffer (in bytes) that IIS 6.0 compression uses to read uncompressed files. A larger buffer yields slightly faster compression performance, but at the cost of additional memory usage (this is only valid when static compression is enabled).
- Compression Buffer Size: This setting specifies the size of the compression buffer (in bytes) that IIS 6.0 compression uses for receiving compressed data. A larger buffer yields slightly faster compression performance, but at the cost of using additional memory (this is only valid if static or dynamic compression is enabled).
- Minimum File Size for Compression: Very small files do not compress well, and in some cases, compression may even make the file larger than it was initially. This setting allows you to specify the minimum size (in bytes) a static file must be for it to be compressed by IIS 6.0 compression (a value of 0 means that all files are compressed, regardless of size).
- Maximum Queue Length: When static compression is enabled, and IIS 6.0 receives a request for a non cached static file, the request is put into a FIFO (first in, first out) queue to be compressed and cached by a background process. This setting specifies how many concurrent background compression requests can be in the queue. If the queue is full, additional compression requests are ignored until there is room in the queue.
Each of these Miscellaneous Settings can be managed in ZipEnable by selecting Settings > Global > Advanced Settings and then the Miscellaneous Settings.
Visitors to your Web site are using a wide variety of different browsers and versions, and it is your responsibility to make sure that you send each user content that their particular browser can handle. While most browsers can handle compressed content for most file types, there are always exceptions.
Under all but the most extreme conditions, a quality compression tool installed on a server with sufficient processing power does not have a significant effect on server load. However, during periods of extremely high traffic or other peak usage conditions, in which CPU utilization may actually approach 100%, it is vital to avoid any additional strain on the CPU, however minimal.
ZipEnable includes a CPU Roll-off feature which automatically turns off compression if CPU usage reaches a certain level. Administrators can choose the threshold based on their own particular system and performance needs, and compression will automatically resume when CPU usage drops below that threshold.
IIS 6.0 has a feature called "edit-while-running" that allows metabase changes to take effect without the need for a restart of the Web service. Support for this feature was added in ZipEnable 1.1. Unfortunately, the vagaries of the edit-while-running feature mean that some compression options still cannot be changed reliably without a Web service restart. Those that can be include the options to toggle compression on and off at the site, directory, and file level. If edit-while-running is enabled, ZipEnable will detect this, and refrain from prompting the user for a service restart whenever the configuration changes do not require it. However, in other cases where we have found a restart to be necessary for reliable application of the changes, ZipEnable will prompt for a service restart even if edit-while-running is enabled.
Want to quickly deploy your global settings for static and dynamic compression? Run the ZipEnable configuration Wizard (select Run Wizard on the Global Properties tab or select File, then Run Configuration Wizard) to set up static and dynamic compression, levels of compression, and the files with certain extensions to be compressed for all or individual virtual servers. Without ZipEnable and this wizard, you would have to navigate to each site and select multiple tabs and dialogs to accomplish what the Configuration Wizard can set in a minute.
Why do I need a command line interface to ZipEnable?
We added this feature in for programmatic control of IIS 6.0 native compression via ZipEnable -- and for those who love to use the command line in general. Software companies and organizations with the need can use this interface to programmatically control IIS 6.0 native compression with a few commands (much less work than writing your own code to interact with and manage IIS 6.0 metabase setting for compression -- and you get browser compatibility as well). Read the docs to learn more.
What can I do for reporting on compression savings with IIS 6.0 built-in compression?
Currently, there is no reporting mechanism or data source for IIS 6.0 built-in compression, so ZipEnable cannot help here. Port80 Software is working directly with the Microsoft IIS team to develop a future solution.
If long-term, in-depth reporting on pre- and post-compression file sizes is necessary, Port80's httpZip is now fully supported for IIS 6.0. While no ISAPI filter can claim quite the performance of a solution embedded into the core server, httpZip does have advantages for specific situations in which reporting is necessary or in which it is preferable to apply compression immediately preceding transmission.
Does ZipEnable work with SharePoint Portal Server?
Yes, compression can be configured for SharePoint Portal Server using ZipEnable (and IIS 6.0 native compression in the core Web server). If you install ZipEnable on a server running SharePoint Portal Server and encounter an error, you should verify that the "check if file exists" option is deselected for the ZEIsapi.dll wildcard extension for your virtual directories.
This can be done through Internet Services Manager >> Web Sites folder >> Properties >> Home Directory (or Virtual Directory) tab >> click Configuration
In the Add/Edit Application Extension Mapping dialog, deselect the "Verify that file exists" checkbox.
Can compression help speed up and ease the strain of my RSS blog feeds?
Yes, it will. Review this discussion of RSS and compression.
Will HTTP compression hurt my search engine rankings in any way?
No, compression is completely compatible with search engines and their bots -- you have nothing to worry about here. In fact, compression adds more throughput, increasing the likelihood that a search engine robot will be answered with responses when your Web site is spidered, and some smarter search engines like Google even prefer compressed content, as it is less data (and therefore cheaper) for them to download and index.
Will ZipEnable manage IIS 6.0 built-in compression if I am running the Web server in IIS 5 Isolation Mode?
Yes, simply use ZipEnable to manage compression in this case.
I am testing a few different compression tools at once. Is there any issue to be aware of here?
When testing compression solutions, both hardware and software, many compression tools do not play well together and can cause collisions and issues when used simultaneously to compress a response.
Make sure to disable compression (at the global and every site level it has been turned on at in the past) or even uninstall any other compression tools before you evaluate ZipEnable. You may want to visit the default IIS 6.0 compression interface as well and turn everything off first before testing native compression management with ZipEnable. If you decide to stop testing ZipEnable and move to another tool like httpZip, make sure everything at the global and site levels has been disabled, or you could find that you cannot get compression to work or may even crash your Web server. Please contact Support if you have any questions related to evaluating HTTP compression.
Port80 Software usually makes ISAPI filters. Is ZipEnable an ISAPI filter?
ZipEnable is our first product that is not an IIS server module or ISAPI filter. Instead, ZipEnable installs as a modest .exe with no moving parts that could directly impact your Web server's performance or other applications running on the server. The tool reads and edits IIS 6.0 metabase settings to give you a graphical control over the built-in Windows Server 2003 compression engine -- and makes compression much safer with browser compatibility and CPU Roll-off.
Check out httpZip for IIS 6.0 ISAPI-based compression!
Does ZipEnable work with your other Port80 Software products?
ZipEnable's functionality does not interact or overlap with any other Port80 product, as it is not an IIS server module or ISAPI filter.