Uli Margull, 2002-10-30 (for version 1.20.227)
| Release | Date | By | Comment |
|---|---|---|---|
| R1.20.226 | 2002-10-30 | U.Margull | Password protection for Info page added |
| R1.20.215-beta | 2002-09-19 | U.Margull | Logging added, Info Page added, more settings (MinSize, MaxSize) |
| R1.10.171 | 2002-06-20 | U.Margull | Preparing the FlatCompression for Open Source |
| R1.01.147 | 2002-04-25 | U.Margull | First documentation of FlatCompression Filter |
Thanks to 1 mal 1 Software GmbH, Fürth, Germay, who developed and donated the original filter software. The filter was developed for the FLATCAST video/audio streaming portal.
Design and programming was done by Uli Margull, with thanks to Johannes Welck, Martin Miller and the 20kBit Michael!
The FlatCompression filter is used to compress the entity of the http response.
The compression itself is done with the zlib library (www.zlib.org).
Home of the filter is www.flatcompression.org.
IMPORTANT: The ISAPI filter FlatComp.dll has to be installed as a IIS-wide ISAPI filter. This means, it can not used on a single virtual web presence, but only system-wide.
The ISAPI filter returns a info page when the special URL /FlatCompression/XXX is found, where XXX is the password set in the registry. If no password is set, the info page can be displayed using /FlatCompression.
IMPORTANT: It is recommended to choose a password!
The info page displays:
The ISAPI filter now logs some information in memory.
The format of the logged information is:
Typical logging information is:
Additionally, each response is searched for a Flatcompression-control: header.
The header can have the following values:
| content | Description |
| no-compress | This response will not be compressed |
Note: The header can be set in the IIS5 configuration or by ASP, ASP.Net or other dynamical scripting. However, it can not be set using the <meta> tag in the html, like <meta http-equiv="Flatcompression-control" content="no-compress">
For default mode, no registry settings are necessary. The filter should work out-of-the-box. In the default mode, all responses with Content-Type: text/html are compressed.
Some of the filter behaviour can be changed by registry settings. These settings are found unter HKLM->Software->FlatCompression. The settings are:
| Name | Type | Default | Description |
| Flags | REG_DWORD | 0 | Special flags for filter behaviour. Right now the following
bitmasks are defined:
Bit 0: If set: Log each compressed response |
| mime | REG_MULTI_SZ | text/ | Mime types that will be compressed. All entries that match
are compressed. The default value compresses all text/* mime types, e.g.
text/html, text/plain, text/css, etc.
A maximum of 5 entries will be used by the filter. IMPORTANT: REG_MULTI_SZ cannot be edited with regedit.exe. Use regedt32.exe instead. |
| MinSize | REG_DWORD | 0 | Threshold for the size of the response: if the size of the
response is smaller than this threshold, the response will
not be compressed.
Inactive if value is zero. |
| MaxSize | REG_DWORD | 0 | Threshold for the size of the response: if the size of the
response is larger than this threshold, the response will
not be compressed.
Inactive if value is zero. |
| password | REG_SZ | Password protection for the info page. With the password MyPass set, the info page and the filter re-initialization can only be reached by /FlatCompression/MyPass |
The parameters are loaded when the filter starts (i.e. when IIS starts). A reload of the parameters can be forced from the flatcompression info page (or directly by calling the following URL, where MyPass is the password: /FlatCompression/MyPass/InitFilter ).
Here are some of the questions I have already answered:
FlatCompression was build with security in mind. Hopefully, the routines do not contain a bug, like buffer overflow, etc. If You want to review the code, go ahead, and mail me any suggestions.
Other than buffer attacks, there is not much to worry about. The info page does not contain much relevant information, besides that FlatCompression is in use, and the logging info (if enabled). The only action an attacker could issue is a re-initialize of the filter, and even that would not compromise the system very much. Additionally, the info page is password-protected.
It was deliberately choosen to make the info page read-only, since now the settings can only be changed by accessing to the registry.
Yes, when compressing a static html page, one could cache the compressed response. The IIS5 does this, and it works pretty fine. If you need this feature, use the IIS5 compression filter (can be used additionally to the FlatCompression filter).
However, dynamic content cannot be cached since, well, its dynamic. The primary use of this filter is with dynamic content, and therefor no caching was implemented. Adding caching would involve be a complete redesign of the software, and at the moment, its not even on the to-do list. But this is open source, and if theres a demand, it will probably be done one day or another.
Well, if You dont know how to do this, better be careful and check the IIS manuals first.
Since the filter has to be installed as a system wide filter, heres a short description of how its done:
The filter looks at the incoming request. If the Accept-Encoding header contains 'gzip' or 'deflate', then the compression is activated. When the response is prepared by the server, the filter looks at the response, especially at the Content-Type. If the mime type of the response should be compressed, then a special header Content-Encoding: is added. The entity of the response then is compressed and the compressed entity is sent to the browser.
When sending a response to the browser, the content length has to be known. This is not known at first. Therefor, the complete header and the complete answer is cached in the filter. When the complete answer is available, it is compressed, the compressed size is added to the header, and the header as well as the compressed entity are sent to the browser.