This project is read-only.

Compressor (Content Compression Module)

Introduction:

Xpedite supports both Deflate and GZip compression. When both gzip and deflate accept-encoding's are supported, Xpedite will prefer the use of Deflate. Both compression algorithms will see nearly identical results in terms of compression ratio as well as performance. Deflate does have a very slight edge of GZip, but not a big enough difference to have any significant boost under most situations.

Key Differences:

q Values

As you are likely well aware, there are many different implementations of compression modules for .NET. The most common implementations simply do a .Contains("gzip") to determine if the "Accept-Encoding" supports gzip (or deflate, etc). However, this is misleading, as a valid "Accept-Encoding" may look something like:

gzip; q=0


What most solutions don't consider, is the q value that may be associated with a particular coding (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html). The above encoding actually indicates that gzip is NOT supported. As such, Xpedite will fully parse the "Accept-Encoding" and verify that the quality value (q) associated with the coding is not 0. How often would this present a problem? Honestly, under standard circumstances, you would never actually come across this issue. However, the above is a perfectly valid "accept-encoding" and thus should be handled by any compression module to avoid undesired behavior.

Exclusions

Unfortunately, some resources do not play nicely with compression. Specifically, some resources do not handle compression via use of the HttpResponse.Filter property (i.e., WebResource.axd). Some solutions will make a second http request from the server to query the content of such a resource and then re-send the response on to the client compressed. If the preceding approach is used with content caching on the server, this can help improve efficiency. Xpedite does not implement such a solution at this time. However, Xpedite will allow you to configure resources to be excluded from content compression regardless of the "accept-encoding". Please see configuration instructions/examples for details.

Configuration

To start using Xpedite for content compression in your web application, simply add a project reference to Xpedite assembly and add one of the following xml fragments to the web.config file.


IIS6
  <system.web>
    <httpModules>
      <add name="ContentCompressor"
           type="Xpedite.Compression.CompressionModule, Xpedite, PublicKeyToken=f6736b2cf1ee5ed4"/>
    </httpModules>
  </system.web>

IIS7
  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true">
      <add name="ContentCompressor" 
           type="Xpedite.Compression.CompressionModule, Xpedite, PublicKeyToken=f6736b2cf1ee5ed4"/>
    </modules>
  </system.webServer>


As mentioned above, from time to time you may need to exclude a file from being compressed (i.e., WebResource.axd). To configure Xpedite to ignore selected files despite their "accept-encoding", add a reference in the web config to Xpedite's custom configuration section and add the selected files to be excluded.

Define Custom Configuration Section
  <configuration>
    <configSections>
      <section 
        name="xpedite" type="Xpedite.Config.ConfigSectionHandler, Xpedite, PublicKeyToken=f6736b2cf1ee5ed4" 
        requirePermission="false"/>
    </configSections>
  </configuration>


Once the custom configuration section has been added, the Xpedite configuration may then be specified:

Compressor Configuration
  <configuration>
    <xpedite>
      <compression>
        <excludes>
          <add absolutePathPattern="WebResource.axd"/>
          <add absolutePathPattern="\.(gif|jpe?g|png)$"/>
        </excludes>
      </compression>
    </xpedite>
  </configuration>


The xml attribute absolutePathPattern may be any valid regular expression.

Note: Xpedite does not consider the querystring portion of a URL when evaluating exclusions. To conditionally compress a file based on a querystring parameter does not seem logical. If someone has a valid need for such a feature, I will consider adding support; until then only the absolute path is tested.

Note: Compressing an image file may result in a larger file and thus should not be compressed.

Note: Using the CompressionModule if IIS is already configured to use Static/Dynamic Compression is not recommended.

Sample Compression Results

Uncompressed
Uncompressed.png

Compressed
Compressed.png

Future Enhancements

No future enhancements to the Compression Module are planned at this time. If you have a suggestion, I would be happy to hear it!

Last edited Aug 12, 2010 at 4:25 AM by CBaxter, version 21

Comments

No comments yet.