Re: Content compression FAQ
On Mon, 21 Jul 2003, Slava Bizyayev wrote: I will patch FAQ with this shortly. Well but what does HTTP/1.1 support mean ? As far as I know the compressing has not any HTTP/1.1 specific features. mod_deflate compresses content using 8K buffer. When the buffer is filled mod_deflate passes the compressed data to Apache. Sorry, I had mixed up with gzipping module of my upcoming lightweight http and reverse-proxy server. mod_deflate does not wait to fill up a whole 8K buffer, it passes the compressed data to Apache as soon as it is available. And also it supports flushing the compressed data as described below. If an upstream module calls ap_bflush() to flush a pending data then mod_deflate asks zlib to flush a compressed stream and then passes a partially filled buffer to Apache. Since flushing a compressed stream descreases a compression ratio so mod_deflate has DeflateIgnoreFlush to ignore the ap_bflush() calls of an upstream module. It can be used for example with Chili!Soft ASP that calls ap_bflush() after any output even after an output of several bytes. Igor Sysoev http://sysoev.ru/en/
Re: Content compression FAQ
On Sat, 19 Jul 2003, Slava Bizyayev wrote: Here is small correction to Web Content Compression FAQ. What does HTTP/1.0 only support mean in this answer: Q: Are there any content compression solutions for vanilla Apache 1.3.X? A: Yes, There are two compression modules written in C that are available for vanilla Apache 1.3.X: * mod_deflate an Apache handler written in C by Igor Sysoev (Russia). * mod_gzip an Apache handler written in C. Original author: Kevin Kiley, Remote Communications, Inc. (U.S.) Both of these modules support HTTP/1.0 only. mod_deflate does not care about chunks at all - Apache does it. If Apache's responses is HTTP/1.1 then Apache send it in chunks because mod_deflate always deletes Content-Length header. mod_deflate compresses content using 8K buffer. When the buffer is filled mod_deflate passes the compressed data to Apache. If an upstream module calls ap_bflush() to flush a pending data then mod_deflate asks zlib to flush a compressed stream and then passes a partially filled buffer to Apache. Since flushing a compressed stream descreases a compression ratio so mod_deflate has DeflateIgnoreFlush to ignore the ap_bflush() calls of an upstream module. It can be used for example with Chili!Soft ASP that calls ap_bflush() after any output even after an output of several bytes. So mod_deflate as well as Apache::Dynagzip are the only handlers 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. Igor Sysoev http://sysoev.ru/en/
Re: Content compression FAQ
Thank you Igor, I will patch FAQ with this shortly. Slava - Original Message - From: Igor Sysoev [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: Stas Bekman [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, July 21, 2003 5:19 AM Subject: Re: Content compression FAQ On Sat, 19 Jul 2003, Slava Bizyayev wrote: Here is small correction to Web Content Compression FAQ. What does HTTP/1.0 only support mean in this answer: Q: Are there any content compression solutions for vanilla Apache 1.3.X? A: Yes, There are two compression modules written in C that are available for vanilla Apache 1.3.X: * mod_deflate an Apache handler written in C by Igor Sysoev (Russia). * mod_gzip an Apache handler written in C. Original author: Kevin Kiley, Remote Communications, Inc. (U.S.) Both of these modules support HTTP/1.0 only. mod_deflate does not care about chunks at all - Apache does it. If Apache's responses is HTTP/1.1 then Apache send it in chunks because mod_deflate always deletes Content-Length header. mod_deflate compresses content using 8K buffer. When the buffer is filled mod_deflate passes the compressed data to Apache. If an upstream module calls ap_bflush() to flush a pending data then mod_deflate asks zlib to flush a compressed stream and then passes a partially filled buffer to Apache. Since flushing a compressed stream descreases a compression ratio so mod_deflate has DeflateIgnoreFlush to ignore the ap_bflush() calls of an upstream module. It can be used for example with Chili!Soft ASP that calls ap_bflush() after any output even after an output of several bytes. So mod_deflate as well as Apache::Dynagzip are the only handlers 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. Igor Sysoev http://sysoev.ru/en/
Re: Content compression FAQ
Slava Bizyayev wrote: Oops, sorry for that. It should be OK now. http://devl4.outlook.net/devdoc/FAQ/compression.pod Thanks, committed __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Content compression FAQ
Thanks Stas! Full POD file is available now at http://devl4.outlook.net/devdoc/FAQ/compression.pod Slava - Original Message - From: Stas Bekman [EMAIL PROTECTED] Sent: Monday, July 14, 2003 12:42 AM Subject: Re: Content compression FAQ Great work, Slava. Please send the diff (or probably just the whole thing), or the URL where we can download it from and we'll update http://perl.apache.org/docs/tutorials/client/compression/compression.html
Re: Content compression FAQ
Slava Bizyayev wrote: Thanks Stas! Full POD file is available now at http://devl4.outlook.net/devdoc/FAQ/compression.pod Forbidden You don't have permission to access /devdoc/FAQ/compression.pod on this server. Slava - Original Message - From: Stas Bekman [EMAIL PROTECTED] Sent: Monday, July 14, 2003 12:42 AM Subject: Re: Content compression FAQ Great work, Slava. Please send the diff (or probably just the whole thing), or the URL where we can download it from and we'll update http://perl.apache.org/docs/tutorials/client/compression/compression.html -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Content compression FAQ
Oops, sorry for that. It should be OK now. ;-( Slava - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: mod_perl Mailing List [EMAIL PROTECTED] Sent: Saturday, July 19, 2003 3:29 PM Subject: Re: Content compression FAQ Slava Bizyayev wrote: Thanks Stas! Full POD file is available now at http://devl4.outlook.net/devdoc/FAQ/compression.pod Forbidden You don't have permission to access /devdoc/FAQ/compression.pod on this server. Slava - Original Message - From: Stas Bekman [EMAIL PROTECTED] Sent: Monday, July 14, 2003 12:42 AM Subject: Re: Content compression FAQ Great work, Slava. Please send the diff (or probably just the whole thing), or the URL where we can download it from and we'll update http://perl.apache.org/docs/tutorials/client/compression/compression.html -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mod_perl] Re: Content compression FAQ
Ross Matt-QMR000 wrote: I like to be removed from this list but the un-scribe does not work for me. the problem is the mail address that I used way back when has been aliases. the list's help email explains how to unsubscribe from a different address, post to [EMAIL PROTECTED] for the details. If everything else fails please contact [EMAIL PROTECTED] __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: [mod_perl] Re: Content compression FAQ
I like to be removed from this list but the un-scribe does not work for me. the problem is the mail address that I used way back when has been aliases. -Original Message- From: Jonathan M. Hollin [mailto:[EMAIL PROTECTED] Sent: Friday, July 11, 2003 2:37 AM To: Slava Bizyayev; mod_perl Mailing List Subject: Re: [mod_perl] Re: Content compression FAQ At 04/07/2003 17:29, Slava Bizyayev wrote: I've just updated the content at http://devl4.outlook.net/devdoc/FAQ/compression.html . It's very good Slava. Concise, informative and thorough. There is a small mistake in the section, Q: How hard is it to implement content compression on an existing site? Change no more that installing to no more than installing. Other than that, it looks great. Jonathan M. Hollin Digital-Word Ltd: http://digital-word.com/
Re: Content compression FAQ
Slava Bizyayev wrote: Hi everyone, I've just updated the content at http://devl4.outlook.net/devdoc/FAQ/compression.html . It is supposed to be a final version, unless I missed something important. Great work, Slava. Please send the diff (or probably just the whole thing), or the URL where we can download it from and we'll update http://perl.apache.org/docs/tutorials/client/compression/compression.html We can update it as many times as needed, so there is no really need to first perfect it. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mod_perl] Re: Content compression FAQ
At 04/07/2003 17:29, Slava Bizyayev wrote: I've just updated the content at http://devl4.outlook.net/devdoc/FAQ/compression.html . It's very good Slava. Concise, informative and thorough. There is a small mistake in the section, Q: How hard is it to implement content compression on an existing site? Change no more that installing to no more than installing. Other than that, it looks great. Jonathan M. Hollin Digital-Word Ltd: http://digital-word.com/
Re: Content compression FAQ
Hi everyone, I've just updated the content at http://devl4.outlook.net/devdoc/FAQ/compression.html . It is supposed to be a final version, unless I missed something important. Please let me know then. Thanks, Slava
Re: Content compression FAQ
It should not be considered a bugfix anymore. It is NOT required to do, because that particular story with M$IE is over. Recently, there were some problems with M$IE reported, namely a partially lost compressed content when using SSL over HTTP/1.1. It happens infrequently. The problem remains in research stage to date. It seems to be NOT a problem of compression: the problem is effectively addressed through downgrade of HTTP/1.1 to HTTP/1.0 over SSL for this browser. Then the response could be sent back compressed over HTTP/1.0. It works fine. Thanks, Slava - Original Message - From: David Dick [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, June 14, 2003 5:20 PM Subject: Re: How practical is that Practical mod_perl? or, as a bugfix for future versions of mod_perl compression modules, before compressing the page, the module should provide the option of adding 2048 bytes of spaces to the beginning of the page, which according to my quick calculations, gzips down to 46 bytes? only for ie6 of course. :) Slava Bizyayev wrote: gzip problem in IE6 http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312496 is over since 1. M$ provides a free patch; 2. those lazy users (who usually don't care to apply patches) are not able to report problems anymore. Personally, I would recommend not to deal with deflate when possible.
Re: Content compression FAQ
Slava Bizyayev wrote: It should not be considered a bugfix anymore. It is NOT required to do, because that particular story with M$IE is over. Sounds like we agree to disagree on this one. My opinion would be, if there is a known problem with a browser version that can be solved with a minimum amount of disruption to other users, then it's worth doing. For me, the prospect of adding at most 46 bytes to a compressed response is worth it. For people who need every last bit of bandwidth performance, it may not be. Hence, the bugfix should be optional. I understand that microsoft have a patch for the problem, the issue is how many people actually are using the patch? Probably the vast majority to be sure, but there ain't no way of telling. or, as a bugfix for future versions of mod_perl compression modules, before compressing the page, the module should provide the option of adding 2048 bytes of spaces to the beginning of the page, which according to my quick calculations, gzips down to 46 bytes? only for ie6 of course. :) Slava Bizyayev wrote: gzip problem in IE6 http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312496 is over since 1. M$ provides a free patch; 2. those lazy users (who usually don't care to apply patches) are not able to report problems anymore.
Re: Content compression FAQ
I have a problem with this question: From one side it is pretty simple for instance to add AddEncoding gzip .gz and to configure mod_rewrite to respond with the statically compressed content instead of plain version. It should work for any imaginable particular architecture of the site on vanilla Apache. However, you need to duplicate full functionality (and maintenance) of ClientFixup in your External Rewriting Engine. Personally I don't like this idea, because in more common cases (when you try to help many other people) it is going to grow up even over the heap of configuration features of mod_gzip. I would prefer to avoid discussions about static (and semi-static) compressions in this FAQ. I'm looking forward to discuss all this stuff next fall here under the name of Effective Content Delivery rfc. It is supposed to target Apache-2 mainly. Thanks, Slava - Original Message - From: Nigel Hamilton [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: mod_perl Mailing List [EMAIL PROTECTED] Sent: Monday, June 23, 2003 3:27 AM Subject: Re: Content compression FAQ HI SLava, Your new FAQ looks really good! I've just got one small suggestion. I've heard that compression can also work with pre-compressing files with: gzip -9 index.html - index.html.gz. And you can then configure Apache Multiviews to serve the pre-Gzipped file. This means you don't have to dynamically zip the file each time and it works with vanilla Apache 1.3. That said, I've been unable to configure Apache to do this properly. Does anyone have a clear solution that can be incorporated into SLava's new FAQ? Nige OK, the preview of a new version of FAQ is available at http://devl4.outlook.net/devdoc/FAQ/compression.html (temporarily). I cannot finish comparison of modules because the other authors are not available for discussions to date. I would probably drop the comparison until better times if you don't mind... Thanks, Slava - Original Message - From: Slava Bizyayev [EMAIL PROTECTED] To: mod_perl Mailing List [EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 1:10 AM Subject: Content compression FAQ Hello everyone again, This thread is supposed to improve Content Compression FAQ at http://perl.apache.org/docs/tutorials/client/compression/compression.html in order to assist Practical mod_perl as Stas suggested. Any of your questions, suggestions, concerns, and/or criticisms of FAQ would be highly appreciated over here. Basically, I'm going to rewrite the preamble, to make clear comparison of modules (a kind of table is expected), and to extend the list of practical questions targeting the interests of Apache administrators mainly. I would highly appreciate if somebody could offer a draft of short and clear explanation of features of Apache::Filter chain vs. Apache::OutputChain for those sysadmins who know nothing about them initially, but have to be able to configure them properly (with appropriate handlers) in the end. Please do not duplicate questions from the thread How practical... to over here. Currently I'm just placing formal redirections from that thread to this one. I will continue to answer all that questions here. Let's go ;-) Slava -- Nigel Hamilton Turbo10 Metasearch Engine email: [EMAIL PROTECTED] tel: +44 (0) 207 987 5460 fax: +44 (0) 207 987 5468 http://turbo10.com Search Deeper. Browse Faster.
Re: Content compression FAQ
OK, the preview of a new version of FAQ is available at http://devl4.outlook.net/devdoc/FAQ/compression.html (temporarily). I cannot finish comparison of modules because the other authors are not available for discussions to date. I would probably drop the comparison until better times if you don't mind... Thanks, Slava - Original Message - From: Slava Bizyayev [EMAIL PROTECTED] To: mod_perl Mailing List [EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 1:10 AM Subject: Content compression FAQ Hello everyone again, This thread is supposed to improve Content Compression FAQ at http://perl.apache.org/docs/tutorials/client/compression/compression.html in order to assist Practical mod_perl as Stas suggested. Any of your questions, suggestions, concerns, and/or criticisms of FAQ would be highly appreciated over here. Basically, I'm going to rewrite the preamble, to make clear comparison of modules (a kind of table is expected), and to extend the list of practical questions targeting the interests of Apache administrators mainly. I would highly appreciate if somebody could offer a draft of short and clear explanation of features of Apache::Filter chain vs. Apache::OutputChain for those sysadmins who know nothing about them initially, but have to be able to configure them properly (with appropriate handlers) in the end. Please do not duplicate questions from the thread How practical... to over here. Currently I'm just placing formal redirections from that thread to this one. I will continue to answer all that questions here. Let's go ;-) Slava
Re: Content compression FAQ
HI SLava, Your new FAQ looks really good! I've just got one small suggestion. I've heard that compression can also work with pre-compressing files with: gzip -9 index.html - index.html.gz. And you can then configure Apache Multiviews to serve the pre-Gzipped file. This means you don't have to dynamically zip the file each time and it works with vanilla Apache 1.3. That said, I've been unable to configure Apache to do this properly. Does anyone have a clear solution that can be incorporated into SLava's new FAQ? Nige OK, the preview of a new version of FAQ is available at http://devl4.outlook.net/devdoc/FAQ/compression.html (temporarily). I cannot finish comparison of modules because the other authors are not available for discussions to date. I would probably drop the comparison until better times if you don't mind... Thanks, Slava - Original Message - From: Slava Bizyayev [EMAIL PROTECTED] To: mod_perl Mailing List [EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 1:10 AM Subject: Content compression FAQ Hello everyone again, This thread is supposed to improve Content Compression FAQ at http://perl.apache.org/docs/tutorials/client/compression/compression.html in order to assist Practical mod_perl as Stas suggested. Any of your questions, suggestions, concerns, and/or criticisms of FAQ would be highly appreciated over here. Basically, I'm going to rewrite the preamble, to make clear comparison of modules (a kind of table is expected), and to extend the list of practical questions targeting the interests of Apache administrators mainly. I would highly appreciate if somebody could offer a draft of short and clear explanation of features of Apache::Filter chain vs. Apache::OutputChain for those sysadmins who know nothing about them initially, but have to be able to configure them properly (with appropriate handlers) in the end. Please do not duplicate questions from the thread How practical... to over here. Currently I'm just placing formal redirections from that thread to this one. I will continue to answer all that questions here. Let's go ;-) Slava -- Nigel Hamilton Turbo10 Metasearch Engine email: [EMAIL PROTECTED] tel:+44 (0) 207 987 5460 fax:+44 (0) 207 987 5468 http://turbo10.com Search Deeper. Browse Faster.
Content compression FAQ
Hello everyone again, This thread is supposed to improve Content Compression FAQ at http://perl.apache.org/docs/tutorials/client/compression/compression.html in order to assist Practical mod_perl as Stas suggested. Any of your questions, suggestions, concerns, and/or criticisms of FAQ would be highly appreciated over here. Basically, I'm going to rewrite the preamble, to make clear comparison of modules (a kind of table is expected), and to extend the list of practical questions targeting the interests of Apache administrators mainly. I would highly appreciate if somebody could offer a draft of short and clear explanation of features of Apache::Filter chain vs. Apache::OutputChain for those sysadmins who know nothing about them initially, but have to be able to configure them properly (with appropriate handlers) in the end. Please do not duplicate questions from the thread How practical... to over here. Currently I'm just placing formal redirections from that thread to this one. I will continue to answer all that questions here. Let's go ;-) Slava
