Re: pre-spawning database connections[newbie]
Sven Geisler wrote: Hi Ben, Do you use Apache::DBI? I mean yes because you're using connect_on_init. Apache::DBI do not really close your DBI connection. You will get the same connection with the same connection parameters, when you call DBI-connect. All connections are cached by Apache::DBI. Yes, you should call DBI-connect. Each sub process will get it's own connections. What Sven said, plus it helps to RTFM before asking the list. Please read: http://perl.apache.org/docs/1.0/guide/databases.html#Apache__DBI___Initiate_a_persistent_database_connection Am Mon, 2003-01-13 um 13.08 schrieb Ben Wrigley: Hi All, I'm a mod_perl newbie and just trying to understand a little more about the startup.pl files and prespawning databases. I am using the connect_on_init routine in the startup.pl which is fine. What I'm not sure is then how to use this most economically in my scripts. It seems that in the scripts you should call the DBI-connect again, but that seems to be bypassing the connection I made at startup or am I misunderstanding completely. Thanks for your help Ben -- __ 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: Load balancers
John Siracusa wrote: (This may seem off topic for this list, but I'll try to bring it around before the end of the message :) We've been struggling with load balancers for a while now. It seems that most experts hang at [EMAIL PROTECTED] It's also preferrable that the hw solutions will be discussed there. [...] This brings me to the mod_perl angle. Has anyone ever tried using a slimmed down mod_perl server as a load balancer? Is this feasible? Making routing decisions is obviously the easy part when using mod_perl, but would those mod_perl apache process just be too big and too slow to proxy requests efficiently? And how would they deal with detecting back-end servers that have failed? As someone has mentioned, squid is doing that (See the guide). The good thing is that it spawns the process and never quits it, so you don't have an overhead of perl startup for each request. Indeed it'll use a lot of memory. But may be toying with mod_perl 2.0 / threaded mpm will prove to be more memory efficient. Also PPerl comes to a mind. __ 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: Writing to stdin of subprocess under modperl 1.0 fails :/
Antti Haapala wrote: Hello all, I'm having trouble with following script under mod_perl 1.26 (perl 5.6.1). use strict (); use IO::Handle (); use IPC::Open2 (); [...] Use IPC::Run instead of the IPC::Open* family, it surely works and a much more flexible tool! Probably need to add an item to the guide's troubleshooting. __ 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: 1.3.27 DSO hassles
Sinclair, Alan (CORP, GEAccess) wrote: All, Having been successfully using modperl for the last 2 years statically linked with Apache, I have been trying again to make modperl work with 1.3.27 when the Apache core modules are loaded as DSOs. There has been some traffic in the past on this subject and I checked the archives and followed through on some of the suggestions - Recompiled perl 5.6 with the --Ubincompat5005 option for specific use with modperl - Setup modperl using the perl compiled with --Ubincompat5005 - I use the following configure options for the APACI for Apache 1.3.27 ./configure --prefix=/opt/apache-so \ --enable-rule=SHARED_CORE \ --enable-module=most \ --enable-shared=max \ --activate-module=src/modules/perl/libperl.a \ --disable-shared=perl Apache is compiled and statically links modperl without any problems (Solaris 2.6). When Apache is executed, I receive this error: fatal: relocation error: file /opt/apache-so/libexec/mod_negotiation.so: symbol __floatdisf: referenced symbol not found I have tried the recommendations, specifically the issue with perl's malloc on Solaris which can be corrected with the --Ubincompat5005 option. There were some suggestions offered in this thread (large files CFLAGS?) http://marc.theaimsgroup.com/?t=10168427183r=1w=2 Though I didn't see a success report. If somebody on Solaris 2.6 were able to get it to work, please chime in. __ 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 2.0 and print/send_http_header method SEGFAULT
Jérôme Augé wrote:
Hi,
I'm beginning with mod_perl (mod_perl-1.99_05 + Apache 2.0.40 from
RedHat 8.0) and I want to write a module for rewriting the documents
that passes through the Apache proxy. So, I looked at the
Apache::AdBlocker
(http://perl.apache.org/docs/tutorials/tips/mod_perl_tricks/mod_perl_tricks.html#A_Banner_Ad_Blocker)
module and I'm facing some problems for writing the content of the
documents back to the client.
My main problem is that I get a SEGFAULT when calling the $r-print()
or $r-send_http_header() method.
I get the request, copy the headers from headers_in, make my own
request with LWP, copy the headers to headers_out, then it SEGFAULT
when writing the document ... Are this methods deprecated/not fully
implemented ? what is the correct way to write data to the client ?
The other problem is that if I use the $r-push_handlers(PerlHandler =
\proxy_handler) mechanism, my proxy_handler() function is never
called, so I do the work directly into the handler sub, is this ok ?
I attached my test module below (I register it with a PerlTransHandler
Apache::Plop statement in httpd.conf)
After making your example work, I don't see any segfaults. Please try
again with modperl-1.99_08 which was released a few days ago.
I've attached Plop.pm that apparently works. Hope that this is what you
wanted to accomplish. I've used the following config:
Location /plop/
SetHandler perl-script
PerlHeaderParserHandler Apache::Plop
/Location
Now to your code:
1. You can't push_handlers when you are inside a response handler.
Use PerlHeaderParserHandler instead
2. $r-headers_in-do() expects a return value and will abort on 0; see
the attached code
also it should be:
$request-header( $_[0] = $_[1] );
instead of:
$request-header( {$_[0]} = $_[1] );
have you looked at error_log? You'd have seen that error reported.
3. This is not good:
my $request = HTTP::Request-new( $r-method, $r-uri);
since you don't the whole url. Use this instead:
my $request = HTTP::Request-new( $r-method, $r-construct_url);
this requires 'use Apache::URI'
4. Finally I've used a special header: (which can be anything)
$request-header( GetReal = 1 );
to know that now I'm inside the real request.
Hope that this helps.
Also you might want to use a sub-request rather than a heavy weighted LWP
to accomplish what you 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
package Apache::Plop;
use strict;
use Apache::RequestRec;
use Apache::RequestIO;
use Apache::RequestUtil;
use Apache::Const;
use Apache::ServerUtil;
use Apache::Response;
use Apache::URI;
use APR::Table;
use LWP::UserAgent;
my $ua = LWP::UserAgent-new();
sub handler {
my $r = shift;
if( $r-proxyreq ) {
return Apache::DECLINED;
}
print STDERR Good, this is a proxyreq ...\n;
$r-handler(perl-script); #ok, let's do it
$r-push_handlers(PerlResponseHandler = \proxy_handler);
return Apache::OK;
}
sub proxy_handler {
my $r = shift;
if( $r-method ne GET ) {
return Apache::DECLINED;
}
print STDERR Good, this is a GET method ...\n;
if ( ($r-headers_in-get('GetReal')||0) == 1) {
$r-content_type('text/plain');
print hey;
return Apache::OK;
}
# prepare the real request
my $request = HTTP::Request-new( $r-method, $r-construct_url);
# copy headers from client request
my %headers_in;
print STDERR -- client headers --\n;
$r-headers_in()-do(
sub {
warn $_[0]: $_[1]\n;
$headers_in{ $_[0] } = $_[1];
$request-header( $_[0] = $_[1] );
return 1;
}
);
print STDERR -- end --\n;
# make the real request myself
$ua-agent( $headers_in{ 'User-Agent' } );
$request-header( GetReal = 1 );
warn $request-as_string;
my $response = $ua-request( $request );
if ( ! $response-is_success() ) {
print STDERR == ERROR ==\n;
return Apache::DECLINED;
}
print STDERR -- server headers --\n;
my %headers_out;
$response-headers()-scan(
sub {
print STDERR $_[0]: $_[1]\n;
$headers_out{$_[0]} = $_[1];
}
);
print STDERR -- end --\n;
# simply override the content
my $content = $response-content;
$content = htmlbodyplop/body/html;
# adjust the headers for the new content
$headers_out{ 'Content-length' } = length( $content );
$headers_out{ 'Content-type' } = 'text/html';
# copy the modified response headers back to Apache
foreach (keys %headers_out) {
$r-headers_out-{$_} = $headers_out
Re: mod_perl 2.0 and print/send_http_header method SEGFAULT
Stas Bekman wrote: Jérôme Augé wrote: [...] After making your example work, I don't see any segfaults. Please try again with modperl-1.99_08 which was released a few days ago. [...] 1. You can't push_handlers when you are inside a response handler. Use PerlHeaderParserHandler instead I've played some more with your original code and did find the segfault you were talking about. Though it happens when you use push_handlers in the same phase to which you push to. Hence I didn't see it in the code that I've fixed. So most likely your _05 version will work just fine with the version that I've posted in my original reply. Meanwhile I'm looking at how it's the best to prevent from the segfault to happen and push_handlers() be used in a wrong place. __ 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: Configuring Apache witch Perl
Marek Turczyniak wrote:
Hi
I try adding name virtual host from LDAP. here is code:
...
foreach $entry ($mesg-all_entries) {
my %config;
$config{ 'servername' } = $entry-get_value('servername');
$config{ 'documentroot' } = $entry-get_value('documentroot');
push @mytab,\%config;
}
$VirtualHost{'www.nethosting.pl'} = \@mytab;
...
I have some problem while apachectl configtest:
package Apache::ReadConfig;
#hashes:
%VirtualHost = (
'www.nethosting.pl' = [
{
'servername' = '...',
'documentroot' = '...'
},
];
]
);
#arrays:
#scalars:
1;
__END__
Syntax OK
Insecure dependency in eval while running with -T switch.
Callback called exit.
What's wrong?
Something that has to do with the tainted variables in your code. You
can test and probably reproduce it outside mod_perl with just adding the
-T switch.
__
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 mod_jk
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
Hi,
I'm trying to use mod_perl (1.99-07) with mod_jk (1.2) and Apache
(2.0.43). (and cannot move to 1.99-08 immediately)
When I try starting apache with both mod_perl mod_jk enabled, I'm seeing
the following error :
$ sudo bin/apachectl start
Syntax error on line 8 of /opt/apache2/conf/mod_jk.conf:
Invalid command 'JkWorkersFile', perhaps mis-spelled or defined by a module
not included in the server configuration
Any ideas what might be happening ?..
You say that it's working fine with 1.99_08, but I don't think anything
significant has been changed in the configuration parsing between _07
and _08. Have you tried stepping through with gdb?
It should be pretty easy to do if you use this script:
http://perl.apache.org/docs/2.0/devel/debug/code/.debug-modperl-register
as discussed here:
http://perl.apache.org/docs/2.0/devel/debug/c.html#Precooked_gdb_Startup_Scripts
You want to break at ap_find_command_in_modules, where the directive is
searched for. It simply goes though the list of registered modules and
asks each module whether it knows this command:
for (modp = *mod; modp; modp = modp-next) {
if (modp-cmds (cmdp = ap_find_command(cmd_name, modp-cmds))) {
*mod = modp;
return cmdp;
}
}
If you see that mod_jk is not in that list, you have to go back earlier
and see why it failed to get mod_jk into the list. Somewhere around
ap_add_module.
p.s. I use ddd over gdb, which makes the debugging a much easier task.
__
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
HEAD requests in Apache 2.0
Here is something new in Apache 2.0 that's worth your attention. Apache 2.0 automatically discards the response body for HEAD requests, so there is no more need to add logic to handle HEAD request unless you want to save the processing cycles. This was done in order to ensure that the response headers for GET/POST/... and HEAD will be the same. Here is a quote from http_protocol.c:ap_http_header_filter /* [...] The idea is that * we don't want to send out 0 Content-Lengths if it is a head request. * This happens when modules try to outsmart the server, and return * if they see a HEAD request. Apache 1.3 handlers were supposed to * just return in that situation, and the core handled the HEAD. In * 2.0, if a handler returns, then the core sends an EOS bucket down * the filter stack, and the content-length filter computes a C-L of * zero and that gets put in the headers, and we end up sending a * zero C-L to the client. We can't just remove the C-L filter, * because well behaved 2.0 handlers will send their data down the stack, * and we will compute a real C-L for the head request. RBB */ __ 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
cvs commit: modperl-2.0/src/modules/perl modperl_filter.h mod_perl.c modperl_filter.c
stas2003/01/11 18:15:59
Modified:xs/tables/current/ModPerl FunctionTable.pm
src/modules/perl modperl_filter.h mod_perl.c
modperl_filter.c
Log:
improve the code readability by s/filter_register/filter_add/g because the
filters are actually inserted, not just registered
Revision ChangesPath
1.91 +4 -4 modperl-2.0/xs/tables/current/ModPerl/FunctionTable.pm
Index: FunctionTable.pm
===
RCS file: /home/cvs/modperl-2.0/xs/tables/current/ModPerl/FunctionTable.pm,v
retrieving revision 1.90
retrieving revision 1.91
diff -u -r1.90 -r1.91
--- FunctionTable.pm 11 Jan 2003 00:02:16 - 1.90
+++ FunctionTable.pm 12 Jan 2003 02:15:58 - 1.91
@@ -2322,7 +2322,7 @@
},
{
'return_type' = 'void',
-'name' = 'modperl_input_filter_register_connection',
+'name' = 'modperl_input_filter_add_connection',
'args' = [
{
'type' = 'conn_rec *',
@@ -2332,7 +2332,7 @@
},
{
'return_type' = 'void',
-'name' = 'modperl_input_filter_register_request',
+'name' = 'modperl_input_filter_add_request',
'args' = [
{
'type' = 'request_rec *',
@@ -3177,7 +3177,7 @@
},
{
'return_type' = 'void',
-'name' = 'modperl_output_filter_register_connection',
+'name' = 'modperl_output_filter_add_connection',
'args' = [
{
'type' = 'conn_rec *',
@@ -3187,7 +3187,7 @@
},
{
'return_type' = 'void',
-'name' = 'modperl_output_filter_register_request',
+'name' = 'modperl_output_filter_add_request',
'args' = [
{
'type' = 'request_rec *',
1.15 +4 -4 modperl-2.0/src/modules/perl/modperl_filter.h
Index: modperl_filter.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_filter.h,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- modperl_filter.h 30 May 2002 02:33:48 - 1.14
+++ modperl_filter.h 12 Jan 2003 02:15:58 - 1.15
@@ -37,9 +37,9 @@
apr_status_t modperl_output_filter_handler(ap_filter_t *f,
apr_bucket_brigade *bb);
-void modperl_output_filter_register_connection(conn_rec *c);
+void modperl_output_filter_add_connection(conn_rec *c);
-void modperl_output_filter_register_request(request_rec *r);
+void modperl_output_filter_add_request(request_rec *r);
MP_INLINE apr_status_t modperl_output_filter_flush(modperl_filter_t *filter);
@@ -61,8 +61,8 @@
apr_read_type_e block,
apr_off_t readbytes);
-void modperl_input_filter_register_connection(conn_rec *c);
+void modperl_input_filter_add_connection(conn_rec *c);
-void modperl_input_filter_register_request(request_rec *r);
+void modperl_input_filter_add_request(request_rec *r);
#endif /* MODPERL_FILTER_H */
1.146 +4 -4 modperl-2.0/src/modules/perl/mod_perl.c
Index: mod_perl.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.145
retrieving revision 1.146
diff -u -r1.145 -r1.146
--- mod_perl.c12 Dec 2002 10:05:07 - 1.145
+++ mod_perl.c12 Jan 2003 02:15:58 - 1.146
@@ -481,8 +481,8 @@
static int modperl_hook_pre_connection(conn_rec *c, void *csd)
{
-modperl_input_filter_register_connection(c);
-modperl_output_filter_register_connection(c);
+modperl_input_filter_add_connection(c);
+modperl_output_filter_add_connection(c);
return OK;
}
@@ -595,10 +595,10 @@
ap_hook_handler(modperl_response_handler_cgi,
NULL, NULL, APR_HOOK_MIDDLE);
-ap_hook_insert_filter(modperl_output_filter_register_request,
+ap_hook_insert_filter(modperl_output_filter_add_request,
NULL, NULL, APR_HOOK_LAST);
-ap_hook_insert_filter(modperl_input_filter_register_request,
+ap_hook_insert_filter(modperl_input_filter_add_request,
NULL, NULL, APR_HOOK_LAST);
ap_register_output_filter(MP_FILTER_REQUEST_OUTPUT_NAME,
1.41 +38 -38modperl-2.0/src/modules/perl/modperl_filter.c
Index: modperl_filter.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_filter.c,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- modperl_filter.c 25 Nov 2002 22:47:39 - 1.40
+++ modperl_filter.c 12 Jan 2003 02:15:58 - 1.41
@@ -443,11
cvs commit: modperl-2.0/xs/tables/current/ModPerl FunctionTable.pm
stas2003/01/11 18:33:28
Modified:xs/Apache/Filter Apache__Filter.h
xs/maps modperl_functions.map
xs/tables/current/ModPerl FunctionTable.pm
Log:
add $filter-seen_eos flag for the streaming interface
Revision ChangesPath
1.21 +8 -0 modperl-2.0/xs/Apache/Filter/Apache__Filter.h
Index: Apache__Filter.h
===
RCS file: /home/cvs/modperl-2.0/xs/Apache/Filter/Apache__Filter.h,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- Apache__Filter.h 12 Jan 2003 02:31:54 - 1.20
+++ Apache__Filter.h 12 Jan 2003 02:33:27 - 1.21
@@ -125,3 +125,11 @@
return ctx-data ? SvREFCNT_inc(ctx-data) : PL_sv_undef;
}
+
+static MP_INLINE SV *mpxs_Apache__Filter_seen_eos(pTHX_ I32 items,
+ SV **MARK, SV **SP)
+{
+modperl_filter_t *modperl_filter;
+mpxs_usage_va_1(modperl_filter, $filter-seen_eos());
+return modperl_filter-seen_eos ? PL_sv_yes : PL_sv_no;
+}
1.48 +1 -0 modperl-2.0/xs/maps/modperl_functions.map
Index: modperl_functions.map
===
RCS file: /home/cvs/modperl-2.0/xs/maps/modperl_functions.map,v
retrieving revision 1.47
retrieving revision 1.48
diff -u -r1.47 -r1.48
--- modperl_functions.map 12 Jan 2003 02:31:54 - 1.47
+++ modperl_functions.map 12 Jan 2003 02:33:27 - 1.48
@@ -74,6 +74,7 @@
mpxs_Apache__Filter_print | | ...
mpxs_Apache__Filter_read | | ...
+ mpxs_Apache__Filter_seen_eos | | ...
mpxs_Apache__Filter_ctx | | filter, data=Nullsv
SV *:DEFINE_TIEHANDLE | | SV *:stashsv, SV *:sv=Nullsv
1.93 +26 -0 modperl-2.0/xs/tables/current/ModPerl/FunctionTable.pm
Index: FunctionTable.pm
===
RCS file: /home/cvs/modperl-2.0/xs/tables/current/ModPerl/FunctionTable.pm,v
retrieving revision 1.92
retrieving revision 1.93
diff -u -r1.92 -r1.93
--- FunctionTable.pm 12 Jan 2003 02:31:55 - 1.92
+++ FunctionTable.pm 12 Jan 2003 02:33:28 - 1.93
@@ -4892,6 +4892,32 @@
]
},
{
+'return_type' = 'SV *',
+'name' = 'mpxs_Apache__Filter_seen_eos',
+'attr' = [
+ 'static',
+ '__inline__'
+],
+'args' = [
+ {
+'type' = 'PerlInterpreter *',
+'name' = 'my_perl'
+ },
+ {
+'type' = 'I32',
+'name' = 'items'
+ },
+ {
+'type' = 'SV **',
+'name' = 'mark'
+ },
+ {
+'type' = 'SV **',
+'name' = 'sp'
+ }
+]
+ },
+ {
'return_type' = 'void',
'name' = 'mpxs_Apache__Log_BOOT',
'attr' = [
cvs commit: modperl-2.0/t/filter/TestFilter reverse.pm
stas2003/01/11 18:37:11
Modified:t/filter/TestFilter reverse.pm
Log:
send the signature only when eos has been seen (the filter can be invoked
many times during the same request)
Revision ChangesPath
1.5 +4 -1 modperl-2.0/t/filter/TestFilter/reverse.pm
Index: reverse.pm
===
RCS file: /home/cvs/modperl-2.0/t/filter/TestFilter/reverse.pm,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- reverse.pm25 Nov 2002 22:46:29 - 1.4
+++ reverse.pm12 Jan 2003 02:37:11 - 1.5
@@ -18,7 +18,10 @@
$filter-print(\n);
}
}
-$filter-print(Reversed by mod_perl 2.0\n);
+
+if ($filter-seen_eos) {
+$filter-print(Reversed by mod_perl 2.0\n);
+}
return Apache::OK;
}
cvs commit: modperl-2.0/t/filter/TestFilter buckets.pm
stas2003/01/11 20:00:42
Modified:t/filter/TestFilter buckets.pm
Log:
make sure that the body of the filter is executed only once
Revision ChangesPath
1.8 +22 -17modperl-2.0/t/filter/TestFilter/buckets.pm
Index: buckets.pm
===
RCS file: /home/cvs/modperl-2.0/t/filter/TestFilter/buckets.pm,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- buckets.pm11 Sep 2002 00:50:31 - 1.7
+++ buckets.pm12 Jan 2003 04:00:42 - 1.8
@@ -19,31 +19,36 @@
sub handler {
my($filter, $bb) = @_;
-Apache::TestToString-start;
+unless ($filter-ctx) {
-plan tests = 4;
+Apache::TestToString-start;
-my $ba = $filter-r-connection-bucket_alloc;
+plan tests = 4;
-#should only have 1 bucket from the response() below
-for (my $bucket = $bb-first; $bucket; $bucket = $bb-next($bucket)) {
-ok $bucket-type-name;
-ok $bucket-length == 2;
-$bucket-read(my $data);
-ok $data eq 'ok';
-}
+my $ba = $filter-r-connection-bucket_alloc;
+
+#should only have 1 bucket from the response() below
+for (my $bucket = $bb-first; $bucket; $bucket = $bb-next($bucket)) {
+ok $bucket-type-name;
+ok $bucket-length == 2;
+$bucket-read(my $data);
+ok (defined $data and $data eq 'ok');
+}
-my $tests = Apache::TestToString-finish;
+my $tests = Apache::TestToString-finish;
-my $brigade = APR::Brigade-new($filter-r-pool, $ba);
-my $bucket = APR::Bucket-new($tests);
+my $brigade = APR::Brigade-new($filter-r-pool, $ba);
+my $bucket = APR::Bucket-new($tests);
-$brigade-insert_tail($bucket);
+$brigade-insert_tail($bucket);
-my $ok = $brigade-first-type-name =~ /mod_perl/ ? 4 : 0;
-$brigade-insert_tail(APR::Bucket-new(ok $ok\n));
+my $ok = $brigade-first-type-name =~ /mod_perl/ ? 4 : 0;
+$brigade-insert_tail(APR::Bucket-new(ok $ok\n));
-$filter-next-pass_brigade($brigade);
+$filter-next-pass_brigade($brigade);
+
+$filter-ctx(1); # flag that we have run this already
+}
Apache::OK;
}
Re: [ANNOUNCE] Apache::DBI 0.90_02
Beau E. Cox wrote: WOW! I had heard moving A:DBI to 2 was going to be very difficult! I've been waiting... I think it's not what you think. The difficult thing is the pool over threads support, so you can re-use the same connection over all threads in the process. 0.90_02 version has a pool per proc/thread, no sharing. But you still benefit from the per-process cache just as in mod_perl 1.0. [...] 0.90_02 January 10, 2003 - Changes to make Apache::DBI load and function under mod_perl 2.0. __ 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
cvs commit: modperl-2.0/t/apache scanhdrs2.t
stas2003/01/10 23:41:04
Modified:t/apache scanhdrs2.t
Log:
t_cmp's args are (expected, received, comment)
not (received, expected, comment)
(the debug info was confusing otherwise)
Revision ChangesPath
1.2 +3 -3 modperl-2.0/t/apache/scanhdrs2.t
Index: scanhdrs2.t
===
RCS file: /home/cvs/modperl-2.0/t/apache/scanhdrs2.t,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- scanhdrs2.t 29 Jun 2002 20:39:22 - 1.1
+++ scanhdrs2.t 11 Jan 2003 07:41:04 - 1.2
@@ -14,10 +14,10 @@
my $res = GET $location?$redirect, redirect_ok = 0;
-ok t_cmp($res-header('Location'), $redirect,
+ok t_cmp($redirect, $res-header('Location'),
Location header);
-ok t_cmp($res-code, 302,
+ok t_cmp(302, $res-code,
status == 302);
$redirect = '/index.html';
@@ -27,7 +27,7 @@
ok t_cmp(1, !$res-header('Location'),
no Location header);
-ok t_cmp($res-code, 200,
+ok t_cmp(200, $res-code,
status == 200);
ok t_cmp(qr{welcome to}, $res-content,
Re: Problem combining mod_proxy, mod_rewrite mod_perl
Jan P. Monsch wrote: G'day! I would like to combine mod_proxy, mod_rewrite and mod_perl on an Apache 2.0.43 for Windows with mod_perl 2.0. The Perl Version I use is ActiveState 5.6.1. Just by loading the module the server behaves differently. Instead seeing the the reverse proxied site I get following error in the browser: - Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /directx1/directx1/directx1/directx1/directx1/directx1/directx1/directx1/directx1/directx1/directx1/. Reason: Max-Forwards has reached zero - proxy loop? - It seems as if the rewrite rules are applied in a recursive loop. The rewrite.log does support this. Any ideas why this is happening and how can I get the config running again. [...] From your explanations and debug traces it looks like a bug in mod_proxy/mod_rewrite. You probably will get the same story with mod_cgi. If so, you need to report this bug to the httpd-dev list. __ 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: Shared memory 'copy-on-write' issue
Perrin Harkins wrote: Anton Permyakov wrote: reading http://perl.apache.org/docs/1.0/api/Apache/SizeLimit.html#Shared_Memory_Opti ons i am seeing that link about memory sharing by copy-on-write points to http://perl.apache.org/docs/1.0/guide/index.html and 'META: change link when site is live' stands after it. Site is alive, how knows where should this link point to? It does go the guide correctly, but a more specific link would be this: http://perl.apache.org/docs/1.0/guide/performance.html#Sharing_Memory I've fixed the link to point to the above URL. Thanks for pointing this out. __ 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: An URL is not Invoking the Anticipated Perl Module [mp2]
Steve, please don't throw more than one question into the same email. It makes it really hard to followup. Please post each question separately. Steve D wrote: For the purpose of clarifying the issue, are you saying there is contention between the two handlers which are declared within the httpd.conf, as it has been setup in this case? That is, since a handler has been declared within by the directory section [/var/www/perl] and another for the location [/CurrDate], the two handlers are contenting against the one other? Therefore, in this case, although Location /CurrDate has been defined, the default handler Directory /var/www/perl is overriding the CurrDate name space[!?] Would someone please clarify. Eh? Did you: s/per-script/perl-script/ and tried again? From studying this further, I noticed I forgot to prefix the Location /CurrDate section with a PerlModule directive. Consequently, the following line has been added to the perl.conf file. PerModule: MyApache::CurrDate However, now, with this addition, when starting the Apache the following exception is genereated: httpd failed. The error was: Starting httpd: [Fri Jan 10 12:11:15 2003] [error] Can't locate MyApache/CurrDate.pm in @INC (@INC contains: /var/www/perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache2 /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl .) at (eval 4) line 3. You'll notice from this message, the path does include '/var/www/perl' and the perl module which is being called is within the '/var/www/perl/MyApache/' directory. (For good measure it was also placed within '/var/www/perl' without a resolution to the run time exception.) There was a bug in older mod_perl versions, and you'd get the Can't locate module error when in fact, the module has failed to compile. Please try again with the cvs version. Incidentally, the format of the configuration file which is being used in this case has been adapted from the article Introducting mod_perl Handlers. I've also been using Getting Your Feet Wet with mod_perl. These resources can be respectfully found at http://perl.apache.org/docs/2.0/user/handlers/intro.html#What_are_Handlers_ and http://perl.apache.org/docs/2.0/user/intro/start_fast.html#Handler_Modules I found these to be very helpful for a newcomer. Great. This later article was especially beneficial for it connected several fregmented thoughts together [at least in my own learning curve] into good concise working document. In my case, I found it helpful to get a perl script working [as a first measure] and then proceed to the use of a response handler. However, I did run across a problem with how the perl script name space was defined. The first example [in the article Getting Your Feet Wet] would not work when I used the syntax PerlResponseHandler Modperl::Registry nor PerlResponseHandler Modperl::Registry::handler. Consequently, I changed the format to PerlHandler ModPerl::Registry::handler and then my test script was able to run. It should work with 'PerlResponseHandler Modperl::Registry'. What was the error message (please start a new thread on this one, don't continue here) Consequently, at this stage, a few questions remain. 1) Since, at least in this situation, I had to adapt the handler from being PerlResponseHandler to PerlHandler in order to get the perl scripting to work, does that also mean the same adaptation will be necessary in order to yield a result from a reponse handler for the CurrDate.pm module? 2) Once again, how do I instruct Apache to properly locate the CurrDate.pm file? [Stas, you may have already given me the answer to this latter question but more clarity is still needed.] 3) When I include the provision of the line PerModule: MyApache::CurrDate within the perl.conf file, Apache throws an exception and failed to start. s/PerModule:/PerlModule/ I don't know where did you take PerModule: from. __ 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: maybe off topic? Mod write config issue
George Valpak wrote: Sorry if this is offtopic here - I looked on http://httpd.apache.org/lists.html and didn't see any better lists for this question...if there is one, let me know and Iwill post it there George, why not to try a specially designated httpd-users support list: http://httpd.apache.org/lists.html#http-users Also see: http://httpd.apache.org/docs/mod/mod_rewrite.html http://httpd.apache.org/docs/misc/rewriteguide.html I want to redirect http://www.i18n.com/showcase/foo to http://showcase.i18n.com/foo I am running a dual apache config (mp1, current release for mp and apache) so Ialready have some rewrite rules: VirtualHost www.i18n.com ServerName www.i18n.com RewriteEngine On RewriteLogLevel 0 RewriteRule ^/(.*.shtml)$ http://localhost:8000/$1 [proxy] RewriteRule ^/(.*.pl)$ http://localhost:8000/$1 [proxy] RewriteRule ^/(.*.inc)$ http://localhost:8000/$1 [proxy,last] NoCache * ProxyPassReverse / http://www.i18n.com/ snip /VirtualHost This all works fine. The virtual host showcase.i18n.com is defined in the same httpd.conf file and it works. Now I want to add the new rewrite rule: RewriteLogLevel 3 RewriteLog /usr/local/httpd_docs/logs/vslash_rewrite.log RewriteRule ^/showcase/(.*)$ http://showcase.i18n.com/$1 [proxy,last] this is added to the top of the list of rules. some weird things happen: 1 - nothing get written to the log file, even at level 9. It is owned by root (created by touch). Is that ok? 2 - the rewrite doesn't happen and I get a 404 error; The requested URL /showcase was not found on this server. Apache/1.3.27 Server at www.i18n.com Port 80 in my browser (Opera 6.05). Any ideas? It is live if you want to see it.. thanks, GV -- __ 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: Unregister streamed output filters
Esteban Fernandez Stafford wrote: Hello all, is there a way to unregister a streamed filter? I have seen this in many (all?) apache (C programmed) filters; they are able of declining the filtering of a certain stream, for example, when they do not know how to handle a certain content type. In the apache api this is done with ap_remove_output_filter(f). Is there something similar in mp2? Not at this moment, but hopefully it'll be supported soon. Since you need this feature, telling us in what situation you'd like to remove a filter will help us to build a better test case and provide a good real-world example for documentation. __ 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: development techniques
Jim Martinez wrote: [...] At apachecon, a speaker (who neither bragged nor rambled) mentioned lwp use instead of (or to complement) the web browser portion. Will the use of lwp instead of a browser improve my coding ability (either in terms of speed or just improving my perl coding)? Seems like I'd have to spend too much time with the lwp script (tell it to first request the page then choose option A and B then hit the submit button ... ) There are many benefits to using command line tools (which can be anything, but LWP::UserAgent and other packages in libwww-perl are a gift from god). Here are some of them off the top of my head: 1. You get the results as they come in (browsers tend to cash things). 2. You can program things: - make a sequence of request/response cycles based on a response - you can choose to display only certain bits of the response: e.g., show me only headers, only the body, only the size of the body, only certain keywords, etc. 3. You can easily reproduce sequences or specific inputs, especially when there is a sequence of request/response pairs to get to some state. 4. you can involve someone else in debugging the problem, without needing to come down (fly?) to his cubicle to explain how a certain anomaly is reached. So you can educate your users to create test scripts that reproduce the problem. 5. We (mod_perl programmers) very often use the single server mode (httpd -X) to test things. If you have a page with embedded images, it's going to take a while before you get the output, because you have only one server (this is documented in the guide). 6. Filling in forms. - You can prefill forms programmatically (saving you a lot of time and protecting from mistyping things) - You can provide inputs which with normal manual typing won't be possible (so you can test your program's behavior when a 10MB core file is submitted as a fname form's field). ... I guess there are many more things that could be added here, you get the idea. Apache::Test is one of the new tools that work with both versions of Apache (and mod_perl and other mod_*). If you are a 3rd party mod_perl module developer (CPAN or in-house) you definitely should use it to test your module. See: http://perl.apache.org/docs/general/testing/testing.html The only major drawback to command line tools I can see is when you need to observe the html as is (e.g. you can't use some logic/parser to verify correctness), here the browser is definitely more useful. So knowing when to use what technique is important. Both have an application. (I've also noticed that lwp-get sometimes have a significant delay because it tries to resolve IPs, even though the request is made to localhost. So many times I end up using just 'lynx --source') Is there some way to improve this cycle : edit code - refresh browser - possibly look at the error log - edit code - ... Or maybe you use another approach that's better? Inject mod_perl into your brain ;0) Seriously, I don't think that the core of this cycle can be any different, other than the 'refresh browser' part. Talking about the 'refresh browser' part. In one of the companies I've worked for, there was this girl who did some perl coding and who was very inefficient, because she didn't know she could do a refresh. Many times she needed to debug a form to which you get after a sequence of several forms, all requiring a lot of things to type in. So every time she would change a bit of code (1 sec), she would go to the first form and start filling in a form, then submit, get to the next form, fill it in, submit, and so on, till she gets to the stage she is debugging, see that her fix didn't work and start all again from scratch. On the way she would enter different data by mistake which would lead her to the wrong stage and she would need to start from scratch again. I'm sure that you all have seen someone in your office do that. Do them and your company a favor, explain to them that you can do a refresh to resubmit just the last stage. Or even better, show them the light by pointing them to libwww-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: mod_perl pre-install questions
Richard wrote: I had a brand new server setup yesterday, which has SuExec installed. I read somewhere, I don't remember where, that mod_perl won't work with SuExec. Is that true? Or did I just think I read that somewhere? It's true. It's all explained here: http://perl.apache.org/docs/1.0/guide/install.html#Is_it_possible_to_run_mod_perl_enabled_Apache_as_suExec_ I see mod_perl in my RPM package installer, with the options of ignore dependancies and force install, what do you recommend? I'd recommend to install it manually, YMMV. This has been discussed many times here, check the archives if you are curious why. What do I need to do to install it? Should I use the RPM installer? Do I need to disable SuExec? If not, how will the user and group settings in httpd.conf work with mod_perl installed? Thank you for any advice you may have You will find all the information that you need here: http://perl.apache.org/docs/1.0/guide/ Please take some time to read things under this URL. __ 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: Passing CGI environment to subprograms
I don't see any reason why your `` invoked process doesn't see the CGI
env vars. For example:
#!/usr/bin/perl
print Content-type: text/plain\n\n;
$ENV{'PATH'} = '/bin:/usr/bin';
delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};
print qx{printenv |grep REMOTE_ADDR};
prints:
REMOTE_ADDR=127.0.0.1
So as you can see, it works. The problem is probably in your external
program, since the env vars are all there.
Or may be you are using PerlSetEnv Off?
http://perl.apache.org/docs/1.0/guide/config.html#PerlSetupEnv
I've now located and tried the subprocess_env() in conjunction w/
spawn_proc_prog(). I just do a foreach on the ENV hash and stuff
the values
into subprocess_env(). That works (I have a test perl subprogram
that just
dumps the ENV), but now I am not able to get the output of the program.
I
pasted in the read_data() func from the example and I have a single
scalar
accepting the return value from spawn_proc_prog() per the example
and that
is supposed to give me the output filehandle.
Can you post a simple test program that reproduces the problem?
Also it'd be really useful if somebody could add a test suite for
Apache::Subprocess for (mod_perl 1.0). You can look at the
t/apr/subprocess test in mod_perl 2.0 to a basic example. It's a good
way to learn how to use Apache::Test, which is covered here:
http://perl.apache.org/docs/general/testing/testing.html
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: An URL is not Invoking the Anticipated Perl Module
Steve D wrote: The problem: Apache is generating File does not exist within its error.log and the message Object not found (The requested URL was not found. Error number 404.) while attempting to call a perl module from a brower. [...] Location /CurrDate SetHandler per-script PerlResponseHandler MyApache::CurrDate /Location s/per-script/perl-script/ SetHandler can't verify at parsing time whether a handler really exists, it's really a string. So in your case the default handler was handling that Location. See: http://httpd.apache.org/docs-2.0/mod/core.html#sethandler If you still have questions regarding this (my guess is that it should work just fine) please ask. re: PerlResponseHandler vs PerlHandler, I've updated the docs to always use PerlResponseHandler. PerlHandler is just a backcompat thing to easy httpd.conf porting, so it works. p.s. please remember to mention in the subject [mp2] or at least in the body of the message, when talking about mod_perl 2.0. __ 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: [mp2] input filter
Steve wrote:
I'm having some trouble configuring an input filter.. I'm using Apache
2.0.43, mod_perl 1.99_08-dev and perl 5.8.0.
In httpd.conf, I just did this inside a VirtualHost
PerlInputFilterHandler myApache::Filters::filter_in
My code looks something like this:
package myApache::Filters;
#here I loaded different modules etc..
sub filter_in : FilterConnectionHandler{
my ($filter, $bb, $mode, $block, $readbytes) = @_
my $rv =$filter-next-get_brigade($bb, $mode, $block, $readbytes);
return $rv unless $rv = APR::SUCCESS;
print STDERR INPUT FILTER\n;
my $c = $filter-c
return Apache::OK;
}
Are you sure that this is the code that you run? How about adding a
semicolon after $filter-c
In your original post you've asked whether it's OK that the debug
warning is printed twice. Yes, that's OK. A filter is called one or more
times depending on how other filters output their data. You should get
the filter called once per bucket brigade.
This is pretty much just taken from the mod_perl filter documenation, so I'm
pretty sure the code is OK.
My problem is this:
From the time I hit refresh in my browser to the time the content
appears takes a very long time. The request completes eventually, it
just takes forever. As soon as I take the filter handler out of
httpd.conf it works perfectly
Is this a configuration issue? Anyone have any ideas as to why this
happens?
While it responds slowly, do you see the debug printouts coming out
slowly as well? Try to use the MyApache::FilterSnoop filter
http://perl.apache.org/docs/2.0/user/handlers/filters.html#All_in_One_Filter
and see where things are delayed.
Also try using a command line useragent: lynx --source, lwp-request,
etc. So you will see the output as it comes out.
__
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: OSCON ideas - MVC talk
Nathan Torkington wrote: (yes, yes, we all want to see the How mod_perl 2.0 was finished but I'm not sure that's on the cards :-) Since the submission deadline is one week that certainly would not happen. Though an improved mod_perl 2.0 by Example tutorial is definitely a must for those who want to get familiar with most of the 2.0 new features. __ 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: OSCON ideas - MVC talk
Stas Bekman wrote: Since the submission deadline is one week that certainly would not happen. For some reason I thought the deadline was Jan 15th, I see that it's Feb 15th. Submit your proposals here: http://conferences.oreillynet.com/cs/os2003/create/e_sess __ 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: [mp2.0] Input Filter virus scan (more info)
Issac Goldstand wrote: [snip] . Notice that you may need to have to store the context data between filter calls, which currently is not supported, but I'm working on adding this feature asap. If you need to store something in between the filter calls (filter may get the data in chunks, every time it's called it may only gets a chunk of data), the context is the way to store such data (e.g. partial bucket brigades, counters, etc.). Just give me some time and I'll commit the implementation and the updated doc with examples. I'm experiencing some problems with not seeing EOS, which prevents me from completing it. Stay tuned. __ 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.c Not Compatible with Apache
Dale Lancaster wrote: Trying to narrow down a problem I am having with mod_perl::PerlRun on a stock RedHat 8.0 system, I have the following that simply doesn't work reliably under Apache 2.0.40 and mod_perl-1.99_05-3. The script runs fine for the first few refreshes and then I get the ominous error message: Error message: Not a CODE reference at /home/usa/cgi-bin/env.cgi line 7. Thanks for the report, Dale. Please try again with the current cvs, I've just committed a bug fix and a test that was reproducing it based on your report. __ 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: [mp2.0] Input Filter virus scan (more info)
Chris Hoffmann wrote: [...] My need is to scan incoming data. If anyone has used mod_vscan on incoming data or know if the All-in-One Filter example located at; http://perl.apache.org/docs/2.0/user/handlers/filters.html#All_in_One_Filter can do this please contact me. I'm not familiar with mod_vscan and you don't specify how the scan filter works, but I see no reason why it shouldn't work, as long as all you need is an access to the request's headers. Notice that you may need to have to store the context data between filter calls, which currently is not supported, but I'm working on adding this feature asap. Also all-in-one filter is an example of how to snoop on the data going through the filter, since you don't need the output filter, you can use a simpler only-input connection filter: http://perl.apache.org/docs/2.0/user/handlers/filters.html#Connection_Output_Filters One more thing that needs to be figured out is how to make the filter abort the normal request processing if the virus is discovered and return a 40x response. __ 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 and apache instll ok, but....
Matt Lopresti wrote: I am using RedHat 7.2, apache 1.3.27, mod_perl 1.27. Everything istalls correctly and make test is all a go. I then start the server, run a print env script and I dont get a MOD_PERL env and the gatway interface is CGI/1.1, I am however getting the server software env with mod_perl/1.27. I also added the the script in httpd.conf and took out the she bang line to perform another test, no go, internal server error. I do this process as root. What's the relevant section of your httpd.conf, where a Location is configured to run under mod_perl handler? You probably run scripts under mod_cgi. Did you look at: http://perl.apache.org/docs/1.0/guide/getwet.html#Configuring_and_Starting_the_mod_perl_Server http://perl.apache.org/docs/1.0/guide/getwet.html#A_Simple_Apache_Perl_Content_Handler Here is how I built mod_perl and apache: % tar xzvf apache_1.3.27.tar.gz % tar xzvf mod_perl-1.27.tar.gz % cd mod_perl-1.27 % perl Makefile.PL APACHE_SRC=../apache_1.3.27/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 (I have also used the USE_DSO=1) % make make test make install % cd ../apache_1.3.27 % make installd I'm not sure what installd is, but the rest looks good. __ 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 and apache instll ok, but....
Matt Lopresti wrote:
I am worried about the ENV{MOD_PERL} var not being set. What would cause
that not to get set? Is it a perms issue? In the conf file the User is
nobody and the Group is nobody. I am doing the entire make as root.
If you are seeing the mod_perl token in the server response headers or
the server startup:
http://perl.apache.org/docs/1.0/guide/install.html#Checking_the_error_log
http://perl.apache.org/docs/1.0/guide/install.html#Testing_via_telnet
but not in the script:
http://perl.apache.org/docs/1.0/guide/install.html#Testing_via_a_CGI_script
that means only one thing: You're calling the script under mod_cgi and
not mod_perl. Re-check again that you make the request to a location
configured to be run under Apache::Registry and also that you
don't override the mod_perl settings with ScriptAlias setting later in
httpd.conf.
__
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: Need help with perl and ezmlm-web
Margo Poolak wrote: Hello! I have several problems that i dont know how to fix! 1) Im trying to make work the ezmlm-web but it gives me an error: [...] 2) Oki trying to install ezmlm: /home/listmg/pakid/Ezmlm-0.03 perl Makefile.PL make make test make install Gives me an error: Can't use an undefined value as a HASH reference at /usr/lib/perl5/5.8.0/ExtUtils/MakeMaker.pm line 457 Look's like a problem with perl...stupid as im trying to install perl again(because i don't know what else could be done!) These two has nothing to do with mod_perl, please take them to one of the lists at http://lists.perl.org 3) Trying to install perl: perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2/ make[1]: Leaving directory `/home/listmg/pakid/mod_perl-1.99_07/docs/api/mod_perl-2.0' make[1]: Entering directory `/home/listmg/pakid/mod_perl-1.99_07/xs' make[2]: Entering directory `/home/listmg/pakid/mod_perl-1.99_07/xs/APR' make[3]: Entering directory `/home/listmg/pakid/mod_perl-1.99_07/xs/APR/APR' gcc -c -I/home/listmg/pakid/mod_perl-1.99_07/src/modules/perl -I/home/listmg/pakid/mod_perl-1.99_07/xs -I/usr/local/apache2//include -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -I/usr/include/gdbm -DMOD_PERL -O2 -march=i386 -mcpu=i686 -DVERSION=\0.01\ -DXS_VERSION=\0.01\ -fpic -I/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE APR.c Running Mkbootstrap for APR () chmod 644 APR.bs rm -f ../../../blib/arch/auto/APR/APR.so LD_RUN_PATH=/usr/lib gcc -shared -L/usr/local/lib APR.o -o ../../../blib/arch/auto/APR/APR.so -L/usr/local/apache2//lib -lapr -laprutil /usr/bin/ld: cannot find -lapr collect2: ld returned 1 exit status make[3]: *** [../../../blib/arch/auto/APR/APR.so] Error 1 make[3]: Leaving directory `/home/listmg/pakid/mod_perl-1.99_07/xs/APR/APR' make[2]: *** [subdirs] Error 2 make[2]: Leaving directory `/home/listmg/pakid/mod_perl-1.99_07/xs/APR' make[1]: *** [subdirs] Error 2 make[1]: Leaving directory `/home/listmg/pakid/mod_perl-1.99_07/xs' make: *** [subdirs] Error 2 Now i don't know what those errors are? You need to use the latest cvs version or wait for the new version to be released, which should happen RSN. http://perl.apache.org/download/source.html#2_0_Development_Source_Distribution __ 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.c Not Compatible with Apache
I've updated the README file to specify the minimum and maximum Apache versions required, the next mod_perl version's release will include it. As for your troubles, as Randy has suggested you probably have a bunch of various installs laying around and you've it all messed up. You don't need to install apr separately from Apache, just grab the latest cvs version of Apache and mod_perl, build them and you will be all set. See: http://perl.apache.org/docs/2.0/user/install/install.html#Getting_Bleeding_Edge_CVS_Sources http://perl.apache.org/docs/2.0/user/install/install.html#Configuring_and_Installing_Prerequisites http://perl.apache.org/docs/2.0/user/install/install.html#Downloading_the_mod_perl_Source ... It should just work. To make sure that you aren't messing up with other installation on your system, go and clean those up first. __ 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: Question on possible effects of mod_perl on mod_cgi
[When starting a new thread, please remember to create a new mail, rather than doing a reply to one of the threads. If you don't do that, your mail software attaches reference ids to the original thread and your post gets folded into the thread you've replied to. people may delete the whole thread without seeing your post if they weren't interested in this thread. it also has an ill effect on mail archives.] Terra Info wrote: I am debugging a particularly nasty issue right now on a perl script that when written 2+ yrs ago worked fine. NB: It does not run under mod_perl and it has not been modified since then. You mean, it has never worked under mod_perl 1.0? Can you test it with mod_perl 1.0? I run it from the cmd line (with the identical query string and all referenced %ENV vars set identical as well) and it runs fine. I run it as a typical CGI and it has problems that, in *some* ways, mirror the behavior of a poorly written (symptoms associated with unscoped globals, etc;) perl app under mod_perl. And since this is a poorly written app I am curious. Is there any link between mod_perl (1.99..) and mod_cgi (Apache 2)? Does mod_perl in anyway influence or maybe cause PerlRun like caching under mod_cgi? I am just trying to eliminate all possibilities as this one has been a real PITFA. You can turn the debugging on and see whether it gets cached. in ModPerl::RegistryCooker set: use constant DEBUG = 4; restart the server and watch error_log, compare the output of Registry with PerlRun. __ 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: perl's system() w/ apache under win2k
Terra Info wrote: Two things: 1) this is not the list for this question. 2) a probable answer anyhow- If that's a real pitfall and it's doomed to be a recurrent question, can we please document this under win32/? Also, Randy, it seems that there is whole lot of win32 issues which apply to all mod_perl versions (per our faq discussion), so rather than duplicating them in docs/1.0/os/win32 and docs/2.0/os/win32, we should probably have an area for general win32 issues, e.g. docs/general/os/win32 and point to it from both 1.0 and 2.0. The issue is not file permissions (per se) or anything like that. It is the way WinNT and up is built. What you were doing in Win 98 worked because apps all ran in the same user space. Despite logging into a 98 machine you were really executing all programs as the default user and inside that users memory space. That happened to be, for the most part, shared by almost everything else running on the system. Hence when you ran a gui app from within apache the system would display the gui part of it on the screen. Instead of going into how WinNT and up is designed (go over to mikeysoft's site and you may see something there or maybe a MCSE book on Win2K will have the design philosophy in it) let's just skip to the possible fix. Check to see if the user you run apache under is allowed to interact with the desktop. It should be in the services CPL applet under the entry for that service. Check that and restart the service. This may allow your app to run but I doubt it. Also, keep in mind this is not secure at all and your best bet is to see if the app you are running has a /quiet switch or something that will keep it from trying to paint any dialog boxes. If you wrote that app then you should put a hook into it that will allow that option (obviously adding the code to bypass init'n the gui code) and then execute it with that option. Tom Philip Fibiger wrote: Hello all, I've got a pretty simple perl script that used to run on a windows 98 machine running apache just fine. It would use system() to launch a windows app that has a graphical display to sync a ms-sql database to a mysql one. Anyway, it's been replaced by a new machine running win2k, and I'm having some problems. When I attempt to use system() to execute the program under win2k, the program appears to start (it shows up in the task list) but it never gets past that point. The same thing happens with any program that has a gui. I checked permissions, and I can log in w/ the same account apache uses, and I can execute the program just fine. Is there some permissions issue, or some alternate way of launching the program via perl that i'm not seeing? Thanks! Philip -- __ 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: sed error in perl Makefile.pl
[...] When I run perl Makefile.PL APACHE_SRC=../apache_1.3.xx/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 \ APACHE_PREFIX=/home/user/httpd/apache I see this (note the sed error) (cd ../apache_1.3.27 CC=gcc CFLAGS= -D_REENTRANT -DTHREADS_HAVE_PIDS -fno- strict-aliasing -I/usr/local/include ./configure --activate-module=src/modules/ perl/libperl.a --disable-rule=EXPAT --prefix=/home/user/httpd/apache) CC=gcc CFLAGS= -D_REENTRANT -DTHREADS_HAVE_PIDS -fno-strict-aliasing -I/usr/local/include ./configure --activate-module=src/modules/perl/libperl.a --disable-rule=EXPAT --prefix=/home/user/httpd/apache Configuring for Apache, Version 1.3.27 + using installation path layout: Apache , (config.layout) + activated perl module (modules/perl/libperl.a) Creating Makefile sed: -e expression #44, char 46: Unknown option to 's' Creating Configuration.apaci in src First, you need to figure out where this error is coming from, sed isn't very helpful here. Since we are talking about ./configure errors, you need to modify apache-1.3/configure to start with: #!/bin/sh -x (notice the -x) now log the build process into a file a look what happens between two strings: Creating Makefile and Creating Configuration.apaci in src From what I see the error is in apache domain, but since I don't have this problem I could be wrong. __ 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: Question on possible effects of mod_perl on mod_cgi
Terra Info wrote:
The threads issue is my bag. I know better but was busy and distracted,
hence I just did a reply to all and trimmed out the excess.
No prob. the comment was addressed to all subscribers.
Anyhow, I
think you may have misunderstood my question. Although I have a specific
issue at hand, my question was more generic. My questions are more
related to the overall design of mod_perl and its effects on the
functioning of Apache's other components. Anyhow, in answer to your
question, I have not tried it under mod_perl 1 or 2 because this script
would never function under them. It is that poorly written.
I meant the Apache::PerlRun from mod_perl 1.0. Obviously I wasn't trying
to suggest for you to run it as a pure handler ;)
Notice that ModPerl::PerlRun and others aren't exactly the same as their
1.0 counterparts. Due to the threading issues, currently 2.0's registry
aren't chdir()'ing to the scripts directory. That may change in the
future. But this may be unrelated to your problem.
So, is there any link between mod_perl (1.99..) and mod_cgi (Apache 2)?
No.
Does mod_perl in anyway influence or maybe cause PerlRun like caching
under mod_cgi?
The two has nothing to do with each other.
I realize the answers are probably no but I am at my wits
end with this bug and am trying to elminate things as causes that
normally I would not even think were related.
So you have a better handle on why I am asking, I have a script that
runs fine from the cmd line under all parameter combinations, runs fine
in most situations under CGI but when a few param combinations occur it
fails to execute to completion. The odd thing is the place it hangs up
is the line before exit;. I added a warn('foo at line nnn') after every
line and it warns all they way to the line for exit; but never exists
and apache tells me that the script times out. That combined with the
fact that the script, when executed on the command line, under a faked
up ENV that matches exactly what it gets from httpd runs flawlessly and
to completion, seems to suggest something is happening in the in-process
handling of the CGI script. Does that problem lie in mod_cgi, perl or in
some funky interaction between components? With some of the symptoms I
saw I wanted to rule out mod_perl before I went any further.
Thanks and I hope this made it more clear what I was looking for and why,
I still don't understand you. When do you see the problem? When you run
the script under mod_cgi or mod_perl? I don't understand why do you keep
referring to mod_cgi.
And we are talking about Apache/mod_perl 2.0 here, right?
__
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: perl's system() w/ apache under win2k
Terra Info wrote: I will write up a more publically palatable version of the below and post it for someone more intimately associated with the docs and development to merge into the tree. Great, thank you! Keep in mind that this is an issue not just for MP but also any CGI script or frankly any service that allows execution of external binaries that try to initialize and display GUI components. Although I have not tested it, I would imagine that this would be an issue on a Unix/linix variant as well as the design of the OS is similar to WinNT and up. Or the other way around if you want to follow the timeline correctly ;-}. I believe that Unix users are aware of this issue from the very first steps of using the system and therefore we hardly ever see this kind of questions on this list. Apparently permissions on winNT is something unexpected and new for those who are used to older win32 systems. Moreover, error_log usually tells what the exact problem is when the code is written properly to report errors (e.g., checking the return status of system()). My guess is that this should work on winNT too. If there are similar issues with MacOS X or other platforms, please send the info in, so we will add it to the docs. Though my guess is that MacOS X is based on FreeBSD and therefore all the normal Unix perms concepts apply as is. Correct me if I'm wrong. __ 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: Question on possible effects of mod_perl on mod_cgi
OK, now it's clear, thanks for the explanation. FWIW, there were discussions of possible pipes read/write deadlocks in the current mod_cgi implementation in Apache 2.0, so you may experience just that. Check the httpd-dev list archives. [...] * Given that, I noticed PerlRun was no longer prominintly displayed in the docs What made you think so? The PerlRun docs weren't touched for ages. and the migration FAQ did not to my knowledge even touch on it. Because all you have to do is to s/Apache::/ModPerl::/ for all registry handlers, which includes PerlRun. Do you think that it'll help to explicitly list them all? __ 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: perl's system() w/ apache under win2k
Terra Info wrote: [...] application. If you would like to take output from that application then you should write to STDOUT all text you want the perl application to see as a return value from your system() call or `` (backticks) call. you probably meant qx(), as system doesn't return the sub-process' STDOUT, but only the exec status. __ 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
cvs commit: modperl-2.0 Changes
stas2002/12/31 19:48:20 Modified:.Changes Log: log the recent change Revision ChangesPath 1.92 +2 -0 modperl-2.0/Changes Index: Changes === RCS file: /home/cvs/modperl-2.0/Changes,v retrieving revision 1.91 retrieving revision 1.92 diff -u -r1.91 -r1.92 --- Changes 1 Jan 2003 03:45:54 - 1.91 +++ Changes 1 Jan 2003 03:48:20 - 1.92 @@ -10,6 +10,8 @@ =item 1.99_08-dev +Add PerlPreConnectionHandler support in Apache::Test [Stas] + Enable PerlPreConnectionHandler [Stas] Support the Host: request header in Apache::TestClient [Stas]
cvs commit: modperl-2.0 README
stas2002/12/31 20:10:49 Modified:.README Log: shape up the README file: - most important mention up to which Apache version the released version is expected to work with, to reduce a number of questions on the mod_perl list, when people try the latest Apache. - do require Perl 5.6.1, to avoid faulty bug reports - give credits to TicketMaster Revision ChangesPath 1.8 +30 -6 modperl-2.0/README Index: README === RCS file: /home/cvs/modperl-2.0/README,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- README27 Jun 2002 06:36:03 - 1.7 +++ README1 Jan 2003 04:10:49 - 1.8 @@ -1,9 +1,21 @@ This is mod_perl version 2.0-tobe -Apache version 2.0.39 or higher is required. +*** Prerequisites *** -Perl version 5.6.0 or higher is required. Perl-5.8.0-RC2 if you build -with 5.8.0 series. +Apache: + this version of mod_perl works with Apache versions 2.0.39 - + 2.0.43. Older Apache versions aren't supported. Newer Apache version + may not work with this version of mod_perl, but only with the cvs + version which can be obtained from: + http://perl.apache.org/download/source.html#2_0_Development_Source_Distribution + +Perl: + version 5.6.1 or higher is required. mod_perl builds with 5.6.0, + but it's likely that you will have problems using it. + + Perl version 5.8.0 is required for threaded MPMs. + +*** Status *** mod_perl is currently considered beta when used with the prefork MPM. @@ -12,13 +24,20 @@ Only DSO build of mod_perl-2.0 is currently supported, static builds will be support in the future. -docs are available in /docs. Currently they don't get installed on -'make install'. Certain API documentation can be found in docs/api/. -the online version is at http://perl.apache.org/release/docs). +*** Documentation *** + +Documentation are available in /docs. Currently they don't get +installed on 'make install'. Certain API documentation can be found in +/docs/api/. the online version is at +http://perl.apache.org/release/docs). + +*** Todo *** mod_perl-2.0-tobe is not 100% feature complete with the 1.xx version. See the todo/ directory for what remains to be done. +*** Support *** + For comments, questions, bug-reports, etc., join the mod_perl users list by sending mail to [EMAIL PROTECTED] @@ -28,8 +47,13 @@ For announcements join the mod_perl announce list by sending mail to [EMAIL PROTECTED] +*** Developers *** + mod_perl-2.0 was designed and written by Doug MacEachern, with contributions from many others (see the CREDITS and Changes files). Doug's mod_perl-2.0 development time is sponsored by Covalent Technologies: http://www.covalent.net/ + +Stas Bekman's mod_perl-2.0 development time is sponsored by +TicketMaster: http://www.ticketmaster.com/ \ No newline at end of file
Re: mod_perl make failed: cannot find -lapr
Randy Kobes wrote: On Tue, 31 Dec 2002, Steve Davis wrote: Your help will be very much appreciated to resolve the following issue. When attempting to make mod_perl.so, the make script 'almost' makes a touchdown but fails before getting to the finishing line. Now it is time get some help from a coach. Hopefully, with a little help, a touchdown will soon follow. Below, I present was appears to be the problem, but someone else will have to direct me to the next set of steps. [ .. ] This problem 'may' have to do with an issue of a change of naming conventions which were adapted by the apr apache group. Confer with Stas Bekman's post on Nov 26, 2002 with a title of Problems compiling mod_perl 1.99_07 in RH 8.0. He provides a cvs patch; but, unfortunately, I'm not familiar with using that-as least-as of yet. (Look's like I might have learn this package real soon.) Are they any intentions to update the mod_perl-1.99_07.tar.gz? If my conclusion is correct, then currently, and according to the on-line instructions, the present tar.gz edition is not compatible to the latest edition of apache. (2.0.43). So, 'maybe' the cause of my make failure. It appears as if, only the cvs repository maybe a valid for compiling. If my analysis is correct, and a new edition of the respective non-cvs files be acquired somehow. It might be easier to obtain the whole mod_perl 2.0 sources via cvs, rather than patching - this is described at http://perl.apache.org/download/source.html#2_0_Development_Source_Distribution You likely have a cvs client already, so it's a matter of changing to an appropriate directory and doing % cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login % cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic co modperl-2.0 Or you can use the cvs snapshots tarballs, linked from the same URL Randy provided. 1.99_08 should be released RSN. I will make sure that it will state in the README file which Apache version it will work with. __ 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: Modules Executed Twice
David Wheeler wrote:
Hi All,
I'm developing a new module for mod_perl 1.27, and I'm noticing that
some code is getting executed twice when the Apache server starts up.
It was supposed to be fixed in 1.25_01:
=item 1.25_01 - July 6, 2001
...
fix double-loading bug of Perl{Require,Module}s at startup time
Here is the diff:
Index: Apache/Apache.pm
===
RCS file: /home/cvs/modperl/Apache/Apache.pm,v
retrieving revision 1.62
retrieving revision 1.63
diff -u -r1.62 -r1.63
--- Apache/Apache.pm29 Jan 2001 16:07:08 - 1.62
+++ Apache/Apache.pm26 Apr 2001 05:30:45 - 1.63
@@ -30,7 +30,10 @@
sub httpd_conf {
shift;
-push @Apache::ReadConfig::PerlConfig,
+no strict 'refs';
+#use a symbolic reference so %Apache::ReadConfig::
+#is empty at compile time
+push @{Apache::ReadConfig::PerlConfig},
map $_\n, @_;
}
[...]
sub test_seen {
return if $Apache::Server::Starting;
$seen++;
warn Seen: $seen\n
}
Indeed, that's the workaround that was added originaly to cure the above
problem. Perhaps you can play with httpd_conf and see why it doesn't
work for you. I know that several people have reported that they still
had this problem since 1.26 was released.
__
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: Modules Executed Twice
David Wheeler wrote:
On Monday, December 30, 2002, at 02:45 PM, Stas Bekman wrote:
David Wheeler wrote:
Hi All,
I'm developing a new module for mod_perl 1.27, and I'm noticing that
some code is getting executed twice when the Apache server starts up.
It was supposed to be fixed in 1.25_01:
=item 1.25_01 - July 6, 2001
...
fix double-loading bug of Perl{Require,Module}s at startup time
Hrm, interesting. I wonder what the problem is?
Indeed, that's the workaround that was added originaly to cure the
above problem. Perhaps you can play with httpd_conf and see why it
doesn't work for you. I know that several people have reported that
they still had this problem since 1.26 was released.
I have a better workaround, now. I found that I could make the problem
go away by reversing the order in which the modules are loaded in
httpd.conf:
PerlModule TestSeen
PerlModule DoubleTest
Not exactly sure why that makes a difference, though.
Because $seen wasn't reset yet on reload.
Is httpd_conf() documented somewhere? I can't see what's supposed to be
passed to it.
It's an internal thing. You can add debug prints and Carp::cluck, to see
who calls it with what args. Hopefully someone will be able to track the
problem down and finally cure it for good.
__
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: Modules Executed Twice
Hann, Brian wrote: Is anyone getting duplicates (i.e. 2 of the same email) of this thread? It just started happening today. I can't tell, since I never receive dups because of the procmail rule: :0 Wh: msgid.lock | formail -D 8192 saved/msgid.cache hint, hint ;) __ 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
cvs commit: modperl-2.0/build xs_generate.pl
stas2002/12/29 00:21:03 Modified:buildxs_generate.pl Log: unshift Apache-Test/lib into @INC, so the locate Apache::Test will be searched for first Revision ChangesPath 1.2 +1 -1 modperl-2.0/build/xs_generate.pl Index: xs_generate.pl === RCS file: /home/cvs/modperl-2.0/build/xs_generate.pl,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- xs_generate.pl5 Mar 2001 03:55:08 - 1.1 +++ xs_generate.pl29 Dec 2002 08:21:03 - 1.2 @@ -1,4 +1,4 @@ -use lib qw(lib); +use lib qw(lib Apache-Test/lib); use ModPerl::WrapXS ();
cvs commit: modperl-2.0/ModPerl-Registry/lib/ModPerl RegistryCooker.pm RegistryLoader.pm
stas2002/12/29 02:08:08
Modified:ModPerl-Registry/lib/ModPerl RegistryCooker.pm
RegistryLoader.pm
Log:
support the NameWithVirtualHost setting in namespace_from_uri() as in 1.0
(would be nice to add a test, but I'm not sure how to do that)
Revision ChangesPath
1.26 +12 -0 modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm
Index: RegistryCooker.pm
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- RegistryCooker.pm 28 Dec 2002 07:13:26 - 1.25
+++ RegistryCooker.pm 29 Dec 2002 10:08:08 - 1.26
@@ -85,6 +85,12 @@
#
+
+unless (defined $ModPerl::RegistryCooker::NameWithVirtualHost) {
+$ModPerl::RegistryCooker::NameWithVirtualHost = 1;
+}
+
+#
# func: new
# dflt: new
# args: $class - class to bless into
@@ -310,6 +316,12 @@
my $script_name = $path_info $self-[URI] =~ /$path_info$/ ?
substr($self-[URI], 0, length($self-[URI]) - length($path_info)) :
$self-[URI];
+
+if ($ModPerl::RegistryCooker::NameWithVirtualHost
+$self-[REQ]-server-is_virtual) {
+my $name = $self-[REQ]-get_server_name;
+$script_name = join , $name, $script_name if $name;
+}
$script_name =~ s:/+$:/__INDEX__:;
1.7 +5 -1 modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryLoader.pm
Index: RegistryLoader.pm
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryLoader.pm,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- RegistryLoader.pm 29 Dec 2002 09:18:50 - 1.6
+++ RegistryLoader.pm 29 Dec 2002 10:08:08 - 1.7
@@ -21,7 +21,7 @@
}
sub handler {
-my($self, $uri, $filename) = @_;
+my($self, $uri, $filename, $virthost) = @_;
# set the inheritance rules at run time
@ISA = $self-{package};
@@ -73,6 +73,8 @@
package = $self-{package},
} = ref($self) || $self;
+$rl-{virthost} = $virthost if defined $virthost;
+
# can't call SUPER::handler here, because it usually calls new()
# and then the ModPerlRegistryLoader::new() will get called,
# instead of the super class' new, so we implement the super
@@ -86,6 +88,7 @@
# when when finfo() and slurp_filename() are ported to 2.0 and
# RegistryCooker is starting to use them
+sub get_server_name { return $_[0]-{virthost} if exists $_[0]-{virthost} }
sub filename { shift-{filename} }
sub status { Apache::HTTP_OK }
sub my_finfo{ shift-{filename} }
@@ -95,6 +98,7 @@
sub log_error { shift; die @_ if $@; warn @_; }
sub run { return Apache::OK } # don't run the script
sub server { shift }
+sub is_virtual { exists shift-{virthost} }
# the preloaded file needs to be precompiled into the package
# specified by the 'package' attribute, not RegistryLoader
cvs commit: modperl-2.0 Changes
stas2002/12/29 02:11:49 Modified:ModPerl-Registry TODO .Changes Log: document recent changes Revision ChangesPath 1.11 +0 -2 modperl-2.0/ModPerl-Registry/TODO Index: TODO === RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/TODO,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- TODO 26 Nov 2002 07:47:26 - 1.10 +++ TODO 29 Dec 2002 10:11:49 - 1.11 @@ -25,8 +25,6 @@ - $Apache::Server::CWD doesn't exist -- NameWithVirtualHost is not handled - - need to figure out what's happening with ModPerl::Registry::MarkLine, why it's not on by default? 1.89 +9 -0 modperl-2.0/Changes Index: Changes === RCS file: /home/cvs/modperl-2.0/Changes,v retrieving revision 1.88 retrieving revision 1.89 diff -u -r1.88 -r1.89 --- Changes 21 Dec 2002 03:46:07 - 1.88 +++ Changes 29 Dec 2002 10:11:49 - 1.89 @@ -10,6 +10,15 @@ =item 1.99_08-dev +restore the ModPerl::RegistryLoader::new() method for backwards +compatibility [Stas] + +port the support for NameWithVirtualHost in ModPerl::RegistryCooker +and ModPerl::RegistryLoader [Stas] + +fix the handling of the return status in ModPerl::RegistryCooker, add +a test to verify that [Stas] + under non-threaded perl need to check whether mod_perl is running, when modperl_vhost_is_running check is done. [Stas]
cvs commit: modperl-2.0/lib/ModPerl TypeMap.pm
stas2002/12/29 16:27:13
Modified:lib/ModPerl TypeMap.pm
Log:
print a warning when a function is not going to be glued, because one of its
args or return types can't be resolved
Revision ChangesPath
1.18 +9 -3 modperl-2.0/lib/ModPerl/TypeMap.pm
Index: TypeMap.pm
===
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/TypeMap.pm,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- TypeMap.pm23 May 2002 19:49:07 - 1.17
+++ TypeMap.pm30 Dec 2002 00:27:13 - 1.18
@@ -144,7 +144,7 @@
return 1 if $map-{argspec};
for (@_) {
-return unless $self-map_type($_);
+return (0, $_) unless $self-map_type($_);
}
return 1;
@@ -230,8 +230,14 @@
$self-thx_fixup($func);
-return unless $self-can_map($map, $func-{return_type},
- map $_-{type}, @{ $func-{args} });
+my($status, $failed_type) =
+$self-can_map($map, $func-{return_type},
+map $_-{type}, @{ $func-{args} });
+
+unless ($status) {
+warn unknown typemap: '$failed_type' (skipping $func-{name})\n;
+return;
+}
my $type = $map-{return_type} || $func-{return_type} || 'void';
my $map_type = $self-map_type($type);
cvs commit: modperl-2.0/t/directive perlloadmodule3.t
stas2002/12/29 16:59:23
Modified:t/directive perlloadmodule3.t
Log:
make this test work with Apache::TestClient, Apache::TestRequest::module()
affects global testing env, so should run it only when it's needed.
Revision ChangesPath
1.3 +7 -8 modperl-2.0/t/directive/perlloadmodule3.t
Index: perlloadmodule3.t
===
RCS file: /home/cvs/modperl-2.0/t/directive/perlloadmodule3.t,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- perlloadmodule3.t 21 Dec 2002 03:47:18 - 1.2
+++ perlloadmodule3.t 30 Dec 2002 00:59:23 - 1.3
@@ -9,15 +9,11 @@
my $config = Apache::Test::config();
my $base_hostport = Apache::TestRequest::hostport($config);
-Apache::TestRequest::module($module);
-my $hostport = Apache::TestRequest::hostport($config);
-
-# XXX: probably a good idea to split into more tests, that test
-# smaller portions of information, but requires a more elaborated
-# logic.
+# XXX: probably a good idea to split into more sub-tests, that test
+# smaller portions of information, but requires a more elaborate
+# logic. Alternatively could use diff($expected, $received).
-# XXX: this subtest fails when lwp is not installed, need to investigate
-plan tests = 3, todo = [1];
+plan tests = 3;
t_debug(connecting to $base_hostport);
{
@@ -40,6 +36,9 @@
my $received = GET_BODY $location;
ok t_cmp($expected, $received, server merge);
}
+
+Apache::TestRequest::module($module);
+my $hostport = Apache::TestRequest::hostport($config);
t_debug(connecting to $hostport);
{
Re: [mp2] APR::Socket::recv set read timeout ?
Michael wrote: ii) is there any way to perform a select(2) or like on the $socket? I would like to implement some sort of 'timeout' in the read loop..say, after 5 secs if nothing is recv'd from the client then the connection will be closed. I have tried alarm/die pair but it was a failure. Any idea? You have the APR::Socket object, so it should be possible. Though I see that apr_poll_ API is not glued. !MODULE=APR::Poll apr_poll_socket_add apr_poll_socket_clear apr_poll_data_get apr_poll_revents_get apr_poll_socket_mask apr_poll apr_poll_socket_remove apr_poll_data_set apr_poll_setup The ! mark in xs/maps/apr_functions.map disables the glueing of this API subset at the build time. sorry but I would like to ask how do I glue that? I tried the util/xs_check.pl in the modperl2 src dir, and it reports.. unable to glue 27 mapped functions: [...] it requires more than that, since the C types used by apr_pool functions aren't all having Perl typemap entries. Before we implement these let's ask Doug why he chose to skip APR::Poll in first place. Finally, as I've mention before, I would like to put this non http thing together with other http things on the same port 80. Is this possible? say, when this handler sees GET|POST|HEAD it forgets the request and let the Apache HTTP module process it in the normal way? This is a job of the PerlPreConnectionHandler, which is currently not implemented. Its purpose is to look at the first request of the new connection and dynamically assign a protocol handler for the current connection. __ 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
cvs commit: modperl-2.0/ModPerl-Registry/lib/ModPerl RegistryCooker.pm
stas2002/12/27 23:13:26
Modified:ModPerl-Registry/lib/ModPerl RegistryCooker.pm
Log:
constant.pm already wrappes the values into a sub call, so no need to do
it twice
Revision ChangesPath
1.25 +3 -3 modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm
Index: RegistryCooker.pm
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- RegistryCooker.pm 24 Dec 2002 01:51:40 - 1.24
+++ RegistryCooker.pm 28 Dec 2002 07:13:26 - 1.25
@@ -76,9 +76,9 @@
# constant subs
#
#
-use constant NOP = sub { };
-use constant TRUE = sub { 1 };
-use constant FALSE = sub { 0 };
+use constant NOP = '';
+use constant TRUE = 1;
+use constant FALSE = 0;
use constant NAMESPACE_ROOT = 'ModPerl::ROOT';
cvs commit: modperl-2.0/ModPerl-Registry/lib/ModPerl RegistryLoader.pm
stas2002/12/27 23:39:21
Modified:ModPerl-Registry/lib/ModPerl RegistryLoader.pm
Log:
use the ModPerl::Registry package as the default, so it'll be backcompat
with 1.0
Revision ChangesPath
1.5 +1 -0 modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryLoader.pm
Index: RegistryLoader.pm
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryLoader.pm,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- RegistryLoader.pm 16 Aug 2002 09:01:17 - 1.4
+++ RegistryLoader.pm 28 Dec 2002 07:39:20 - 1.5
@@ -16,6 +16,7 @@
sub create {
my $class = shift;
my $self = bless {@_} = ref($class)||$class;
+$self-{package} ||= 'ModPerl::Registry';
$self-{pool} = APR::Pool-new();
$self-load_package($self-{package});
return $self;
Re: mod_perl 2 and problems w/ ErrorDocument Directive
Terra Info wrote: Sounds good. Thanks for the help. I will patch my copy. Or just grab the latest cvs. Will all MP1 functionality be migrating over to MP2? Pretty much yes. In particular the PerlHandler Apache::Status functionality. Doug mentioned that most of its functionality works as-is. It needs some patching to work with the new registry. __ 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: [mp2] APR::Socket::recv set read timeout ?
Michael wrote: Hi all. As suggested by Geoff and Stas, I am trying out modperl2.. Now I have some questions: i) with Apache::CommandServer (can be found at http://perl.apache.org/docs/2.0/user/overview/overview.html#toc_Protocol_Modules_with_mod_perl_2_0), I setup everything according to the guide..but telnet localhost 8084 Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. Login: foo Password: foo ^] I must hit return once before the 'Login' prompt appears, and after a few tests I found that $socket-send() do not send the buffer to the client right away. Is this related to some configurable directives in httpd.conf or I did something wrong.. or just a feature? I'm trying to bring the overview and design notes docs up-to-date, Doug wrote them long time ago and things have changed a bit since then. The almost up-to-date version of the overview is here: http://perl.apache.org/docs/2.0/user/intro/overview.html How did you get to the old URL? Via google? For the latest docs on protocols see: http://perl.apache.org/docs/2.0/user/handlers/protocols.html If based on this doc you can bring the example from the overview up-to-date and send a patch here, I'll move it into the protocols doc, where it belongs. ii) is there any way to perform a select(2) or like on the $socket? I would like to implement some sort of 'timeout' in the read loop..say, after 5 secs if nothing is recv'd from the client then the connection will be closed. I have tried alarm/die pair but it was a failure. Any idea? You have the APR::Socket object, so it should be possible. Though I see that apr_poll_ API is not glued. !MODULE=APR::Poll apr_poll_socket_add apr_poll_socket_clear apr_poll_data_get apr_poll_revents_get apr_poll_socket_mask apr_poll apr_poll_socket_remove apr_poll_data_set apr_poll_setup The ! mark in xs/maps/apr_functions.map disables the glueing of this API subset at the build time. __ 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: Relative path problem
Andrzej Jan Taramina wrote: Steve: In my index.pl, I call another perl file using a reletive path, like ../lib/work.pm. But I found this file cannot be found. Could someone tell me what is going on or give me some directions? Since your script is compiled under mod_perl ahead of time, and things like working directory are shared amongst all processes, you cannot assume that the relative path will be rooted from the script location directory under mp. You need to use fully qualified pathnames (config parameters that are passed into your script or read in are a good way to work around this issue). I heard rumours that MP2 might have a better solution by the time it goes final next year, but that was just a rumour at this stage. Maybe Stas can illuminate the matter more. The best solution is to use a project specific namespace, rather than ../../whatever.pm. It's all explained at: http://perl.apache.org/docs/1.0/guide/porting.html#_INC_and_mod_perl and the sections that follow. __ 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: RedHat 8.0 standard Apache2.0 and mod_perl 2.0::PerlRun doesn'twork?
Dale Lancaster wrote: Thanks for the information. I did try removing Apache:DBI, but it still fails. OK Building everything from source will be time consuming. If I do that, I will probably just drop back to Apache 1.3 since I know it works. It's not time consuming at all, just follow the copy-n-paste recipe from the install page for 2.0. It'll help a lot if you try that first and verify that the bug hasn't been fixed already. __ 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: Relative path problem
Andrzej Jan Taramina wrote: Stas: Are you talking about registry scripts or handlers? Because the former do change into the script's dir. CGI script using ModPerl::Registry and mp2. And that doesn't seem to workat least not using the HTML::Template module, which under mp2 does not find the requested template, which is located in the same directory as the script. It only finds it if I specify a fully qualified file/path. Any ideas why? That's why I repeatedly ask to mention the mod_perl version when reporting problems and not leave us guessing. Indeed, currently ModPerl::Registry and friends (mod_perl 2.0) don't chdir() to the script's dir, because under threads chdir() affects all threads. The original poster was talking about mod_perl 1.0. __ 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
cvs commit: modperl/src/modules/perl apache_inc.h
stas2002/12/26 17:28:26 Modified:src/modules/perl apache_inc.h Log: s/\cM// Revision ChangesPath 1.7 +1 -1 modperl/src/modules/perl/apache_inc.h Index: apache_inc.h === RCS file: /home/cvs/modperl/src/modules/perl/apache_inc.h,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- apache_inc.h 16 Jun 2002 19:28:20 - 1.6 +++ apache_inc.h 27 Dec 2002 01:28:26 - 1.7 @@ -73,7 +73,7 @@ #define apache_isnan isnan #undef isnan #endif - + #ifdef PERL_IS_5_6 #ifdef opendir
cvs commit: modperl/Util .cvsignore
stas2002/12/26 17:45:22 Modified:Connection .cvsignore File .cvsignore Log .cvsignore ModuleConfig .cvsignore Server .cvsignore Table.cvsignore URI .cvsignore Util .cvsignore Log: update cvs ignore files Revision ChangesPath 1.2 +2 -0 modperl/Connection/.cvsignore Index: .cvsignore === RCS file: /home/cvs/modperl/Connection/.cvsignore,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- .cvsignore28 Jul 1998 17:09:13 - 1.1 +++ .cvsignore27 Dec 2002 01:45:21 - 1.2 @@ -1,2 +1,4 @@ Makefile pm_to_blib +Connection.xs + 1.2 +1 -0 modperl/File/.cvsignore Index: .cvsignore === RCS file: /home/cvs/modperl/File/.cvsignore,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- .cvsignore22 Dec 1998 16:36:50 - 1.1 +++ .cvsignore27 Dec 2002 01:45:22 - 1.2 @@ -1,2 +1,3 @@ Makefile pm_to_blib +File.xs 1.2 +1 -0 modperl/Log/.cvsignore Index: .cvsignore === RCS file: /home/cvs/modperl/Log/.cvsignore,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- .cvsignore13 Jul 1998 13:25:23 - 1.1 +++ .cvsignore27 Dec 2002 01:45:22 - 1.2 @@ -1,2 +1,3 @@ Makefile pm_to_blib +Log.xs 1.2 +2 -0 modperl/ModuleConfig/.cvsignore Index: .cvsignore === RCS file: /home/cvs/modperl/ModuleConfig/.cvsignore,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- .cvsignore22 May 1998 07:43:36 - 1.1 +++ .cvsignore27 Dec 2002 01:45:22 - 1.2 @@ -1,2 +1,4 @@ Makefile pm_to_blib +ModuleConfig.xs + 1.2 +1 -0 modperl/Server/.cvsignore Index: .cvsignore === RCS file: /home/cvs/modperl/Server/.cvsignore,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- .cvsignore28 Jul 1998 17:09:14 - 1.1 +++ .cvsignore27 Dec 2002 01:45:22 - 1.2 @@ -1,2 +1,3 @@ Makefile pm_to_blib +Server.xs 1.2 +1 -0 modperl/Table/.cvsignore Index: .cvsignore === RCS file: /home/cvs/modperl/Table/.cvsignore,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- .cvsignore8 Nov 1998 01:26:42 - 1.1 +++ .cvsignore27 Dec 2002 01:45:22 - 1.2 @@ -1,2 +1,3 @@ Makefile pm_to_blib +Table.xs 1.2 +1 -0 modperl/URI/.cvsignore Index: .cvsignore === RCS file: /home/cvs/modperl/URI/.cvsignore,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- .cvsignore17 Jul 1998 20:48:38 - 1.1 +++ .cvsignore27 Dec 2002 01:45:22 - 1.2 @@ -1,2 +1,3 @@ Makefile pm_to_blib +URI.xs 1.2 +1 -0 modperl/Util/.cvsignore Index: .cvsignore === RCS file: /home/cvs/modperl/Util/.cvsignore,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- .cvsignore18 Jul 1998 14:44:15 - 1.1 +++ .cvsignore27 Dec 2002 01:45:22 - 1.2 @@ -1,2 +1,3 @@ Makefile pm_to_blib +Util.xs
Re: RedHat 8.0 standard Apache2.0 and mod_perl 2.0::PerlRun doesn'twork?
Dale Lancaster wrote: I have searched the archives and various websites to find my problem and its associated resolution to no avail. I upgraded my working Apache 1.3 and mod_perl 1.x website using the PerlRun option of modperl to the RedHat 8.0 standard release with Apache/mod_perl 2.0 combo -- bad move it appears. ModPerl::Registry and friends are in beta now. I've ported the 1.0's version and made it a bit more modular via ModPerl::RegistryCooker. It's quite possible that I broke some of the functionalities while porting as you saw in the recent bug fix. The problem is that I couldn't verify whether the porting was 1:1 because there was no exhaustive test suite. For 2.0 we are hoping to have one. First, disable Apache::DBI. Does the problem persist? Second, please download the latest cvs versions of apache and mod_perl and try again. Does the problem persist? If it does, please send a short script that reproduces the problem, and hopefully a self-contained one, so it's not relying on mysql. In short, think of it this way: To solve the problem, I need to reproduce it first. So help me to accomplish that first. __ 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: [modperl 1.27] Problem regarding Perl*Handler and the HTTPrequestline
in Apache/mod_perl 2.0, you can write an input filter that _does_ allow you do parse the Request Line yourself. then again, you can write a protocol handler for any protocol you can dream up, so there's no reason to mess with HTTP :) Actually in 2.0 you can even implement this in a HeaderParser handler. Here is such an example: http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlHeaderParserHandler Here is an example of the input filter that modifies the request headers (as suggested by Geoff): http://perl.apache.org/docs/2.0/user/handlers/filters.html#Connection_Input_Filters __ 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
cvs commit: modperl Changes
stas2002/12/24 17:46:10
Modified:src/modules/perl perl_util.c
.Changes
Log:
prevent segfaults in mod_perl_mark_where() when a sub can't get
resolved
Submitted by: Gerald Richter [EMAIL PROTECTED]
Reviewed by: stas
Revision ChangesPath
1.50 +8 -3 modperl/src/modules/perl/perl_util.c
Index: perl_util.c
===
RCS file: /home/cvs/modperl/src/modules/perl/perl_util.c,v
retrieving revision 1.49
retrieving revision 1.50
diff -u -r1.49 -r1.50
--- perl_util.c 15 May 2002 02:08:16 - 1.49
+++ perl_util.c 25 Dec 2002 01:46:09 - 1.50
@@ -852,11 +852,16 @@
name = perl_sv_name(sub);
sv_setpv(GvSV(CopFILEGV(curcop)), );
-sv_catpvf(GvSV(CopFILEGV(curcop)), %s subroutine `%_', where, name);
+if (name) {
+sv_catpvf(GvSV(CopFILEGV(curcop)), %s subroutine `%_', where, name);
+SvREFCNT_dec(name);
+}
+else {
+sv_catpvf(GvSV(CopFILEGV(curcop)), %s subroutine unknown, where);
+}
+
CopLINE_set(curcop, 1);
-if(name)
- SvREFCNT_dec(name);
}
#endif
1.658 +3 -0 modperl/Changes
Index: Changes
===
RCS file: /home/cvs/modperl/Changes,v
retrieving revision 1.657
retrieving revision 1.658
diff -u -r1.657 -r1.658
--- Changes 28 Nov 2002 09:42:45 - 1.657
+++ Changes 25 Dec 2002 01:46:09 - 1.658
@@ -10,6 +10,9 @@
=item 1.27_01-dev
+prevent segfaults in mod_perl_mark_where() when a sub can't get
+resolved [Gerald Richter [EMAIL PROTECTED]]
+
Need to load B::Terse/TerseSize if it wasn't loaded yet in that child
before using it. [Dan Sully [EMAIL PROTECTED]]
cvs commit: modperl-2.0/ModPerl-Registry/t/conf extra.conf.in
stas2002/12/23 17:51:40
Modified:ModPerl-Registry/lib/ModPerl RegistryCooker.pm
ModPerl-Registry/t/conf extra.conf.in
Added: ModPerl-Registry/t 404.t
ModPerl-Registry/t/cgi-bin 404.pl
Log:
fix the handling of the return status in ModPerl::RegistryCooker,
add a test to verify that
Revision ChangesPath
1.1 modperl-2.0/ModPerl-Registry/t/404.t
Index: 404.t
===
use strict;
use warnings FATAL = 'all';
use Apache::Test;
use Apache::TestUtil;
use Apache::TestRequest qw(GET_BODY HEAD);
plan tests = 1;
my $url = /error_document/cannot_be_found;
{
my $response = Oops, can't find the requested doc;
ok t_cmp(
$response,
GET_BODY($url),
test ErrorDocument,
);
}
1.1 modperl-2.0/ModPerl-Registry/t/cgi-bin/404.pl
Index: 404.pl
===
use strict;
use warnings;
my $r = shift;
$r-content_type('text/plain');
print Oops, can't find the requested doc;
1.24 +2 -2 modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm
Index: RegistryCooker.pm
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- RegistryCooker.pm 16 Aug 2002 09:01:17 - 1.23
+++ RegistryCooker.pm 24 Dec 2002 01:51:40 - 1.24
@@ -157,9 +157,9 @@
# handlers shouldn't set $r-status but return it
my $old_status = $self-[REQ]-status;
my $rc = $self-run;
-my $new_status = $self-[REQ]-status($old_status);
+$self-[REQ]-status($old_status);
-return ($rc != Apache::OK) ? $rc : $new_status;
+return ($rc != Apache::OK) ? $rc : $self-[STATUS];
}
#
1.8 +9 -0 modperl-2.0/ModPerl-Registry/t/conf/extra.conf.in
Index: extra.conf.in
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/t/conf/extra.conf.in,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- extra.conf.in 15 Aug 2002 16:17:52 - 1.7
+++ extra.conf.in 24 Dec 2002 01:51:40 - 1.8
@@ -117,3 +117,12 @@
PerlOptions +ParseHeaders
/Location
+### the 404 test ###
+
+Alias /error_document/ @ServerRoot@/cgi-bin/
+Location /error_document
+ErrorDocument 404 /error_document/404.pl
+SetHandler perl-script
+Options +ExecCGI
+PerlResponseHandler ModPerl::Registry
+/Location
Re: Database Pooling
Jean-Michel Hiver wrote: [...] * I _think_ that mod_perl 2 on Apache 2 might solve your problem since it's threaded (list, am I right here? I'm still working on mp1 for the most part) Eventually, yes. __ 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: Installed OK, but fails immediately on tests
Nigel Gilbert wrote:
I have run 'perl Makefile.PL' and 'make' without error, following the
mod_perl installation instructions, but when I run make test, the
server is shown as 'failing to start' and the test sequence aborts.
Further investigation shows that httpd has started successfully and the
problem is in t/TEST, which tries to do a 'simple_fetch' of
/test.html to demonstrate that the server is working, but this fails.
I think the reason that it fails is that any attempt to GET a page
using the server on port 8529 returns a 403 Forbidden code. A
colleague wondered whether this port had to be included in
/etc/services, but I can see no mention of this in the documentation.
Some context:
The server is running SunOS dusty 5.7 Generic sun4u sparc SUNW,Ultra-4
The server is also running a production version of Apache on port 80
(without mod_perl)
Perl is v5.8.0 built for sun4-solaris
I am attempting to install mod_perl-1.27
Here is the end of the transcript and what appears in the error_log
/opt/apache_1.3.20/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t
httpd listening on port 8529
will write error_log to: t/logs/error_log
letting apache warm up...\c
done
/usr/bin/perl t/TEST 0
still waiting for server to warm up...not ok
server failed to start! (please examine t/logs/error_log) at t/TEST
line 95.
make: *** [run_tests] Error 29
{dusty:41} cat t/logs/error_log
[notice] Destruction-DESTROY called for $global_object
Subroutine fileparse_set_fstype redefined at
/usr/local/lib/perl5/5.8.0/File/Bas
ename.pm line 154.
Subroutine fileparse redefined at
/usr/local/lib/perl5/5.8.0/File/Basename.pm li
ne 168.
Subroutine basename redefined at
/usr/local/lib/perl5/5.8.0/File/Basename.pm lin
e 235.
Subroutine dirname redefined at
/usr/local/lib/perl5/5.8.0/File/Basename.pm line
248.
Constant subroutine CGI::XHTML_DTD redefined at
/usr/local/lib/perl5/5.8.0/const
ant.pm line 108.
[Mon Dec 23 21:44:18 2002] [warn] [notice] child_init for process
15493, report
any problems to [no address given]
{dusty:42}
what's wrong?
The error_log is not very helpfull here, may be it's just slow to start?
mod_perl 1.0's test suite waits too little before it gives up.
So try:
make start_httpd
t/TEST
make stop_httpd
you can manually test whether the server is running by fetching
localhost:8529, after 'make start_httpd'. If you are already doing that,
and as you say you get 403, check the perms.
And no, you don't need 8529 to be in /etc/services
Also, any reason for using 1.3.20 and not the latest version of Apache 1.3?
__
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 2 and problems w/ ErrorDocument Directive
Terra Info wrote: PS: I forgot to let you know if it works on MP1. I do not have that installed on any machines so if someone out there on the list could check that out and post back I would appreciate it. Everything you need is below. Here is the fix, I've messed up this part while porting. I'll commit that fix soonish + a new test. Index: lib/ModPerl/RegistryCooker.pm === RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm,v retrieving revision 1.23 diff -u -r1.23 RegistryCooker.pm --- lib/ModPerl/RegistryCooker.pm 16 Aug 2002 09:01:17 - 1.23 +++ lib/ModPerl/RegistryCooker.pm 24 Dec 2002 01:44:52 - @@ -157,7 +157,8 @@ # handlers shouldn't set $r-status but return it my $old_status = $self-[REQ]-status; my $rc = $self-run; -my $new_status = $self-[REQ]-status($old_status); +my $new_status = $self-[STATUS]; +$self-[REQ]-status($old_status); return ($rc != Apache::OK) ? $rc : $new_status; } __ 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: Install Problem: make test: modules/src.t
Mark Hawkes wrote: When I 'make test' I'm getting failures relating to modules/src.t [...] $ make test TEST_VERBOSE=1 --snip-- dir=../src ok 2 main= not ok 3 module_magic_number = 0 not ok 4 httpd_version = not ok 5 -I../src -I../src/modules/perl ok 6 FAILED tests 3-5 Failed 3/6 tests, 50.00% okay --snip-- Failed Test Status Wstat Total Fail Failed List of failed --- modules/src.t 63 50.00% 3-5 6 tests skipped. httpd terminated Failed 1/34 test scripts, 97.06% okay. 3/398 subtests failed, 99.25% okay. make: *** [run_tests] Error 29 what t/logs/error_log has to say about that? BTW, you can run just one test: % make start_httpd % t/TEST -v modules/src.t % make stop_httpd Please remember to follow the guidelines at: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems to get the issues resolved much faster. -- __ 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: [mp1] strange build problem with request_rec structure breaksAPI
[...]
I've tracked the difference down as to where it is in the structure: all
elements before and including finfo (type: struct stat) are in sync,
and all elements after and including parsed_uri (type: uri_components)
are 8 bytes off (extra 8 bytes in apache-mod_perl).
Either finfo is eight bytes longer in apache-mod_perl, or
apache-mod_perl has slipped some other element between finfo and
parsed_uri.
Somehow apache-mod_perl and apache-vanilla have a different ideas of the
request_rec structure. Because I compile mod_ssl using apxs from
apache-vanilla it works with apace-vanilla but not apache-mod_perl.
it's the struct stat that's different, not the request_rec. And no,
mod_perl doesn't mangle the Apache datastructures.
Check this out:
/* sizeof.c */
#include stdio.h
#include sys/stat.h
int main()
{
printf(size of struct stat is: %d\n, sizeof(struct stat));
return 0;
}
# sizeof.pl
use Inline C;
foo();
__END__
__C__
int foo()
{
printf(size of struct stat is: %d\n, sizeof(struct stat));
return 0;
}
% gcc -o sizeof sizeof.c ; ./sizeof
size of struct stat is: 88
% /home/stas/perl/5.6.0/bin/perl ./sizeof.pl
size of struct stat is: 96
tested with other perls on the same machine and the result is the same
(beware to delete _Inline before each try, since it won't recompile the
code if you use a different perl version, but the C code haven't changed)
So as you can see there is indeed 8 bytes difference. This is because
some of the members of the struct stat aren't of the same size when
compiled with perl and C. You may want to dig deeper and figure out the
one that's different. But first compare perl -V of the older perl build
under which things worked and the output of the newly built perl. I
suspect that the latter has the USE_LARGE_FILES enabled, whereas the
older doesn't. On my machine /usr/include/bits/stat.h uses a different
struct stat when large files are enabled.
Ah, indeed that seems to be the issue:
gcc -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o sizeof sizeof.c ; ./sizeof
size of struct stat is: 96
here you go -D_FILE_OFFSET_BITS=64 is the one that causes the prob.
__
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
cvs commit: modperl-2.0 Changes
stas2002/12/20 18:26:02
Modified:src/modules/perl modperl_cmd.c
.Changes
Log:
revert the last change, the file/linenumber of the error are already
reported by httpd
Revision ChangesPath
1.36 +2 -5 modperl-2.0/src/modules/perl/modperl_cmd.c
Index: modperl_cmd.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- modperl_cmd.c 20 Dec 2002 07:23:00 - 1.35
+++ modperl_cmd.c 21 Dec 2002 02:26:02 - 1.36
@@ -8,11 +8,8 @@
static char *modperl_cmd_too_late(cmd_parms *parms)
{
-return apr_psprintf(parms-pool,
-mod_perl is already running, too late for %s (%s:%d),
-parms-cmd-name,
-parms-directive-filename,
-parms-directive-line_num);
+return apr_pstrcat(parms-pool, mod_perl is already running,
+ too late for , parms-cmd-name, NULL);
}
char *modperl_cmd_push_handlers(MpAV **handlers, const char *name,
1.87 +0 -3 modperl-2.0/Changes
Index: Changes
===
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.86
retrieving revision 1.87
diff -u -r1.86 -r1.87
--- Changes 20 Dec 2002 07:23:00 - 1.86
+++ Changes 21 Dec 2002 02:26:02 - 1.87
@@ -10,9 +10,6 @@
=item 1.99_08-dev
-when reporting too late for something, print the config file and the
-line number [Stas]
-
fix $r-read to read all the requested amount of data if possible,
adjust the test TestApache::read to verify that [Stas]
cvs commit: modperl-2.0 Changes
stas2002/12/20 19:46:07 Modified:src/modules/perl modperl_cmd.c .Changes Log: under non-threaded perl need to check whether mod_perl is running, when modperl_vhost_is_running check is done. Revision ChangesPath 1.37 +1 -1 modperl-2.0/src/modules/perl/modperl_cmd.c Index: modperl_cmd.c === RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v retrieving revision 1.36 retrieving revision 1.37 diff -u -r1.36 -r1.37 --- modperl_cmd.c 21 Dec 2002 02:26:02 - 1.36 +++ modperl_cmd.c 21 Dec 2002 03:46:07 - 1.37 @@ -61,7 +61,7 @@ return FALSE; } #else -return TRUE; +return modperl_is_running(); #endif } 1.88 +3 -0 modperl-2.0/Changes Index: Changes === RCS file: /home/cvs/modperl-2.0/Changes,v retrieving revision 1.87 retrieving revision 1.88 diff -u -r1.87 -r1.88 --- Changes 21 Dec 2002 02:26:02 - 1.87 +++ Changes 21 Dec 2002 03:46:07 - 1.88 @@ -10,6 +10,9 @@ =item 1.99_08-dev +under non-threaded perl need to check whether mod_perl is running, +when modperl_vhost_is_running check is done. [Stas] + fix $r-read to read all the requested amount of data if possible, adjust the test TestApache::read to verify that [Stas]
cvs commit: modperl-2.0/t/directive perlloadmodule3.t
stas2002/12/20 19:47:18
Modified:t/directive perlloadmodule3.t
Log:
1st subtest fails when lwp is not installed, need to investigate, make it
TODO for now
Revision ChangesPath
1.2 +2 -1 modperl-2.0/t/directive/perlloadmodule3.t
Index: perlloadmodule3.t
===
RCS file: /home/cvs/modperl-2.0/t/directive/perlloadmodule3.t,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- perlloadmodule3.t 12 Dec 2002 10:13:56 - 1.1
+++ perlloadmodule3.t 21 Dec 2002 03:47:18 - 1.2
@@ -16,7 +16,8 @@
# smaller portions of information, but requires a more elaborated
# logic.
-plan tests = 3;
+# XXX: this subtest fails when lwp is not installed, need to investigate
+plan tests = 3, todo = [1];
t_debug(connecting to $base_hostport);
{
Re: install apache:asp in windows
Karthik wrote: Sir, I want to run sum asp programs using apache webserver 1.3 so i downloaded mod_perl-2.0-current.tar to have asp support on apache webserver. 1. Please tell me how to install.(in the website it is not clear) What is it not clear? Could you please be more specific? What document are you talking about? Have you read: http://perl.apache.org/docs/1.0/os/win32/install.html If not, please do it first. 2. Is there any change in config file. RTFM: http://perl.apache.org/docs/1.0/os/win32/config.html 3. then how to run an asp file. RTFM again at: http://www.apache-asp.org/ Hope that now you have enough information to figure it out on your own. Please do ask further *specific* questions, if you have any, but after you have read the documents listed in this email. Thanks. __ 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 2 and problems w/ ErrorDocument Directive
Terra Info wrote: I have a script that provides custom error messages that I set up using the ErrorDocument directive (ie; ErrorDocument 400 /cgi-global/error.pl?error=400useXML=1). When run under typical mod_cgi all works as planned and it outputs the proper stuff. When run under mod_perl it outputs the same but then appends the default ErrorDocument (ie; ErrorDocument 500 /error/HTTP_INTERNAL_SERVER_ERROR.html.var) output on the end so I have effectively two HTML docs on the output page. The odd part of this issue is this. When it is a 404 error The stock error doc says that Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request which makes no sense since the only log entry is File does not exist: /var/www/terradev/docs/bad-link. When you use the 500.pl example below you get Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request. despite the fact that the custom error script did work and output what it was supposed to and the error logs confirm that. Looks like ModPerl::Registry is not handling correctly the return status , hence you get the run of the default handler as well. I'll look into it. But first, does it work properly with mod_perl 1.0? Finally please attach the script that fails, preferrably removing all but the very minimal code that allows to reproduce the problem. Thanks. And if you can a test to modperl-2.0/ModPerl-Registry/t that reproduces the problem, that would be even better. If you don't know Apache::Test, you can learn more about it at: http://perl.apache.org/docs/general/testing/testing.html and looking at the existing tests. To run the registry tests you need to cd to the ModPerl-Registry dir first and run 'make test'. If it seems like too much work, I'll take care of adding the test. But it'd be cool if people who encounter problems were able to submit tests with their reports. Thanks. __ 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
cvs commit: modperl-2.0 Changes
stas2002/12/19 23:23:00
Modified:src/modules/perl modperl_cmd.c
.Changes
Log:
when reporting too late for something, print the config file and the
line number
Revision ChangesPath
1.35 +5 -2 modperl-2.0/src/modules/perl/modperl_cmd.c
Index: modperl_cmd.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- modperl_cmd.c 12 Dec 2002 11:45:26 - 1.34
+++ modperl_cmd.c 20 Dec 2002 07:23:00 - 1.35
@@ -8,8 +8,11 @@
static char *modperl_cmd_too_late(cmd_parms *parms)
{
-return apr_pstrcat(parms-pool, mod_perl is already running,
- too late for , parms-cmd-name, NULL);
+return apr_psprintf(parms-pool,
+mod_perl is already running, too late for %s (%s:%d),
+parms-cmd-name,
+parms-directive-filename,
+parms-directive-line_num);
}
char *modperl_cmd_push_handlers(MpAV **handlers, const char *name,
1.86 +3 -0 modperl-2.0/Changes
Index: Changes
===
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.85
retrieving revision 1.86
diff -u -r1.85 -r1.86
--- Changes 17 Dec 2002 07:15:46 - 1.85
+++ Changes 20 Dec 2002 07:23:00 - 1.86
@@ -10,6 +10,9 @@
=item 1.99_08-dev
+when reporting too late for something, print the config file and the
+line number [Stas]
+
fix $r-read to read all the requested amount of data if possible,
adjust the test TestApache::read to verify that [Stas]
Re: mod_perl fails tests
[EMAIL PROTECTED] wrote: Yes, I was able to find CGI.pm. Do you know how I can fix my problem and get mod_perl installed and configured. I want to see the output of: find /usr/lib/perl5 -name CGI.pm Does it match one of the paths in @INC, as reported by the error message? Thanks- Rodney On Wed, 18 Dec 2002 16:13:19 +0800 Stas Bekman [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: I am having some trouble installing mod_perl on my redhat linux 8.0 box. I successfully installed apache 2.0.43 from source and placed it in the /usr/local/apache2 directory. In addition, I downloaded the latest version of mod_perl from cvs. I successfully used the following command to generate the makefile: perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2 MP_INST_APACHE2=1. Even though the make process was successful the make test process was not. As clear as I can tell from the error message that I listed below, mod_perl is looking for apache components in /home/software/apache_cvs/modperl-2.0/t/conf/httpd .conf which is clearly wrong since my httpd.conf file is in /usr/local/apache2/conf. Actually, this is the correct httpd.conf which is autogenerated for the tests only Here is the error message: waiting for server to start: ...[Tue Dec 17 17:37:17 2002] [info] 19 Apache:: modules loaded [Tue Dec 17 17:37:17 2002] [info] 5 APR:: modules loaded [Tue Dec 17 17:37:17 2002] [info] base server + 6 vhosts ready to run tests ..[Tue Dec 17 17:37:19 2002] [info] 19 Apache:: modules loaded [Tue Dec 17 17:37:20 2002] [info] 5 APR:: modules loaded .[Tue Dec 17 17:37:20 2002] [info] base server + 6 vhosts ready to run tests Syntax error on line 693 of /home/software/apache_cvs/modperl-2.0/t/conf/httpd.conf: Can't locate CGI.pm in @INC (@INC contains: /home/software/apache_cvs/modperl-2.0/blib/lib/Apache2 /home/software/apache_cvs/modperl-2.0/blib/arch/Apache2 /home/software/apache_cvs/modperl-2.0/Apache-Test/lib /home/software/apache_cvs/modperl-2.0/lib /home/software/apache_cvs/modperl-2.0/blib/lib /home/software/apache_cvs/modperl-2.0/blib/arch /home/software/apache_cvs/modperl-2.0/t/response /home/software/apache_cvs/modperl-2.0/t/protocol /home/software/apache_cvs/modperl-2.0/t/hooks /home/software/apache_cvs/modperl-2.0/t/filter /home/software/apache_cvs/modperl-2.0/t /home/software/apache_cvs/modperl-2.0/t/htdocs/testdirective/perlmodule-vh /home/software/apache_cvs/modperl-2.0/t/htdocs/testdirective/main /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl) at (eval 22) line 3. !!! server has died with status 255 (t/logs/error_log wasn't created, start the server in the debug mode) make: *** [run_tests] Error 143 You mean, you have 5.8.0 but no CGI.pm? It should be there, because it's the part of the core. can you please do: find /usr/lib/perl5 -name CGI.pm Do you get 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 -- __ 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 troubles with RedHat 8.0 and Perl 5.8.0
iansmith wrote: On Thu, 19 Dec 2002, Stas Bekman wrote: Before you rebuild it, if you can get the segfault backtrace, that would be great. If you don't know how, check: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems Tried to do a make test in the mod_perl directory and got... Syntax error on line 3 of mod_perl-1.27/t/conf/httpd.conf: Invalid command '=pod', perhaps mis-spelled or defined by a module not included in the server configuration Usually that happens when mod_perl hasn't been compiled yet. Are you sure you have followed the right order of build as explained at the install page? I did a manual run with gdb and got this when it crashed... Starting program: /var/www-1/source/apache_1.3.27/src/httpd -X [New Thread 8192 (LWP 5250)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8192 (LWP 5250)] #0 0x400c8dfd in perl_header_parser () from /var/www-1/libexec/libperl.so #1 0x0806acdd in run_method () #2 0x0806add7 in ap_header_parse () #3 0x0807f198 in process_request_internal () #4 0x0807f552 in ap_process_request () #5 0x08076816 in child_main () #6 0x080769b6 in make_child () #7 0x08076b1d in startup_children () #8 0x0807714a in standalone_main () #9 0x08077968 in main () #10 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 Any ideas? Thanks. Any chance you can recompile mod_perl with DEBUG enabled and get the trace again, so that we can see the arguments to the faulty call? -- __ 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: When perl is not quite fast enough
[apache.org keeps on timing out :( reposting 3rd time :(] Jeff AA wrote: -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: 16 December 2002 13:22 To: [EMAIL PROTECTED] Subject: When perl is not quite fast enough While reading Mark Fowler excelent Perl Advent Calendar (http://www.perladvent.org/2002/) 6th entry: http://www.perladvent.org/2002/6th/, in the references section I've noticed a link to Nicolas Clark's notes from his YAPC::EU::2002 presentation, on how to make your perl code faster: http://www.ccl4.org/~nick/P/Fast_Enough/ Dear ModPerl Lister, I have two questions: 1) In this list, I have seen folks asking general Perlish questions told to take their discussions elsewhere, along with the useless recommendation that they browse lists.perl.org - I have done this several times and joined a few of the lists, but only ever found lists that were rather beginner. I have also lurked in some of the groups.yahoo.com pearly lists without finding the right level. - can folks name any specific useful intermediate/advanced Perl lists? i.e. Perl 4+ years in a commercial env I think the comp.lang.perl.moderated newsgroup (and if not accepted by the first, comp.lang.perl.misc) used to be the best resource to discuss general perl things. It's been a while since I've last used it, so I'm not sure if it's still a good resource. If others can confirm that it's still useful, I'll add that resource to: http://perl.apache.org/docs/offsite/other.html#Perl If you know of other good resources for general perl discussions which aren't already listed at lists.perl.org please let us know and we will update that section. It's probably a good idea to link from http://perl.apache.org/help/index.html to http://perl.apache.org/docs/offsite/other.html to help direct those seeking help on other topics in the vicinity of mod_perl. 2) I have one common approach to speed improvement that is not mentioned at all, to do with symbol table manipulation for functions, that I would like to polish via a list discussion - is this list appropriate for a thread discussing Perlish performance in general? I would guess that symbol table fiddles might be risky in a mod_perlish env. It sounds good to me if it helps other mod_perl users to improve their code's performance. __ 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: modperl 2.0 problems with Apache::Cookie and related modules.
b. ash wrote: Hi, I am trying to configure a working apache2/modperl2 setup, unfortunately I can not seemt to get a critical module Apache::Cookie to install, I keep getting this error. Can't locate Apache/MyConfig.pm in @INC (@INC contains: /usr/local/lib/perl5/5.8.0/i686-linux-thread-multi /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i686-linux-thread-multi /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl .) at Makefile.PL line 27. BEGIN failed--compilation aborted at Makefile.PL line 27. any ideas what might be going on here. A backcompat version of Apache::MyConfig is now available via Apache::compat in the mod_perl cvs. Though it won't solve the Apache::Cookie lib as reported by others. __ 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 fails tests
[EMAIL PROTECTED] wrote: I am having some trouble installing mod_perl on my redhat linux 8.0 box. I successfully installed apache 2.0.43 from source and placed it in the /usr/local/apache2 directory. In addition, I downloaded the latest version of mod_perl from cvs. I successfully used the following command to generate the makefile: perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2 MP_INST_APACHE2=1. Even though the make process was successful the make test process was not. As clear as I can tell from the error message that I listed below, mod_perl is looking for apache components in /home/software/apache_cvs/modperl-2.0/t/conf/httpd .conf which is clearly wrong since my httpd.conf file is in /usr/local/apache2/conf. Actually, this is the correct httpd.conf which is autogenerated for the tests only Here is the error message: waiting for server to start: ...[Tue Dec 17 17:37:17 2002] [info] 19 Apache:: modules loaded [Tue Dec 17 17:37:17 2002] [info] 5 APR:: modules loaded [Tue Dec 17 17:37:17 2002] [info] base server + 6 vhosts ready to run tests ..[Tue Dec 17 17:37:19 2002] [info] 19 Apache:: modules loaded [Tue Dec 17 17:37:20 2002] [info] 5 APR:: modules loaded .[Tue Dec 17 17:37:20 2002] [info] base server + 6 vhosts ready to run tests Syntax error on line 693 of /home/software/apache_cvs/modperl-2.0/t/conf/httpd.conf: Can't locate CGI.pm in @INC (@INC contains: /home/software/apache_cvs/modperl-2.0/blib/lib/Apache2 /home/software/apache_cvs/modperl-2.0/blib/arch/Apache2 /home/software/apache_cvs/modperl-2.0/Apache-Test/lib /home/software/apache_cvs/modperl-2.0/lib /home/software/apache_cvs/modperl-2.0/blib/lib /home/software/apache_cvs/modperl-2.0/blib/arch /home/software/apache_cvs/modperl-2.0/t/response /home/software/apache_cvs/modperl-2.0/t/protocol /home/software/apache_cvs/modperl-2.0/t/hooks /home/software/apache_cvs/modperl-2.0/t/filter /home/software/apache_cvs/modperl-2.0/t /home/software/apache_cvs/modperl-2.0/t/htdocs/testdirective/perlmodule-vh /home/software/apache_cvs/modperl-2.0/t/htdocs/testdirective/main /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl) at (eval 22) line 3. !!! server has died with status 255 (t/logs/error_log wasn't created, start the server in the debug mode) make: *** [run_tests] Error 143 You mean, you have 5.8.0 but no CGI.pm? It should be there, because it's the part of the core. can you please do: find /usr/lib/perl5 -name CGI.pm Do you get 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: Release date for mod_perl 2.0
Ask Bjoern Hansen wrote: On 17 Dec 2002, Devin Heitmueller wrote: [...] I'm in a difficult position because the project will be completed in a couple of months. If the consensus is that mod_perl 2.0 will be released by that point, then everything will be fine (I'll develop using the beta code). If it is still months from being stable enough for release, I will have to investigate alternatives. It will get stable faster if you choose to use it. :-) True, other than porting the remaining APIs, we need your bug reports so those ported can be fixed. Other than that perfork mpm is probably in a pretty good shape. Doug says that a few Covalent's clients use it in production for quite a while. Check whether you have all the APIs that you need available, and if so give it a stress test. You can use Apache::compat for those APIs that for some reason aren't there yet. See: http://perl.apache.org/docs/2.0/user/compat/compat.html p.s. when you test, please use the cvs mod_perl version. We plan to make a new beta release soon, since many things were fixed/added since the last release. __ 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 troubles with RedHat 8.0 and Perl 5.8.0
iansmith wrote: I have compiled apache_1.3.27 with mod_perl-1.27 and got no errors. I have mod_perl as a shared module. I can run Apache without mod_perl fine, but when I activate the mod_perl module, it gives me this in error_log for every connection and fails to deliver any pages at all. [notice] child pid 27049 exit signal Segmentation fault (11) My perl is: This is perl, v5.8.0 built for i386-linux-thread-multi I looked over the mod_perl documentation, but can't seem to find anything that says what works and what does not. Do I need to compile a non-threaded version of Perl? Certainly Aaron's solution should work, but it'd be nice to figure out the cause of segfaults, because a threaded 5.8 perl works just fine with mod_perl for me (Mandrake 9.0). Though I built it by myself, I should try using the Perl supplied by Mandrake. Before you rebuild it, if you can get the segfault backtrace, that would be great. If you don't know how, check: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems __ 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
What's On-topic and what's Off-topic on this list
I've the feeling that many subscribers are quite confused about the on-topic/off-topic policy on this list. In general, we try to keep threads mod_perl-centric. Because when the list starts to be dumping grounds for other related things, with a side effect of surging the list's traffic, those who were interested in pure mod_perl discussions, simply leave. And among those who leave we lose current or potential contributors. It's extremely hard to tell what's on-topic and what's not, because mod_perl programmers touch an enourmous amount of areas at their work. And sometimes this list is the only place where you can get an advice on certain topics, which happen to be related to mod_perl. But... my rule of thumb of deciding what's off-topic is very simple: think whether there is another good place to discuss a question in hand. May be an example will help to explain that approach. If somebody asks a beginners question on perl; usually how to write their code better, or why some code doesn't work, you have to agree that there are plenty other forums where this can be discussed (e.g. perlmonks.org). Now, when somebody asks about a proper way to generate unique hardly guessable session keys, that's a grey zone; on one side this is not a mod_perl specific question, on the other side it is, because under mod_perl you can take a benefit of process persistance and the way your keys are generated are a bit different. If you ask about performance improvement, this is kind of questions that are always welcome here, because I doubt there is any other forum where there are as many experts in performance as in the mod_perl community. But again, this is a grey zone. Obviously when something doesn't work under mod_perl, but works under mod_cgi, this is a very ontopic question. So, the next time you are about to ask a question which is not clearly on topic, first think whether you can get your answers elsewhere. If you don't where to ask, and you have browsed the help docs, ask about the right resource (just like Jeff did). If you have failed to find an answer elsewhere, after truly looking for it, I guess it's fine to ask here as a last resort, explaining your situation. But some people dare to post a statement: I know that you can answer my question, so I'm asking it here. That's ugly. I feel that we need to add some sort of explanation of the on/off-topic posts issue to http://perl.apache.org/maillist/email-etiquette.html. Perhaps somebody who's writing is better than mine can contribute that. I feel that I brag too much around and people lose the point. So if somebody can write a clear, concise version of my bragging, or even better your own thoughts, please do that. Finally, it's everybody's list. If you don't like the way things are, change them. But please don't complain if you do nothing to help others (that's unrelated to your post, Jeff :). __ 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: Perl Cookbook modperl chapter
Hill, Ronald wrote: -Original Message- Grant McLean wrote: Nathan Torkington wrote: Current recipe list: [gnat:~] grep head1 Ora/pcb2/ch21.pod =head1 Introduction =head1 Authenticating in mod_perl =head1 Setting Cookies in mod_perl =head1 Accessing Cookie Values from mod_perl =head1 Redirecting the Browser from mod_perl =head1 Interrogating Headers in mod_perl Handlers =head1 Accessing Form Parameters from mod_perl =head1 Receiving Uploaded Files in mod_perl Database persistence is an important topic but it's hard to say whether one directive ... PerlModule Apache::DBI ... constitutes a 'recipe' I agree that database persistence is an important topic and should be included in the perl Cookbook. However, Apache::DBI is not always the answer. Example: I currently have a need to use database persistence for an Ingres Database. So I installed the DBD::Ingres Module and attempted to use Apache::DBI. Needless to asy it did not work :-( After much searching/posting I got my answer. Henrik Tougaard wrote: (from comp.databases.ingres) I wouldn't bet on Apache::DBi working with DBD::Ingres! Reason: cached statementhandles are not implemented (currently) in DBD::Ingres and Apache::DBI uses them. (It's on my todo list, but not scheduled right now - i seem to have run out of tuits). I assume that the only way of getting permanent connections is to have another process hold them for you - but the hassle of accessing the connections would be so great, that it might be just as easy to avoid CGI entirely and go straight for mod_perl. OK, so now what? This type of situation could be discussed then talk about the Apache::DBI module. It's much simpler than that. You need two sentences: 1) under mod_perl, globals remember their values from the previous request, so you can cache the connection with: $dbh ||= myconnect(); 2) If you rdbms supports cached statement handles (which most do), you can use Apache::DBI which caches database connection without needing to change any of your code. But of course I agree that it's a good idea to mention this topic. I suggest that many other topics are to be mentioned but replace discussions with pointers to the relevant chapters of the mod_perl books and online documentation. So newbies, know what to look for. It's not obvious that database connections can be cached. __ 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
When perl is not quite fast enough
While reading Mark Fowler excelent Perl Advent Calendar (http://www.perladvent.org/2002/) 6th entry: http://www.perladvent.org/2002/6th/, in the references section I've noticed a link to Nicolas Clark's notes from his YAPC::EU::2002 presentation, on how to make your perl code faster: http://www.ccl4.org/~nick/P/Fast_Enough/ It's a very good read, and very relevant to us mod_perl users, who always want to have their code run faster. I especially liked it since it's very concise and gives you ideas of areas to explore. Certain things Nicolas talks about are already covered in detail in the mod_perl documentation. BTW, most other things mentioned in his notes are in the performance section of our upcoming mod_perl book (ora promises to get the book on the shelves in feb-mar next year). Me thinking to ask Nicolas to contribute these notes to our tutorial section (http://perl.apache.org/docs/tutorials/) and if possible to add some more meat to the original notes. If you remember our evil plan was to host at perl.apache.org interesting tutorials, relevant to mod_perl developers, but which are of interest to non-mod_perl developers too, thus bringing them to our site and hopefully getting them interested in mod_perl. Nicolas's doc, looks like a good bite ;) __ 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: Perl Cookbook modperl chapter
Gunther Birznieks wrote: Stas Bekman wrote: Hill, Ronald wrote: It's much simpler than that. You need two sentences: 1) under mod_perl, globals remember their values from the previous request, so you can cache the connection with: $dbh ||= myconnect(); But Apache::DBI implements pinging (immediate or timing based) which is much superior to this. Some databases drop connection otherwise. Or consider the case where the database goes down and then all the $dbh becomes invalid. Apache::DBI would recover gracefully I think. But the above method wouldn't. You are correct. 2) If you rdbms supports cached statement handles (which most do), you can use Apache::DBI which caches database connection without needing to change any of your code. I am not aware of Apache::DBI caching statement handles. Are you sure that Apache::DBI does this? Ah, sorry, wrong copy-n-paste. i wanted to say connection. Thanks for correcting me! Or is it a side effect of caching the database handle. If it is the latter, then then caching with #1 above would not solve the problem. If it is the former, perhaps someone can add a global setup variable to Apache::DBI to turn this feature off. eg $Apache::DBI::statement_handle_caching = 0; # default = 1 __ 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
We need help from mod_perl users with technical expertise in non-mainstreamOSs
Here at the list we have a rather sucky trend in the last year or so. Those folks who report problems that they have on platforms that aren't *BSD, Linux and Win32 mostly get unasnwered. Doug, who seems to know about everything, used to respond to those souls, but nowadays he's too busy with real work. We have plenty of folks who are kind enough to help others with Linux, BSD flavors and Win32. So we are all dandy on these platforms. So, my big request is to all the folks on the other platforms, whose users don't get their problems resolved here. If somebody posts a problem that happens on the platform that you use, please try to help that person, even if you don't consider yourself an expert. Many times a participation in the person's quest helps him to find the way on its own. What bugs most people is the silence. Also if you know somebody who may know the answer but not on the list, please take the initiative and try to kindly ask that person to help. And who knows may be he will enjoy to help and do that in the future as well. Please, stop lurking in the shades, but try to help when you see that nobody else does. Especially if you were helped here before. Remember that you have to give back, if everybody becomes a leech there will be no blood left. Also remember that helping others is addictive, you just need to start doing that. Also remember that we all do mistakes. And we aren't experts in all fields. So if your answer is incorrect, it's not a big problem, since surprisingly, someone, who ignores the original question in first place, immediately posts to correct you. Don't feel bad about that, since you've just learned something. On the opposite feel good about your follow-up, because you tried to help. So, if my rant wakes anybody out there on SunOS, can you please try to figure out what the problem is with Kenny Smith's report: http://mathforum.org/epigone/modperl/sleikrigroo There are many earlier questions that went unanswered, just go to http://mathforum.org/epigone/modperl and see which posts have no followup, and try to help. It's better late, then never. __ 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
cvs commit: modperl-2.0/t/response/TestCompat request_body.pm
stas2002/12/15 00:30:40
Modified:.Changes
lib/Apache compat.pm
t/conf modperl_extra.pl
t/compat request_body.t
t/response/TestCompat request_body.pm
Log:
fix the method content() in Apache::compat to read a whole request
body. same for ModPerl::Test::read_post. add tests.
Revision ChangesPath
1.84 +3 -0 modperl-2.0/Changes
Index: Changes
===
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.83
retrieving revision 1.84
diff -u -r1.83 -r1.84
--- Changes 15 Dec 2002 07:43:40 - 1.83
+++ Changes 15 Dec 2002 08:30:39 - 1.84
@@ -10,6 +10,9 @@
=item 1.99_08-dev
+fix the method content() in Apache::compat to read a whole request
+body. same for ModPerl::Test::read_post. add tests. [Stas]
+
Adjust the reverse filter test to work on win32 (remove trailing \r)
[Randy Kobes [EMAIL PROTECTED]]
1.75 +11 -7 modperl-2.0/lib/Apache/compat.pm
Index: compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.74
retrieving revision 1.75
diff -u -r1.74 -r1.75
--- compat.pm 6 Dec 2002 13:09:15 - 1.74
+++ compat.pm 15 Dec 2002 08:30:40 - 1.75
@@ -241,6 +241,8 @@
return $r-parse_args($args);
}
+use constant IOBUFSIZE = 8192;
+
sub content {
my $r = shift;
@@ -248,13 +250,17 @@
return undef unless $r-should_client_block;
-my $len = $r-headers_in-get('content-length');
-
+my $data = '';
my $buf;
-$r-get_client_block($buf, $len);
+while (my $read_len = $r-get_client_block($buf, IOBUFSIZE)) {
+if ($read_len == -1) {
+die some error while reading with get_client_block;
+}
+$data .= $buf;
+}
-return $buf unless wantarray;
-return $r-parse_args($buf)
+return $data unless wantarray;
+return $r-parse_args($data);
}
sub clear_rgy_endav {
@@ -316,8 +322,6 @@
$r-read($line, $r-headers_in-get('Content-length'));
$line ? $line : undef;
}
-
-use constant IOBUFSIZE = 8192;
#XXX: howto convert PerlIO to apr_file_t
#so we can use the real ap_send_fd function
1.21 +10 -4 modperl-2.0/t/conf/modperl_extra.pl
Index: modperl_extra.pl
===
RCS file: /home/cvs/modperl-2.0/t/conf/modperl_extra.pl,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- modperl_extra.pl 7 Oct 2002 02:35:18 - 1.20
+++ modperl_extra.pl 15 Dec 2002 08:30:40 - 1.21
@@ -47,6 +47,8 @@
$server-log-info(base server + $vhosts vhosts ready to run tests);
}
+use constant IOBUFSIZE = 8192;
+
sub ModPerl::Test::read_post {
my $r = shift;
@@ -54,12 +56,16 @@
return undef unless $r-should_client_block;
-my $len = $r-headers_in-get('content-length');
-
+my $data = '';
my $buf;
-$r-get_client_block($buf, $len);
+while (my $read_len = $r-get_client_block($buf, IOBUFSIZE)) {
+if ($read_len == -1) {
+die some error while reading with get_client_block;
+}
+$data .= $buf;
+}
-return $buf;
+return $data;
}
sub ModPerl::Test::add_config {
1.2 +30 -16modperl-2.0/t/compat/request_body.t
Index: request_body.t
===
RCS file: /home/cvs/modperl-2.0/t/compat/request_body.t,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- request_body.t15 Aug 2002 09:35:11 - 1.1
+++ request_body.t15 Dec 2002 08:30:40 - 1.2
@@ -6,7 +6,7 @@
use Apache::TestUtil;
use Apache::TestRequest;
-plan tests = 3;
+plan tests = 5;
my $location = /TestCompat::request_body;
@@ -41,6 +41,35 @@
);
}
+# encoding/decoding
+{
+my %data = (
+test = 'decoding',
+body = '%DC%DC+%EC%2E+%D6%D6+%D6%2F',
+);
+ok t_cmp(
+$data{body},
+GET_BODY(query(%data)),
+q{decoding}
+ );
+}
+
+
+# big POST
+{
+my %data = (
+test = 'big_input',
+body = ('x' x 819_235),
+ );
+my $content = join '=', %data;
+ok t_cmp(
+length($data{body}),
+POST_BODY($location, content = $content),
+q{big POST}
+ );
+}
+
+
### helper subs ###
sub query {
@@ -48,18 +77,3 @@
$location? . join '', map { $_=$args{$_} } keys %args;
}
-# accepts multiline var where, the lines
cvs commit: modperl-2.0/xs/APR/APR Makefile.PL
stas2002/12/15 00:49:24
Modified:xs/APR/APR Makefile.PL
Log:
s/qx/qq/; need to build the string not to run it
Revision ChangesPath
1.7 +2 -1 modperl-2.0/xs/APR/APR/Makefile.PL
Index: Makefile.PL
===
RCS file: /home/cvs/modperl-2.0/xs/APR/APR/Makefile.PL,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- Makefile.PL 28 Nov 2002 08:43:33 - 1.6
+++ Makefile.PL 15 Dec 2002 08:49:24 - 1.7
@@ -6,8 +6,9 @@
# XXX: this works only with libapr 0.9.2+ (not on win32)
my @libs = grep $_, map { -x $_ qx{$_ --link-ld} }
-map { qx{$prefix/bin/$_-config} } qw(apr apu);
+map { qq{$prefix/bin/$_-config} } qw(apr apu);
chomp @libs;
+
my $define = @libs ? '-DMP_HAVE_APR_LIBS' : '';
ModPerl::MM::WriteMakefile(
Re: mod_perl 2.0 trouble compiling = cannont find -lapr -laprutil
So, I have updated my src of apache, arp and mod_perl2 from cvs. Still the exact same result. I've messed up while adjusting for the new libapr's naming. it's fixed now in cvs. Though you shouldn't have had a problem in first place. it'd have just skipped linking to the apr libs and shouldn't have caused a problem. In any case. Please update your cvs version and try again. If you fail, please check that you build against the new versions that you have installed. that's make sure that you've deleted all the old installs, if they are no longer needed. If you still fail, post a complete report as explained here: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems __ 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: Problems with Apache::compat and german special chars
[perl.apache.org keeps on timing out once in a while :( reposting]
Tom Schindl wrote:
Problems with Apache::compat
CGI-PARAM-STRING: header=%DC%DC%DC%DCbody=%D6%D6%D6%D6type=save_thread
cut--
[Sun Dec 08 21:39:09 2002] [error] [client 127.0.0.1] Character in c
format wrapped at
/usr/bestsolution/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache2/Apache/compat.pm
line 217.
, referer: http://localhost/discussion-board
cut--
When I copy the lines of interest into a small perl program and execute
it, everything works perfectly. What's going wrong there?
cut--
map { s/%([0-9a-fA-F]{2})/pack(c,hex($1))/ge; $_; } split /[=;]/,
$string, -1
cut--
Doug has fixed this already in the cvs version of mod_perl. Ditto for the
s/+/ / transform:
revision 1.71
date: 2002/11/23 22:35:06; author: dougm; state: Exp; lines: +2 -0
PR:
Obtained from:
Submitted by: Walery Studennikov [EMAIL PROTECTED]
Reviewed by: dougm
tr/+/ /; in parse_args compat method
revision 1.70
date: 2002/10/21 20:21:34; author: dougm; state: Exp; lines: +1 -1
PR:
Obtained from:
Submitted by: Walery Studennikov [EMAIL PROTECTED]
Reviewed by:dougm
fix parse_args compat method to support non-ascii characters
The problem was that the buggy code was doing pack(c, $num) which
expects a
number in range -128..127, whereas a fixed version does pack(C, $num),
which works with 0..255.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [mp2] Byterange requests
Nathan Byrd wrote: Hi all, I'm currently attempting to upgrade Apache::PAR to work with mod_perl 2, and one of the issues I am running into is with byterange requests: With mod_perl 1.x, it was possible (using Apache::File) to use byteranges with requests using $r-each_byterange and $r-set_byterange (a good example is in the mod_perl Developer's Cookbook, section 6.7, Byteserving and Range Requests.) It appears that with Apache2/mod_perl2 ap_each_byterange and ap_set_byterange are no longer available, replaced instead by a protocol filter in Apache. The only documentation for Apache I could find regarding this is at http://httpd.apache.org/docs-2.0/developer/filters.html - in that document, it explains that Byterange: We have coded it to be inserted for all requests, and it is removed if not used. Does anyone know if the above statement includes mod_perl requests, or is there another workaround to send byterange responses with mod_perl modules? I suppose it could be implemented in the module itself (or as a patch to mod_perl, maybe in Apache::Response), but I don't want to attempt that if the byterange filter could be run anyway for a request. I've read the ap_byterange_filter() code (modules/http/http_protocol.c) and it has all the bytecode functionality in that function, plus a helper ap_set_byterange, which is private to that filter, so it can't be used by mod_perl. If I understand correctly the benefits of slicing the response in the response handler is good if it somehow saves memory/CPU cycles. Otherwise byterange_filter will do that work for you. It looks like implementing this functionality as a third party module is a good idea. Mostly likely you can simply rip off the code from ap_byterange_filter, making it more modular and then adding the XS to have the perl api. Or you can write the whole thing in perl. I think all the ingredients are readily available. __ 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
cvs commit: modperl-2.0 Makefile.PL Changes
stas2002/12/14 20:03:43
Modified:.Makefile.PL Changes
Log:
Strongly suggest win32 users to upgrade to 5.8.0, if they run 5.6.x
Submitted by: Randy Kobes [EMAIL PROTECTED]
Reviewed by: stas
Revision ChangesPath
1.88 +7 -2 modperl-2.0/Makefile.PL
Index: Makefile.PL
===
RCS file: /home/cvs/modperl-2.0/Makefile.PL,v
retrieving revision 1.87
retrieving revision 1.88
diff -u -r1.87 -r1.88
--- Makefile.PL 29 Jun 2002 19:44:04 - 1.87
+++ Makefile.PL 15 Dec 2002 04:03:43 - 1.88
@@ -298,13 +298,18 @@
sub perl_version_check {
if ($] 5.006_001) {
error You are running Perl version 5.6.0\n .
- We strongly suggest you upgrade to at least 5.6.1;
+We strongly suggest you upgrade to at least 5.6.1;
}
if ($] = 5.007 and $] 5.008) {
error 5.7.x development versions of Perl are no longer supported\n .
- Upgrade to 5.8.0 or higher;
+Upgrade to 5.8.0 or higher;
exit 1;
+}
+
+if (WIN32 and $] 5.008) {
+error You are running a Perl version 5.6.x\n .
+We strongly suggest you upgrade to 5.8\n;
}
}
1.82 +3 -0 modperl-2.0/Changes
Index: Changes
===
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.81
retrieving revision 1.82
diff -u -r1.81 -r1.82
--- Changes 14 Dec 2002 17:29:34 - 1.81
+++ Changes 15 Dec 2002 04:03:43 - 1.82
@@ -10,6 +10,9 @@
=item 1.99_08-dev
+Strongly suggest win32 users to upgrade to 5.8.0, if they run 5.6.x
+[Randy Kobes [EMAIL PROTECTED]]
+
When installing the mod_perl shared object, first need to check
whether the directory 'modules' already exists, and create it if not.
[Randy Kobes [EMAIL PROTECTED]]
cvs commit: modperl-2.0 Changes
stas2002/12/14 23:43:40 Modified:t/filter reverse.t .Changes Log: Adjust the reverse filter test to work on win32 (remove trailing \r) Submitted by: Randy Kobes [EMAIL PROTECTED] Reviewed by: stas Revision ChangesPath 1.4 +1 -0 modperl-2.0/t/filter/reverse.t Index: reverse.t === RCS file: /home/cvs/modperl-2.0/t/filter/reverse.t,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- reverse.t 25 Nov 2002 22:46:28 - 1.3 +++ reverse.t 15 Dec 2002 07:43:40 - 1.4 @@ -25,5 +25,6 @@ # test the filtering of the non-mod_perl response handler (file) my $location = '/filter/reverse.txt'; my $response = GET_BODY $location; +$response =~ s/\r//g; ok t_cmp($expected, $response, reverse filter); } 1.83 +3 -0 modperl-2.0/Changes Index: Changes === RCS file: /home/cvs/modperl-2.0/Changes,v retrieving revision 1.82 retrieving revision 1.83 diff -u -r1.82 -r1.83 --- Changes 15 Dec 2002 04:03:43 - 1.82 +++ Changes 15 Dec 2002 07:43:40 - 1.83 @@ -10,6 +10,9 @@ =item 1.99_08-dev +Adjust the reverse filter test to work on win32 (remove trailing \r) +[Randy Kobes [EMAIL PROTECTED]] + Strongly suggest win32 users to upgrade to 5.8.0, if they run 5.6.x [Randy Kobes [EMAIL PROTECTED]]
Re: [mp2] make install quirk
Randy Kobes wrote:
On Sat, 14 Dec 2002, Stas Bekman wrote:
[looks my original reply didn't make it through, trying again]
Beau E. Cox wrote:
Hi -
I am posting this message informally - this is not
critical (maybe not worth looking at); during
the mp2 make install, mod_perl.so is copied to the
apache2 tree (on my system) like this:
cp mod_perl.so /usr/local/apache2/modules
Now, if you haven't configured any apache2 modules
(as I haven't for my test server), the subdirectory
modules doesn't exist, so mod_perl.so is put into
the apache2 tree as _file_ 'modules' under
/usr/local/apache2. That's why I couldn't find it!
[...]
This is a known problem. I came up with this patch:
http://marc.theaimsgroup.com/?l=apache-modperl-devm=103847596809386w=2
But I'm afraid it's not portable and hence I couldn't commit it. Here is the
relevant snippet of the patch:
install:
+ test -d $(MODPERL_AP_LIBEXECDIR) || mkdir $(MODPERL_AP_LIBEXECDIR)
$(MODPERL_TEST_F) $(MODPERL_LIB_DSO) \
$(MODPERL_CP) $(MODPERL_LIB_DSO) $(MODPERL_AP_LIBEXECDIR)
Any portability gurus know how to make this Makefile's line (the one with +)
portable? I think 'mkdir' is portable. What about 'test -d'?
On Win32, at least, 'test' isn't available. What about something
like the following:
perl -e exit ! -d \$(MODPERL_AP_LIBEXECDIR)\ || mkdir $(...)
(the \ may be needed if the directory contains spaces, as Win32
might). And if one is worried about the system mkdir
availability, one can use
perl -MExtUtils::Command -e mkpath directory
randy++!
Please check that this work for you and I'll commit it (verified on linux).
You need to run a full build to check, unless you patch the Makefile manually.
I also see that my copy-n-paste has translated \t into spaces, so replace
those with tabs (between the + and $)
I've replaced \\ with qq{} because shells and quotes, even escaped ones are
a big trouble. At least your suggestion didn't work for me. qq{} works just fine.
Index: lib/Apache/Build.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/Build.pm,v
retrieving revision 1.108
diff -u -r1.108 Build.pm
--- lib/Apache/Build.pm 28 Nov 2002 16:31:36 - 1.108
+++ lib/Apache/Build.pm 14 Dec 2002 08:43:32 -
@@ -1057,6 +1057,9 @@
lib: $(MODPERL_LIB)
install:
+ $(MODPERL_PERLPATH) -e exit ! -d qq{$(MODPERL_AP_LIBEXECDIR)} || \
+ $(MODPERL_PERLPATH) -MExtUtils::Command \
+ -e mkpath $(MODPERL_AP_LIBEXECDIR)
$(MODPERL_TEST_F) $(MODPERL_LIB_DSO) \
$(MODPERL_CP) $(MODPERL_LIB_DSO) $(MODPERL_AP_LIBEXECDIR)
__
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 2.0 trouble compiling = cannont find -lapr -laprutil
D. Fairbanks wrote: [...] LD_RUN_PATH=/usr/lib gcc -shared -L/usr/local/lib APR.o -o ../../../blib/arch/Apache2/auto/APR/APR.so -L/usr/local/apache2/2.0.43/lib -lapr -laprutil /usr/bin/ld: cannot find -lapr collect2: ld returned 1 exit status make[3]: *** [../../../blib/arch/Apache2/auto/APR/APR.so] Error 1 [...] I've read the dialog between Benny Jensen and Stas Bekman from: [EMAIL PROTECTED]">http://mathforum.org/epigone/modperl/tendprerplu/[EMAIL PROTECTED] I've checked my Apache/Perl install three times against: http://perl.apache.org/docs/2.0/user/install/install.html#Condiguring_and_In stalling_Prerequisites And I've had an Apache Head check my installs, configs, versions, lib's processes. So far everything checks out fine. !?! But, mod-perl still won't compile and neither will apr-util. As repeated many times here, mod_perl builds on top of other components that just keep on changing (one of the reasons why a production mod_perl can't be released). So if you take a released version of mod_perl, it *will* build and work with the apr/apache released at about the same date. If you use any later releases/cvs of these components and a new version of mod_perl wasn't yet released, you *must* use the cvs version of mod_perl, as it adjusts on the go to the latest changes in the components it uses. In short, you need the latest mod_perl from cvs. http://perl.apache.org/docs/2.0/user/install/install.html#Installing_mod_perl_from_Source (scroll down to the CVS Bleeding-Edge Version) re: problems with building apr, email the apr list directly. ______ 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: Stupid newbie question: where is .?
Stephen Walton wrote: Please state [mp2] or something in the subject or at least in the message so we don't have to guess what version you are talking about. So, I'm using mod_perl as installed via RPMS on RedHat 8.0, and can't believe that an hour of hunting hasn't netted an answer to this apparently simple problem. Perl scripts seem not to have . set to ~user/public_html, as use() and require() fail on files which are in the same directory as the CGI script. What have I missed? The error message states that . is in @INC. To be specific, I've enabled mod_perl for ~user's files like this: Directory /home/user/public_html Options +Includes +ExecCGI AddHandler perl-script .pl PerlHandler ModPerl::Registry::handler PerlOptions +ParseHeaders /Directory Yes, ModPerl::Registry does *not* chdir to the script's dir in 2.0. Here is why: http://perl.apache.org/docs/2.0/user/coding/coding.html#Threads_Coding_Issues_under_mod_perl Various workarounds were discussed, but none were implemented so far. By the time mod_perl 2.0 is released we should sort it out. For now use mod_perl 1.0 if that's an issue to you. Of course you are more than welcome to sort this problem out and submit a patch for 2.0. __ 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: [mp2] make install quirk
[looks my original reply didn't make it through, trying again] Beau E. Cox wrote: Hi - I am posting this message informally - this is not critical (maybe not worth looking at); during the mp2 make install, mod_perl.so is copied to the apache2 tree (on my system) like this: cp mod_perl.so /usr/local/apache2/modules Now, if you haven't configured any apache2 modules (as I haven't for my test server), the subdirectory modules doesn't exist, so mod_perl.so is put into the apache2 tree as _file_ 'modules' under /usr/local/apache2. That's why I couldn't find it! [...] This is a known problem. I came up with this patch: http://marc.theaimsgroup.com/?l=apache-modperl-devm=103847596809386w=2 But I'm afraid it's not portable and hence I couldn't commit it. Here is the relevant snippet of the patch: install: + test -d $(MODPERL_AP_LIBEXECDIR) || mkdir $(MODPERL_AP_LIBEXECDIR) $(MODPERL_TEST_F) $(MODPERL_LIB_DSO) \ $(MODPERL_CP) $(MODPERL_LIB_DSO) $(MODPERL_AP_LIBEXECDIR) Any portability gurus know how to make this Makefile's line (the one with +) portable? I think 'mkdir' is portable. What about 'test -d'? __ 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
