Re: Books - was How practical is that Practical mod_perl?
Alex McLintock wrote: At 17:40 12/06/03 -0400, Perrin Harkins wrote: On Thu, 2003-06-12 at 17:31, Gedanken wrote: speaking of mod perl books, i have gotten lost somewhere. theres the eagle book, theres stas' book (practical mod_perl i learned today), and theres 'geoffs book'. what is the name of geoffs book please? It's mod_perl Developer's Cookbook. You can find info on all the known books linked from the front page of perl.apache.org: http://perl.apache.org/docs/offsite/books.html - Perrin By the way. My book reviews website http://news.diversebooks.com/ has reviews of several perl books. The system is being enhanced to make it easier to submit, find, and link to book reviews. (And yes - new development is being done in perl) Any feedback on how what sort of book reviews you like, and what you find uesful is welcome. This site seems to be offline. In any case if it's still alive, I'd suggest to ask perl.org webmasters to link to 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: Books - was How practical is that Practical mod_perl?
At 17:40 12/06/03 -0400, Perrin Harkins wrote: On Thu, 2003-06-12 at 17:31, Gedanken wrote: speaking of mod perl books, i have gotten lost somewhere. theres the eagle book, theres stas' book (practical mod_perl i learned today), and theres 'geoffs book'. what is the name of geoffs book please? It's mod_perl Developer's Cookbook. You can find info on all the known books linked from the front page of perl.apache.org: http://perl.apache.org/docs/offsite/books.html - Perrin By the way. My book reviews website http://news.diversebooks.com/ has reviews of several perl books. The system is being enhanced to make it easier to submit, find, and link to book reviews. (And yes - new development is being done in perl) Any feedback on how what sort of book reviews you like, and what you find uesful is welcome. Alex
Re: How practical is that Practical mod_perl?
From this point the discussion is switched to the thread Content compressed FAQ. See you there! Thanks, Slava - Original Message - From: Perrin Harkins [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, June 13, 2003 10:20 AM Subject: Re: How practical is that Practical mod_perl? On Fri, 2003-06-13 at 03:46, Slava Bizyayev wrote: Every good book about mod_perl achievements can result in better contracts for each of us and can bring aboard new talented contributors. A bad book can damage/destroy public interest and finally can kill this technology. There are many bad books about Perl and they haven't killed it. Regardless, I think what you're forgetting here is that you are complaining about a problem that is very obscure. Personally I fail to understand: Why would I hesitate to ask list for a help being ordered to write (or review) things in which I feel not quite expert? Stas asked many times for people to review the book, and some of us did. If I were writing a book and wanted to include a small example of compression, I would expect that reading the FAQ, reading the POD for the modules, and testing one of them out with whatever browsers I have handy would be enough. I would not feel the need to run an exhaustive test of every browser ever made just for a couple of pages in a huge book that is mostly about other things. To date there are no other module around with close set of properties and options... And I can not write this in my FAQ myself. Because it would be reasonably considered an impolite behavior. You can write the simple facts of the situation. The things you just mentioned on the list about Netscape 4 support are not in the FAQ. Neither is Apache::CompressClientFixup. You need to put them there, or no one will know about these issues. For example, you could add a section like this: Q: Are there any known problems with specific browsers? A: Yes, Netscape 4 has problems with compressed cascading style sheets and JavaScript files. Apache::Dynagzip handles this by detecting Netscape 4 and leaving those files uncompressed. If you are using one of the other modules, you can use Apache::CompressClientFixup to disable compression for these files. ... You get the idea. As long as you talk about specific issues and don't generally slam the other modules, no one will be upset by it. - Perrin
Re: How practical is that Practical mod_perl?
From this point the discussion is switched to the thread Content compressed FAQ. See you there! Thanks, Slava - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: Perrin Harkins [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, June 14, 2003 3:11 AM Subject: Re: How practical is that Practical mod_perl? Slava, In my understanding you would better rewrite p.401-402 from the scratch for the next edition (which is not supposed to happen very soon, isn't it?). Otherwise, you will have to rewrite Apache::GzipChain appropriately. Whatever you decide, I would be more than happy to help you in that work. Just let me know. I will be waiting around. There is no need to wait for the next edition. Almost every technical book nowadays has an errata which keeps on growing, since the technology advance makes chunks of the book obsolete. We all know that and people are used to refer to the errata list which provides the updates and corrections if any. When the next edition comes, these updates normally get merged into the book. I think the simplest possible thing to do is this: Make sure that the tutorial on compression: http://perl.apache.org/docs/tutorials/client/compression/compression.html is up-to-date and everybody is happy with it. We will link to that document from the errata page, so all those interested in the compression state of art will read it before using it. When the time for a new edition comes, we will make sure that the link to the most up-to-date tutorial will be in the book. If you think that some of the compression-related material provided in the book is erroneous, I'd be more than happy to fix it, hopefully with a help of experts like yourself.please submit any corrections to [EMAIL PROTECTED] and we will put them online at http://modperlbook.org/. I think it's a time to start a new thread on how to improve: 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: How practical is that Practical mod_perl?
From this point the discussion is switched to the thread Content compressed FAQ. See you there! Thanks, Slava - Original Message - From: Carl Brewer [EMAIL PROTECTED] To: Stas Bekman [EMAIL PROTECTED] Cc: Slava Bizyayev [EMAIL PROTECTED]; Perrin Harkins [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, June 14, 2003 9:28 AM Subject: Re: How practical is that Practical mod_perl? Stas Bekman wrote: Slava, [chomp] I think it's a time to start a new thread on how to improve: http://perl.apache.org/docs/tutorials/client/compression/compression.html For starters, apache2/mp2 coverage. As I understand it, and my logs seem to indicate, mod_deflate compresses everything thrown at it, dynamic or otherwise :)
Re: How practical is that Practical mod_perl?
From this point the discussion is switched to the thread Content compressed FAQ. See you there! 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. Thanks, Slava - Original Message - From: David Dick [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, June 13, 2003 6:46 AM Subject: Re: How practical is that Practical mod_perl? ok, i thought you might have been referred to problems that early versions of IE6 seemed to have with gzip, or with deflate problems in mozilla/n6. Slava Bizyayev wrote: NN-4.X sends HTTP header Accept-Encoding: gzip requesting any web content. Unfortunately NN-4.X fails to ungzip css files and JavaScript libraries. It is pretty old and well-known bug in NN-4.X. To work around this bug mod_gzip uses internal procedures for recognition of NN-4.X. The similar approach is used in mod_deflate. Apache::GzipChain does not have internal resources to work around this bug. You can find on CPAN http://search.cpan.org/author/SLAVA/Apache-CompressClientFixup-0.06/ which is supposed to serve any mod_perl compressor including Apache::GzipChain, but this handler is missed in example on p.402. # From: [EMAIL PROTECTED] # To: [EMAIL PROTECTED] # Date: Wed, 15 Jan 2003 20:05:06 +0200 # # ... Our customers still include 17% Netscape 4 users, sigh ... # Thanks, Slava - Original Message - From: David Dick [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 4:41 PM Subject: Re: How practical is that Practical mod_perl? The direct implementation of the example configuration p.402 is supposed to lead you to about 15% of unsatisfied clients recently. Can we have some more information about what in the implementation leads to the unsatisfied clients?
Re: How practical is that Practical mod_perl?
Stas Bekman wrote: [...] BTW, Eric is working on creating a new site for http://modperlbook.org/ which will include the source code, errata and other useful information. We will let you know when this work has been completed. I've just put it online. Enjoy, -- Eric Cholet
Re: How practical is that Practical mod_perl?
Slava, In my understanding you would better rewrite p.401-402 from the scratch for the next edition (which is not supposed to happen very soon, isn't it?). Otherwise, you will have to rewrite Apache::GzipChain appropriately. Whatever you decide, I would be more than happy to help you in that work. Just let me know. I will be waiting around. There is no need to wait for the next edition. Almost every technical book nowadays has an errata which keeps on growing, since the technology advance makes chunks of the book obsolete. We all know that and people are used to refer to the errata list which provides the updates and corrections if any. When the next edition comes, these updates normally get merged into the book. I think the simplest possible thing to do is this: Make sure that the tutorial on compression: http://perl.apache.org/docs/tutorials/client/compression/compression.html is up-to-date and everybody is happy with it. We will link to that document from the errata page, so all those interested in the compression state of art will read it before using it. When the time for a new edition comes, we will make sure that the link to the most up-to-date tutorial will be in the book. If you think that some of the compression-related material provided in the book is erroneous, I'd be more than happy to fix it, hopefully with a help of experts like yourself.please submit any corrections to [EMAIL PROTECTED] and we will put them online at http://modperlbook.org/. I think it's a time to start a new thread on how to improve: 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: How practical is that Practical mod_perl?
Stas Bekman wrote: Slava, [chomp] I think it's a time to start a new thread on how to improve: http://perl.apache.org/docs/tutorials/client/compression/compression.html For starters, apache2/mp2 coverage. As I understand it, and my logs seem to indicate, mod_deflate compresses everything thrown at it, dynamic or otherwise :)
Re: How practical is that Practical mod_perl?
From: Ged Haywood [EMAIL PROTECTED] Sent: Friday, June 13, 2003 6:30 AM Subject: Re: How practical is that Practical mod_perl? It is unrealistic (and perhaps a little Oriental?) to refuse to accept that we make mistakes, and that we will continue to make them. It is far more constructive to prepare for them - usually one would try to minimise their impact; to acknowledge them, and if necessary to own up to them :) when they are made; and to take whatever corrective action might be called for in a timely fashion. Yes Ged, we are on the same page here. Just different words. In all the above, for several years Stas has set us a fine example. Personally I fail to understand: Why would I hesitate to ask list for a help being ordered to write (or review) things in which I feel not quite expert? Of course, it is not mandatory to do when you feel strong enough to take full responsibility for the result... I don't know if I fully understand what you're saying here. When, here on this List and on numerous occasions, Stas begged us for reviews of the text of his book, did you respond? I didn't even hear about that. Hm... I have TOTALLY missed the thread... So, what it looks like? In fact, it was stupid me who missed the call, failed to respond and to help guys timely, and is now barking like a dog, shaming others for the own fault?.. Looks like a moment of truth. I feel really sorry for the fault to help timely. I apologize especially to Stas and Eric for the hurtful words... Slava
Re: How practical is that Practical mod_perl?
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. Thanks, Slava - Original Message - From: David Dick [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, June 13, 2003 6:46 AM Subject: Re: How practical is that Practical mod_perl? ok, i thought you might have been referred to problems that early versions of IE6 seemed to have with gzip, or with deflate problems in mozilla/n6. Slava Bizyayev wrote: NN-4.X sends HTTP header Accept-Encoding: gzip requesting any web content. Unfortunately NN-4.X fails to ungzip css files and JavaScript libraries. It is pretty old and well-known bug in NN-4.X. To work around this bug mod_gzip uses internal procedures for recognition of NN-4.X. The similar approach is used in mod_deflate. Apache::GzipChain does not have internal resources to work around this bug. You can find on CPAN http://search.cpan.org/author/SLAVA/Apache-CompressClientFixup-0.06/ which is supposed to serve any mod_perl compressor including Apache::GzipChain, but this handler is missed in example on p.402. # From: [EMAIL PROTECTED] # To: [EMAIL PROTECTED] # Date: Wed, 15 Jan 2003 20:05:06 +0200 # # ... Our customers still include 17% Netscape 4 users, sigh ... # Thanks, Slava - Original Message - From: David Dick [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 4:41 PM Subject: Re: How practical is that Practical mod_perl? The direct implementation of the example configuration p.402 is supposed to lead you to about 15% of unsatisfied clients recently. Can we have some more information about what in the implementation leads to the unsatisfied clients?
Re: How practical is that Practical mod_perl?
Hi Slava, On Sat, 14 Jun 2003, Slava Bizyayev wrote: So, what it looks like? http://groups.yahoo.com/group/modperl/message/34174 Looks like a moment of truth. Yup. :) 73, Ged.
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. Thanks, Slava - Original Message - From: David Dick [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, June 13, 2003 6:46 AM Subject: Re: How practical is that Practical mod_perl? ok, i thought you might have been referred to problems that early versions of IE6 seemed to have with gzip, or with deflate problems in mozilla/n6. Slava Bizyayev wrote: NN-4.X sends HTTP header Accept-Encoding: gzip requesting any web content. Unfortunately NN-4.X fails to ungzip css files and JavaScript libraries. It is pretty old and well-known bug in NN-4.X. To work around this bug mod_gzip uses internal procedures for recognition of NN-4.X. The similar approach is used in mod_deflate. Apache::GzipChain does not have internal resources to work around this bug. You can find on CPAN http://search.cpan.org/author/SLAVA/Apache-CompressClientFixup-0.06/ which is supposed to serve any mod_perl compressor including Apache::GzipChain, but this handler is missed in example on p.402. # From: [EMAIL PROTECTED] # To: [EMAIL PROTECTED] # Date: Wed, 15 Jan 2003 20:05:06 +0200 # # ... Our customers still include 17% Netscape 4 users, sigh ... # Thanks, Slava - Original Message - From: David Dick [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 4:41 PM Subject: Re: How practical is that Practical mod_perl? The direct implementation of the example configuration p.402 is supposed to lead you to about 15% of unsatisfied clients recently. Can we have some more information about what in the implementation leads to the unsatisfied clients?
Re: How practical is that Practical mod_perl?
Hi Perrin, Thank you for the response. At least it's better to know that the book is not that bad in common sense. Let's try to talk a little (and with only minimum of emotions) about the details that just pissed me off yesterday. Every new book written about mod_perl is a very important event for the community of all people participating in development and implementation of this really good and progressive technology. This is a kind of our public face. This is a way to promote our real achievements to people who do not subscribe to this mailing list and do not read our on-line docs carefully. Every good book about mod_perl achievements can result in better contracts for each of us and can bring aboard new talented contributors. A bad book can damage/destroy public interest and finally can kill this technology. We all are in one boat over here. We should together refrain from doing mistakes (at least publicly). Personally I fail to understand: Why would I hesitate to ask list for a help being ordered to write (or review) things in which I feel not quite expert? Of course, it is not mandatory to do when you feel strong enough to take full responsibility for the result... It's my firm belief that mod_perl-made web content compression is easy recognizable and very important achievement of our community. It saves real money and allows some real providers to serve higher content volumes without increasing hardware and traffic expenditures. It might be a brilliant promoter of mod_perl if/when being introduced appropriately... Yes, I know that content compression is not in that common use to date, and I know why. Even more - I know how to fix the situation. That was why I came up here with my Apache::Dynagzip. It is really work horse: universal, flexible, and easy configurable. To date there are no other module around with close set of properties and options... And I can not write this in my FAQ myself. Because it would be reasonably considered an impolite behavior. That was a good chance with a new book... I will be thinking about your idea concerning FAQ... Thanks, Slava - Original Message - From: Perrin Harkins [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 4:13 PM Subject: Re: How practical is that Practical mod_perl? On Thu, 2003-06-12 at 03:03, Slava Bizyayev wrote: Yesterday I've finally received a long-waiting book (http://www.modperlbook.org/) written by Stas Bekman and Eric Cholet. In fact, I don't know who is that Eric Cholet Eric pre-dates you on this list by a few years. He knows his stuff. The direct implementation of the example configuration p.402 is supposed to lead you to about 15% of unsatisfied clients recently. BTW, it would be curious to see HTTP client logs from Apache::GzipChain over HTTP/1.0 and HTTP/1.1 for dynamically generated and partially flushed content. And how about SSL over HTTP/1.1? It would probably help even me to switch to the right handler finally one day. It's a 900 page book! You're talking about, what 7 pages of it? There is going to be some errata, just like there is in every other technical book. The fact is, most people do not compress their content, and those who do probably don't have as much experience with it as you do. I certainly wouldn't know about these details you're speaking of, and the FAQ which you maintain doesn't fully discuss them either. It says that Dynagzip handles them, but not that the others don't. Maybe you should add a more complete comparison. For some reason Stas forgot even to mention http://perl.apache.org/docs/tutorials/client/compression/compression.html which he personally initiated about a year ago when we discussed Apache::Dynagzip over here. Is there something wrong with that text? You can't expect every page of the mod_perl site to be mentioned in the book. From my point of view, that was namely Stas who failed in this situation. He failed to recognize that the absence of information in area that you do not understand (or don't care to understand) is always better (and much more practical), than wrong and misleading recommendations. It doesn't sound like the advice in the book is so terrible to me, just not as good as it could be. More to the point, I don't see how you can say this is all Stas' fault. Why not Eric? Why not all the technical reviewers (like me) who didn't know enough or care enough about content compression to suggest changes there? There's no need to be insulting Stas. My real question to the list subscribers (see subject line) rises from the fact that I cannot review other parts of this book with full details, and since this book provides misleading recommendations about content compression opportunities on mod_perl enabled Apache I'm not sure any more about other parts... I haven't received my copy yet, but the parts of the earlier version that I reviewed
Re: How practical is that Practical mod_perl?
NN-4.X sends HTTP header Accept-Encoding: gzip requesting any web content. Unfortunately NN-4.X fails to ungzip css files and JavaScript libraries. It is pretty old and well-known bug in NN-4.X. To work around this bug mod_gzip uses internal procedures for recognition of NN-4.X. The similar approach is used in mod_deflate. Apache::GzipChain does not have internal resources to work around this bug. You can find on CPAN http://search.cpan.org/author/SLAVA/Apache-CompressClientFixup-0.06/ which is supposed to serve any mod_perl compressor including Apache::GzipChain, but this handler is missed in example on p.402. # From: [EMAIL PROTECTED] # To: [EMAIL PROTECTED] # Date: Wed, 15 Jan 2003 20:05:06 +0200 # # ... Our customers still include 17% Netscape 4 users, sigh ... # Thanks, Slava - Original Message - From: David Dick [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 4:41 PM Subject: Re: How practical is that Practical mod_perl? The direct implementation of the example configuration p.402 is supposed to lead you to about 15% of unsatisfied clients recently. Can we have some more information about what in the implementation leads to the unsatisfied clients?
Re: How practical is that Practical mod_perl?
Hi Stas, In my understanding you would better rewrite p.401-402 from the scratch for the next edition (which is not supposed to happen very soon, isn't it?). Otherwise, you will have to rewrite Apache::GzipChain appropriately. Whatever you decide, I would be more than happy to help you in that work. Just let me know. I will be waiting around. Thanks, Slava - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Perrin Harkins [EMAIL PROTECTED] Cc: Slava Bizyayev [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 6:56 PM Subject: Re: How practical is that Practical mod_perl? I've very little to add to Perrin's wise reply, other than if you find incorrect or outdated information please submit it to us and we will make sure that the corrections/additions will make it to the Errata and will be rectified in the future editions. For example Chris Winters emailed me telling that Appendix B (Apache Perl Modules) doesn't mention OpenInteract. So it'll be mentioned in the next update. BTW, Eric is working on creating a new site for http://modperlbook.org/ which will include the source code, errata and other useful information. We will let you know when this work has been completed. __ 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: How practical is that Practical mod_perl?
Hi all, On Fri, 13 Jun 2003, Slava Bizyayev wrote: We should together refrain from doing mistakes (at least publicly). It is unrealistic (and perhaps a little Oriental?) to refuse to accept that we make mistakes, and that we will continue to make them. It is far more constructive to prepare for them - usually one would try to minimise their impact; to acknowledge them, and if necessary to own up to them :) when they are made; and to take whatever corrective action might be called for in a timely fashion. In all the above, for several years Stas has set us a fine example. Personally I fail to understand: Why would I hesitate to ask list for a help being ordered to write (or review) things in which I feel not quite expert? Of course, it is not mandatory to do when you feel strong enough to take full responsibility for the result... I don't know if I fully understand what you're saying here. When, here on this List and on numerous occasions, Stas begged us for reviews of the text of his book, did you respond? Many of us did. If we missed some mistakes we will all share the blame and I for one am quite happy with that. Let's call an end to this. 73, Ged.
Re: How practical is that Practical mod_perl?
ok, i thought you might have been referred to problems that early versions of IE6 seemed to have with gzip, or with deflate problems in mozilla/n6. Slava Bizyayev wrote: NN-4.X sends HTTP header Accept-Encoding: gzip requesting any web content. Unfortunately NN-4.X fails to ungzip css files and JavaScript libraries. It is pretty old and well-known bug in NN-4.X. To work around this bug mod_gzip uses internal procedures for recognition of NN-4.X. The similar approach is used in mod_deflate. Apache::GzipChain does not have internal resources to work around this bug. You can find on CPAN http://search.cpan.org/author/SLAVA/Apache-CompressClientFixup-0.06/ which is supposed to serve any mod_perl compressor including Apache::GzipChain, but this handler is missed in example on p.402. # From: [EMAIL PROTECTED] # To: [EMAIL PROTECTED] # Date: Wed, 15 Jan 2003 20:05:06 +0200 # # ... Our customers still include 17% Netscape 4 users, sigh ... # Thanks, Slava - Original Message - From: David Dick [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 4:41 PM Subject: Re: How practical is that Practical mod_perl? The direct implementation of the example configuration p.402 is supposed to lead you to about 15% of unsatisfied clients recently. Can we have some more information about what in the implementation leads to the unsatisfied clients?
Re: How practical is that Practical mod_perl?
On Fri, 2003-06-13 at 03:46, Slava Bizyayev wrote: Every good book about mod_perl achievements can result in better contracts for each of us and can bring aboard new talented contributors. A bad book can damage/destroy public interest and finally can kill this technology. There are many bad books about Perl and they haven't killed it. Regardless, I think what you're forgetting here is that you are complaining about a problem that is very obscure. Personally I fail to understand: Why would I hesitate to ask list for a help being ordered to write (or review) things in which I feel not quite expert? Stas asked many times for people to review the book, and some of us did. If I were writing a book and wanted to include a small example of compression, I would expect that reading the FAQ, reading the POD for the modules, and testing one of them out with whatever browsers I have handy would be enough. I would not feel the need to run an exhaustive test of every browser ever made just for a couple of pages in a huge book that is mostly about other things. To date there are no other module around with close set of properties and options... And I can not write this in my FAQ myself. Because it would be reasonably considered an impolite behavior. You can write the simple facts of the situation. The things you just mentioned on the list about Netscape 4 support are not in the FAQ. Neither is Apache::CompressClientFixup. You need to put them there, or no one will know about these issues. For example, you could add a section like this: Q: Are there any known problems with specific browsers? A: Yes, Netscape 4 has problems with compressed cascading style sheets and JavaScript files. Apache::Dynagzip handles this by detecting Netscape 4 and leaving those files uncompressed. If you are using one of the other modules, you can use Apache::CompressClientFixup to disable compression for these files. ... You get the idea. As long as you talk about specific issues and don't generally slam the other modules, no one will be upset by it. - Perrin
Re: How practical is that Practical mod_perl?
It arrived, today. (Practical mod_perl ) My first impression was ...!, this is a Fat Book!!! while I browse the book, I found some chapters importants. I believe that all know to Stas Bekman for your contributions to mod_perl documentation and tests, this is a good book, and I hope to discuss his content with us. Regards. Perrin Harkins wrote: On Fri, 2003-06-13 at 03:46, Slava Bizyayev wrote: Every good book about mod_perl achievements can result in better contractsfor each of us and can bring aboard new talented contributors. A bad bookcan damage/destroy public interest and finally can kill this technology. There are many bad books about Perl and they haven't killed it. Regardless, I think what you're forgetting here is that you arecomplaining about a problem that is very obscure. Personally I fail to understand: Why would Ihesitate to ask list for a help being ordered to write (or review) things inwhich I feel not quite expert? Stas asked many times for people to review the book, and some of us did.If I were writing a book and wanted to include a small example ofcompression, I would expect that reading the FAQ, reading the POD forthe modules, and testing one of them out with whatever browsers I havehandy would be enough. I would not feel the need to run an exhaustivetest of every browser ever made just for a couple of pages in a hugebook that is mostly about other things. To date there are no other module aroundwith close set of properties and options... And I can not write this in myFAQ myself. Because it would be reasonably considered an impolite behavior. You can write the simple facts of the situation. The things you justmentioned on the list about Netscape 4 support are not in the FAQ. Neither is Apache::CompressClientFixup. You need to put them there, orno one will know about these issues.For example, you could add a section like this:Q: Are there any known problems with specific browsers?A: Yes, Netscape 4 has problems with compressed cascading style sheetsand _javascript_ files. Apache::Dynagzip handles this by detectingNetscape 4 and leaving those files uncompressed. If you are using oneof the other modules, you can use Apache::CompressClientFixup to disablecompression for these files You get the idea. As long as you talk about specific issues anddon't generally slam the other modules, no one will be upset by it.- Perrin
How practical is that Practical mod_perl?
Yesterday I've finally received a long-waiting book (http://www.modperlbook.org/) written by Stas Bekman and Eric Cholet. In fact, I don't know who is that Eric Cholet, but the presence of the name of Stas Bekman was enough in my case to decide, how important the book is supposed to be for me in order to optimize Apache configurations and perl code. I did never really plan to write any review of this book just because I feel not strong enough to discuss recommendations of the well-known leader of modern mod_perl development. Indeed, I've got confused and disappointed when found that the book covers some area of my own expertise inappropriately. I'm talking about Chapter 11 (p.401-402) and Appendix B (p.784-787). In Chapter 11 I was surprised to learn that Stas practically uses Apache::GzipChain as a universal tool for web content compression. The direct implementation of the example configuration p.402 is supposed to lead you to about 15% of unsatisfied clients recently. BTW, it would be curious to see HTTP client logs from Apache::GzipChain over HTTP/1.0 and HTTP/1.1 for dynamically generated and partially flushed content. And how about SSL over HTTP/1.1? It would probably help even me to switch to the right handler finally one day. Then the reader has to learn that mod_gzip and mod_deflate can serve only static outgoing files. To the best of my knowledge it's just a false, and I would bet my hardly earned buck against Stas' dime that average programmer like me would be able to configure practically mod_gzip to compress dynamic content (over HTTP/1.0). For some reason Stas forgot even to mention http://perl.apache.org/docs/tutorials/client/compression/compression.html which he personally initiated about a year ago when we discussed Apache::Dynagzip over here. Is there something wrong with that text? Any questions, discussions, and/or suggestions are still very welcome. I hope the list subscribers understand that I'm writing this words with full respect and no attempt to shame Andreas Koenig for the Apache::GzipChain, or Ken Williams for Apache::Compress, or any other author of any other compression handler mentioned in the book. Every one of them was a great pioneer in proper practical implementation of mod_perl, and everyone did his best. From my point of view, that was namely Stas who failed in this situation. He failed to recognize that the absence of information in area that you do not understand (or don't care to understand) is always better (and much more practical), than wrong and misleading recommendations. My real question to the list subscribers (see subject line) rises from the fact that I cannot review other parts of this book with full details, and since this book provides misleading recommendations about content compression opportunities on mod_perl enabled Apache I'm not sure any more about other parts... Any thoughts? Thanks, Slava
Re: How practical is that Practical mod_perl?
On Thu, 2003-06-12 at 03:03, Slava Bizyayev wrote: Yesterday I've finally received a long-waiting book (http://www.modperlbook.org/) written by Stas Bekman and Eric Cholet. In fact, I don't know who is that Eric Cholet Eric pre-dates you on this list by a few years. He knows his stuff. The direct implementation of the example configuration p.402 is supposed to lead you to about 15% of unsatisfied clients recently. BTW, it would be curious to see HTTP client logs from Apache::GzipChain over HTTP/1.0 and HTTP/1.1 for dynamically generated and partially flushed content. And how about SSL over HTTP/1.1? It would probably help even me to switch to the right handler finally one day. It's a 900 page book! You're talking about, what 7 pages of it? There is going to be some errata, just like there is in every other technical book. The fact is, most people do not compress their content, and those who do probably don't have as much experience with it as you do. I certainly wouldn't know about these details you're speaking of, and the FAQ which you maintain doesn't fully discuss them either. It says that Dynagzip handles them, but not that the others don't. Maybe you should add a more complete comparison. For some reason Stas forgot even to mention http://perl.apache.org/docs/tutorials/client/compression/compression.html which he personally initiated about a year ago when we discussed Apache::Dynagzip over here. Is there something wrong with that text? You can't expect every page of the mod_perl site to be mentioned in the book. From my point of view, that was namely Stas who failed in this situation. He failed to recognize that the absence of information in area that you do not understand (or don't care to understand) is always better (and much more practical), than wrong and misleading recommendations. It doesn't sound like the advice in the book is so terrible to me, just not as good as it could be. More to the point, I don't see how you can say this is all Stas' fault. Why not Eric? Why not all the technical reviewers (like me) who didn't know enough or care enough about content compression to suggest changes there? There's no need to be insulting Stas. My real question to the list subscribers (see subject line) rises from the fact that I cannot review other parts of this book with full details, and since this book provides misleading recommendations about content compression opportunities on mod_perl enabled Apache I'm not sure any more about other parts... I haven't received my copy yet, but the parts of the earlier version that I reviewed were very good. The book covers a huge amount of ground, and is pretty much the only source of information outside of the on-line guide that discusses many of these real-world issues. It is based on the discussions and discoveries that have taken place on this list over the years, and is a great source of info for anyone who doesn't want to dig through all the old posts to get up to speed. - Perrin
Re: Books - was How practical is that Practical mod_perl?
speaking of mod perl books, i have gotten lost somewhere. theres the eagle book, theres stas' book (practical mod_perl i learned today), and theres 'geoffs book'. what is the name of geoffs book please? i wanna have all 3 after reading the reviews yet geoffs last name is escaping me. -- gedanken
Re: Books - was How practical is that Practical mod_perl?
On Thu, 2003-06-12 at 17:31, Gedanken wrote: speaking of mod perl books, i have gotten lost somewhere. theres the eagle book, theres stas' book (practical mod_perl i learned today), and theres 'geoffs book'. what is the name of geoffs book please? It's mod_perl Developer's Cookbook. You can find info on all the known books linked from the front page of perl.apache.org: http://perl.apache.org/docs/offsite/books.html - Perrin
