Apache::CompressClientFixup - Perl extension for Apache-1.3.X to avoid gzip compression for some buggy browsers.


It is assumed that the Apache::CompressClientFixup package is installed in your Perl library. See README for installation instructions if necessary.

You may use something like the following in your httpd.conf:

  PerlModule Apache::CompressClientFixup
  <Location /devdoc/Dynagzip>
      SetHandler perl-script
      PerlFixupHandler Apache::CompressClientFixup
      Order Allow,Deny
      Allow from All

You can, for example, restrict compression for MSIE over SSL and restrict compression for Netscape Navigator 4.X with

  PerlModule Apache::CompressClientFixup
  <Location /devdoc/Dynagzip>
    SetHandler perl-script
    PerlFixupHandler Apache::CompressClientFixup
    PerlSetVar RestrictMSIEoverSSL On
    PerlSetVar NetscapePrintable On
    Order Allow,Deny
    Allow from All


Standard gzip compression significantly scales bandwidth, and helps to satisfy clients, who receive the compressed content faster, especially on dial up's.

Obviously, the success of proper implementation of content compression depends on quality of both sides of the request-response transaction. Since on server side we have 6 open source modules/packages for web content compression (in alphabetic order):


the main problem of implementation of web content compression deals with fact that some buggy web clients declare the ability to receive and decompress gzipped data in their HTTP requests, but fail to keep promises when the response arrives really compressed.

All known content compression modules rely on Accept-Encoding: gzip HTTP request header in accordance with rfc2616. HTTP server should never respond with compressed content to the client which fails to declare self capability to uncompress data accordingly.

Thinking this way, we would try to unset the incoming Accept-Encoding HTTP header for those buggy clients, because they would better never set it up...

We would separate this fixup handler from the main compression module for a good reason. Basically, we would benefit from this extraction, because in this case we may create only one common fixup handler for all known compression modules. It would help to

·Share specific information;
·Simplify the control of every compression module;
·Wider reuse the code of the requests' correction;
·Simplify further upgrades.


Thanks to Rob Bloodgood for the patch that helps to eliminate some unnecessary warnings.


This handler is supposed to serve the fixup stage on mod-perl enabled Apache-1.3.X.

It unsets HTTP request header Accept-Encoding for the following web clients:

Microsoft Internet Explorer

Internet Explorer sometimes loses the first 2048 bytes of data that are sent back by Web Servers that use HTTP compression, - Microsoft confirms for MSIE 5.5 in Microsoft Knowledge Base Article - Q313712 (;en-us;Q313712).

The similiar statement about MSIE 6.0 is confirmed in Microsoft Knowledge Base Article - Q312496.

In accordance with Q313712 and Q312496, these bugs affect transmissions through


and special patches for MSIE-5.5 and MSIE-6.0 were published on Internet.

Microsoft has confirmed that this was a problem in the Microsoft products.

Microsoft states that this problem was first corrected in Internet Explorer 6 Service Pack 1.

Since then, later versions of MSIE are not supposed to carry this bug at all.

This version of the handler does not restrict compression for MSIE over HTTP.

Restriction over HTTPS for all versions of MSIE could be configured with

    PerlSetVar RestrictMSIEoverSSL On

in httpd.conf if required.


It is not recommended any more to restrict MSIE over SSL since Vlad Jebelev reported successfull delivery of compressed content to MSIE over SSL providing dynamic Apache downgrade from HTTP/1.1 to HTTP/1.0 in accordance with SSL recommendations. Since then it would be considered preferable solution to downgrade the protocol for this client instead of discarding compression.

This approach works fine with Apache::Dynagzip 0.09, or later.

Netscape 4.X

This is HTTP/1.0 client. Netscape 4.X is failing to

a) handle <script> referencing compressed JavaScript files (Content-Type: application/x-javascript)
b) handle <link> referencing compressed CSS files (Content-Type: text/css)
c) display the source code of compressed HTML files
d) print compressed HTML files

See detailed description of these bugs at - Michael Schroepl's Web Site.

This version serves cases (a) and (b) as default for this type of browsers. Namely, it unsets HTTP request header Accept-Encoding for Content-Type: application/x-javascript and for Content-Type: text/css when the request is originated from Netscape 4.X client.

This version serves cases (c) and (d) conditionally: To activate printability for Netscape Navigator 4.X you need to place

    PerlSetVar NetscapePrintable On

in your httpd.conf. It turns off any compression for that buggy browser.

On Wednesday January 15, 2003 Michael Schroepl wrote to

    ... Our customers still include 17% Netscape 4 users, sigh ...

Partial Request from Any Web Client

In accordance with rfc2616 server may ignore Range features of the request and respond with full HTTP body indeed. Usually you should not care about compression features in this case.

For experimental reasons this version unsets HTTP header Accept-Encoding for any web client conditionally when

    PerlSetVar RestrictRangeCompression On

is present in your httpd.conf and HTTP header Range is present within the request. You may experiment with this option when you know what you are doing...


This module requires these other modules and libraries:


which come bandled with mod_perl. You don't need to install them additionally.


Slava Bizyayev <> - Freelance Software Developer & Consultant.


Copyright (C) 2002, 2003 Slava Bizyayev. All rights reserved.

This package is free software. You can use it, redistribute it, and/or modify it under the same terms as Perl itself.

The latest version of this module can be found on CPAN.


mod_perl at

Apache::Dynagzip at

Web Content Compression FAQ at

Michael Schroepl's Web Site at

1 POD Error

The following errors were encountered while parsing the POD:

Around line 128:

Non-ASCII character seen before =encoding in '·Apache::Compress'. Assuming ISO8859-1