Re: Memoize.pm and mod_perl
[EMAIL PROTECTED] wrote: Has anyone used the Memoize module extensively in a mod_perl environment? I am thinking of using it to cache queries from the database, particularly for lookups (somthing like $obj-get_name_from_id()). In many cases the data is static so I don't mind is staying over from one request to the next but I wanted to primarily use to limit the number of queries per http request. To keep the cache from growing (the website receives 20 hit/min on average w/ 20,000 users) I wanted to either implement a LRU/Expiration cache. The other alternative I was considering was to use a cleanup handler after every request. I would like to know any experiences/thoughts anyone has had of using Memoize in a mod_perl environment. Memoize should work just fine under mod_perl. If you need to reset the cache between requests you should call its flush_cache() function. refer to its manpage for more info. __ 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: [RFC] web-messaging application for mod_perl
Adi Fairbank wrote: On, or in the near vicinity of Mon, 14 Jul 2003 18:49:58 +0300 Stas Bekman [EMAIL PROTECTED] has thus written: Probably the best bet is to give it some cool unique name, like Apache::AdiChat and then you are all set, since you are not going to take over [...] What's wrong with WebMessaging ? Do you foresee that interfering with some future software in the Apache:: namespace, or is it just too generic? I thought it was a good name since it accurately describes what it is: not webmail, not instant messaging, but web messaging. (basically, it's like those message boxes you get on a stock trading website when you login to your account) James has gone into a detailed reply why this could be a bad idea. I'd just add that it's very hard to choose a good name for a module. And it seems that unique k001 names never have such problems. Perhaps you can have a unique name for your application and in the future you will extract a framework from it, making your app use it and allowing other apps to do the same. So with time you will see whether Apache::WebMessaging is a good name and whether it fits well into the scope of what it's supposed to do. __ 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: untainting PATH in mod_perl
On Tue, Jul 15, 2003 at 12:19:14PM +0300, Stas Bekman wrote:
Dominique Quatravaux wrote:
Sorry, getting out of good ideas..
Surprise, surprise: I found out that my code does not work under
mod_perl 1.23 either! And I found the real solution: one has to add
PerlSetupEnv Off
to the Apache configuration file. Now the untainting mumbo-jumbo in
perl section works.
Warning: this has the consequence of breaking the part of the CGI
environment emulation that deals with environment (e.g. instead of
$ENV{HTTP_USER_AGENT}, you now have to check
Apache-request()-subprocess_env(HTTP_USER_AGENT)). Glancing at its
source code, I don't think CGI.pm will survive that...
BTW, I finally got around to reading mod_perl's source, and it
is now clear to me that the environment, when being copied from
-subprocess_env() into %ENV, gets tainted (around line 704 in
src/modules/perl/mod_perl.c). The whole %ENV gets tainted, not just
the HTTP_USER_AGENT and such from the CGI context, so PATH is tainted
as well. This explains our now common problem - and also guarantees
that there is no easy way out of it if you use CGI.pm yourself :-(.
You need to untaint the variables before you use them. Since they get reset
on every request, you need to untaint them inside your script/handler's run
time, not the BEGIN block...:
http://perl.apache.org/docs/1.0/guide/porting.html#BEGIN_blocks
it should work just fine with mp1 and mp2.
Relying on 'PerlSetupEnv Off' is not a very good idea, since if you want to
release your code for others to use, they may not be able to turn it off,
since it'll break their CGI-legacy code as you have observed.
FWIW, I use the following code when I need to use ``|qx:
local $ENV{PATH} = /bin:/usr/bin;
local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
But this code must be used in each scope where you intend to use
backticks, a system call Etc. Is there no way to untaint your
PATH environment one time for the script or handler?
P
--
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Peter B. Ensch ([EMAIL PROTECTED])
Linux 2.4.20-4GB 5:47am Up 2 days 18:47
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Apache::Registry in mod_perl 2
This page: http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache__Registry___C_Apache__PerlRun__and_Friends says that mod_perl 2's ModPerl::Registry does not chdir() into the script's directory, wheras mod_perl 1's Apache::Registry DOES chdir(). It also says that this will eventually be fixed by the time mod_perl 2 is released, and in the meantime you can use the Apache::Registry (which is part of mod_perl 1) in mod_perl 2. As I will be trying to get some old scripts working in mod_perl 2, it seems prudent to use Apache::Registry. So how can I go about installing just Apache::Registry from the mod_perl 1 tar file without having to install ALL of mod_perl 1 ? Colin __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
Re: [RFC] web-messaging application for mod_perl
hi ( 03.07.14 20:14 -0700 ) Adi Fairbank: ( I wouldn't want to have any piece of software named after me... just my personal style. Software lives for too long, especially open source. It would still be called that long after I'm dead. ) don't be too sure. no one may call it anything at all in about 6 months ... Here are the possibilities: what about Apache::Messaging::Web to leave room for other messaging modules to share this namespace [::Pager or ::Fax ...] -- \js
Re: untainting PATH in mod_perl
Peter B. Ensch wrote:
FWIW, I use the following code when I need to use ``|qx:
local $ENV{PATH} = /bin:/usr/bin;
local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
But this code must be used in each scope where you intend to use
backticks, a system call Etc. Is there no way to untaint your
PATH environment one time for the script or handler?
If you write code used by other people this is probably the only way to go.
This is because you want to control the setting. What if PATH gets untainted
at the server startup, but then some other module sets a new tainted value to
$ENV{PATH}? So it's a good habit to have it local to the code that you run.
Besides helps to avoid forking external processes. If you can rewrite your code:
foreach(`/bin/ls $path`) {
do something
}
(which is probably not the real code), not to `` but to read the file in, and
process it, you eliminate the whole problem altogether. I realize that this is
not always possible.
How about abstracting untaint and `` into a single function:
sub backticks {
local $ENV{PATH} = /bin:/usr/bin;
local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
qx(@_);
}
__
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: Apache::Registry in mod_perl 2
ColinB wrote: This page: http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache__Registry___C_Apache__PerlRun__and_Friends says that mod_perl 2's ModPerl::Registry does not chdir() into the script's directory, wheras mod_perl 1's Apache::Registry DOES chdir(). It also says that this will eventually be fixed by the time mod_perl 2 is released, and in the meantime you can use the Apache::Registry (which is part of mod_perl 1) in mod_perl 2. As I will be trying to get some old scripts working in mod_perl 2, it seems prudent to use Apache::Registry. You have omitted this sentence: However you will have problems if you are using anything but the preforked MPM, the main reason why ModPerl::Registry doesn't chdir(). So how can I go about installing just Apache::Registry from the mod_perl 1 tar file without having to install ALL of mod_perl 1 ? simply copy it into one of the dirs in your @INC. You will also need to load Apache::compat for it to work. Alternatively you can subclass ModPerl::Registry's chdir_file function to perform chdir, like Apache::Registry does. __ 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: untainting PATH in mod_perl
On Tue, Jul 15, 2003 at 04:30:35PM +0300, Stas Bekman wrote:
Peter B. Ensch wrote:
FWIW, I use the following code when I need to use ``|qx:
local $ENV{PATH} = /bin:/usr/bin;
local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
But this code must be used in each scope where you intend to use
backticks, a system call Etc. Is there no way to untaint your
PATH environment one time for the script or handler?
If you write code used by other people this is probably the only way to go.
This is because you want to control the setting. What if PATH gets
untainted at the server startup, but then some other module sets a new
tainted value to $ENV{PATH}? So it's a good habit to have it local to the
code that you run.
Besides helps to avoid forking external processes. If you can rewrite your
code:
foreach(`/bin/ls $path`) {
do something
}
(which is probably not the real code), not to `` but to read the file in,
and process it, you eliminate the whole problem altogether. I realize that
this is not always possible.
How about abstracting untaint and `` into a single function:
sub backticks {
local $ENV{PATH} = /bin:/usr/bin;
local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
qx(@_);
}
Stas,
Thanks for your explanation and suggestion. I'm a lot clearer on this
issue now.
P.
--
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Peter Ensch,
[EMAIL PROTECTED] A-1140 (214) 480 2333
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Re: Apache::Registry in mod_perl 2
On Tue, 2003-07-15 at 08:44, ColinB wrote: So how can I go about installing just Apache::Registry from the mod_perl 1 tar file without having to install ALL of mod_perl 1 ? Just copy the Apache/Registry.pm file into the same directory that all your other Apache:: modules are in. - Perrin
Re: mod_perl 1.0 and 2.0
Chris Faust wrote: There is a 0.92 version of Apache::DBI is mp2 aware (there may even be a later version at this point). We started with mp1 and do to problems we decided to goto mp2 (which turned out to be non mod_perl and apache related), there wasn't any major performance increase or anything like that and I don't remember anything major coming up during the switch (outside of cookies - which always seem to be a problem). I use a bunch of the popular modules like HTML::Template, Image::Magick, DBI, Parse/WriteExcel, Date::Manip etc and I haven't had any problems. Like Sreeji said, its really about your requirements - but the above is my experience, for what its worth. -Chris - Original Message - *From:* Jamie Krasnoo mailto:[EMAIL PROTECTED] *To:* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] *Sent:* Wednesday, July 09, 2003 3:49 PM *Subject:* mod_perl 1.0 and 2.0 Hi all, Im currently working on a personal project to get myself back in mod_perl programming order. However Im more used to using mod_perl 1.0 with Apache 1.3.x. Im going through the documentation for mod_perl 2.0 but Im worried that most of the modules I need wont work with mod_perl 2.0. Ive been looking for what modules will and will not work with 2.0 (like Apache::DBI for pooling connections with MySQL). Would it be a better benefit to me to switch over to 2.0? Thanks, Jamie We need more help in porting more mods to go with mp2... too ;) Come join the fray :) speeves cws
Re: segmentation fault under mod_perl+XML::XPath
Hello, Ged and other.
Thanks for long suggestion letter. I've solved my problem with mod_perl
compiled staticaly.
GH Hi there,
GH Haven't seen any replies, so I thought you'd like to hear from someone. :)
Thanks...
GH On Wed, 2 Jul 2003, Ruslan U. Zakirov wrote:
I've tried to use XML::XPath under mod_perl 1.27 and Apache 1.3.27, but
got segmentation fault
GH It's not uncommon to see XML and segfaults in the same post. :(
GH Have you searched the archives?
Looked at it. My problem was different.
Under command line and CGI it's working fine and all tests during installation of
XML::XPath were fine, but the same code crush apache+mod_perl.
GH [snip]
Apache - with so, unique_id, no expat
mod_perl with everything as DSO
GH Whenever I see segfaults in a DSO Apache I'd say try static linking if
GH you don't know what else to try. :)
Exactly this method is a solution.
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
GH Did you compile this Perl yourself? The standard advice is to compile
GH mod_perl and Perl with the same compiler.
usemymalloc=n, bincompat5005=undef
GH Highly unlikely, but maybe a malloc problem?
ccversion='', gccversion='2.95.3 20010315 (release) [FreeBSD]', gccosandvers=''
GH You should be OK with that compiler, is that what you're using yourself?
GH Hope you're not using gcc 3.x with that Perl...
I don't want to try 3.x yet.
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-DPIC -fpic', lddlflags='-shared -L/usr/local/lib'
GH Never heard of Perl (as opposed to mod_perl) dynamic linking causing a
GH problem, so don't worry about that. (Until later.:)
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x80711c5 in poolCopyString ()
(gdb) bt
#0 0x80711c5 in poolCopyString ()
GH This is the code in xmlparse.c from my 1.3.27 source tree:
GH --
GH static const XML_Char *poolCopyString(STRING_POOL *pool, const XML_Char *s)
GH {
GH do {
GH if (!poolAppendChar(pool, *s))
GH return 0;
GH } while (*s++);
GH s = pool-start;
GH poolFinish(pool);
GH return s;
GH }
GH --
GH Assuming you're using the same thing...
GH As far as I can see this must mean that your pointer s is invalid, and
GH either the dereference *s causes a memory bound error or else the s++
GH increment tries to increment it off the end of the stack or something.
GH There's nothing else in that function that would be likely to cause the
GH fault, if pool were invalid I'd expect it to happen in poolAppendChar().
GH I have no idea why these might be but it's a bit serious of course.
GH You're into XS territory, the sort of thing that can easily be thrown
GH by struct alignment problems such as you might get on the less well
GH exercised configurations - which probably includes FreeBSD - and an
GH unsuitable combination of compilers/dso/libraries/...
GH You shouldn't have to be delving this deeply into these packages, but
GH if a static link or a compiler change doesn't fix it and you don't
GH mind cranking gdb a bit further you could find out what that pointer
GH is pointing to and if it's a valid XML_Char pointer.
GH Hope this gets you started in the right direction, but please don't
GH take it as authoritative as I've never used FreeBSD nor XML::XPath.
Big thanks for your reply.
GH 73,
GH Ged.
Ruslan.
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: mod_perl Redirect Error
Rasoul Hajikhani wrote: Hello there, We have just upgraded to : Apache/1.3.27 Ben-SSL/1.48 (Unix) PHP/4.2.3 mod_perl/1.27 configured Running perl 5.6.1. I am getting 302 error message on my redirects. This comes as a complete surprise since the same piece of code works just fine on: Apache/1.3.14 Ben-SSL/1.42 (Unix) PHP/4.0.3pl1 mod_perl/1.24_01 configured Here is my code: $r-headers_in-unset(Content-length); $r-header_out(Location = $uri); $r-status(REDIRECT); $r-send_http_header; return REDIRECT; I am not sure where to begin debugging. I first wanted to check w/ you guys to see if there are any quick fixes. I appreciate any feed back. This is probably because Apache has changed the way it handles return codes. I believe you should return OK as in this example: http://perl.apache.org/docs/1.0/guide/snippets.html#mod_rewrite_in_Perl __ 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: [RFC] web-messaging application for mod_perl
Adi Fairbank wrote: On, or in the near vicinity of Tue, 1 Jul 2003 11:23:00 +0200 Enrico Sorcinelli [EMAIL PROTECTED] has thus spoken: On Mon, 30 Jun 2003 12:57:00 -0700 Adi Fairbank [EMAIL PROTECTED] wrote: Apache::WebMessaging I am about ready to release an intraserver web-messaging application for mod_perl. A brief description of the app follows; I'd like to hear some comments from the mod_perl/Perl/P5EE community on: You could look about Apache::* modules naming conventions: http://perl.apache.org/products/apache-modules.html#Module_Naming_Conventions Apache::App::WebMessaging namespace could be a right place :-) According to the asterisk note below Apache::App:: However, if you are planning a substantial framework with many inter-related modules, you should probably go with a top-level namespace outside of Apache::. This app already has 7-8 inter-related modules, though I would not call it a substantial framework. In fact it requires you to already have your own application framework setup in order to use it. It's basically a plug-in application for your existing mod_perl framework. I could rename it to just WebMessaging:: but it is specifically designed for mod_perl, which is why I think it should go in Apache::. Also, I noticed there are currently no Apache::App:: modules. Should this be the first?? Probably the best bet is to give it some cool unique name, like Apache::AdiChat and then you are all set, since you are not going to take over any future framework/namespaces... __ 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
Memoize.pm and mod_perl
Has anyone used the Memoize module extensively in a mod_perl environment? I am thinking of using it to cache queries from the database, particularly for lookups (somthing like $obj-get_name_from_id()). In many cases the data is static so I don't mind is staying over from one request to the next but I wanted to primarily use to limit the number of queries per http request. To keep the cache from growing (the website receives 20 hit/min on average w/ 20,000 users) I wanted to either implement a LRU/Expiration cache. The other alternative I was considering was to use a cleanup handler after every request. I would like to know any experiences/thoughts anyone has had of using Memoize in a mod_perl environment. Sidharth.
Re: Memoize.pm and mod_perl
On Mon, 2003-07-14 at 14:12, [EMAIL PROTECTED] wrote: Has anyone used the Memoize module extensively in a mod_perl environment? I'd suggest you use Cache::FileCache, MLDBM::Sync, or Cache::Mmap instead. Memoize is cool, but unnecessary if you are planning ahead like this. - Perrin
Re: Memoize.pm and mod_perl
I don't know anything about Memoize, but perhap db-level caching would work for you? If you user MySQL, Mysql 4.0.1 and beyond has Query Caching capabilities built into it. http://www.mysql.com/documentation/mysql/bychapter/manual_Reference.html#Query_Cache -=bill
[DIGEST] mod_perl digest 2002/06/30
-- mod_perl digest June 30, 2003 - July 13, 2003 -- Recent happenings in the mod_perl world... Features o mod_perl status o module announcements o application announcements o mailing list highlights o mp2 porting tips / documentation o links o problem reporting guidelines mod_perl status o mod_perl - stable: 1.28 (released July 3, 2003) [1] - development: 1.28_01-dev [2] o Apache - stable: 1.3.27 (released October 3, 2002) [3] - development: 1.3.28-dev [4] o mod_perl 2.0 - beta: 1.99_09 (released April 28, 2003) [5] - development: 1.99_10-dev [6] o Apache 2.0 - stable: 2.0.47 (released July 7, 2003) [7] - developement: 2.0.48-dev - new-territories: 2.1.xx o Perl - stable: 5.8.0 (released July 18, 2002) [8] - development: ...towards 5.9.0 has started [9] 5.8.1 RC 2 (released July 11, 2003) - tarball [10] - perldelta [11] module announcements o Apache::SessionManager 0.05 - HTTP session manager wrapper around Apache::Session [12] application announcements o OpenInteract 1.99_01 (2.0 beta 2) - extensible web application server [13] mailing list highlights o mod_perl 1.28 released [14] o possible conflict between Apache::print and perl 5.8 behavior [15] o Apache 2.1 Authentication Provider article on perl.com [16] mp2 porting tips / documentation o Suggested application naming conventions [17] o Status of modules ported to mod_perl 2.0 [18] o perl.apache.org documents [19] o Apache::compat [20] links o The Apache/Perl Integration Project [21] o mod_perl documentation [22] o Apache modules on CPAN [23] o _Writing Apache Modules with Perl and C_ homepage [24] o _mod_perl Developer's Cookbook_ homepage [25] o Other mod_perl-related books [26] o mod_perl news and advocacy [27] o mod_perl list archives - modperl@ [28] - dev@ [29] - docs-dev@ [30] - advocacy@ [31] problem reporting guidelines Whenever you have a problem that you want to ask about on the modperl list, please be sure to read the instructions on how to report problems: For mod_perl 1.0 [32] For mod_perl 2.0 [33] For your convenience, these are located in the shortcuts menu on all pages at http://perl.apache.org/. You will save yourself and us a lot of time by following the instructions on these pages. Thank you! happy mod_perling... --James [EMAIL PROTECTED] -- [1] http://perl.apache.org/dist/ [2] http://cvs.apache.org/snapshots/modperl/ [3] http://www.apache.org/dist/httpd/ [4] http://cvs.apache.org/snapshots/apache-1.3/ [5] http://perl.apache.org/dist/mod_perl-1.99_04.tar.gz [6] http://cvs.apache.org/snapshots/modperl-2.0/ [7] http://www.apache.org/dist/httpd/ [8] http://www.cpan.org/src/stable.tar.gz [9] http://www.cpan.org/src/README.html [10] http://www.cpan.org/authors/id/J/JH/JHI/perl-5.8.1-RC2.tar.gz [11] http://search.cpan.org/src/JHI/perl-5.8.1-RC2/pod/perldelta.pod [12] http://mathforum.org/epigone/modperl/flerdspubloi [13] http://mathforum.org/epigone/modperl/khimgangnu [14] http://mathforum.org/epigone/modperl/tandspixrar [15] http://mathforum.org/epigone/modperl/goisheesmil [16] http://mathforum.org/epigone/modperl/winlultril [17] http://mathforum.org/epigone/modperl/blerstrenkung [18] http://perl.apache.org/products/apache-modules.html#Porting_CPAN_modules_to_mod_perl_2_0_Status [19] http://perl.apache.org/docs/2.0/devel/porting/porting.html [20] http://perl.apache.org/docs/2.0/api/Apache/compat.html [21] http://perl.apache.org/ [22] http://perl.apache.org/docs/ [23] http://www.cpan.org/modules/by-module/Apache/ [24] http://www.modperl.com/ [25] http://www.modperlcookbook.org/ [26] http://perl.apache.org/docs/offsite/books.html [27] http://www.take23.org/ [28] http://perl.apache.org/maillist/modperl.html#Searchable_Archives [29] http://perl.apache.org/maillist/dev.html#Searchable_Archives [30] http://perl.apache.org/maillist/docs-dev.html#Searchable_Archives [31] http://perl.apache.org/maillist/advocacy.html#Searchable_Archives [32] http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems [33] http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems
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: [RFC] web-messaging application for mod_perl
On, or in the near vicinity of Mon, 14 Jul 2003 18:49:58 +0300 Stas Bekman [EMAIL PROTECTED] has thus written: Probably the best bet is to give it some cool unique name, like Apache::AdiChat and then you are all set, since you are not going to take over any future framework/namespaces... Well, I don't like that name, but I do get what you mean. ( I wouldn't want to have any piece of software named after me... just my personal style. Software lives for too long, especially open source. It would still be called that long after I'm dead. ) What's wrong with WebMessaging ? Do you foresee that interfering with some future software in the Apache:: namespace, or is it just too generic? I thought it was a good name since it accurately describes what it is: not webmail, not instant messaging, but web messaging. (basically, it's like those message boxes you get on a stock trading website when you login to your account) Here are the possibilities: 1 Apache::WebMessaging 2 Apache::App::WebMessaging 3 Apache::SomeOtherUniqueName (e.g. ServerMessaging, or UserMessaging, or SystemMessaging) I personally prefer 1 or 2, so if there are no serious objections, I'll pick one of those. Let me know which you like the best. -Adi
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: untainting PATH in mod_perl
Sorry, getting out of good ideas..
Surprise, surprise: I found out that my code does not work under
mod_perl 1.23 either! And I found the real solution: one has to add
PerlSetupEnv Off
to the Apache configuration file. Now the untainting mumbo-jumbo in
perl section works.
Warning: this has the consequence of breaking the part of the CGI
environment emulation that deals with environment (e.g. instead of
$ENV{HTTP_USER_AGENT}, you now have to check
Apache-request()-subprocess_env(HTTP_USER_AGENT)). Glancing at its
source code, I don't think CGI.pm will survive that...
BTW, I finally got around to reading mod_perl's source, and it
is now clear to me that the environment, when being copied from
-subprocess_env() into %ENV, gets tainted (around line 704 in
src/modules/perl/mod_perl.c). The whole %ENV gets tainted, not just
the HTTP_USER_AGENT and such from the CGI context, so PATH is tainted
as well. This explains our now common problem - and also guarantees
that there is no easy way out of it if you use CGI.pm yourself :-(.
Hope I'm being helpful at last,
--
Dominique QUATRAVAUX Ingénieur senior
01 44 42 00 08 IDEALX
mod_perl 2.0 and cookies
So Ive decided to dive headlong into 2.0. So far I like it but find the documentation lacking and there seems to be a lot missing. I tried Apache::Cookie with it, no dice. It gave an error to the effect that it didnt know what bootstrap was (I think that was it). Apache::Cookie made inserting cookies in mod_perl 1.0 so easy which in turn made life easier for programming. However I have scoured the documentation on how to insert a cookie into the header and the only thing I could come up with is that you use a filter to do it. Somehow I dont think that this is right and I am completely off. Could someone enlighten me as to how cookies work in MP2? If I can get past this I can figure out the rest on my own and maybe write a little documentation if I can understand it enough to do so. Thank you, Jamie
Re: mod_perl 2.0 and cookies
So I've decided to dive headlong into 2.0. So far I like it but find the documentation lacking and there seems to be a lot missing. I tried Apache::Cookie with it, no dice. It gave an error to the effect that it didn't know what bootstrap was (I think that was it). Apache::Cookie made inserting cookies in mod_perl 1.0 so easy which in turn made life easier for programming. However I have scoured the documentation on how to insert a cookie into the header and the only thing I could come up with is that you use a filter to do it. Somehow I don't think that this is right and I am completely off. Could someone enlighten me as to how cookies work in MP2? If I can get past this I can figure out the rest on my own and maybe write a little documentation if I can understand it enough to do so. From what I've figured out through experiementing, tho I'd find out a lot more by reading source and I'd be a bit more accurate in this... But I think mod_perl 2 is just simply lacking all together. I think the docs are lacking info because the program is lacking hte feature! Course, this only means I havern't figured out how to use the features, if they are there. But, to me, mod_perl x+1 should be backwards compatible with mod_perl x, if it isn't, then it's broken. (in my opinion..) Dennis
Re: mod_perl 2.0 and cookies
On Fri, 11 Jul 2003, Jamie Krasnoo wrote: So I've decided to dive headlong into 2.0. So far I like it but find the documentation lacking and there seems to be a lot missing. I tried Apache::Cookie with it, no dice. It gave an error to the effect that it didn't know what bootstrap was (I think that was it). Apache::Cookie made inserting cookies in mod_perl 1.0 so easy which in turn made life easier for programming. However I have scoured the documentation on how to insert a cookie into the header and the only thing I could come up with is that you use a filter to do it. Somehow I don't think that this is right and I am completely off. Could someone enlighten me as to how cookies work in MP2? If I can get past this I can figure out the rest on my own and maybe write a little documentation if I can understand it enough to do so. It wasn't clear to me - are you using the development version of httpd-apreq-2? The CPAN version of libapreq are for mod_perl 1 - you'll need httpd-apreq-2 (available via cvs) for Apache 2. If you are using Apache::Cookie of httpd-apreq-2, at this point, probably the simplest way to see examples of the basic usage is to go through the tests, under glue/perl/t/. Documentation patches would be welcome - it would be easiest to subscribe to the [EMAIL PROTECTED] mailing list and submit them there. -- best regards, randy kobes
RE: mod_perl 2.0 and cookies
On Fri, 11 Jul 2003, Ross Matt-QMR000 wrote: I would really 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 to different address. Try sending a message to [EMAIL PROTECTED] for some suggestions. -- best regards, randy kobes
Re: untainting PATH in mod_perl
I need some help with this. Can you share the code you use w/in
your Perl section?
Sure! Here is how I untaint a selected range of variables from the
WWW server's %ENV, and discard all the others (good move to ease
debugging anyway):
# From httpd.conf
PerlTaintCheck On
perl
BEGIN {
# Untaint environment. Those variables come from
# Apache; even if they didn't, they would come from the root
# user who launched Apache. No security problems here.
my %cleanenv;
foreach my $var (qw(PATH GATEWAY_INTERFACE MOD_PERL)) {
($cleanenv{$var})=($ENV{$var} =~ m/^(.*)$/g);
}
%ENV=%cleanenv;
}
/perl
I'm pretty confused because I was able to untaint my PATH var.
by putting
$ENV{PATH} = '/bin';
in the ***same scope*** where I was getting the error.
Makes sense to me: if you are using Apache::Registry (for example),
your script only gets compiled once and the BEGIN blocks run at that
time. In fact Apache::Registry reads your cgi, then cooks it into
something like this:
package Some::Name::Made::Up::By::Apache::Registry::To::Isolate::Your::cgi;
sub handler {
# Your script here
}
Then it evals that (by that time, the BEGIN blocks run), then calls
Some::Name::...::handler(). The purpose of these steps is caching: the
next time the CGI is hit, the evalling needs not be redone, only the
handler call.
Now, my guess was that %ENV gets reset between the eval and the
handler call. As you mention, putting the untainter in the same scope
solves the problem, because you now circumvent the cleaning. Putting
it in the perl section should also solve the problem once for all,
because the perl section runs before the default %ENV value is
stashed (even before Apache forks, in fact).
--
Dominique QUATRAVAUX Ingénieur senior
01 44 42 00 08 IDEALX
Re: mod_perl 1.0 and 2.0
There is a 0.92 version of Apache::DBIis mp2 aware (there may even be a later version at this point). We started with mp1 and do to problems we decided to goto mp2 (which turned out to be non mod_perl and apache related), there wasn't any major performance increase or anything like that and I don't remember anything major coming up during the switch (outside of cookies - which always seem to be a problem). I use a bunch of the popular modules like HTML::Template, Image::Magick, DBI, Parse/WriteExcel, Date::Manip etc and I haven't had any problems. Like Sreeji said, its really about your requirements - but the above is my experience, for what its worth. -Chris - Original Message - From: Jamie Krasnoo To: [EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 3:49 PM Subject: mod_perl 1.0 and 2.0 Hi all, Im currently working on a personal project to get myself back in mod_perl programming order. However Im more used to using mod_perl 1.0 with Apache 1.3.x. Im going through the documentation for mod_perl 2.0 but Im worried that most of the modules I need wont work with mod_perl 2.0. Ive been looking for what modules will and will not work with 2.0 (like Apache::DBI for pooling connections with MySQL). Would it be a better benefit to me to switch over to 2.0? Thanks, Jamie
Compile issue: conflicting typesfinger at mod_perl. This may be the case as I've managed to compile another Apache server without mod_perl on a different system (RH 9 with PHP). However, I'm thinking it's more along the lines of a compiler (IOW, RedHat'
On RedHat Linux 9.0, with Apache 1.3.27, PHP 4.3.2, and mod_perl 1.28, I'm getting a compile error. These, near as I know, are the latest stable versions of everything - which is why I suspect I'm running into this problem: make[2]: Entering directory `/usr/local/src/apache_1.3.27/src/support' gcc -c -I../os/unix -I../include -DLINUX=22 -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -I/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE `../apaci` htpasswd.c htpasswd.c:145: conflicting types for `getline' /usr/include/stdio.h:473: previous declaration of `getline' make[2]: *** [htpasswd.o] Error 1 make[2]: Leaving directory `/usr/local/src/apache_1.3.27/src/support' make[1]: *** [build-support] Error 1 make[1]: Leaving directory `/usr/local/src/apache_1.3.27' make: *** [build] Error 2 I've seen pWhat Eric Stewart - Network Admin - USF Tampa Library - [EMAIL PROTECTED] SCUBA Diver: 220 Dives Most Recent: 05/10/03 Chankanaab Park, Cozumel GeoCacher:58 Found Most Recent: 07/04/03 GCGBHE - Fun in the Sun http://www.scubadiving.com/talk/ and http://www.geocaching.com/
Re: untainting PATH in mod_perl
On Thu, Jul 10, 2003 at 10:25:59AM +0200, Dominique Quatravaux wrote:
I need some help with this. Can you share the code you use w/in
your Perl section?
Sure! Here is how I untaint a selected range of variables from the
WWW server's %ENV, and discard all the others (good move to ease
debugging anyway):
# From httpd.conf
PerlTaintCheck On
perl
BEGIN {
# Untaint environment. Those variables come from
# Apache; even if they didn't, they would come from the root
# user who launched Apache. No security problems here.
my %cleanenv;
foreach my $var (qw(PATH GATEWAY_INTERFACE MOD_PERL)) {
($cleanenv{$var})=($ENV{$var} =~ m/^(.*)$/g);
}
%ENV=%cleanenv;
}
/perl
I'm pretty confused because I was able to untaint my PATH var.
by putting
$ENV{PATH} = '/bin';
in the ***same scope*** where I was getting the error.
Makes sense to me: if you are using Apache::Registry (for example),
your script only gets compiled once and the BEGIN blocks run at that
time. In fact Apache::Registry reads your cgi, then cooks it into
something like this:
package Some::Name::Made::Up::By::Apache::Registry::To::Isolate::Your::cgi;
sub handler {
# Your script here
}
Then it evals that (by that time, the BEGIN blocks run), then calls
Some::Name::...::handler(). The purpose of these steps is caching: the
next time the CGI is hit, the evalling needs not be redone, only the
handler call.
Now, my guess was that %ENV gets reset between the eval and the
handler call. As you mention, putting the untainter in the same scope
solves the problem, because you now circumvent the cleaning. Putting
it in the perl section should also solve the problem once for all,
because the perl section runs before the default %ENV value is
stashed (even before Apache forks, in fact).
Dominique,
Thanks for sharing your code; unfortunately, it's not working for me.
I copied it into my httpd.conf file, stopped/started the server and
I still get the same error:
[Thu Jul 10 11:10:38 2003] [error] 19156: ModPerl::Registry: Error executing run mode
'getlib': \
Insecure $ENV{PATH} while running setgid at
/opt/asic/http/2.0.46/worker/perl-lib/Webace/Art.pm line 386
where line #386 is:
foreach my $release (`/bin/ls $path`) { # $path is already untainted
do stuff
}
Any other ideas?
Thanks and regards,
P
--
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Peter Ensch,
[EMAIL PROTECTED] A-1140 (214) 480 2333
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Re: untainting PATH in mod_perl
Thanks for sharing your code; unfortunately, it's not working for me.
I copied it into my httpd.conf file, stopped/started the server and
I still get the same error:
Sorry, getting out of good ideas.. I'm not using mod_perl 1.99, this
probably explains why my code does not work, and also it prevents me
from further investigating your problem. There was a thread recently
on the list about perl ... /perl section only being implemented
recently, do you run the latest version of mod_perl?
Insecure $ENV{PATH} while running setgid
While running setgid? That's odd (although I don't think this
nterfers with your problem in any way)
foreach my $release (`/bin/ls $path`) { # $path is already untainted
do stuff
}
TI (still) MTOWTDI: why not try
use IO::Pipe;
my $pipe = new IO::Pipe()-reader(/bin/ls,$path);
while($pipe) {
}
(although this will not save you from having to review all your codebase)
--
Dominique QUATRAVAUX Ingénieur senior
01 44 42 00 08 IDEALX
untainting PATH in mod_perl
perlsec says that to untaint the PATH env one should
do:
$ENV{'PATH'} = '/bin:/usr/bin';
delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};
In plain CGI, I normally do this inside a BEGIN
block; in mod_perl however, this doesn't work. A
print of $ENV{PATH} returns the original tainted
PATH.
In my script I'm doing something like
foreach(`/bin/ls $path`) {
do something
}
$path is already untainted but I'm still getting
an 'Insecure $ENV{PATH}' error. What am I missing
here?
Thanks,
P
--
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Peter Ensch,
[EMAIL PROTECTED] A-1140 (214) 480 2333
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Re: untainting PATH in mod_perl
In plain CGI, I normally do this inside a BEGIN block; in mod_perl however, this doesn't work. This would work if this was done in a Perl section of the httpd.conf file (this is what I do). I am not sure why the BEGIN block is not executed, but my guess is that the environment gets automatically restored at the end of every script run under Apache::Registry, including the tainted PATH. -- Dominique QUATRAVAUX Ingénieur senior 01 44 42 00 08 IDEALX
mod_perl 1.0 and 2.0
Hi all, Im currently working on a personal project to get myself back in mod_perl programming order. However Im more used to using mod_perl 1.0 with Apache 1.3.x. Im going through the documentation for mod_perl 2.0 but Im worried that most of the modules I need wont work with mod_perl 2.0. Ive been looking for what modules will and will not work with 2.0 (like Apache::DBI for pooling connections with MySQL). Would it be a better benefit to me to switch over to 2.0? Thanks, Jamie
Re: untainting PATH in mod_perl
On Wed, Jul 09, 2003 at 05:40:32PM +0200, Dominique Quatravaux wrote:
In plain CGI, I normally do this inside a BEGIN
block; in mod_perl however, this doesn't work.
This would work if this was done in a Perl section of the httpd.conf
file (this is what I do). I am not sure why the BEGIN block is not
executed, but my guess is that the environment gets automatically
restored at the end of every script run under Apache::Registry,
including the tainted PATH.
I need some help with this. Can you share the code you use w/in
your Perl section?
I'm pretty confused because I was able to untaint my PATH var.
by putting
$ENV{PATH} = '/bin';
in the ***same scope*** where I was getting the error. For example
$ENV{PATH} = '/bin';
my @files = `/bin/ls $path`; # $path is already untainted
was OK; leave out the $ENV line and I get an Insecure $ENV{PATH}
error.
This works (don't know why) but I would prefer to fix the PATH
in one place rather than having to do so everywhere I shell out
or use backticks.
Thanks,
P
--
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Peter B. Ensch ([EMAIL PROTECTED])
Linux 2.4.20-4GB 8:21pm Up 18 days 2:55
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Re: mod_perl 1.0 and 2.0
I think it should be based on your specific requirements. If you want to setup a production box and does not have much time in hand to troubleshoot, then you must go for mod_perl 1.x/Apache-1.x latest stable versions. However, if you have time in hand want to learn a bit about Apache/mod_perl, then 2.x would be better. For any slightly large project, you're likely to face problems it's fun to debug as you'd get to know the code better. I'd also think mod_perl 1.x series may be discontinued after a while, as 2.x gets to be used widely (however, it may be a while). I have been trying to move a large application from mod_perl 1.x to 2.x. There had been many hiccups now then and I had to install latest of version of all components in my tech stack (perl 5.8.0, latest CGI/DBI/DBD ...etc.) and had to tweak my configurations. I found few issues in the process and I've reported them here. From my experience, it's a bit long journey, but quite interesting. Sreeji --- Jamie Krasnoo [EMAIL PROTECTED] wrote: Hi all, I'm currently working on a personal project to get myself back in mod_perl programming order. However I'm more used to using mod_perl 1.0 with Apache 1.3.x. I'm going through the documentation for mod_perl 2.0 but I'm worried that most of the modules I need won't work with mod_perl 2.0. I've been looking for what modules will and will not work with 2.0 (like Apache::DBI for pooling connections with MySQL). Would it be a better benefit to me to switch over to 2.0? Thanks, Jamie Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
Re: Newbie question about mod_perl capabilities
On Monday, Jul 7, 2003, at 20:50 Europe/London, Ged Haywood wrote: On 7 Jul 2003, Walter H. van Holst wrote: I am new to mod_perl and am trying to figure out whether it suits my needs or not. Can I use it to intercept any http CONNECT requests Apache receives and answer those? The concept of a connection is at the transport level, way below HTTP. The HTTP protocol simply assumes a reliable transport (you don't even need an Internet:) and deals with exchanges of messages. See RFC1945. Sorry Ged, Walter is talking about CONNECT which is a proxy request. It goes in place of GET or POST in the request line: CONNECT mail.openrelay.com:25 HTTP/1.1 I *think* mod_perl will be able to intercept this, but I've never tried it. You might need to do it very early on in the request, and make sure it gets passed through to mod_proxy later on or things just won't work. Matt.
Re: Newbie question about mod_perl capabilities
On Tue, 2003-07-08 at 10:14, Matt Sergeant wrote: Sorry Ged, Walter is talking about CONNECT which is a proxy request. It goes in place of GET or POST in the request line: CONNECT mail.openrelay.com:25 HTTP/1.1 I *think* mod_perl will be able to intercept this, but I've never tried it. You might need to do it very early on in the request, and make sure it gets passed through to mod_proxy later on or things just won't work. Well, thanks to a someone on IRC I have found a code snippet that might do exactly that. So it appears that mod_perl can do this. And yes, it is intended for exactly the kind of CONNECT requests you describe. Regards, Walter -- Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. (Bill Gates)
Re: Newbie question about mod_perl capabilities
Hi there, On 8 Jul 2003, Walter H. van Holst wrote: On Tue, 2003-07-08 at 10:14, Matt Sergeant wrote: Sorry Ged, Walter is talking about CONNECT which is a proxy request. Argh. :) Well, thanks to a someone on IRC I have found a code snippet that might do exactly that. So it appears that mod_perl can do this. And yes, it is intended for exactly the kind of CONNECT requests you describe. :) 73, Ged.
Re: FAIL mod_perl-1.28 MSWin32-x86-multi-thread 4.0
On Sun, 6 Jul 2003, DH wrote: This distribution has been tested as part of the cpan-testers effort to test as many new uploads to CPAN as possible. See http://testers.cpan.org/ Please cc any replies to [EMAIL PROTECTED] to keep other test volunteers informed and to prevent any duplicate effort. E:\new\mod_perl-1.28perl Makefile.PL NO_HTTPD=1 APACHE_SRC=E:\Apache INSTALL_DLL=E:\Apache\modules [ ... ] Linking... LINK : fatal error LNK1181: cannot open input file ..\..\..\..\..\Perl\lib\CORE\perl56.lib Thanks for raising this - the problem was that the drive letters weren't included in the dsp file. This is fixed in the mod_perl cvs sources. -- best regards, randy kobes
Re: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
[EMAIL PROTECTED] wrote: Thanks for your prompt response! We did compile Apache with CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 but we're trying to move away from this now, because of vendors like IBM and Oracle not willing to re-compile (websphere mods and mod_ossos) with the same flags. Thus without re-compiling my whole Perl 5.8.0 build I need to come up with a solution. Like I said before Doug MacEachern actually allows you to get away with this in mod_perl 1.27 (with mod_perl 1.24 it would squeal and terminate during compile time). Sorry for my ignorance but it does look like it will work (non-LFS Apache) provided that you don't try to access files larger then 2GB. Is there another low level consideration I'm not taking into account? Everything will work OK if all the components are compiled without large file support. Of course you won't be able to handle files 2GB. Last but not least...Perl 5.6.1 and greater compiles with LFS (default) and Apache has always compiled without it (unless you specifically specify it). Did you re-compile Apache with CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64? mod_perl 1.x does it for you (i.e. uses perl's cppflags) if you build static (since it builds apache). perl -V:cppflags cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -I/usr/include/gdbm'; I'm not sure what happen if you build DSO. __ 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
FAIL mod_perl-1.28 MSWin32-x86-multi-thread 4.0
This distribution has been tested as part of the cpan-testers effort to test as many new uploads to CPAN as possible. See http://testers.cpan.org/ Please cc any replies to [EMAIL PROTECTED] to keep other test volunteers informed and to prevent any duplicate effort. -- E:\new\mod_perl-1.28perl Makefile.PL NO_HTTPD=1 APACHE_SRC=E:\Apache INSTALL_DLL=E:\Apache\modules PerlDispatchHandler.enabled PerlChildInitHandlerenabled PerlChildExitHandlerenabled PerlPostReadRequestHandler..enabled PerlTransHandlerenabled PerlHeaderParserHandler.enabled PerlAccessHandler...enabled PerlAuthenHandler...enabled PerlAuthzHandlerenabled PerlTypeHandler.enabled PerlFixupHandlerenabled PerlHandler.enabled PerlLogHandler..enabled PerlInitHandler.enabled PerlCleanupHandler..enabled PerlRestartHandler..enabled PerlStackedHandlers.enabled PerlMethodHandlers..enabled PerlDirectiveHandlers...enabled PerlTableApienabled PerlLogApi..enabled PerlUriApi..enabled PerlUtilApi.enabled PerlFileApi.enabled PerlConnectionApi...enabled PerlServerApi...enabled Checking if your kit is complete... Looks good 'NO_HTTPD' is not a known MakeMaker parameter name. Writing Makefile for Apache Writing Makefile for Apache::Connection Writing Makefile for Apache::Constants Writing Makefile for Apache::File Writing Makefile for Apache::Leak Writing Makefile for Apache::Log Writing Makefile for Apache::ModuleConfig Writing Makefile for Apache::PerlRunXS Writing Makefile for Apache::Server Writing Makefile for Apache::Symbol Writing Makefile for Apache::Table Writing Makefile for Apache::URI Writing Makefile for Apache::Util Writing Makefile for mod_perl Beginning with version 1.3.15, Apache uses a different convention for Win32 module names. Correspondingly, the name of the mod_perl module built here has been changed from ApacheModulePerl.dll to mod_perl.so. Please see INSTALL.win32 for further details. E:\new\mod_perl-1.28nmake Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cp lib/Apache/Registry.pm blib\lib\Apache\Registry.pm cp E:/Apache/include/ap_compat.h blib\arch/auto/Apache/include/include/ap_compat.h cp E:/Apache/include/os.h blib\arch/auto/Apache/include/include/os.h cp E:/Apache/include/resource.h blib\arch/auto/Apache/include/include/resource.h cp lib/Apache/PerlSections.pm blib\lib\Apache\PerlSections.pm cp lib/Apache/PerlRun.pm blib\lib\Apache\PerlRun.pm cp lib/Apache/Debug.pm blib\lib\Apache\Debug.pm cp lib/mod_perl_hooks.pm.PL blib\lib\mod_perl_hooks.pm.PL cp lib/Apache/MyConfig.pm blib\lib\Apache\MyConfig.pm cp E:/Apache/include/Win9xConHook.h blib\arch/auto/Apache/include/include/Win9xConHook.h cp E:/Apache/include/readdir.h blib\arch/auto/Apache/include/include/readdir.h cp E:/Apache/include/ap_alloc.h blib\arch/auto/Apache/include/include/ap_alloc.h cp E:/Apache/include/http_main.h blib\arch/auto/Apache/include/include/http_main.h cp E:/new/mod_perl-1.28/src/modules/perl/dirent.h blib\arch/auto/Apache/include/modules/perl/dirent.h cp lib/Apache/ExtUtils.pm blib\lib\Apache\ExtUtils.pm cp E:/Apache/include/service.h blib\arch/auto/Apache/include/include/service.h cp E:/Apache/include/ap_ctype.h blib\arch/auto/Apache/include/include/ap_ctype.h cp lib/Apache/src.pm blib\lib\Apache\src.pm cp lib/mod_perl.pm blib\lib\mod_perl.pm cp E:/Apache/include/multithread.h blib\arch/auto/Apache/include/include/multithread.h cp mod_perl_cvs.pod blib\lib\mod_perl_cvs.pod cp E:/Apache/include/ap.h blib\arch/auto/Apache/include/include/ap.h cp E:/Apache/include/compat.h blib\arch/auto/Apache/include/include/compat.h cp E:/Apache/include/http_config.h blib\arch/auto/Apache/include/include/http_config.h cp E:/Apache/include/xml/xmlrole.h blib\arch/auto/Apache/include/include/xml/xmlrole.h cp E:/new/mod_perl-1.28/src/modules/perl/mod_perl.h blib\arch/auto/Apache/include/modules/perl/mod_perl.h cp E:/Apache/include/xml/nametab.h blib\arch/auto/Apache/include/include/xml/nametab.h cp apaci/mod_perl.exp blib\arch/auto/Apache/mod_perl.exp cp E:/Apache/include/http_log.h blib\arch/auto/Apache/include/include/http_log.h cp lib/Apache/testold.pm blib\lib\Apache\testold.pm cp lib/Apache/Symdump.pm blib\lib\Apache\Symdump.pm cp lib/Apache/Status.pm blib\lib\Apache\Status.pm cp E:/Apache/include/registry.h blib\arch/auto/Apache/include/include/registry.h cp E:/new/mod_perl-1.28/src/modules/perl/mod_perl_version.h blib\arch/auto/Apache/include/modules/perl/mod_perl_version.h cp lib/Apache/RedirectLogFix.pm blib\lib\Apache\RedirectLogFix.pm cp E:/Apache/include/hsregex.h blib\arch/auto/Apache/include/include/hsregex.h cp mod_perl_method_handlers.pod blib\lib\mod_perl_method_handlers.pod cp lib/Apache/Include.pm blib\lib
Newbie question about mod_perl capabilities
Hi, I am new to mod_perl and am trying to figure out whether it suits my needs or not. Can I use it to intercept any http CONNECT requests Apache receives and answer those? Regards, Walter -- Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. (Bill Gates)
Re: require'ing data files under mod_perl
On Thu, Jul 03, 2003 at 05:15:31PM -0400, Perrin Harkins wrote: On Thu, 2003-07-03 at 16:59, Peter Ensch wrote: OK. Thanks. Well, yes it is being reloaded whenever the form is submitted and w/out restarting the server. Here's some of the output (error_log): [Thu Jul 3 15:52:00 2003] users.dat: users.dat loaded by process 18294 at /opt/a... Just a guess, but maybe this is because you're passing a variable to the require function. Try hard-coding it and see if it changes. This sounded like a good explanation but it wasn't. Hard-coding the require'd file didn't make any difference; nor did the assignment to a variable. In each case the require'd file was reloaded each time the script was invoked. It's a mystery! P -- ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^ Peter Ensch, [EMAIL PROTECTED] A-1140 (214) 480 2333 ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Re: Newbie question about mod_perl capabilities
Hi there, On 7 Jul 2003, Walter H. van Holst wrote: I am new to mod_perl and am trying to figure out whether it suits my needs or not. Can I use it to intercept any http CONNECT requests Apache receives and answer those? The concept of a connection is at the transport level, way below HTTP. The HTTP protocol simply assumes a reliable transport (you don't even need an Internet:) and deals with exchanges of messages. See RFC1945. Read the Eagle Book (*), for more information about where mod_perl fits into the scheme of things. Chapter 3 has a good explanation of the Apache request cycle. 73, Ged. (*) Writing Apache Modules with Perl and C, ISBN 1-56592-567-X
mod_perl-1.99_0.9 on Mac OS X 10.2.6
Hi, I heared a lot of people complaining that they can't get mod_perl-1.99_09 running on Mac OS X. Here is a little scenario that worked for me. These are the steps: Sources: Grab the sources from your closest mirrors and untar them. If this is the first time you upgrade to 5.8.0, note that Apple ships 5.6.0 with Mac OS X and both are binary incompatible to each other, so you might have to rebuild some of your modules. perl-5.8.0.tar.gz httpd-2.0.45.tar.gz mod_perl-1.99_09.tar.gz Perl: Compile Perl with iThreads. % cd perl-5.8.0 % sh Configure -de -Dusethreads % make % make test % sudo make install Apache: Compile Apache with MPM worker style % cd httpd-2.0.45 % ./configure --with-mpm=worker % make % sudo make install mod_perl: Last but not least. % cd mod_perl-1.99_09 % perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2 MP_INST_APACHE2=1 MP_USE_DSO=1 MP_COMPAT_1X=0 % make % sudo make install Note: Dont forget to append LoadModule perl_module modules/mod_perl.so and PerlModule Apache2 to your httpd.conf!!! Thats it! Not guaranteed to work for you, here it works fine, at least until now. There are still lots of tests that fail. Cheers, Sebastian Riedel
segmentation fault under mod_perl+XML::XPath
Hello.
I've tried to use XML::XPath under mod_perl 1.27 and Apache 1.3.27, but
got segmentation fault with this peace of code:
use XML::XPath;
my $mfname='/proj/optolink/html/.meta.xml';
my $xp = XML::XPath-new(filename = $mfname);
my $ns = $xp-find('//[EMAIL PROTECTED]yes]');
Perl 5.8.0, Apache - with so, unique_id, no expat
mod_perl with everything as DSO
Under command line it's working fine and all tests during installation of
XML::XPath were fine, but the same code crush apache+mod_perl.
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x80711c5 in poolCopyString ()
(gdb) bt
#0 0x80711c5 in poolCopyString ()
#1 0x806cf71 in XML_SetBase ()
#2 0x28cfcc92 in XS_XML__Parser__Expat_SetBase ()
from
/usr/local/lib/perl5/site_perl/5.8.0/i386-freebsd/auto/XML/Parser/Expat/Expat.so
#3 0x28c398fb in Perl_pp_entersub () from
/usr/local/libexec/apache/libperl.so
#4 0x28c33c28 in Perl_runops_standard ()
from /usr/local/libexec/apache/libperl.so
#5 0x28bf2f36 in S_call_body () from /usr/local/libexec/apache/libperl.so
#6 0x28bf2d16 in Perl_call_sv () from
/usr/local/libexec/apache/libperl.so
#7 0x28bd3d56 in perl_call_handler ()
from /usr/local/libexec/apache/libperl.so
#8 0x28bd359e in perl_run_stacked_handlers ()
from /usr/local/libexec/apache/libperl.so
#9 0x28bd1d64 in perl_handler () from
/usr/local/libexec/apache/libperl.so
#10 0x8052595 in ap_invoke_handler ()
#11 0x806225c in process_request_internal ()
#12 0x80622bd in ap_process_request ()
#13 0x805b52e in child_main ()
#14 0x805b6a0 in make_child ()
#15 0x805b7bd in startup_children ()
#16 0x805bcb4 in standalone_main ()
#17 0x805c397 in main ()
#18 0x804ebe1 in _start ()
Any help would be good.
Ruslan.
[win32] mod_perl 1 and ActivePerl 8xx
In the current mod_perl 1 cvs repository there's now a workaround that allows mod_perl 1 to compile against Win32 ActivePerl 8xx and Apache/1.3. I've put up a ppm package of this under http://theoryx5.uwinnipeg.ca/ppms/ which you can access by setting the repository within the ppm shell to http://theoryx5.uwinnipeg.ca/cgi-bin/ppmserver?urn:/PPMServer58 However, within this same location, there's already a mod_perl package for mod_perl 2 (associated with mod_perl.ppd), so the mod_perl 1 package is named mod_perl-1, and corresponding mod_perl-1.ppd file. Installing this should run a post-install script to copy the Apache module mod_perl.so to your Apache/modules directory - if this doesn't work, you can grab mod_perl-1.so from http://theoryx5.uwinnipeg.ca/ppms/scripts/ and install it manually to Apache/modules/mod_perl.so. In this repository there's also ppm packages of some Apache modules. Those tied to mod_perl-1 for some reason have a '-1' appended to their names; currently there's libapreq-1 (for Apache::Request and Apache::Cookie) Embperl-1 (based on Embperl-2.0b9) AxKit-1 (based on AxKit-1.61) Apache-Template-1 (for Template-Toolkit) Apache-Filter-1 (the mod_perl 1 version) Apache-ASP and HTML-Mason, also available in this repository, don't have the '-1' appended to their name, as they work in principle with either mod_perl 1 or 2. All the above packages, including mod_perl-1, either passed all their supplied tests or failed a handful which didn't look any worse than the ActivePerl 6xx counterparts. They also worked with some quick tests on a real server (running Apache/1.3.27 and WinXP). However, there are some major differences between between ActivePerl 6xx and 8xx - if you use these packages, and find some strange behaviour, feel free to ask on this list; for this, it'd help to have the Perl and Apache versions used, what the error was, and as brief an example as possible that invokes the behaviour. -- best regards, randy kobes
Re: [ANNOUNCE] mod_perl-1.28
On Thu, 3 Jul 2003, Steve Hay wrote:
Philippe M. Chiasson wrote:
The URL
http://perl.apache.org/dist/mod_perl-1.28.tar.gz
has entered CPAN
I still get the same test failures that I reported before when
RC2 was announced:
modules/request...FAILED tests 3-8
Failed 6/10 tests, 40.00% okay
Setup: Windows XP, Perl 5.8.0, Apache 1.3.27, Apache-Test 1.03,
libapreq-1.2 (built/installed *after* mod_perl 1.28).
I used to have All tests successful under mp-1.27.
This may be a problem with libapreq - the mod_perl
t/modules/request.t tests, among other things, the sizes involved
with file uploads. The error log you posted earlier reported a
difference in these sizes for three (text) files, with a binary
(gif) file apparently OK (interestingly, with a patch I posted
earlier to allow Win32 ActivePerl 8xx to be used with mod_perl 1
(with LARGE_FILES support), I get a failure with the gif file,
but not the text files). Anyway, could you see if the following
helps (applied to the libapreq sources)? For me, this allows all
the mod_perl t/modules/request tests to pass.
Index: Request/Request.xs
===
RCS file: /home/cvs/httpd-apreq/Request/Request.xs,v
retrieving revision 1.36
diff -u -r1.36 Request.xs
--- Request/Request.xs 25 Jun 2003 07:59:37 - 1.36
+++ Request/Request.xs 4 Jul 2003 05:32:59 -
@@ -533,7 +533,7 @@
if (fd 0)
XSRETURN_UNDEF;
-if ( !(RETVAL = PerlIO_fdopen(fd, r)) )
+if ( !(RETVAL = PerlIO_fdopen(fd, rb)) )
XSRETURN_UNDEF;
#else
if ( ( RETVAL = PerlIO_importFILE(fp,0) ) == NULL )
@@ -558,7 +558,7 @@
PerlIO *fp;
fd = PerlLIO_dup(fd);
- if (!(fp = PerlIO_fdopen(fd, r))) {
+if (!(fp = PerlIO_fdopen(fd, rb))) {
PerlLIO_close(fd);
croak(fdopen failed!);
}
The first r - rb change (which affects the mod_perl tests)
is only relevant for Perl 5.7, which is why this problem didn't
arise on Win32 with Perl-5.6. Also, I think this r - rb
doesn't have any effect on Unix, but I haven't tested this.
--
best regards,
randy
Re: [ANNOUNCE] mod_perl-1.28
Hi Randy,
Randy Kobes wrote:
On Thu, 3 Jul 2003, Steve Hay wrote:
Philippe M. Chiasson wrote:
The URL
http://perl.apache.org/dist/mod_perl-1.28.tar.gz
has entered CPAN
I still get the same test failures that I reported before when
RC2 was announced:
modules/request...FAILED tests 3-8
Failed 6/10 tests, 40.00% okay
Setup: Windows XP, Perl 5.8.0, Apache 1.3.27, Apache-Test 1.03,
libapreq-1.2 (built/installed *after* mod_perl 1.28).
I used to have All tests successful under mp-1.27.
This may be a problem with libapreq - the mod_perl
t/modules/request.t tests, among other things, the sizes involved
with file uploads. The error log you posted earlier reported a
difference in these sizes for three (text) files, with a binary
(gif) file apparently OK (interestingly, with a patch I posted
earlier to allow Win32 ActivePerl 8xx to be used with mod_perl 1
(with LARGE_FILES support), I get a failure with the gif file,
but not the text files). Anyway, could you see if the following
helps (applied to the libapreq sources)? For me, this allows all
the mod_perl t/modules/request tests to pass.
Yes, this fixes it for me.
All the mod_perl 1.28 tests now pass (and all the libapreq 1.2 tests
still pass as well).
Thanks!
Steve
Index: Request/Request.xs
===
RCS file: /home/cvs/httpd-apreq/Request/Request.xs,v
retrieving revision 1.36
diff -u -r1.36 Request.xs
--- Request/Request.xs 25 Jun 2003 07:59:37 - 1.36
+++ Request/Request.xs 4 Jul 2003 05:32:59 -
@@ -533,7 +533,7 @@
if (fd 0)
XSRETURN_UNDEF;
-if ( !(RETVAL = PerlIO_fdopen(fd, r)) )
+if ( !(RETVAL = PerlIO_fdopen(fd, rb)) )
XSRETURN_UNDEF;
#else
if ( ( RETVAL = PerlIO_importFILE(fp,0) ) == NULL )
@@ -558,7 +558,7 @@
PerlIO *fp;
fd = PerlLIO_dup(fd);
- if (!(fp = PerlIO_fdopen(fd, r))) {
+if (!(fp = PerlIO_fdopen(fd, rb))) {
PerlLIO_close(fd);
croak(fdopen failed!);
}
The first r - rb change (which affects the mod_perl tests)
is only relevant for Perl 5.7, which is why this problem didn't
arise on Win32 with Perl-5.6. Also, I think this r - rb
doesn't have any effect on Unix, but I haven't tested this.
Re: [ANNOUNCE] mod_perl-1.28
On Thu, 2003-07-03 at 15:46, Steve Hay wrote: Hi Philippe, Philippe M. Chiasson wrote: The URL http://perl.apache.org/dist/mod_perl-1.28.tar.gz has entered CPAN I still get the same test failures that I reported before when RC2 was announced: modules/request...FAILED tests 3-8 Failed 6/10 tests, 40.00% okay Setup: Windows XP, Perl 5.8.0, Apache 1.3.27, Apache-Test 1.03, libapreq-1.2 (built/installed *after* mod_perl 1.28). I used to have All tests successful under mp-1.27. (I note that Apache::Reload didn't make it in either; I thought the plan was to put a backport of the version from mp2 into it?) After discussing this at length with Stas, we decided it would be simpler to release 1.28 as-is (since it's been almost a year since the last release) and quicken the release milestone of 1.29 to include Apache::Reltoad and a whole bunch of other 'controversial' unresolved issues. So, Apache::Reload did not make it, but: 1. it is on CPAN 2. Apache::StatINC is still in 3. mod_perl-1.29 will have Apache::Reload 4. mod_perl-1.29 will be released soon So, that's what it'll be for now folks ! Steve signature.asc Description: This is a digitally signed message part
[ANNOUNCE] mod_perl-1.28
The URL
http://perl.apache.org/dist/mod_perl-1.28.tar.gz
has entered CPAN as
file: $CPAN/authors/id/G/GO/GOZER/mod_perl-1.28.tar.gz
size: 375986 bytes
md5: 889ad726a6d7c2fe03b2b1b93662f515
Changes since 1.27:
Apache::FakeRequest now isa Apache so code that is carefull about
$r and checks that $r-isa('Apache') will not fail [David Wheeler
[EMAIL PROTECTED]
Add Mac OS X support to Apache::SizeLimit [David Wheeler
[EMAIL PROTECTED]]
Add Win32 support to Apache::SizeLimit [Matt Phillips
[EMAIL PROTECTED] and Mohamed Hendawi [EMAIL PROTECTED]]
Change Apache::SizeLimit to not push a cleanup handler if already in
the cleanup handler phase, and adjust docs to show that cleanup
handler is the preferred phase to use [Perrin Harkins
[EMAIL PROTECTED]]
Rename Apache::test to Apache::testold because Apache::test on
case-insensitive systems will collide with Apache::Test which
supercedes Apache::test. So if you want to keep on using Apache::test,
either bundle it with your project (putting it under inc/ or t/ so it
won't be installed) or require mod_perl 1.28 and use Apache::testold
instead. Of course the best route is to port your test suite to use
a much better Apache::Test which work with mod_perl 1.0 and 2.0.
[Philippe M. Chiasson, Stas Bekman]
Tweak mod_perl.h to defined _INCLUDE_APACHE_FIRST only after apache
headers were included [Stas Bekman]
avoid various warnings under src/modules/perl/:
- declare bufsiz to be STRLEN in Apache.xs, and add
STRLEN to Apache/typemap
- add I32 typecast in Constants.xs
- avoid use of unregistered local variables for Win32
in mod_perl.c and perl_config.c
- s/I32/U8/ in mod_perl.h, perl_config.c, and perl_util.c
- declare i and http_code to be STRLEN in perl_util.c
[Stas Bekman, Randy Kobes]
don't use $r variable in Apache::PerlRun::compile(), so the script
won't use use inherited $r by mistake [Stas Bekman]
define PERL_DIRECTIVE_HANDLERS so that ModuleConfig.c gets
generated when building on Win32 within Visual Studio
[John Petrakis [EMAIL PROTECTED]]
enable PERL_SECTIONS for Win32 [Dirk Maetens [EMAIL PROTECTED]]
use touch() from ExtUtils::Command, rather than a system touch(),
for the benefit of platforms without touch(). [Randy Kobes
[EMAIL PROTECTED]]
can't let the default typemap rule to convert sv into char* in
unescape_url, since it doesn't handle correctly undefs (returns an
unallocated string, which then causes a segfault in
ap_unescape_url. use SvPV_force, instead, which does the right
thing. [Stas Bekman]
Make sure to start perl, if it's not running, before processing Perl*
directives, with threaded perl and PERL_STACKED_HANDLERS=0 [Stas
Bekman]
Add Apache::Module to Bundle::Apache [Stas Bekman]
use $Config{'installstyle'} instead of hardcoded 'lib', to handle
Makefile.PL's PREFIX option correctly [Philippe M. Chiasson
[EMAIL PROTECTED]]
prevent segfaults in mod_perl_mark_where() when a sub can't get
resolved [Gerald Richter [EMAIL PROTECTED]]
Apache::Status: Need to load B::Terse/TerseSize if it wasn't loaded
yet in that child before using it. [Dan Sully
[EMAIL PROTECTED]]
document the server_root_relative() method [Stas Bekman
[EMAIL PROTECTED]]
eliminate warnings when flushing functions with empty () prototypes in
Apache::PerlRun::flush_namespace [Yair Lenga [EMAIL PROTECTED]]
fix Apache::Status to not use :: in filenames, which is not allowed on
certain OSs [DH [EMAIL PROTECTED]]
various cygwin fixes [Per Einar Ellefsen [EMAIL PROTECTED]]
fix to compile with 5.8.0 on win32 [Randy Kobes
[EMAIL PROTECTED]]
Document the possible misuses of the Apache::Constant constants
[Per Einar Ellefsen [EMAIL PROTECTED]]
Patches since 1.27 can be reviewed here:
http://www.apache.org/~gozer/mp1/1.27-dev/
--
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/print||$$++redo}'
signature.asc
Description: This is a digitally signed message part
Re: [ANNOUNCE] mod_perl-1.28
Hi Philippe, Philippe M. Chiasson wrote: The URL http://perl.apache.org/dist/mod_perl-1.28.tar.gz has entered CPAN I still get the same test failures that I reported before when RC2 was announced: modules/request...FAILED tests 3-8 Failed 6/10 tests, 40.00% okay Setup: Windows XP, Perl 5.8.0, Apache 1.3.27, Apache-Test 1.03, libapreq-1.2 (built/installed *after* mod_perl 1.28). I used to have All tests successful under mp-1.27. (I note that Apache::Reload didn't make it in either; I thought the plan was to put a backport of the version from mp2 into it?) Steve
Is statically-compiled mod_perl better?
What is the preferred method of compiling mod_perl - static or dynamic? I have read that *static* linking is likely to load and execute faster, but may be wasteful of resources if there are multiple proceses each with its own copy of the common code. It therefore seems likely that a statically compiled mod_perl would be faster, provided that a large number of httpd's are not being run at the same time. Is this correct? It seems that at present it is not possible to build mod_perl 2.0 statically. It can only be built dynamically and loaded using LoadModule in httpd.conf. This seems strange if the preferred method of building is static. Thanks Colin __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
Re: Is statically-compiled mod_perl better?
Hi there, On Thu, 3 Jul 2003, ColinB wrote: What is the preferred method of compiling mod_perl - static or dynamic? Static. (But that's just my opinion after years of experience and watching people running into trouble with DSO mod_perl on this List. :) I have read that *static* linking is likely to load and execute faster, but may be wasteful of resources if there are multiple proceses each with its own copy of the common code. In normal circumstances the speed of loading is unlikely to be an issue. If you're using mod_perl 1.x on Linux/Unix/whatever then unless you're using 'httpd -X' or a very strange configuration there will be multiple processes. A recent post by Randal seemed to indicate the memory saved by using a DSO mod_perl wasn't as large as one might think - check the archives. It therefore seems likely that a statically compiled mod_perl would be faster, provided that a large number of httpd's are not being run at the same time. Is this correct? There are many factors to consider, but the speed difference between static and DSO isn't often talked about here so you can draw your own conclusions. Check out the tuning section of the Guide, the archives. It seems that at present it is not possible to build mod_perl 2.0 statically. It can only be built dynamically and loaded using LoadModule in httpd.conf. This seems strange if the preferred method of building is static. True. That's because it's still in development. Check the archives... 73, Ged.
Re: Is statically-compiled mod_perl better?
Ged == Ged Haywood [EMAIL PROTECTED] writes: Ged A recent post by Randal seemed to indicate the memory saved Ged by using a DSO mod_perl wasn't as large as one might think - check the Ged archives. And I've confirmed that observation at least on Solaris and OpenBSD. You can build a static mod_perl-enabled binary. Just be sure to have: ClearModuleList AddModule mod_mime.c ... and add only the modules that you're using. Modules that don't get add-ed appear to take up no data space... just becoming part of the shared single binary that is being accessed. (You can get the list with 'httpd -l' and a bit of text massaging.) My front proxy processes are a mere 1.5 Meg right now, running basically mod_ssl, mod_rewrite, and mod_proxy, and it's the same binary as my backend mod_perl work processes, running about 10 to 15 Meg a piece. No more DSO. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Is statically-compiled mod_perl better?
Thanks for the comments. I guess I'll just have to stick with the dynamically-linked mod_perl 2.0 for the time being. I'll keep checking the mod_perl 2.0 site pages and pick up a static-capable version when it becomes available. Colin __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
Re: require'ing data files under mod_perl
On Mon, Jun 30, 2003 at 05:28:43PM -0400, Perrin Harkins wrote:
On Sat, 2003-06-28 at 15:08, Peter B. Ensch wrote:
Coding in plain CGI I've often require'd files containing
data in perl data-structures. The script may write to the
file (via Data::Dumper for example) allowing subsequent
invokations of the script to have access to the revised
data.
It would be simpler and faster to use MLDBM::Sync for this.
Not familiar w/ this module and it's not on our system; I'll
certainly look into it.
I was expecting this methodology to break under mod_perl
thinking that the require would only happen once (the
first time the script runs after server startup); however,
it seems to be working the way it always did.
Why is this? Am I missing something?
Can't tell without seeing some code. Your require'd files with not be
reloaded unless you are using Apache::Reload or Apache::StatINC to force
them.
I'm NOT using A::Reload or A::StatINC. My script appears to be
require'ing the data file on each user transaction, just like
under plain CGI.
I'm using CGI::Application and this part of the code happens inside
the cgiapp_init() method which I'm overriding:
our $USERS : unique = /path/to/users.dat;
sub cgiapp_init {
my $self = shift;
$self-param('users' = require ${\$USERS});
}
So, to reiterate, I may write to users.dat on one transaction
and read on another; the file contents is always up-to-date.
I still can't understand why this is because I did not think
it would be reloaded unless the server was restarted.
BTW - it doesn't have anything to do with the 'unique' our
attribute; same behavour with or without.
I'm new to apache and I'm not running in single-process mode;
this shouldn't have a bearing should it?
Thanks,
P
--
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Peter Ensch,
[EMAIL PROTECTED] A-1140 (214) 480 2333
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Re: require'ing data files under mod_perl
On Thu, 2003-07-03 at 13:38, Peter Ensch wrote:
I'm using CGI::Application and this part of the code happens inside
the cgiapp_init() method which I'm overriding:
our $USERS : unique = /path/to/users.dat;
sub cgiapp_init {
my $self = shift;
$self-param('users' = require ${\$USERS});
}
That's confusing code. Your users.dat file is a chunk of code that
returns a value that you use? A little obscure, in my opinion. And
what's that stuff with the ref/de-ref syntax for?
So, to reiterate, I may write to users.dat on one transaction
and read on another; the file contents is always up-to-date.
The file is up-to-date, or the param 'users' is?
Why don't you debug it a little by putting a warn statement in your
users.dat file that prints the process ID? Then you can tell if it is
truly being executed more than once by the same process.
- Perrin
Re: require'ing data files under mod_perl
On Thu, Jul 03, 2003 at 02:51:23PM -0400, Perrin Harkins wrote:
On Thu, 2003-07-03 at 13:38, Peter Ensch wrote:
I'm using CGI::Application and this part of the code happens inside
the cgiapp_init() method which I'm overriding:
our $USERS : unique = /path/to/users.dat;
sub cgiapp_init {
my $self = shift;
$self-param('users' = require ${\$USERS});
}
That's confusing code. Your users.dat file is a chunk of code that
returns a value that you use? A little obscure, in my opinion. And
what's that stuff with the ref/de-ref syntax for?
The file contains a simple hash ref. like
{
duck = 'quack',
dog = 'woof',
cat = 'meow',
}
The ref/de-ref was a mistake; a hold over from when USERS was a
constant (and which didn't interpolate in a require). Now it's
$self-param('users' = require $USERS);
So, to reiterate, I may write to users.dat on one transaction
and read on another; the file contents is always up-to-date.
The file is up-to-date, or the param 'users' is?
The file is. IE. it gets written and and the new stuff is available
by simply reloading the page.
Why don't you debug it a little by putting a warn statement in your
users.dat file that prints the process ID? Then you can tell if it is
truly being executed more than once by the same process.
Hmm. Not sure how to do that w/out messing w/ the headers and
making the app. crash. How would I do that?
P
--
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Peter Ensch,
[EMAIL PROTECTED] A-1140 (214) 480 2333
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Re: require'ing data files under mod_perl
On Thu, 2003-07-03 at 16:16, Peter Ensch wrote: So, to reiterate, I may write to users.dat on one transaction and read on another; the file contents is always up-to-date. The file is up-to-date, or the param 'users' is? The file is. IE. it gets written and and the new stuff is available by simply reloading the page. Well, the file getting written is not related to require loading each time or not. The thing that I would not expect to change is the in-memory data. Why don't you debug it a little by putting a warn statement in your users.dat file that prints the process ID? Then you can tell if it is truly being executed more than once by the same process. Hmm. Not sure how to do that w/out messing w/ the headers and making the app. crash. How would I do that? Before the hash stuff in the file, put in a statement like this: warn users.dat loaded by process $$; - Perrin
Re: require'ing data files under mod_perl
On Thu, Jul 03, 2003 at 04:24:35PM -0400, Perrin Harkins wrote: On Thu, 2003-07-03 at 16:16, Peter Ensch wrote: So, to reiterate, I may write to users.dat on one transaction and read on another; the file contents is always up-to-date. The file is up-to-date, or the param 'users' is? The file is. IE. it gets written and and the new stuff is available by simply reloading the page. Well, the file getting written is not related to require loading each time or not. The thing that I would not expect to change is the in-memory data. Why don't you debug it a little by putting a warn statement in your users.dat file that prints the process ID? Then you can tell if it is truly being executed more than once by the same process. Hmm. Not sure how to do that w/out messing w/ the headers and making the app. crash. How would I do that? Before the hash stuff in the file, put in a statement like this: warn users.dat loaded by process $$; OK. Thanks. Well, yes it is being reloaded whenever the form is submitted and w/out restarting the server. Here's some of the output (error_log): [Thu Jul 3 15:52:00 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:00 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:00 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:03 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:04 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:06 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:32 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:33 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:52:34 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:00 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:03 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:05 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:22 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:25 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:28 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:28 2003] users.dat: users.dat loaded by process 18338 at /opt/a... Here are the httpd process: [490] % ps -Alf |grep apache 8 S root 17921 ... /apps/apache/http/2.0.46/worker/bin 8 S apache 18338 ... /apps/apache/http/2.0.46/worker/bin 8 S apache 18336 ... /apps/apache/http/2.0.46/worker/bin 8 S apache 18337 ... /apps/apache/http/2.0.46/worker/bin So. What's going on? I'm not using A::Reload. P -- ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^ Peter Ensch, [EMAIL PROTECTED] A-1140 (214) 480 2333 ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Re: require'ing data files under mod_perl
On Thu, 2003-07-03 at 16:59, Peter Ensch wrote: OK. Thanks. Well, yes it is being reloaded whenever the form is submitted and w/out restarting the server. Here's some of the output (error_log): [Thu Jul 3 15:52:00 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:00 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:00 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:03 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:04 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:06 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:32 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:33 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:52:34 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:00 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:03 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:05 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:22 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:25 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:28 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:28 2003] users.dat: users.dat loaded by process 18338 at /opt/a... Just a guess, but maybe this is because you're passing a variable to the require function. Try hard-coding it and see if it changes. - Perrin
Re: Best compression for mod_perl application?
--- Bill Marrs [EMAIL PROTECTED] wrote: My own personal experience with mod_deflate (in Apache/2.0.46) is that it tends to spike my server's load. My server (gametz.com) is dual http://lists.over.net/pipermail/mod_gzip/2003-June/007130.html seems to say that mod_gzip has its own implementation for compression whereas mod_deflate uses zlib. I am assuming the shared library is somehow at fault here ? Mithun __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
segmentation fault under mod_perl+XML::XPath
Hello.
I've tried to use XML::XPath under mod_perl 1.27 and Apache 1.3.27, but
got segmentation fault with this peace of code:
use XML::XPath;
my $mfname='/proj/optolink/html/.meta.xml';
my $xp = XML::XPath-new(filename = $mfname);
my $ns = $xp-find('//[EMAIL PROTECTED]yes]');
Under command line and CGI it's working fine and all tests during installation of
XML::XPath were fine, but the same code crush apache+mod_perl.
Apache - with so, unique_id, no expat
mod_perl with everything as DSO
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=freebsd, osvers=4.5-stable, archname=i386-freebsd
uname='freebsd flamengo.citl.miee.ru 4.5-stable freebsd 4.5-stable #3: tue apr 23
15:48:51 msd 2002 [EMAIL PROTECTED]:usrsrcsyscompileflamengo i386 '
config_args='-de'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing
-I/usr/local/include',
optimize='-O',
cppflags='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing
-I/usr/local/include'
ccversion='', gccversion='2.95.3 20010315 (release) [FreeBSD]', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags ='-Wl,-E -L/usr/local/lib'
libpth=/usr/lib /usr/local/lib
libs=-lm -lc -lcrypt -lutil
perllibs=-lm -lc -lcrypt -lutil
libc=, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-DPIC -fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under freebsd
Compiled at Oct 23 2002 11:00:00
@INC:
/usr/local/lib/perl5/5.8.0/i386-freebsd
/usr/local/lib/perl5/5.8.0
/usr/local/lib/perl5/site_perl/5.8.0/i386-freebsd
/usr/local/lib/perl5/site_perl/5.8.0
/usr/local/lib/perl5/site_perl
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x80711c5 in poolCopyString ()
(gdb) bt
#0 0x80711c5 in poolCopyString ()
#1 0x806cf71 in XML_SetBase ()
#2 0x28cfcc92 in XS_XML__Parser__Expat_SetBase ()
from
/usr/local/lib/perl5/site_perl/5.8.0/i386-freebsd/auto/XML/Parser/Expat/Expat.so
#3 0x28c398fb in Perl_pp_entersub () from
/usr/local/libexec/apache/libperl.so
#4 0x28c33c28 in Perl_runops_standard ()
from /usr/local/libexec/apache/libperl.so
#5 0x28bf2f36 in S_call_body () from /usr/local/libexec/apache/libperl.so
#6 0x28bf2d16 in Perl_call_sv () from
/usr/local/libexec/apache/libperl.so
#7 0x28bd3d56 in perl_call_handler ()
from /usr/local/libexec/apache/libperl.so
#8 0x28bd359e in perl_run_stacked_handlers ()
from /usr/local/libexec/apache/libperl.so
#9 0x28bd1d64 in perl_handler () from
/usr/local/libexec/apache/libperl.so
#10 0x8052595 in ap_invoke_handler ()
#11 0x806225c in process_request_internal ()
#12 0x80622bd in ap_process_request ()
#13 0x805b52e in child_main ()
#14 0x805b6a0 in make_child ()
#15 0x805b7bd in startup_children ()
#16 0x805bcb4 in standalone_main ()
#17 0x805c397 in main ()
#18 0x804ebe1 in _start ()
Any help would be good.
Ruslan.
Re: mod_perl-1.99_09 for Redhat 9
On Thu, 2003-06-26 at 06:53, Bill Marrs wrote: I'm looking for a Redhat 9 compatible mod_perl-1.99_09 rpm. If anyone has one or knows where I can get one, let me know. I've just finished building RPMs for mod_perl 1.99_09 on RH9/i386 Grab them at: http://www.apache.org/~gozer/mp2/ Thanks, -bill p.s. I did find a Rawhide (bleeding edge Red Hat release, I think) mod_perl-1.99_09, but it doesn't seem to be compatible (I got an error from Apache). signature.asc Description: This is a digitally signed message part
RE: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perl handler philosophy)
Hi Joe -- +1. Scripting _inside_ the server opens up possibilities that are unimaginable to folks who are content confining themselves to the lowest common denominator (CGI). Perhaps you could bullet-point a few of these possibilities for those of us who are confined by our lack of imagination? TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: segmentation fault under mod_perl+XML::XPath
Hi there,
Haven't seen any replies, so I thought you'd like to hear from someone. :)
On Wed, 2 Jul 2003, Ruslan U. Zakirov wrote:
I've tried to use XML::XPath under mod_perl 1.27 and Apache 1.3.27, but
got segmentation fault
It's not uncommon to see XML and segfaults in the same post. :(
Have you searched the archives?
Under command line and CGI it's working fine and all tests during installation of
XML::XPath were fine, but the same code crush apache+mod_perl.
[snip]
Apache - with so, unique_id, no expat
mod_perl with everything as DSO
Whenever I see segfaults in a DSO Apache I'd say try static linking if
you don't know what else to try. :)
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Did you compile this Perl yourself? The standard advice is to compile
mod_perl and Perl with the same compiler.
usemymalloc=n, bincompat5005=undef
Highly unlikely, but maybe a malloc problem?
ccversion='', gccversion='2.95.3 20010315 (release) [FreeBSD]', gccosandvers=''
You should be OK with that compiler, is that what you're using yourself?
Hope you're not using gcc 3.x with that Perl...
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-DPIC -fpic', lddlflags='-shared -L/usr/local/lib'
Never heard of Perl (as opposed to mod_perl) dynamic linking causing a
problem, so don't worry about that. (Until later.:)
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x80711c5 in poolCopyString ()
(gdb) bt
#0 0x80711c5 in poolCopyString ()
This is the code in xmlparse.c from my 1.3.27 source tree:
--
static const XML_Char *poolCopyString(STRING_POOL *pool, const XML_Char *s)
{
do {
if (!poolAppendChar(pool, *s))
return 0;
} while (*s++);
s = pool-start;
poolFinish(pool);
return s;
}
--
Assuming you're using the same thing...
As far as I can see this must mean that your pointer s is invalid, and
either the dereference *s causes a memory bound error or else the s++
increment tries to increment it off the end of the stack or something.
There's nothing else in that function that would be likely to cause the
fault, if pool were invalid I'd expect it to happen in poolAppendChar().
I have no idea why these might be but it's a bit serious of course.
You're into XS territory, the sort of thing that can easily be thrown
by struct alignment problems such as you might get on the less well
exercised configurations - which probably includes FreeBSD - and an
unsuitable combination of compilers/dso/libraries/...
You shouldn't have to be delving this deeply into these packages, but
if a static link or a compiler change doesn't fix it and you don't
mind cranking gdb a bit further you could find out what that pointer
is pointing to and if it's a valid XML_Char pointer.
Hope this gets you started in the right direction, but please don't
take it as authoritative as I've never used FreeBSD nor XML::XPath.
73,
Ged.
Re: segmentation fault under mod_perl+XML::XPath
Hello again, On Thu, 3 Jul 2003, Ged Haywood wrote: There's nothing else in that function that would be likely to cause the fault, if pool were invalid I'd expect it to happen in poolAppendChar(). Of course unless poolAppendChar() turns out to be a function defined by a macro, which it does, so forget that last bit. Could be pool too. :( 73, Ged.
Re: [RFC] web-messaging application for mod_perl
On Mon, 30 Jun 2003 12:57:00 -0700 Adi Fairbank [EMAIL PROTECTED] wrote: Apache::WebMessaging I am about ready to release an intraserver web-messaging application for mod_perl. A brief description of the app follows; I'd like to hear some comments from the mod_perl/Perl/P5EE community on: You could look about Apache::* modules naming conventions: http://perl.apache.org/products/apache-modules.html#Module_Naming_Conventions Apache::App::WebMessaging namespace could be a right place :-) by - Enrico
Best compression for mod_perl application?
I used to use mod_gzip under Apache 1.3, and it worked great, saving my over 50% of my bandwidth for my mod_perl generated pages. But, it appears that mod_gzip doesn't work with Apache 2. Apache 2 has a built-in mod_deflate, but I've had some trouble with it (seemed to cause a load spike on my server + errors if I print ). I recall there used to be alternatives to mod_gzip out there, but I'm not sure if they apply to Apache 2. Are any of you use compression on your mod_perl pages? Do you recommend any compression schemes for the Apache 2/mp2 environment? TIA, -=bill
Re: Best compression for mod_perl application?
HI Bill, mod_gzip gave me a lot of grief when I used it - spurious errors kept filling the log and it didn't work easily with SSL. I spent a day trying to configure a nasty proxy solution. Apache::DynaGZIP has been much less hassle to install and run and it works with SSL. Although, I have not tried it on Apache 2. Kind Rehards, NIgel -- 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: Best compression for mod_perl application?
Apache::Dynagzip is not supposed to work on Apache-2. That would be of my real interest to know as many details of Bill's experience with mod_deflate as he can provide. Thanks, Slava - Original Message - From: Nigel Hamilton [EMAIL PROTECTED] To: Bill Marrs [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 9:56 AM Subject: Re: Best compression for mod_perl application? HI Bill, mod_gzip gave me a lot of grief when I used it - spurious errors kept filling the log and it didn't work easily with SSL. I spent a day trying to configure a nasty proxy solution. Apache::DynaGZIP has been much less hassle to install and run and it works with SSL. Although, I have not tried it on Apache 2. Kind Rehards, NIgel -- 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: Best compression for mod_perl application?
Hi Nigel, I had the same question three month ago. There are a few sources which compare the different modules. See mod_perl guide. My solution is now mod_deflate 1.0.18 with apache 1.3.27. My configuration in httpd.conf is: # activate compress IfModule mod_deflate.c # main switch DeflateEnable on DeflateMinLength1024 DeflateCompLevel8 # compress over proxies DeflateProxied on # switch off MSIE 4.x - has bugs DeflateDisableRange MSIE 4. # experimentell - for uploads DeflateVary on # DeflateHTTP 1.1 # default # activate for HTTP 1.0 DeflateHTTP 1.0 # DeflateTypestext/html # default # add more content types for compression DeflateTypestext/css DeflateTypestext/plain DeflateTypestext/rtf DeflateTypestext/xml DeflateTypestext/javascript DeflateTypesimage/vnd.dwg DeflateTypesimage/vnd.dxf DeflateTypesapplication/msword DeflateTypesapplication/vnd.hp-HPGL DeflateTypesapplication/vnd.ms-access DeflateTypesapplication/vnd.ms-excel DeflateTypesapplication/vnd.ms-powerpoint DeflateTypesapplication/vnd.ms-project DeflateTypesapplication/vnd.visio DeflateTypesapplication/x-javascript # pdf does no work # DeflateTypesapplication/pdf /IfModule I hope that helps you. Regards, Sven. Am Die, 2003-07-01 um 17.02 schrieb Slava Bizyayev: Apache::Dynagzip is not supposed to work on Apache-2. That would be of my real interest to know as many details of Bill's experience with mod_deflate as he can provide. Thanks, Slava - Original Message - From: Nigel Hamilton [EMAIL PROTECTED] To: Bill Marrs [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 9:56 AM Subject: Re: Best compression for mod_perl application? HI Bill, mod_gzip gave me a lot of grief when I used it - spurious errors kept filling the log and it didn't work easily with SSL. I spent a day trying to configure a nasty proxy solution. Apache::DynaGZIP has been much less hassle to install and run and it works with SSL. Although, I have not tried it on Apache 2. Kind Rehards, NIgel -- 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: A::Registry vs. mod_perl handler philosophy
On Fri, 2003-06-20 at 12:18, Peter B. Ensch wrote: It's been suggested to me that content generating apps should be done under A::R, whereas logging, authentication Etc. should be implemented as mod_perl handlers. What is the opinion of the group? I'm late to the party, but here's an old post of mine that sums up my opinion: http://marc.theaimsgroup.com/?l=apache-modperlm=95440118003848w=2 - Perrin
Re: Best compression for mod_perl application?
And how about http://devl4.outlook.net/devdoc/FAQ/compression.html for Apache 1.3.27? ;-) Slava - Original Message - From: Sven Geisler [EMAIL PROTECTED] To: Nigel Hamilton [EMAIL PROTECTED]; Slava Bizyayev [EMAIL PROTECTED] Cc: Bill Marrs [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 10:48 AM Subject: Re: Best compression for mod_perl application? Hi Nigel, I had the same question three month ago. There are a few sources which compare the different modules. See mod_perl guide. My solution is now mod_deflate 1.0.18 with apache 1.3.27. My configuration in httpd.conf is: # activate compress IfModule mod_deflate.c # main switch DeflateEnable on DeflateMinLength1024 DeflateCompLevel8 # compress over proxies DeflateProxied on # switch off MSIE 4.x - has bugs DeflateDisableRange MSIE 4. # experimentell - for uploads DeflateVary on # DeflateHTTP 1.1 # default # activate for HTTP 1.0 DeflateHTTP 1.0 # DeflateTypestext/html # default # add more content types for compression DeflateTypestext/css DeflateTypestext/plain DeflateTypestext/rtf DeflateTypestext/xml DeflateTypestext/javascript DeflateTypesimage/vnd.dwg DeflateTypesimage/vnd.dxf DeflateTypesapplication/msword DeflateTypesapplication/vnd.hp-HPGL DeflateTypesapplication/vnd.ms-access DeflateTypesapplication/vnd.ms-excel DeflateTypesapplication/vnd.ms-powerpoint DeflateTypesapplication/vnd.ms-project DeflateTypesapplication/vnd.visio DeflateTypesapplication/x-javascript # pdf does no work # DeflateTypesapplication/pdf /IfModule I hope that helps you. Regards, Sven. Am Die, 2003-07-01 um 17.02 schrieb Slava Bizyayev: Apache::Dynagzip is not supposed to work on Apache-2. That would be of my real interest to know as many details of Bill's experience with mod_deflate as he can provide. Thanks, Slava - Original Message - From: Nigel Hamilton [EMAIL PROTECTED] To: Bill Marrs [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 9:56 AM Subject: Re: Best compression for mod_perl application? HI Bill, mod_gzip gave me a lot of grief when I used it - spurious errors kept filling the log and it didn't work easily with SSL. I spent a day trying to configure a nasty proxy solution. Apache::DynaGZIP has been much less hassle to install and run and it works with SSL. Although, I have not tried it on Apache 2. Kind Rehards, NIgel -- 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: [RFC] web-messaging application for mod_perl
On, or in the near vicinity of Tue, 1 Jul 2003 11:23:00 +0200 Enrico Sorcinelli [EMAIL PROTECTED] has thus spoken: On Mon, 30 Jun 2003 12:57:00 -0700 Adi Fairbank [EMAIL PROTECTED] wrote: Apache::WebMessaging I am about ready to release an intraserver web-messaging application for mod_perl. A brief description of the app follows; I'd like to hear some comments from the mod_perl/Perl/P5EE community on: You could look about Apache::* modules naming conventions: http://perl.apache.org/products/apache-modules.html#Module_Naming_Conventions Apache::App::WebMessaging namespace could be a right place :-) According to the asterisk note below Apache::App:: However, if you are planning a substantial framework with many inter-related modules, you should probably go with a top-level namespace outside of Apache::. This app already has 7-8 inter-related modules, though I would not call it a substantial framework. In fact it requires you to already have your own application framework setup in order to use it. It's basically a plug-in application for your existing mod_perl framework. I could rename it to just WebMessaging:: but it is specifically designed for mod_perl, which is why I think it should go in Apache::. Also, I noticed there are currently no Apache::App:: modules. Should this be the first?? -Adi
Re: Best compression for mod_perl application?
This is one of the source I had in mind. Well done Slava. BTW. Do you consider the latest version of mod_deflate? Regardsm Sven. Am Die, 2003-07-01 um 18.12 schrieb Slava Bizyayev: And how about http://devl4.outlook.net/devdoc/FAQ/compression.html for Apache 1.3.27? ;-) Slava - Original Message - From: Sven Geisler [EMAIL PROTECTED] To: Nigel Hamilton [EMAIL PROTECTED]; Slava Bizyayev [EMAIL PROTECTED] Cc: Bill Marrs [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 10:48 AM Subject: Re: Best compression for mod_perl application? Hi Nigel, I had the same question three month ago. There are a few sources which compare the different modules. See mod_perl guide. My solution is now mod_deflate 1.0.18 with apache 1.3.27. My configuration in httpd.conf is: # activate compress IfModule mod_deflate.c # main switch DeflateEnable on DeflateMinLength1024 DeflateCompLevel8 # compress over proxies DeflateProxied on # switch off MSIE 4.x - has bugs DeflateDisableRange MSIE 4. # experimentell - for uploads DeflateVary on # DeflateHTTP 1.1 # default # activate for HTTP 1.0 DeflateHTTP 1.0 # DeflateTypestext/html # default # add more content types for compression DeflateTypestext/css DeflateTypestext/plain DeflateTypestext/rtf DeflateTypestext/xml DeflateTypestext/javascript DeflateTypesimage/vnd.dwg DeflateTypesimage/vnd.dxf DeflateTypesapplication/msword DeflateTypesapplication/vnd.hp-HPGL DeflateTypesapplication/vnd.ms-access DeflateTypesapplication/vnd.ms-excel DeflateTypesapplication/vnd.ms-powerpoint DeflateTypesapplication/vnd.ms-project DeflateTypesapplication/vnd.visio DeflateTypesapplication/x-javascript # pdf does no work # DeflateTypesapplication/pdf /IfModule I hope that helps you. Regards, Sven. Am Die, 2003-07-01 um 17.02 schrieb Slava Bizyayev: Apache::Dynagzip is not supposed to work on Apache-2. That would be of my real interest to know as many details of Bill's experience with mod_deflate as he can provide. Thanks, Slava - Original Message - From: Nigel Hamilton [EMAIL PROTECTED] To: Bill Marrs [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 9:56 AM Subject: Re: Best compression for mod_perl application? HI Bill, mod_gzip gave me a lot of grief when I used it - spurious errors kept filling the log and it didn't work easily with SSL. I spent a day trying to configure a nasty proxy solution. Apache::DynaGZIP has been much less hassle to install and run and it works with SSL. Although, I have not tried it on Apache 2. Kind Rehards, NIgel -- 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.
Apache::Request for CGI? (was: Re: A::Registry vs. mod_perl handler philosophy)
Perrin Harkins [EMAIL PROTECTED] writes: [...] I'm late to the party, but here's an old post of mine that sums up my opinion: http://marc.theaimsgroup.com/?l=apache-modperlm=95440118003848w=2 +1. Scripting _inside_ the server opens up possibilities that are unimaginable to folks who are content confining themselves to the lowest common denominator (CGI). That said, apreq-dev is looking for someone to adopt and develop the CGI port of libapreq-2/Apache::Request. I'm shooting for a developer release of libapreq-2 before OSCON, and it'd be _really_ cool if we had a functional CGI port available. -- Joe Schaefer
Re: Best compression for mod_perl application?
Thanks Sven, From my current point of view mod_deflate for Apache-2 should be still considered in experimental stage. That's why I so interested to collect as much user experience with mod_deflate-2 as possible. Thanks, Slava - Original Message - From: Sven Geisler [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: Nigel Hamilton [EMAIL PROTECTED]; Bill Marrs [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 11:21 AM Subject: Re: Best compression for mod_perl application? This is one of the source I had in mind. Well done Slava. BTW. Do you consider the latest version of mod_deflate? Regardsm Sven. Am Die, 2003-07-01 um 18.12 schrieb Slava Bizyayev: And how about http://devl4.outlook.net/devdoc/FAQ/compression.html for Apache 1.3.27? ;-) Slava - Original Message - From: Sven Geisler [EMAIL PROTECTED] To: Nigel Hamilton [EMAIL PROTECTED]; Slava Bizyayev [EMAIL PROTECTED] Cc: Bill Marrs [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 10:48 AM Subject: Re: Best compression for mod_perl application? Hi Nigel, I had the same question three month ago. There are a few sources which compare the different modules. See mod_perl guide. My solution is now mod_deflate 1.0.18 with apache 1.3.27. My configuration in httpd.conf is: # activate compress IfModule mod_deflate.c # main switch DeflateEnable on DeflateMinLength1024 DeflateCompLevel8 # compress over proxies DeflateProxied on # switch off MSIE 4.x - has bugs DeflateDisableRange MSIE 4. # experimentell - for uploads DeflateVary on # DeflateHTTP 1.1 # default # activate for HTTP 1.0 DeflateHTTP 1.0 # DeflateTypestext/html # default # add more content types for compression DeflateTypestext/css DeflateTypestext/plain DeflateTypestext/rtf DeflateTypestext/xml DeflateTypestext/javascript DeflateTypesimage/vnd.dwg DeflateTypesimage/vnd.dxf DeflateTypesapplication/msword DeflateTypesapplication/vnd.hp-HPGL DeflateTypesapplication/vnd.ms-access DeflateTypesapplication/vnd.ms-excel DeflateTypesapplication/vnd.ms-powerpoint DeflateTypesapplication/vnd.ms-project DeflateTypesapplication/vnd.visio DeflateTypesapplication/x-javascript # pdf does no work # DeflateTypesapplication/pdf /IfModule I hope that helps you. Regards, Sven. Am Die, 2003-07-01 um 17.02 schrieb Slava Bizyayev: Apache::Dynagzip is not supposed to work on Apache-2. That would be of my real interest to know as many details of Bill's experience with mod_deflate as he can provide. Thanks, Slava - Original Message - From: Nigel Hamilton [EMAIL PROTECTED] To: Bill Marrs [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 9:56 AM Subject: Re: Best compression for mod_perl application? HI Bill, mod_gzip gave me a lot of grief when I used it - spurious errors kept filling the log and it didn't work easily with SSL. I spent a day trying to configure a nasty proxy solution. Apache::DynaGZIP has been much less hassle to install and run and it works with SSL. Although, I have not tried it on Apache 2. Kind Rehards, NIgel -- 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: Best compression for mod_perl application?
That would be of my real interest to know as many details of Bill's
experience with mod_deflate as he can provide.
Since I posted my first message, I've been snooping around the 'net to find
more info on mod_gzip and mod_deflate. Here's what I came up with:
The general recommendation seems to be migration from mod_gzip to
mod_deflate when you switch to Apache 2.0. mod_gzip seems to have lost
most of its support going forward while mod_deflate is part of the Apache
source code and has active development.
There is a Apache 2.0 compatible version of mod_gzip, here:
http://www.gknw.de/development/apache/httpd-2.0/unix/modules/
When I tried it, it didn't work for me. It caused my site to spit out
blank pages and garbage. I had used my old Apache 1.3 mod_gzip config with
it. I read that there's some odd timing issues where the Apache 2.0
version of mod_gzip branched a long time ago and thus doesn't have some of
the modern mod_gzip 1.3.x features. I didn't get config errors, though,
just blanks and garbage. So, I decided to back away slowly for mod_gzip on
Apache 2.0. There is more discussion of it here:
http://freshmeat.net/projects/mod_gzip/?topic_id=90
There a good mod_gzip info page here, though little is said about a 2.0
version:
http://www.schroepl.net/projekte/mod_gzip/index.htm
The mod_gzip mailing list has some good info. Here's a 26 Jun 2003 post by
someone who seems to know well what's going on (I think the author of the
above page):
Subject: [Mod_gzip] gzip vs deflate on Apache
http://lists.over.net/pipermail/mod_gzip/2003-June/007130.html
So, I decided to try harder to move ahead with mod_deflate. I'm using a
built from scratch, Apache/2.0.46 mod_perl_1.99_09. Work is being done on
mod_deflate, some recent directives has been added (I hear). One of which
is DeflateCompressionLevel. Along with this addition in 2.0.44 came a
better default for this compression level. It's now 6, the same thing that
gzip and zlib uses by default. Apparently, it had been 1 before that,
which is fast but doesn't compress very well. There's some discussion of
this here:
http://www.webcompression.org/deflate-compress.html
My own personal experience with mod_deflate (in Apache/2.0.46) is that it
tends to spike my server's load. My server (gametz.com) is dual 800Mhz,
1.5GB ram, Linux, doing about 70K pages/day. Last night, I happened to be
watching it while the load jumped up a few points during my site's prime
time, so I pulled mod_deflate out of the config file and that fixed it.
So, today, I'm trying a lower DeflateCompressionLevel. I'm using 4 now
(instead of the default 6). This seems better, though the load is still a
little higher than it should be and I'm not quote at prime time
yet. Still, I am getting decent compression. I'm going to keep an eye on
it, I suspect I'll be at 3 later this evening.
I never had any trouble with load when I used mod_gzip and Apache 1.3.
The other odd problem I got was that if anywhere in my perl code I printed
nothing (e.g. print or $foo=;print $foo), I'd get this error:
error: 20014:Error string not specified yet at /my/perl/code.pl line 123
This error was both blurted to the error_log and to the web page (screwing
up the page and truncating further output).
I changed my code to print instead of (HTML ignores extra
white-space, so no biggie), and the errors all went away. So, I see this
as an annoyance more than a serious bug.
I really should try to tell the author of mod_deflate about these problems.
Here's the config I'm using for mod_deflate:
#
## Deflate
#
LoadModule deflate_module modules/mod_deflate.so
AddOutputFilterByType DEFLATE text/*
SetOutputFilter DEFLATE
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
DeflateBufferSize 8096
# DeflateCompressionLevel 6
DeflateCompressionLevel 4
DeflateMemLevel 9
DeflateWindowSize 15
DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
LogFormat '%r %{outstream}n/%{instream}n (%{ratio}n%%) %{User-agent}i'
defl\
ate
CustomLog /var/log/httpd/deflate_log deflate
All of which I cribbed from the Apache 2.0 manual:
http://httpd.apache.org/docs-2.0/mod/mod_deflate.html
I sort of got forced into upgrading to Apache 2.0/mp2/etc. by RedHat. They
announced they would pull support for old releases (all that used Apache
1.3) by the end of the year. Apparently, this may be an intentional
(evil?) business move by them to motivate more customers to move to their
Enterprise OS (which is very expensive, but has more stable software like
good old Apache 1.3 mp1).
I did try to go back at one point, builing Apache 1.3 from source, but it
had some other problem (maybe, because I used Perl 5.8.0?). But, then I
waffled and decided there's also a lot of value in staying current. So,
I'm back to 2.0 land, and I'm surviving so far.
-=bill
Re: Best compression for mod_perl application?
Hi Bill,
Thanks for taking the time to post your experiences.
It's a shame that so much time is spent tweaking, compiling,
testing, ferretting for bug references.
On Tue, 1 Jul 2003, Bill Marrs wrote:
That would be of my real interest to know as many details of Bill's
experience with mod_deflate as he can provide.
Since I posted my first message, I've been snooping around the 'net to find
more info on mod_gzip and mod_deflate. Here's what I came up with:
The general recommendation seems to be migration from mod_gzip to
mod_deflate when you switch to Apache 2.0. mod_gzip seems to have lost
most of its support going forward while mod_deflate is part of the Apache
source code and has active development.
There is a Apache 2.0 compatible version of mod_gzip, here:
http://www.gknw.de/development/apache/httpd-2.0/unix/modules/
When I tried it, it didn't work for me. It caused my site to spit out
blank pages and garbage. I had used my old Apache 1.3 mod_gzip config with
it. I read that there's some odd timing issues where the Apache 2.0
version of mod_gzip branched a long time ago and thus doesn't have some of
the modern mod_gzip 1.3.x features. I didn't get config errors, though,
just blanks and garbage. So, I decided to back away slowly for mod_gzip on
Apache 2.0. There is more discussion of it here:
http://freshmeat.net/projects/mod_gzip/?topic_id=90
There a good mod_gzip info page here, though little is said about a 2.0
version:
http://www.schroepl.net/projekte/mod_gzip/index.htm
The mod_gzip mailing list has some good info. Here's a 26 Jun 2003 post by
someone who seems to know well what's going on (I think the author of the
above page):
Subject: [Mod_gzip] gzip vs deflate on Apache
http://lists.over.net/pipermail/mod_gzip/2003-June/007130.html
So, I decided to try harder to move ahead with mod_deflate. I'm using a
built from scratch, Apache/2.0.46 mod_perl_1.99_09. Work is being done on
mod_deflate, some recent directives has been added (I hear). One of which
is DeflateCompressionLevel. Along with this addition in 2.0.44 came a
better default for this compression level. It's now 6, the same thing that
gzip and zlib uses by default. Apparently, it had been 1 before that,
which is fast but doesn't compress very well. There's some discussion of
this here:
http://www.webcompression.org/deflate-compress.html
My own personal experience with mod_deflate (in Apache/2.0.46) is that it
tends to spike my server's load. My server (gametz.com) is dual 800Mhz,
1.5GB ram, Linux, doing about 70K pages/day. Last night, I happened to be
watching it while the load jumped up a few points during my site's prime
time, so I pulled mod_deflate out of the config file and that fixed it.
So, today, I'm trying a lower DeflateCompressionLevel. I'm using 4 now
(instead of the default 6). This seems better, though the load is still a
little higher than it should be and I'm not quote at prime time
yet. Still, I am getting decent compression. I'm going to keep an eye on
it, I suspect I'll be at 3 later this evening.
I never had any trouble with load when I used mod_gzip and Apache 1.3.
The other odd problem I got was that if anywhere in my perl code I printed
nothing (e.g. print or $foo=;print $foo), I'd get this error:
error: 20014:Error string not specified yet at /my/perl/code.pl line 123
This error was both blurted to the error_log and to the web page (screwing
up the page and truncating further output).
I changed my code to print instead of (HTML ignores extra
white-space, so no biggie), and the errors all went away. So, I see this
as an annoyance more than a serious bug.
I really should try to tell the author of mod_deflate about these problems.
Here's the config I'm using for mod_deflate:
#
## Deflate
#
LoadModule deflate_module modules/mod_deflate.so
AddOutputFilterByType DEFLATE text/*
SetOutputFilter DEFLATE
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
DeflateBufferSize 8096
# DeflateCompressionLevel 6
DeflateCompressionLevel 4
DeflateMemLevel 9
DeflateWindowSize 15
DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
LogFormat '%r %{outstream}n/%{instream}n (%{ratio}n%%) %{User-agent}i'
defl\
ate
CustomLog /var/log/httpd/deflate_log deflate
All of which I cribbed from the Apache 2.0 manual:
http://httpd.apache.org/docs-2.0/mod/mod_deflate.html
I sort of got forced into upgrading to Apache 2.0/mp2/etc. by RedHat. They
announced they would pull support for old releases (all that used Apache
1.3) by the end of the year. Apparently, this may be an intentional
(evil?) business move by them to motivate more customers to move to their
Enterprise OS (which is very expensive, but has more stable software like
good
Re: Best compression for mod_perl application?
The other odd problem I got was that if anywhere in my perl code I printed nothing (e.g. print or $foo=;print $foo), I'd get this error: error: 20014:Error string not specified yet at /my/perl/code.pl line 123 This error was both blurted to the error_log and to the web page (screwing up the page and truncating further output). I changed my code to print instead of (HTML ignores extra white-space, so no biggie), and the errors all went away. So, I see this as an annoyance more than a serious bug. if you're using mod_perl for your perl script, it might be a mod_perl issue an not mod_deflate - try the same from a mod_cgi script and see if it has the same problem. if not, we probably need to dig around mod_perl core for a fix. --Geoff
Re: Best compression for mod_perl application?
Hi Bill,
Thank you very much for the story. It makes sense. Just a couple of
questions:
1. Are you using any Cascaded Stile Sheets and/of JavaScript libraries
linked to your main web pages?
2. If yes, how do you turn compression off for those files in case of
Netscape-4 originated request?
Thanks,
Slava
- Original Message -
From: Bill Marrs [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, July 01, 2003 2:33 PM
Subject: Re: Best compression for mod_perl application?
That would be of my real interest to know as many details of Bill's
experience with mod_deflate as he can provide.
Since I posted my first message, I've been snooping around the 'net to
find
more info on mod_gzip and mod_deflate. Here's what I came up with:
The general recommendation seems to be migration from mod_gzip to
mod_deflate when you switch to Apache 2.0. mod_gzip seems to have lost
most of its support going forward while mod_deflate is part of the Apache
source code and has active development.
There is a Apache 2.0 compatible version of mod_gzip, here:
http://www.gknw.de/development/apache/httpd-2.0/unix/modules/
When I tried it, it didn't work for me. It caused my site to spit out
blank pages and garbage. I had used my old Apache 1.3 mod_gzip config
with
it. I read that there's some odd timing issues where the Apache 2.0
version of mod_gzip branched a long time ago and thus doesn't have some of
the modern mod_gzip 1.3.x features. I didn't get config errors, though,
just blanks and garbage. So, I decided to back away slowly for mod_gzip
on
Apache 2.0. There is more discussion of it here:
http://freshmeat.net/projects/mod_gzip/?topic_id=90
There a good mod_gzip info page here, though little is said about a 2.0
version:
http://www.schroepl.net/projekte/mod_gzip/index.htm
The mod_gzip mailing list has some good info. Here's a 26 Jun 2003 post
by
someone who seems to know well what's going on (I think the author of the
above page):
Subject: [Mod_gzip] gzip vs deflate on Apache
http://lists.over.net/pipermail/mod_gzip/2003-June/007130.html
So, I decided to try harder to move ahead with mod_deflate. I'm using a
built from scratch, Apache/2.0.46 mod_perl_1.99_09. Work is being done on
mod_deflate, some recent directives has been added (I hear). One of which
is DeflateCompressionLevel. Along with this addition in 2.0.44 came a
better default for this compression level. It's now 6, the same thing
that
gzip and zlib uses by default. Apparently, it had been 1 before that,
which is fast but doesn't compress very well. There's some discussion of
this here:
http://www.webcompression.org/deflate-compress.html
My own personal experience with mod_deflate (in Apache/2.0.46) is that it
tends to spike my server's load. My server (gametz.com) is dual 800Mhz,
1.5GB ram, Linux, doing about 70K pages/day. Last night, I happened to be
watching it while the load jumped up a few points during my site's prime
time, so I pulled mod_deflate out of the config file and that fixed it.
So, today, I'm trying a lower DeflateCompressionLevel. I'm using 4 now
(instead of the default 6). This seems better, though the load is still a
little higher than it should be and I'm not quote at prime time
yet. Still, I am getting decent compression. I'm going to keep an eye on
it, I suspect I'll be at 3 later this evening.
I never had any trouble with load when I used mod_gzip and Apache 1.3.
The other odd problem I got was that if anywhere in my perl code I printed
nothing (e.g. print or $foo=;print $foo), I'd get this error:
error: 20014:Error string not specified yet at /my/perl/code.pl line 123
This error was both blurted to the error_log and to the web page (screwing
up the page and truncating further output).
I changed my code to print instead of (HTML ignores extra
white-space, so no biggie), and the errors all went away. So, I see this
as an annoyance more than a serious bug.
I really should try to tell the author of mod_deflate about these
problems.
Here's the config I'm using for mod_deflate:
#
## Deflate
#
LoadModule deflate_module modules/mod_deflate.so
AddOutputFilterByType DEFLATE text/*
SetOutputFilter DEFLATE
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
DeflateBufferSize 8096
# DeflateCompressionLevel 6
DeflateCompressionLevel 4
DeflateMemLevel 9
DeflateWindowSize 15
DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
LogFormat '%r %{outstream}n/%{instream}n (%{ratio}n%%) %{User-agent}i'
defl\
ate
CustomLog /var/log/httpd/deflate_log deflate
All of which I cribbed from the Apache 2.0 manual:
http://httpd.apache.org/docs-2.0/mod/mod_deflate.html
I sort of got forced into upgrading to Apache 2.0/mp2/etc. by RedHat.
They
announced they would pull support for old releases (all that used Apache
1.3) by the end
Re: Best compression for mod_perl application?
1. Are you using any Cascaded Stile Sheets and/of JavaScript libraries linked to your main web pages? I'm not, but... I think mod_defalte's hook is after all that is processed, so it's not especially relevant. 2. If yes, how do you turn compression off for those files in case of Netscape-4 originated request? http://httpd.apache.org/docs-2.0/mod/mod_deflate.html says to use this sort of thing: # Netscape 4.x has some problems... BrowserMatch ^Mozilla/4 gzip-only-text/html # Netscape 4.06-4.08 have some more problems BrowserMatch ^Mozilla/4\.0[678] no-gzip # MSIE masquerades as Netscape, but it is fine BrowserMatch \bMSIE !no-gzip !gzip-only-text/html # Don't compress images SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary # Make sure proxies don't deliver the wrong content Header append Vary User-Agent env=!dont-vary
Re: Best compression for mod_perl application?
It's amazing! The flow control system is definitely sufficient. Ian Holsman really developed a very good module. The rest is up to accomplishing filters those supposed to be simple and specific. Those minor bug with optional empty chunk in the middle of the body should be easy to fix. Thanks, Slava - Original Message - From: Bill Marrs [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 3:33 PM Subject: Re: Best compression for mod_perl application? 1. Are you using any Cascaded Stile Sheets and/of JavaScript libraries linked to your main web pages? I'm not, but... I think mod_defalte's hook is after all that is processed, so it's not especially relevant. 2. If yes, how do you turn compression off for those files in case of Netscape-4 originated request? http://httpd.apache.org/docs-2.0/mod/mod_deflate.html says to use this sort of thing: # Netscape 4.x has some problems... BrowserMatch ^Mozilla/4 gzip-only-text/html # Netscape 4.06-4.08 have some more problems BrowserMatch ^Mozilla/4\.0[678] no-gzip # MSIE masquerades as Netscape, but it is fine BrowserMatch \bMSIE !no-gzip !gzip-only-text/html # Don't compress images SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary # Make sure proxies don't deliver the wrong content Header append Vary User-Agent env=!dont-vary
[RFC] web-messaging application for mod_perl
Apache::WebMessaging I am about ready to release an intraserver web-messaging application for mod_perl. A brief description of the app follows; I'd like to hear some comments from the mod_perl/Perl/P5EE community on: * is there anything like this already out there? * namespace suggestions (if Apache::WebMessaging is undesirable) * where and how to integrate it into the p5ee project (e.g. P5EEx::Blue::Messaging::WebMessaging ?) * general comments, questions? This software was started as a way to deliver automatic server-generated messages to users of a commercial web application. It was running on our production webserver for a few years, so could be deemed commercial-quality (whatever that means.. good or bad?). It has since been completely rewritten into a form more suitable for general use in the open-source community. It has support for attachments and outbound e-mail forwarding (via smtp). It dynamically generates HTML using CGI.pm, using basic HTML v3 forms for user interaction. It is entirely modular and component-oriented, so can easily be private-labelled or embedded in another application. The design is fairly similar to MVC architecture. It stores messages in a DBMS using DBI, and attachments on a filesystem with a reference in the database table. It has an object-oriented Perl API so message delivery can be triggered from either inside a running mod_perl server or from a standalone app (e.g. another daemon or a cron job). User-to-user messaging is supported through the standard web interface. My motives for releasing it open source are: * to advocate mod_perl * to attract developers to help improve the software, especially by adding extensions (e.g. inbound SMTP, pgp, gpg, jabber, alternate backing stores, interfacing with standard mailbox types: mbox, Maildir, etc) If you want to play with it before I release it to CPAN, you can get a copy here: http://adiraj.org/sw/Apache-WebMessaging/Apache-WebMessaging-0.80pre1.tar.gz TIA for any comments, -Adi
Re: mod_perl And Redirection
$r-headers_in-unset(Content-length); $r-header_out(Location = $uri); $r-status(REDIRECT); $r-send_http_header; return REDIRECT; well, you shouldn't ever mess with $r-status - that messes up Apache's internal bookkeeping. and don't send headers on an error response, which is what REDIRECT is as far as Apache is concerned. so, you end up with $r-header_out(Location = $uri); return REDIRECT; HTH --Geoff
[DIGEST] mod_perl digest 2003/06/16
-- mod_perl digest June 16, 2003 - June 29, 2003 -- Recent happenings in the mod_perl world... Features o mod_perl status o module announcements o mod_perlers wanted o mailing list highlights o mp2 porting tips / documentation o links o problem reporting guidelines mod_perl status o mod_perl - stable: 1.27 (released June 1, 2002) [1] - development: 1.27_01-dev [2] o Apache - stable: 1.3.27 (released October 3, 2002) [3] - development: 1.3.28-dev [4] o mod_perl 2.0 - beta: 1.99_09 (released April 28, 2003) [5] - development: 1.99_10-dev [6] o Apache 2.0 - stable: 2.0.46 (released May 27, 2003) [7] - developement: 2.0.47-dev - new-territories: 2.1.xx o Perl - stable: 5.8.0 (released July 18, 2002) [8] - development: ...towards 5.9.0 has started [9] module announcements o Apache::Test 1.03 - Test framework for web applications [10] o Cache::Mmap 0.07 - Memory-mapped cache [11] o Gestinanna::POF 0.04 - Yet another persistent object framework [12] o Gestinanna::POF::Repository 0.01 - revision-controlled objects in an RDBMS backend [13] o libapreq 1.2 - Apache::Request and friends [14] o Template::Plugin::Apache::SessionManager 0.01 - Session manager plugin for Template Toolkit [15] mod_perlers wanted o Dallas, TX (USA) - short term contract work [16] mailing list highlights o Status of modules ported to mod_perl 2.0 [17] o How to financially support mod_perl (somewhat inadvertant direction of the thread) [18] mp2 porting tips / documentation o Warning users about mod_perl 1.x or 2.x dependency when installing a module [19] o Status of modules ported to mod_perl 2.0 [20] o perl.apache.org documents [21] o Apache::compat [22] links o The Apache/Perl Integration Project [23] o mod_perl documentation [24] o Apache modules on CPAN [25] o _Writing Apache Modules with Perl and C_ homepage [26] o _mod_perl Developer's Cookbook_ homepage [27] o Other mod_perl-related books [28] o mod_perl news and advocacy [29] o mod_perl list archives - modperl@ [30] - dev@ [31] - docs-dev@ [32] - advocacy@ [33] problem reporting guidelines Whenever you have a problem that you want to ask about on the modperl list, please be sure to read the instructions on how to report problems: For mod_perl 1.0 [34] For mod_perl 2.0 [35] For your convenience, these are located in the shortcuts menu on all pages at http://perl.apache.org/. You will save yourself and us a lot of time by following the instructions on these pages. Thank you! happy mod_perling... --James [EMAIL PROTECTED] -- [1] http://perl.apache.org/dist/ [2] http://cvs.apache.org/snapshots/modperl/ [3] http://www.apache.org/dist/httpd/ [4] http://cvs.apache.org/snapshots/apache-1.3/ [5] http://perl.apache.org/dist/mod_perl-1.99_04.tar.gz [6] http://cvs.apache.org/snapshots/modperl-2.0/ [7] http://www.apache.org/dist/httpd/ [8] http://www.cpan.org/src/stable.tar.gz [9] http://www.cpan.org/src/README.html [10] http://mathforum.org/epigone/modperl/fahjilwhai [11] http://mathforum.org/epigone/modperl/steestrongfrand [12] http://mathforum.org/epigone/modperl/skaldshexserm [13] http://mathforum.org/epigone/modperl/brerstruland [14] http://mathforum.org/epigone/modperl/crysardwen [15] http://mathforum.org/epigone/modperl/dronkhalken [16] http://mathforum.org/epigone/modperl/clarstanggler [17] http://mathforum.org/epigone/modperl/phamkhongkong [18] http://mathforum.org/epigone/modperl/swargrexzou [19] http://mathforum.org/epigone/modperl/dreldkrorplen [20] http://perl.apache.org/products/apache-modules.html#Porting_CPAN_modules_to_mod_perl_2_0_Status [21] http://perl.apache.org/docs/2.0/devel/porting/porting.html [22] http://perl.apache.org/docs/2.0/api/Apache/compat.html [23] http://perl.apache.org/ [24] http://perl.apache.org/docs/ [25] http://www.cpan.org/modules/by-module/Apache/ [26] http://www.modperl.com/ [27] http://www.modperlcookbook.org/ [28] http://perl.apache.org/docs/offsite/books.html [29] http://www.take23.org/ [30] http://perl.apache.org/maillist/modperl.html#Searchable_Archives [31] http://perl.apache.org/maillist/dev.html#Searchable_Archives [32] http://perl.apache.org/maillist/docs-dev.html#Searchable_Archives [33] http://perl.apache.org/maillist/advocacy.html#Searchable_Archives [34] http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems [35] http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems
Re: require'ing data files under mod_perl
On Sat, 2003-06-28 at 15:08, Peter B. Ensch wrote: Coding in plain CGI I've often require'd files containing data in perl data-structures. The script may write to the file (via Data::Dumper for example) allowing subsequent invokations of the script to have access to the revised data. It would be simpler and faster to use MLDBM::Sync for this. I was expecting this methodology to break under mod_perl thinking that the require would only happen once (the first time the script runs after server startup); however, it seems to be working the way it always did. Why is this? Am I missing something? Can't tell without seeing some code. Your require'd files with not be reloaded unless you are using Apache::Reload or Apache::StatINC to force them. - Perrin
require'ing data files under mod_perl
Coding in plain CGI I've often require'd files containing data in perl data-structures. The script may write to the file (via Data::Dumper for example) allowing subsequent invokations of the script to have access to the revised data. I was expecting this methodology to break under mod_perl thinking that the require would only happen once (the first time the script runs after server startup); however, it seems to be working the way it always did. Why is this? Am I missing something? Thanks, P -- ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~ Peter B. Ensch ([EMAIL PROTECTED]) Linux 2.4.20-4GB 12:00pm Up 6 days 18:33 ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~
Re: Perl 6 + mod_perl
LB == Leon Brocard [EMAIL PROTECTED] writes: LB However, that said, we already have mod_parrot: LB http://cvs.perl.org/cvsweb/mod_parrot/ Hmm, yes, and now that I've graduated, I should concentrate on making it compile against the current incarnation of parrot. LB I suggest concentrating on mod_perl2 instead for now ;-) Agreed, but that won't keep me from playing. -kevin
Re: mod_perl-1.99_09 for Redhat 9
On Wed, Jun 25, 2003 at 06:53:52PM -0400, Bill Marrs wrote:
I'm looking for a Redhat 9 compatible mod_perl-1.99_09 rpm.
If anyone has one or knows where I can get one, let me know.
For my RedHat 8.0 I've made a custom .spec file to build an RPM
directly from the CVS sources.
Get the 'modperl-2.0.spec' file attached to this mail, and launch the
following command (as root, or any other user if you have configured an
RPM build environnement for it):
# rpmbuild -bb modperl-2.0.spec
It should fetch the latest CVS source, and start the build process, then
package the files into:
/usr/src/redhat/RPMS/i386/mod_perl-2.0_cvs-1.99.10.i386.rpm
Now you can try to upgrade your mod_perl with:
# rpm -Uvh mod_perl-2.0_cvs-1.99.10.i386.rpm
At this point, it should tell you there is a problem with the following
missing dependencies:
perl(Apache::FunctionTable) is needed by mod_perl-2.0_cvs-1.99.10
perl(Apache::StructureTable) is needed by mod_perl-2.0_cvs-1.99.10
perl(Apache::TestConfigParse) is needed by mod_perl-2.0_cvs-1.99.10
perl(Apache::TestConfigPerl) is needed by mod_perl-2.0_cvs-1.99.10
You can ignore them and force the upgrade with the --nodeps option:
# rpm -Uvh --nodeps mod_perl-2.0_cvs-1.99.10.i386.rpm
(In fact, the RedHat SRPMS use a 'filter-requires.sh' shell script that
remove these dependencies from the require list)
Note that I skip the 'make test' phase.
Regards,
Jérôme
--
Name: mod_perl
Version: 2.0_cvs
Release: 1.99.10
Group: System Environment/Daemons
License: GPL
Summary: An embedded Perl interpreter for the Apache Web server.
Source: http://perl.apache.org/dist/mod_perl-%{version}.tar.gz
URL: http://perl.apache.org/
BuildRoot: %{_tmppath}/%{name}-root
Requires: httpd = 2.0.40, perl = 5.8.0
BuildPrereq: httpd-devel = 2.0.40, perl
Prereq: perl
%description
Mod_perl incorporates a Perl interpreter into the Apache web server,
so that the Apache web server can directly execute Perl code.
Mod_perl links the Perl runtime library into the Apache web server and
provides an object-oriented Perl interface for Apache's C language
API. The end result is a quicker CGI script turnaround process, since
no external Perl interpreter has to be started.
Install mod_perl if you're installing the Apache web server and you'd
like for it to directly incorporate a Perl interpreter.
%prep
rm -Rf $RPM_BUILD_DIR/mod_perl-2.0_cvs
cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic co modperl-2.0
mv modperl-2.0 mod_perl-2.0_cvs
%build
cd mod_perl-%{version}
# Compile the module.
perl Makefile.PL \
PREFIX=$RPM_BUILD_ROOT/usr \
INSTALLDIRS=vendor \
MP_APXS=%{_sbindir}/apxs \
MODPERL_AP_INCLUDEDIR=$RPM_BUILD_ROOT/usr/include/httpd \
MODPERL_AP_LIBEXECDIR=$RPM_BUILD_ROOT%{_libdir}/httpd/modules
make
# Run the test suite.
# Need to make t/htdocs/perlio because it isn't expecting to be run as
# root and will fail tests that try and write files because the server
# will have changed it's uid.
#mkdir t/htdocs/perlio
#chmod 777 t/htdocs/perlio
#make test
%install
[ $RPM_BUILD_ROOT != / ] rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT%{_libdir}/httpd/modules
cd mod_perl-%{version}
make install MODPERL_AP_LIBEXECDIR=$RPM_BUILD_ROOT%{_libdir}/httpd/modules
MODPERL_AP_INCLUDEDIR=$RPM_BUILD_ROOT/usr/include/httpd
# Remove the temporary files.
find $RPM_BUILD_ROOT%{_libdir}/perl?/vendor_perl/*/*/auto -name *.bs | xargs rm
%clean
[ $RPM_BUILD_ROOT != / ] rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root)
%doc Changes INSTALL LICENSE README docs
/usr/bin/*
/usr/include/httpd/*
%{_libdir}/httpd/modules/mod_perl.so
%{_libdir}/perl?/vendor_perl/*/*/auto/*
%{_libdir}/perl?/vendor_perl/*/*/Apache
%{_libdir}/perl?/vendor_perl/*/*/Bundle/*
%{_libdir}/perl?/vendor_perl/*/*/APR
%{_libdir}/perl?/vendor_perl/*/*/ModPerl
%{_libdir}/perl?/vendor_perl/*/*/*.pm
/usr/man/man3/*.3*
%changelog
* Wed Jun 25 2003 Jérôme Augé [EMAIL PROTECTED] 1.99-CVS
- build mod_perl-2.0 RPM from the CVS sources
(based on RedHat SPEC file)
mod_perl And Redirection
Hello there, My apologies if you already have received this email, but I keep getting a message that the mail was not sent. We have just upgraded to : Apache/1.3.27 Ben-SSL/1.48 (Unix) PHP/4.2.3 mod_perl/1.27 configured Running perl 5.6.1. I am getting 302 error message on my redirects. This comes as a complete surprise since the same piece of code works just fine on: Apache/1.3.14 Ben-SSL/1.42 (Unix) PHP/4.0.3pl1 mod_perl/1.24_01 configured Here is my code: $r-headers_in-unset(Content-length); $r-header_out(Location = $uri); $r-status(REDIRECT); $r-send_http_header; return REDIRECT; I am not sure where to begin debugging. I first wanted to check w/ you guys to see if there are any quick fixes. I appreciate any feed back. -r
mod_perl-1.99_09 for Redhat 9
I'm looking for a Redhat 9 compatible mod_perl-1.99_09 rpm. If anyone has one or knows where I can get one, let me know. Thanks, -bill p.s. I did find a Rawhide (bleeding edge Red Hat release, I think) mod_perl-1.99_09, but it doesn't seem to be compatible (I got an error from Apache).
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
A::Registry vs. mod_perl handler philosophy
I'm beginning to develop apps under mod_perl. I'm curious as to how people decide between coding for Apache::Registry vs. mod_perl handlers. It's been suggested to me that content generating apps should be done under A::R, whereas logging, authentication Etc. should be implemented as mod_perl handlers. What is the opinion of the group? Regards, P -- ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^ Peter Ensch, [EMAIL PROTECTED] A-1140 (214) 480 2333 ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Re: A::Registry vs. mod_perl handler philosophy
Hi there, On Fri, 20 Jun 2003, Peter B. Ensch wrote: I'm beginning to develop apps under mod_perl. I'm curious as to how people decide between coding for Apache::Registry vs. mod_perl handlers. Use Apache::Registry only if you have to in order to get legacy CGI scripts working. It's been suggested to me that content generating apps should be done under A::R, whereas logging, authentication Etc. should be implemented as mod_perl handlers. All new code should use handlers. 73, Ged.
Re: A::Registry vs. mod_perl handler philosophy
On Fri, 20 Jun 2003, Ged Haywood wrote: Date: Fri, 20 Jun 2003 17:25:23 +0100 (BST) From: Ged Haywood [EMAIL PROTECTED] To: Peter B. Ensch [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: A::Registry vs. mod_perl handler philosophy Hi there, On Fri, 20 Jun 2003, Peter B. Ensch wrote: I'm beginning to develop apps under mod_perl. I'm curious as to how people decide between coding for Apache::Registry vs. mod_perl handlers. Use Apache::Registry only if you have to in order to get legacy CGI scripts working. It's been suggested to me that content generating apps should be done under A::R, whereas logging, authentication Etc. should be implemented as mod_perl handlers. All new code should use handlers. 73, Ged. I wouldn't be so strict about such definitions. If you're only looking to generate content, then I don't see a problem with writing standard CGI scripts and running them under A::R. If you stick with strict and warnings and follow the gotchas listed in The Guide[1], you should be fine. If you also choose to code carefully, you can use the same script under mod_perl or not without changing anything (if that's important to you). Or am I missing something? At CSHL, all our Apache servers are compiled with mod_perl, but Lincoln still has us write most everything as CGI scripts. It's easy and works just fine for us. Also saves having to add Location directives to httpd.conf everytime you want to add a new script. Whatever works for you, I say. But mayhap I'm too permissive. ky [1]-http://perl.apache.org/guide
