Author: stas Date: Mon Apr 11 09:52:33 2005 New Revision: 160925 URL: http://svn.apache.org/viewcvs?view=rev&rev=160925 Log: new version by Slava Bizyayev <[EMAIL PROTECTED]>
Modified: perl/modperl/docs/trunk/src/docs/tutorials/client/compression/compression.pod Modified: perl/modperl/docs/trunk/src/docs/tutorials/client/compression/compression.pod URL: http://svn.apache.org/viewcvs/perl/modperl/docs/trunk/src/docs/tutorials/client/compression/compression.pod?view=diff&r1=160924&r2=160925 ============================================================================== --- perl/modperl/docs/trunk/src/docs/tutorials/client/compression/compression.pod (original) +++ perl/modperl/docs/trunk/src/docs/tutorials/client/compression/compression.pod Mon Apr 11 09:52:33 2005 @@ -2,43 +2,34 @@ Web Content Compression FAQ +=head1 Description + +Everything you wanted to know about web content compression + =head1 Basics of Content Compression -Compression of outgoing traffic from web servers is beneficial for -clients who get quicker responses, as well as for providers who experience -less consumption of bandwidth. - -Recently content compression for web servers has been provided mainly through use of the gzip format. -Other (non perl) modules are available that provide -so-called C<deflate> compression. -Both approaches are currently very similar and use the LZ77 algorithm -combined with Huffman coding. -Luckily for us, there is no real need to understand all the details -of the obscure underlying mathematics in order to compress -outbound content. -Apache handlers available from CPAN can usually do the dirty work for us. -Content compression is addressed through -the proper configuration of appropriate handlers in the httpd.conf file. +Compression of outbound Web server traffic provides benefits both for Web clients who see shorter response times, as well as for content providers, who experience lower consumption of bandwidth. -Compression by its nature is a content filter: +Most recently, content compression for web servers has been provided mainly through use of the C<gzip> encoding. +Other (non perl) modules are available that provide so-called C<deflate> compression. +Both approaches are very similar recently and use the LZ77 algorithm combined with Huffman coding. +Luckily for us, to make use of them, there is no real need for most of us to understand +all the details of the obscure underlying mathematics of these techniques. +Apache handlers available from CPAN can usually do the dirty work. +Apache addresses content compression through handlers configured in its configuration file. + +Compression is, by its nature, a content filter: It always takes its input as plain ASCII data that it converts -to another C<binary> form and outputs the result to some destination. -That's why every content compression handler usually belongs -to a particular chain of handlers within the content generation phase -of the request-processing flow. - -A chain of handlers is one more common term that is good to know about -when you plan to compress data. -There are two of them recently developed for Apache 1.3.X: -C<Apache::OutputChain> and C<Apache::Filter>. -We have to keep in mind -that the compression handler developed for one chain usually fails -inside another. - -Another important point deals with the order of execution of handlers -in a particular chain. -It's pretty straightforward in C<Apache::Filter>. -For example, when you configure +to another C<binary> form, and outputs the result to some destination. +That is why every content compression handler usually belongs to a particular chain of handlers +within the content generation phase of the request-processing flow. + +A C<chain of handlers> is one more common term that is good to know about when you plan to compress data. +There are two of them recently developed for Apache 1.3: C<Apache::OutputChain> and C<Apache::Filter>. +We have to keep in mind that the compression handler developed for one chain usually fails inside another. + +Another important point deals with the order of execution of handlers in a particular chain. +It's pretty straightforward in C<Apache::Filter>. For example, when you configure... PerlModule Apache::Filter <Files ~ "*\.blah"> @@ -47,12 +38,10 @@ PerlHandler Filter1 Filter2 Filter3 </Files> -the content will go through C<Filter1> first, -then the result will be filtered by C<Filter2>, -and finally C<Filter3> will be invoked to make the final changes -in outgoing data. +...the content will go through C<Filter1> first, then the result will be filtered by C<Filter2>, +and finally C<Filter3> will be invoked to make the final changes in outbound data. -However, when you configure +However, when you configure C<Apache::OutputChain> like... PerlModule Apache::OutputChain PerlModule Apache::GzipChain @@ -63,121 +52,104 @@ PerlHandler Apache::OutputChain Apache::GzipChain Apache::SSIChain Apache::PassHtml </Files> -execution begins with C<Apache::PassHtml>. -Then the content will be processed with C<Apache::SSIChain> -and finally with C<Apache::GzipChain>. -C<Apache::OutputChain> will not be involved in content processing at all. +...execution begins with C<Apache::PassHtml>. Then the content will be processed with C<Apache::SSIChain> +and finally with C<Apache::GzipChain>. C<Apache::OutputChain> will not be involved in content processing at all. It is there only for the purpose of joining other handlers within the chain. -It is important to remember that the content compression handler -should always be the last executable handler in any chain. +It is important to remember that the content compression handler should always be the last executable handler in any chain. -Another important problem of practical implementation -of web content compression deals with the fact -that some buggy web clients declare the ability to receive -and decompress gzipped data in their HTTP requests, +Another important problem of practical implementation of web content compression deals with the fact +that some buggy Web clients declare the ability to receive and decompress gzipped data in their HTTP requests, but fail to keep their promises when an actual compressed response arrives. -This problem is addressed through the implementation of -the C<Apache::CompressClientFixup> handler. +This problem is addressed through the implementation of the C<Apache::CompressClientFixup> handler. This handler serves the C<fixup> phase of the request-processing flow. It is compatible with all known compression handlers and is available from CPAN. -=head1 Q: Why it is important to compress web content? +=head1 Q: Why it is important to compress Web content? -=head2 A: Reduced equipment costs and the competitive advantage of -dramatically faster page loads. +=head2 A: Reduced equipment costs and the competitive advantage of dramatically faster page loads. Web content compression noticeably increases delivery speed to clients -and may allow providers to serve higher content volumes without -increasing hardware expenditures. It visibly reduces actual content -download time, a benefit most apparent to users of dialup and -high-traffic connections. +and may allow providers to serve higher content volumes without increasing hardware expenditures. +It visibly reduces actual content download time, a benefit most apparent to users of dialup and high-traffic connections. + +Industry leaders like I<Yahoo> and I<Google> are widely using content compression in their businesses. =head1 Q: How much improvement can I expect? -=head2 A: Effective compression can achieve increases in transmission -efficiency from 3 to 20 times. +=head2 A: Effective compression can achieve increases in transmission efficiency from 3 to 20 times. -The compression ratio is highly content-dependent. For example, if -the compression algorithm is able to detect repeated patterns of -characters, compression will be greater than if no such patterns -exist. You can usually expect to realize an improvement between of 3 -to 20 times on regular HTML, JavaScript, and other ASCII content. I -have seen peak HTML file compression improvements in excess of more -than 200 times, but such occurrences are infrequent. On the other -hand I have never seen ratios of less than 2.5 times on text/HTML -files. Image files normally employ their own compression techniques -that reduce the advantage of further compression. +The compression ratio is highly content-dependent. +For example, if the compression algorithm is able to detect repeated patterns of characters, +compression will be greater than if no such patterns exist. +You can usually expect to realize an improvement between of 3 to 20 times on regular HTML, +JavaScript, and other ASCII content. +I have seen peak HTML file compression improvements in excess of more than 200 times, +but such occurrences are infrequent. +On the other hand I have never seen ratios of less than 2.5 times on text/HTML files. +Image files normally employ their own compression techniques that reduce the advantage of further compression. =for html <blockquote> -On May 21, 2002 Peter J. Cranstone wrote to the [EMAIL PROTECTED] mailing list: +On May 21, 2002 Peter J. Cranstone wrote to the [EMAIL PROTECTED] mailing list: -I<"...With 98% of the world on a dial up modem, all they care about is -how long it takes to download a page. It doesn't matter if it -consumes a few more CPU cycles if the customer is happy. It's cheaper -to buy a newer faster box, than it is to acquire new customers."> +I<"...With 98% of the world on a dial up modem, all they care about is how long it takes to download a page. It doesn't matter if it consumes a few more CPU cycles if the customer is happy. It's cheaper to buy a newer faster box, than it is to acquire new customers."> =for html </blockquote> =head1 Q: How hard is it to implement content compression on an existing site? -=head2 A: Implementing content compression on an existing site -typically involves no more than installing and configuring an -appropriate Apache handler on the web server. - -This approach works in most of the cases I have seen. In some special -cases you will need to take extra care with respect to the global -architecture of your web application, but such cases may generally be -readily addressed through various techniques. To date I have found no -fundamental barriers to practical implementation of web content -compression. +=head2 A: Implementing content compression on an existing site typically involves no more than installing and configuring an appropriate Apache handler on the Web server. + +This approach works in most of the cases I have seen. +In some special cases you will need to take extra care with respect to the global architecture of your Web application, +but such cases may generally be readily addressed through various techniques. +To date I have found no fundamental barriers to practical implementation of Web content compression. -=head1 Q: Does compression work with standard web browsers? +=head1 Q: Does compression work with standard Web browsers? =head2 A: Yes. No client side changes or settings are required. -All modern browser makers claim to be able to handle compressed -content and are able to decompress it on the fly, transparent to the -user. There are some known bugs in some old browsers, but these can -be taken into account through appropriate configuration of the web -server. - -I strongly recommend use of the C<Apache::CompressClientFixup> handler -in your server configuration in order to prevent compression -for known buggy clients. +All modern browser makers claim to be able to handle compressed content and are able to decompress it on the fly, +transparent to the user. +There are some known bugs in some old browsers, but these can be taken into account +through appropriate configuration of the Web server. + +I strongly recommend use of the C<Apache::CompressClientFixup> handler in your server configuration +in order to prevent compression for known buggy clients. -=head1 Q: What software is required on the server side? +=head1 Q: Is it possible to combine the content compression with data encryption? -=head2 A: There are four known mod_perl modules/packages for the web content -compression available to date for Apache 1.3.X (in alphabetical order): +=head2 A: Yes. Compressed content can be encrypted and securely transmitted over SSL. + +On the client side, the browser transparently unencrypts and uncompresses the content for the user. +It is important to maintain the correct order of operations on server side to keep the transaction secure. +You must compress the content first and then apply an encryption mechanism. +This is the only order of operations current browsers support. + +=head1 Q: What software is required on the server side for content compression? + +=head2 A: There are four known mod_perl modules/packages for Web content compression available to date for Apache 1.3 (in alphabetical order): =over 4 =item * Apache::Compress -a mod_perl handler developed by Ken Williams (U.S.). -C<Apache::Compress> is capable to gzip -output through C<Apache::Filter>. -This module accumulates all incoming data and then compresses -the whole content body at once. +a mod_perl handler developed by Ken Williams (U.S.), C<Apache::Compress>, +can generate gzip output through the C<Apache::Filter>. +This module accumulates all incoming data and compresses the entire content body as a unit. =item * Apache::Dynagzip -a mod_perl handler, developed by Slava Bizyayev -- a -Russian programmer residing in the U.S. -C<Apache::Dynagzip> uses the gzip format to compress -output through the C<Apache::Filter> or through the internal -Unix pipe. - -C<Apache::Dynagzip> is most useful when one needs to compress dynamic -outbound web content (generated on the fly from databases, XML, etc.) -when content length is not known at the time of the request. +a mod_perl handler developed by Slava Bizyayev, C<Apache::Dynagzip> uses the gzip format +to compress output dynamically through the C<Apache::Filter> or through the internal Unix pipe. -C<Apache::Dynagzip>'s features include: +C<Apache::Dynagzip> is most useful when one needs to compress dynamic outbound Web content +(generated on the fly from databases, XML, etc.) when content length is not known at the time of the request. + +C<Apache::Dynagzip>'s features include: =over 4 @@ -187,52 +159,61 @@ =item * Support for Perl, Java, or C/C++ CGI applications. -=item * Advanced control over the proxy cache with the -configurable C<Vary> HTTP header. +=item * Advanced control over the proxy cache with the configurable C<Vary> HTTP header. -=item * Optional control over content lifetime in the client's local -cache with the configurable C<Expires> HTTP header. +=item * Optional control over content lifetime in the client's local cache with the configurable C<Expires> HTTP header. -=item * Optional support for server-side caching of the dynamically -generated (and compressed) content. +=item * Optional support for server-side caching of the dynamically generated (and compressed) content. =item * Optional extra-light compression -removal of leading blank spaces and/or blank lines, -which works for all browsers, +removal of leading blank spaces and/or blank lines, which works for all browsers, including older ones that cannot uncompress gzip format. =back - =item * Apache::Gzip -an example of mod_perl filter developed by Lincoln Stein and Doug -MacEachern for their book I<Writing Apache Modules with Perl and C> -(U.S.), which like C<Apache::Compress> works through C<Apache::Filter>. +an example of the mod_perl filter developed by Lincoln Stein and Doug MacEachern +for their book I<Writing Apache Modules with Perl and C> (U.S.), +which like C<Apache::Compress> works through C<Apache::Filter>. C<Apache::Gzip> is not available from CPAN. -The source code may be found on the book's companion web site at -L<http://www.modperl.com/> +The source code may be found on the book's companion Web site at L<http://www.modperl.com/> =item * Apache::GzipChain -a mod_perl handler developed by Andreas Koenig (Germany), which -compresses output through C<Apache::OutputChain> using the gzip format. +a mod_perl handler developed by Andreas Koenig (Germany), +which compresses output through C<Apache::OutputChain> using the gzip format. C<Apache::GzipChain> currently provides in-memory compression only. -Using this module under C<perl-5.8> or higher is appropriate for Unicode data. -UTF-8 data passed to C<Compress::Zlib::memGzip()> are converted to raw -UTF-8 before compression takes place. +Use of this module under C<perl-5.8> or higher is appropriate for Unicode data. +UTF-8 data passed to C<Compress::Zlib::memGzip()> are converted to raw UTF-8 before compression takes place. Other data are simply passed through. =back -=head1 Q: Is it possible to compress the output from C<Apache::Registry> -with C<Apache::Dynagzip>? +=head1 Q: What is the typical overhead in terms of CPU use for the content compression? + +=head2 A: Typical CPU overhead that originates from content compression is insignificant. -=head2 A: Yes, it is supposed to be pretty easy: +In my observations of data compression of files of up to 200K it takes less then 60 ms CPU on a P4 3 GHz processor. +I could not measure the lower boundary reliably for dynamic compression, because there are no really measurable latency. +From the perspective of global architecture and scalability planning, +I would suggest allowing some 10 ms per request on I<regular> Web pages +in order to roughly estimate/predict the performance of the application server. -If your page/application is initially configured like +Estimation of connection times is an even less exact matter for of a variety of possible network-related reasons. +The worst-case scenario is pretty impressive: a slow dialup connection through an ISP with no proxy/buffering +holds the provider's socket for a time interval proportionate to the size of the requested file. +At present, gzip reduces this connection time by a factor of approximately 3-20. +If the ISP buffers its traffic, however, the content provider might not feel a dramatic impact -- apart of the fact +that they are paying their telecom providers for the transmission of considerable unnecessary data. + +=head1 Q: Is it possible to compress the output from C<Apache::Registry> with C<Apache::Dynagzip>? + +=head2 A: Yes. This should be fairly easy to accomplish, as follows: + +If your page/application is initially configured like this: <Directory /path/to/subdirectory> SetHandler perl-script @@ -241,7 +222,7 @@ Options +ExecCGI </Directory> -you might want just to replace it with the following: +you might replace it with the following: PerlModule Apache::Filter PerlModule Apache::Dynagzip @@ -256,24 +237,23 @@ PerlSetVar LightCompression On </Directory> -You should be all set usually after that. +You should usually be all set after that. -In more common cases you need to replace the line +In more common cases, you will need to replace the line: PerlHandler Apache::Registry -in your initial configuration file with the set of the following lines: +in your initial configuration file with the following lines: PerlHandler Apache::RegistryFilter Apache::Dynagzip PerlSetVar Filter On PerlFixupHandler Apache::CompressClientFixup -You might want to add optionally +Optionally, you might add: PerlSetVar LightCompression On -to reduce the size of the stream even for clients incapable to speak gzip -(like I<Microsoft Internet Explorer> over HTTP/1.0). +to reduce the size of the stream for clients unable to speak gzip (like I<Microsoft Internet Explorer> over HTTP/1.0). Finally, make sure you have somewhere declared @@ -281,16 +261,30 @@ PerlModule Apache::Dynagzip PerlModule Apache::CompressClientFixup -This basic configuration uses many defaults. -See C<Apache::Dynagzip> POD for further thin tuning if required. +This basic configuration uses many defaults. See C<Apache::Dynagzip> POD for further fine tuning if required. + +Note, however, that C<Apache::RegistryFilter> is not I<yet another> C<Apache::Registry>. +You may need to adjust your script in accordance with requirements of C<Apache::Filer> first, +especially when the script generates any CGI/1.1-specific HTTP headers. +You can test your compatibility with the C<Apache::Filter> chain using a temporary configuration like: + + PerlModule Apache::Filter + <Directory /path/to/subdirectory> + SetHandler perl-script + PerlHandler Apache::RegistryFilter + PerlSendHeader On + Options +ExecCGI + PerlSetVar Filter On + </Directory> + +with no C<Apache::Dynagzip> involved. +See C<Apache::Filter> documentation if you have any problems. -=head1 Q: Is it possible to compress the output from Mason-driven application -with C<Apache::Dynagzip>? +=head1 Q: Is it possible to compress output from a Mason-driven application with C<Apache::Dynagzip>? -=head2 A: Yes. C<HTML::Mason::ApacheHandler> is compatible with -C<Apache::Filter> chain. +=head2 A: Yes. C<HTML::Mason::ApacheHandler> is compatible with the C<Apache::Filter> chain. -If your application is initially configured like +If your application is initially configured like: PerlModule HTML::Mason::ApacheHandler <Directory /path/to/subdirectory> @@ -300,7 +294,7 @@ </FilesMatch> </Directory> -you might want just to replace it with the following: +you may wish to replace it with the following: PerlModule HTML::Mason::ApacheHandler PerlModule Apache::Dynagzip @@ -317,57 +311,72 @@ You should be all set safely after that. -In more common cases you need to replace the line +In more common cases, you will need to replace the line: PerlHandler HTML::Mason::ApacheHandler -in your initial configuration file with the set of the following lines: +in your initial configuration file with the following lines: PerlHandler HTML::Mason::ApacheHandler Apache::Dynagzip PerlSetVar Filter On PerlFixupHandler Apache::CompressClientFixup -You might want to add optionally +Optionally, you might add: PerlSetVar LightCompression On -to reduce the size of the stream even for clients incapable to speak gzip -(like I<Microsoft Internet Explorer> over HTTP/1.0). +to reduce the size of the stream for clients unable to speak gzip (like I<Microsoft Internet Explorer> over HTTP/1.0). Finally, make sure you have somewhere declared PerlModule Apache::Dynagzip PerlModule Apache::CompressClientFixup -This basic configuration uses many defaults. -See C<Apache::Dynagzip> POD for further thin tuning. +This basic configuration uses many defaults. See C<Apache::Dynagzip> POD for further fine tuning. -=head1 Q: Why is it important to keep control over chunk size? +=head1 Q: Is commercial support available for C<Apache::Dynagzip>? -=head2 A: It helps to reduce the latency of the response. +=head2 A: Yes. I<Slav Company, Ltd.> provides commercial support for C<Apache::Dynagzip> worldwide. -C<Apache::Dynagzip> is the only handler to date -that begins transmission of compressed data as soon -as the initial uncompressed pieces of data arrive -from their source, at a time when the source process -may not even have completed generating the full document -it is sending. -Transmission can therefore be taking place concurrent -with creation of later document content. - -This feature is mainly beneficial for HTTP/1.1 requests, -because HTTP/1.0 does not support chunks. - -I would also mention -that the internal buffer in C<Apache::Dynagzip> -always prevents Apache from the creating too short chunks over HTTP/1.1, -or from transmitting too short pieces of data over HTTP/1.0. - -=head1 Q: Are there any content compression solutions for vanilla Apache 1.3.X? - -=head2 A: Yes, There are two compression modules -written in C that are available -for vanilla Apache 1.3.X: +Since the author of C<Apache::Dynagzip> is employed by Slav Company, service is effective and consistent. + +=head1 Q: Why is it important to maintain a control over the chunk size? + +=head2 A: It helps to reduce response latency. + +C<Apache::Dynagzip> is the only handler to date that begins transmission of compressed data as soon +as the initial uncompressed pieces of data arrive from their source, at a time when the source process +may not even have completed generating the full document it is sending. +Transmission can therefore take place concurrently with creation of later document content. + +This feature is mainly beneficial for HTTP/1.1 requests, because HTTP/1.0 does not support chunks. + +I would also mention that the internal buffer in C<Apache::Dynagzip> always prevents Apache +from the creating too short chunks over HTTP/1.1, or from transmitting too short pieces of data over HTTP/1.0. + +=head1 Q: Is it worthwhile to strip leading blank spaces prior to gzip compression? + +=head2 A: Yes. It is usually worthwhile to do this. + +The benefits of blank space stripping are mostly significant for non-gzipped data transmissions. +One can expect some 5-20% reduction in stream size on regular 'structured' HTML, JavaScript, CSS, XML, etc., +in this case at negligible cost in terms of CPU overhead and response delay. + +After applying gzip compression, the benefits of previously applied blank space stripping are usually reduced +to some 0.5-1.0% of the resulting size, because gzip compresses blank spaces very effectively. +It is still worthwhile, however, to perform blank space stripping because: + +=over 4 + +=item * chances are that your handler will ultimately have to send an uncompressed response back to a known buggy client; + +=item * it really costs next-to-nothing, and every little bit helps to reduce the cost of data transmission, especially considering the cumulative effect of frequent repetitions. + +=back + +=head1 Q: Are there any content compression solutions for vanilla Apache 1.3? + +=head2 A: Yes. There are two compression modules written in C that are available for vanilla Apache 1.3: =over 4 @@ -377,101 +386,94 @@ =item * mod_gzip -an Apache handler written in C. Original author: Kevin Kiley, I<Remote -Communications, Inc.> (U.S.) +an Apache handler written in C, originally by Kevin Kiley, I<Remote Communications, Inc.> (U.S.) =back -Both of these modules support HTTP/1.0 only. +See their respective documentation for further details. =head1 Q: Can I compress the output of my site at the application level? -=head2 A: Yes, if your web server is CGI/1.1 compatible and allows you -to create specific HTTP headers from your application, -or when you use an application framework -that carries its own handler capable of compressing outbound data. - -For example, vanilla Apache 1.3.X is CGI/1.1 compatible. -It allows development of CGI scripts/programs that might be generating -compressed outgoing streams accomplished with specific HTTP headers. - -Alternatively, on mod_perl enabled Apache some application environments -carry their own compression code that could be activated through -the appropriate configurations: +=head2 A: Yes, if your Web server is CGI/1.1 compatible and allows you to create specific HTTP headers from your application, or when you use an application framework that carries its own handler capable of compressing outbound data. + +For example, vanilla Apache 1.3 is CGI/1.1 compatible. +It allows development of CGI scripts/programs that can generate compressed outgoing streams +accomplished with specific HTTP headers. + +Alternatively, on mod_perl enabled Apache, some application environments carry their own compression code +that can be activated through appropriate configuration: C<Apache::ASP> does this with the C<CompressGzip> setting; C<Apache::AxKit> uses the C<AxGzipOutput> setting to do this. -See particular package documentation for details. +See the documentation for the particular packages for details. =head1 Q: Are there any content compression solutions for Apache-2? -=head2 A: Yes, a core compression module written in C, -C<mod_deflate>, has recently become available for Apache-2. - -C<mod_deflate> for Apache-2 is written by Ian Holsman (USA). +=head2 A: Yes. A core compression module written in C, C<mod_deflate>, is available for Apache-2. -This module supports HTTP/1.1 and is filters compatible. +C<mod_deflate> for Apache-2 was written by Ian Holsman (USA). -Despite its name C<mod_deflate> for Apache-2 provides C<gzip>-encoded content. -It contains a set of configuration options sufficient to keep control -over all recently known buggy web clients. - -=head1 Q: When C<Apache::Dynagzip> is supposed to be ported to Apache-2? - -=head2 A: There no recent plans to port C<Apache::Dynagzip> to Apache-2: - -C<mod_deflate> for Apache-2 seems to be capable to provide all basic functionality -required for dynamic content compression: +Despite its name, C<mod_deflate> for Apache-2 provides C<gzip>-encoded content. +In accordance with the concept of output filters that was introduced in Apache-2, +C<mod_deflate> is capable of gzipping outbound traffic from any content generator, including CGI, Java, mod_perl, etc. =over 4 -=item * This module supports flushing over HTTP/1.1 +=item * This module supports flushing. -=item * It is filters compatible. +=item * It is output filter-compatible. -=item * It has a set of configuration options to keep control over the buggy clients. +=item * It has its own set of configuration options to maintain control over buggy clients. =back -The rest of the main C<Apache::Dynagzip> options could be easily addressed -through the implementation of pretty tiny and specific accomplishing filters. +=head1 Q: When is C<Apache::Dynagzip> supposed to be ported to Apache-2? -=head1 Q: Where can I read the original descriptions of C<gzip> -and C<deflate> formats? +=head2 A: There are no current plans to port C<Apache::Dynagzip> to Apache-2: -=head2 A: C<gzip> format is published as rfc1952, -and C<deflate> format is published as rfc1951. +C<mod_deflate> for Apache-2 is capable of providing all basic functionality required for effective +dynamic content compression. +The rest can be easily addressed through implementation of the accompanying specific, tiny filters. +For instance, C<Apache::Clean>, which is already ported to Apache-2, can be used +to strip unnecessary blank spaces from outbound streams. + +=head1 Q: Where can I read the original descriptions of the C<gzip> and C<deflate> formats? + +=head2 A: C<gzip> format is published as rfc1952, and C<deflate> format is published as rfc1951. You can find many mirrors of RFC archives on the Internet. Try, for instance, my favorite at L<http://www.ietf.org/rfc.html> =head1 Q: Are there any known compression problems with specific browsers? -=head2 A: Yes, Netscape 4 has problems with compressed cascading style sheets -and JavaScript files. +=head2 A: Yes. Netscape 4 has problems with compressed cascading style sheets and JavaScript files. + +You can use C<Apache::CompressClientFixup> to disable compression for these files dynamically on Apache-1.3. +C<Apache::Dynagzip> is capable of providing so-called C<light compression> for these files. -You can use C<Apache::CompressClientFixup> to disable compression -for these files dynamically. -C<Apache::Dynagzip> is capable of providing -so-called C<light compression> for these files. +On Apache-2, C<mod_deflate> can be configured to disable compression for these files dynamically, +and the C<Apache::Clean> filter can be used to strip unnecessary blank spaces. =head1 Q: Where can I find more information about the compression features of modern browsers? =head2 A: Michael Schroepl maintains a highly valuable site -Try it at L<http://www.schroepl.net/projekte/mod_gzip/browser.htm> +See it at L<http://www.schroepl.net/projekte/mod_gzip/browser.htm> =head1 Acknowledgments -I highly appreciate efforts of Dan Hansen -done in order to make this text better English... +During this work, I received a great deal of real help +from Kevin Kiley, Igor Sysoev, Michel Schroepl, and Henrik Nordstrom. +I'm thankful to all subscribers of mod_perl users mailing list, mod_gzip mailing list, and squid users mailing list +for the questions and discussions regarding the content compression. +I'm especially thankful to Stas Bekman for the initiative to publish this FAQ on mod_perl Web site. +I highly value patient efforts of Dan Hansen in making this text better English... =head1 Maintainers -The maintainer is the person you should contact with updates, -corrections and patches. +The maintainer is the person you should contact with updates, corrections and patches. =over @@ -491,7 +493,6 @@ =back -Only the major authors are listed above. For contributors see the -Changes file. +Only the major authors are listed above. For contributors see the Changes file. =cut --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]