Re: modules and pragmas - part II
On Wed, Sep 25, 2002 at 12:29:12AM -0400, Perrin Harkins wrote: Are you setting $CGI::XHTML to 0 somewhere? No I posted the whole script: #!/usr/bin/perl -w use CGI qw(standard -no_xhtml); my $q=new CGI; print $q-header,$q-start_html,\n; print $$,\n; thnx, peter -- mag. peter pilsl IT-Consulting tel: +43-699-1-3574035 fax: +43-699-4-3574035 [EMAIL PROTECTED]
Re: Documentation for Apache::exit()?
On Tue, Sep 24, 2002 at 08:03:56PM -0700, Kyle Oppenheim wrote: There are a few performance penalties when using Apache::Registry: * Scripts are compiled at first request instead of server start unless you use something like Apache::RegistryLoader. So, the first request per child will be a little bit slower and you don't get to share memory between httpd children. (Memory sharing can be a big problem.) But it still shares all the modules you pre-load in the http.conf, right? So how much memory is wasted depends on the size of the script in question, or more accurately on how big its data structures are? (including imported variables) BTW, anyone know if Perl 6 will free unused memory? From what I understand, right now it just allocates as needed, but never gives any back to the OS when it's done... (ie, when some function ends)
Re: $r-content
MC Presently I get all the incoming parameters via Apache::Request and
MC append to the URL before redirecting but this is not ideal as I?d like
MC to spit the modified parameters out in a POST. Can anyone give me any
MC advice?
GY see
GY http://perl.apache.org/docs/1.0/guide/snippets.html#Redirecting_POST_Requests
I thought I recalled a $STDIN var in mod_perl, but didn't find anything with a quick
scan of the docs. If that var ~is~ available, and writable, and are doing an internal
redirect, you might be able to just reload it:
$STDIN = $r-content;
$r-internal_redirect_handler($handler);
I know I've done this sort of thing (redirecting POSTs) with a session system. That
is, a handler early in the request that sets up POST data, then everything else uses
only that source:
# My::STDINHandler
use Storable;
sub handler {
store({content = $r-content}, $unique_file_location);
}
sub content {
return retrieve($unique_file_location)-{content}
if $some_good_tests;
return Apache-request-content;
}
# My script
$content = My::STDINHandler::content();
I apologize for any inconsistencies in this message, I'm a bit tired and the coffee
isn't strong enough today.
---
Rodney Broom
President, R.Broom Consulting
http://www.rbroom.com/
Re: $r-content
Rodney Broom wrote: MC Presently I get all the incoming parameters via Apache::Request and MC append to the URL before redirecting but this is not ideal as I?d like MC to spit the modified parameters out in a POST. Can anyone give me any MC advice? GY see GY http://perl.apache.org/docs/1.0/guide/snippets.html#Redirecting_POS- T_Requests I thought I recalled a $STDIN var in mod_perl, but didn't find anything with a quick scan of the docs. If that var ~is~ available, and writable, and are doing an internal redirect, you might be able to just reload it: $STDIN = $r-content; $r-internal_redirect_handler($handler); I know I've done this sort of thing (redirecting POSTs) with a session system. That is, a handler early in the request that sets up POST data, then everything else uses only that source: I didn't think that was what he was asking about. getting the POST data from the main request in a subrequest is generally easy with Apache::Request: my $r = shift; $r = Apache::Request-instance( $r-is_main ? $r : $r-main ); or somesuch. if you want to manipulate the data from one subrequest to another I suspect something like $r-param-set(foo = bar) would work with the above is_main() syntax, but I haven't tested it (I'm tired too :) so perhaps turning the request into a GET is easier. --Geoff
installation bug with Apache v2.0.42
I found a minor installation bug in both modperl v1.99-5. (The same bug also seems to be in the latest modperl-2.0 CVS tree.) The bug occurs when you try to install modperl 2 with the latest version of Apache (2.0.42). For whatever reason, the Apache folks changed the format of the macros in include/ap_release.h between 2.0.40 and 2.0.42. AP_SERVER_BASEREVISION is now: #define AP_SERVER_BASEREVISION AP_SERVER_MINORREVISION . AP_SERVER_PATCHLEVEL instead of simply: #define AP_SERVER_BASEREVISION 2.0.42 This breaks the httpd_version method in Apache/Build.pm. I got around it by simply changing the AP_SERVER_BASEREVISION in include/ap_release.h to the latter format. The correct solution depends on how stable the macro format will be for future versions of Apache. If it's going to stay the way it is, httpd_version needs to be modified to search for other macros as an alternative method for computing the version. -Eugene -- +=== Eugene Eric Kim = [EMAIL PROTECTED] = http://www.eekim.com/ ===+ | Writer's block is a fancy term made up by whiners so they| += can have an excuse to drink alcohol. --Steve Martin ===+
Re: $r-content
From: Geoffrey Young [EMAIL PROTECTED] GY I didn't think that was what he was asking about. getting the POST GY data from the main request in a subrequest is generally easy with GY Apache::Request: Oops, you're right. I was thinking that Mark (jump in any time) needed to keep things in POST to satisfy some upcoming code. Some things insist on POST only. Worse, some things need POST data and use r-args for other purposes all together. I guess the example I was thinking of in my head is where I have to do something like redirecting the user to a login page when their authentication runs out, then still honor their original request (including POST data) without them having to intervene. --- Rodney Broom President, R.Broom Consulting http://www.rbroom.com/
Re: installation bug with Apache v2.0.42
Em Wed, Sep 25, 2002 at 10:40:53AM -0700, Eugene Eric Kim escreveu:
format of the macros in include/ap_release.h between 2.0.40 and 2.0.42.
AP_SERVER_BASEREVISION is now:
#define AP_SERVER_BASEREVISION AP_SERVER_MINORREVISION . AP_SERVER_PATCHLEVEL
instead of simply:
#define AP_SERVER_BASEREVISION 2.0.42
This breaks the httpd_version method in Apache/Build.pm.
Try this patch, is what I'm using here:
--- mod_perl-1.99_05/lib/Apache/Build.pm.orig 2002-09-19 18:44:56.0 -0300
+++ mod_perl-1.99_05/lib/Apache/Build.pm2002-09-19 18:46:32.0 -0300
-740,14 +740,17
return undef;
};
-my $version;
+my ($version,$maj,$min,$pat);
while($fh) {
-next unless /^\#define\s+AP_SERVER_BASEREVISION\s+\(.*)\/;
-$version = $1;
-last;
+$maj = $1 if /^#define\s+AP_SERVER_MAJORVERSION\s+\(.*)\/;
+$min = $1 if /^#define\s+AP_SERVER_MINORVERSION\s+\(.*)\/;
+$pat = $1 if /^#define\s+AP_SERVER_PATCHLEVEL\s+\(.*)\/;
+$maj $min $pat last;
}
+$version = $maj.$min.$pat;
+
close $fh;
$self-httpd_version_cache($dir, $version);
$r-content
Title: $r-content Im trying to read some posted data, modify it and then redirect request inc the modified data. Something like; my $r = Apache::Request-new(Apache-request); my %form = $r-content; #modify %form $r-content(%form); $r-internal_redirect_handler($some_page); Thats the ideal but from some tests Ive done it would seem that content() takes no args and so cannot be used in this way. Presently I get all the incoming parameters via Apache::Request and append to the URL before redirecting but this is not ideal as Id like to spit the modified parameters out in a POST. Can anyone give me any advice? Thanks.
Re: $r-content
Presently I get all the incoming parameters via Apache::Request and append to the URL before redirecting but this is not ideal as I?d like to spit the modified parameters out in a POST. Can anyone give me any advice? see http://perl.apache.org/docs/1.0/guide/snippets.html#Redirecting_POST_Requests for an example that may help. HTH --Geoff
RE: Documentation for Apache::exit()?
There are a few performance penalties when using Apache::Registry: * Scripts are compiled at first request instead of server start unless you use something like Apache::RegistryLoader. So, the first request per child will be a little bit slower and you don't get to share memory between httpd children. (Memory sharing can be a big problem.) But it still shares all the modules you pre-load in the http.conf, right? So how much memory is wasted depends on the size of the script in question, or more accurately on how big its data structures are? (including imported variables) Correct -- if you preload modules in httpd.conf, you will most likely use shared memory for those modules. Of course, the memory page will be copied to the child process if it is modified after forking. This could happen because the module allocates some memory, something else that shares the memory page is modified, etc. However, with Apache::Registry scripts, you are loading code in the child process directly (with the exception of using Apache::RegistryLoader) -- so there's no chance for any memory sharing. - Kyle
RedHat RPM for apache+mod_perl?
Has anyone here come up with an RPM for apache+mod_perl, with the following caveats: 1. mod_perl is statically compiled 2. I don't want SSL. This will be backend server. Only the frontend needs SSL. 3. can co-exist with a non-mod_perl Apache on the same system, meaning that it has its own config dir, pid file, logs, etc. 4. Including mod_rpaf would be a nice bonus, but adding this probably wouldn't be too hard. In other words, is there anything like the excellent apache-perl Debian package, but for Red Hat. ARGH, I really hate Red Hat. But in this case I'm stuck with it. I've been working on this myself for a few hours but I realized I should ask about it here first. -dave /*== www.urth.org we await the New Sun ==*/
ANNOUNCE: Bricolage 1.4.1
The Bricolage team would like to announce the release of Bricolage 1.4.1. This is a maintenance release with many bug fixes. All users of earlier versions of Bricolage are strongly encouraged to upgrade. Bricolage is a full-featured, enterprise-class content management and publishing system. It offers a browser-based interface for ease-of use, a full-fledged templating system with complete programming language support for flexibility, and many other features (see below). It operates in an Apache/mod_perl environment, and uses the PostgreSQL RDBMS for its repository. For a complete list of the changes, See Bric::Changes at http://bricolage.cc/docs/Bric/Changes.html. Learn more about Bricolage and download it from the Bricolage home page, http://bricolage.cc/. Enjoy! --The Bricolage Team
Help with install
Hi I am totally new to modperl, in fact i have not even installed it yet. i want to install Mod perl 2.0 with Apache 2.0.42. I am not sure i understand the perl preReqs in the install docs. I have perl 5.6.1 without thread support. Am I good to go or do I need to build perl again. Also is what is mpm and is 'mpm=prefork' necessary in the apache build config? Any other tips from anyone with a similar setup is appreciated. Thank You. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.391 / Virus Database: 222 - Release Date: 9/19/2002
RE: mod perl and apache with ssl and openssl
Can anyone advise me on how to build apache server with ssl and openssl and using mod perl. It's right there in the user's guide. http://perl.apache.org/docs/1.0/guide/install.html#mod_perl_and_mod_ssl___op enssl_ -Fran
Passing data from ConnectionHandler to a ProtocolHandler ..
Hi, I need to modify the request object before it is handed over to a protocol handler. I'm using 2.0, so suppose I implement a Connection Handler, within which i read from the socket directly .. modify the data read, now how do I pass on this modified data to the Protocol Handler ? Tx
Re: mod perl and apache with ssl and openssl
On Tue, 24 Sep 2002, Allan P. Magmanlac wrote: Hello, Can anyone advise me on how to build apache server with ssl and openssl and using mod perl. this is how I do it WITHOUT mod perl support cd to modssl soure directory and then run the following command ./configure \ --with-apache=../apache_1.3.26 \ --with-ssl=../openssl-0.9.6g \ --prefix=/usr/local/root/httpd_1.3.26 \ --with-crt=/usr/local/root/httpd/usr/local/www/conf/ssl.crt/server.crt \ --with-key=/usr/local/root/httpd/usr/local/www/conf/ssl.key/server.key \ --enable-module=proxy So how would I do it WITH mod perl support. (exact commands would be appreciated) Thanks Sure, here's my receipe. Works every time make sure open-ssl is built and installed then in apache-xxx/ untar and run the Fixpatch script for the appropriate version of appache-ssl rm apache/src/Configuration rm /usr/src/apache/src/Configuration.apaci edit /usr/src/apache/src/Configuration.tmpl and modules, i.e. activate mod_info.o, mod_rewrite.o, mod_so.o libproxy.a or whatever you plan to use then in mod perl source directory Run: perl Makefile.PL \ APACHE_SRC=/usr/src/apache/src \ DO_HTTPD=1 \ USE_APACI=1 \ PREP_HTTPD=1 \ EVERYTHING=1 \ in apache directory ./configure --with-layout=Apache \ --activate-module=src/modules/perl/libperl.a make make install Michael
Re: RedHat RPM for apache+mod_perl?
On Wed, 2002-09-25 at 18:11, Dave Rolsky wrote: Has anyone here come up with an RPM for apache+mod_perl, with the following caveats: I use Apache ToolBox to get all these items and have been very pleased with. It allows you the option of creating a RPM as well, so if that part works for you (mine didn't) you would have something you could take from machine to machine. The process allows for you to modify the install path so it will play nice with other versions of Apache on the same machine. You can configure evey part and it even prompts you to edit the configuration files during the process. I have tested this on: Custom Linux, the OS was assembiled from various GNU parts Installed Apache/mod_perl/php/mod_ssl Mandrake 8.2 Linux Installed Apache/mod_perl/php/mod_ssl/mod_layout Red Hat 7.? Installed Apache/mod_perl/php/mod_ssl/mod_layout I have only tested the recently RPM support one time under Mandrake so I am not sure how well it might work on other platforms. Even if the RPM portion doesn't work the Toolbox takes away most of the grunt work. http://www.apachetoolbox.com 1. mod_perl is statically compiled 2. I don't want SSL. This will be backend server. Only the frontend needs SSL. 3. can co-exist with a non-mod_perl Apache on the same system, meaning that it has its own config dir, pid file, logs, etc. 4. Including mod_rpaf would be a nice bonus, but adding this probably wouldn't be too hard. In other words, is there anything like the excellent apache-perl Debian package, but for Red Hat. ARGH, I really hate Red Hat. But in this case I'm stuck with it. I've been working on this myself for a few hours but I realized I should ask about it here first. -dave /*== www.urth.org we await the New Sun ==*/
