view release on metacpan or  search on metacpan

README  view on Meta::CPAN

=over 4

=item ·Apache::Compress

=item ·Apache::Dynagzip

=item ·Apache::Gzip

=item ·Apache::GzipChain

=item ·mod_deflate

=item ·mod_gzip

=back

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 C<Accept-Encoding: gzip> HTTP request header
in accordance with C<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 C<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

=over 4

=item ·Share specific information;

=item ·Simplify the control of every compression module;

=item ·Wider reuse the code of the requests' correction;

=item ·Simplify further upgrades.

=back

=head2 Acknowledgments

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

=head1 DESCRIPTION

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

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

=head2 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
(http://support.microsoft.com/default.aspx?scid=kb;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

=over 4

=item HTTP

=item HTTPS

=item FTP

=item Gopher

=back

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

Microsoft 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 necessary.

=over 4

=item Note:

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 C<Apache::Dynagzip 0.09>, or later.

=back

=head2 Netscape 4.X

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

=over 4

=item a) handle <script> referencing compressed JavaScript files (Content-Type: application/x-javascript)

=item b) handle <link> referencing compressed CSS files (Content-Type: text/css)

=item c) display the source code of compressed HTML files