Re: [mp2][QUESTION]: Filter to modify request headers on a proxy server
Pringle, Chris (HP-PSG) wrote:
Hi,
I've just tried that script again (see link below) using a POST request.
In the error log file, there is the content of the POST Request e.g.
user=cpringlepassword=x but nothing else. There is no HTTP headers.
My Apache directive to enable the filter is
PerlInputFilterHandler iPAQApache::ResetBrowser
Is this the correct directive?
The directive is correct, but you don't show your code and your config, so I
have no idea if the rest is correct or not. This directive is used to
configure both, connection and request level filters. It's the attribute of
the handler subroutine is what makes the difference and the placement in
httpd.conf.
You need to declare it as:
package iPAQApache::ResetBrowser;
use base qw(Apache::Filter);
sub handler : FilterConnectionHandler { your code is here }
1;
and you need to put it outside of Location or similar block in httpd.conf
just like shown at:
http://perl.apache.org/docs/2.0/user/handlers/filters.html#Connection_Input_Filters
Also make sure that you run at least mod_perl 1.99_09, or even better the
current cvs. And in the future please follow the info at
http://perl.apache.org/bugs/ so we know more about your setup.
__
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][QUESTION]: Filter to modify request headers on a proxy server
Pringle, Chris (HP-PSG) wrote:
Thanks for this. I had put 'PerlInputFilterHandler
iPAQApache::ResetBrowser' inside the proxy block, and it should have
been outside like you said.
So it did work this time, right? Perhaps we should issue a warning if a
connection filter is found insider Location or alike.
PerlInputFilterHandler iPAQApache::ResetBrowser
Is this the correct directive?
The directive is correct, but you don't show your code and your config,
so I
have no idea if the rest is correct or not. This directive is used to
configure both, connection and request level filters. It's the attribute
of
the handler subroutine is what makes the difference and the placement in
httpd.conf.
You need to declare it as:
package iPAQApache::ResetBrowser;
use base qw(Apache::Filter);
sub handler : FilterConnectionHandler { your code is here }
1;
and you need to put it outside of Location or similar block in
httpd.conf
just like shown at:
http://perl.apache.org/docs/2.0/user/handlers/filters.html#Connection_In
put_Filters
Also make sure that you run at least mod_perl 1.99_09, or even better
the
current cvs. And in the future please follow the info at
http://perl.apache.org/bugs/ so we know more about your setup.
__
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: Use of Apache::Directive in BEGIN block
Matisse Enzer wrote: Thank you very much. So does it work now? I had looked at http://perl.apache.org/docs/2.0/user/help/help.html, but did not see the instructions about running t/REPORT You mean, you missed it, since it's there: http://perl.apache.org/docs/2.0/user/help/help.html#Important_Information I will certainly use t/REPORT in the future until mp2bug is part of the distro. it's actually in the distro (outdated META tag), i just need to make it working before 'make install', as now it works only post 'make install'. Perhaps that instruction could be more, um, blatant? patches to improve things are always welcome. __ 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
[Fwd: Re: Perl 5.8.1 and mod_perl2 and FreeBSD]
FYI Original Message Date: Fri, 19 Sep 2003 10:44:13 +0800 From: Autrijus Tang [EMAIL PROTECTED] To: John Peacock [EMAIL PROTECTED] CC: Perl 5 Porters [EMAIL PROTECTED] ??, 2003-09-19 00:05, John Peacock What is the status of thread support on FreeBSD vis-a-vis Perl? There is some comment on the Installing mod_perl 2.0 web page that seems to suggest that the thread support by FreeBSD is unstable. Is that still true? Am I going to be sorry if I try this? My production servers runs with that exact setup (FreeBSD, maintperl, mod_perl2, svn, mason) without any problems. The trick is simple: do *not* use threads; build a non-threaded perl, and avoid using a threaded MPM. Thanks, /Autrijus/ signature.asc Description: PGP signature
Re: Use of Apache::Directive in BEGIN block
Matisse Enzer wrote:
At 11:19 AM -0700 9/19/03, Stas Bekman wrote:
Matisse Enzer wrote:
Thank you very much.
So does it work now?
I wasn't able to get 1.99_09 to install.
-8-- Start Bug Report 8--
1. Problem Description:
make install
for 1.99_09 failed with:
cp xs/modperl_xs_sv_convert.h xs/modperl_xs_typedefs.h xs/modperl_xs_util.h
cp: copying multiple files, but last argument `xs/modperl_xs_util.h' is
not a directory
Try `cp --help' for more information.
make: *** [modperl_xs_h_install] Error 1
[...]
2. Used Components and their Configuration:
*** using lib/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_COMPAT_1X = 1
MP_GENERATE_XS = 1
MP_LIBNAME = mod_perl
MP_USE_DSO = 1
MP_USE_STATIC = 1
Cool, MODPERL_AP_INCLUDEDIR in your top level Makefile is not set.
Can you please try with the cvs version first:
http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution
and if it still doesn't work, please try with this patch, which should go in
in any case:
Index: Makefile.PL
===
RCS file: /home/cvs/modperl-2.0/Makefile.PL,v
retrieving revision 1.124
diff -u -r1.124 Makefile.PL
--- Makefile.PL 26 Aug 2003 22:22:15 - 1.124
+++ Makefile.PL 19 Sep 2003 21:27:30 -
@@ -71,7 +71,7 @@
MODPERL_LIBMAKE= '$(MAKE) -f $(MODPERL_MAKEFILE)',
PERL = $build-perl_config('perlpath'),
MOD_INSTALL= ModPerl::BuildMM::mod_install(),
-MODPERL_AP_INCLUDEDIR = $build-apxs('-q' = 'INCLUDEDIR'),
+MODPERL_AP_INCLUDEDIR = $build-ap_includedir(),
MODPERL_XS_H_FILES = join( \\\n\t, @xs_h_files),
},
clean = {
__
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][QUESTION]: Filter to modify request headers on a proxy server
Pringle, Chris (HP-PSG) wrote: Hi, I am trying to write a filter that will sit on a proxy server and alter HTTP requests. Basically, what I want it to do is modify the User-Agent header field so that when the request is proxied, the remote web server gets a different User-Agent header field to the one that was originally sent by the browser. There are also other header fields I may need to modify, but I would imagine this is a simple task once I've worked out how to alter the User-Agent field. Does anyone have any ideas how I might go about doing this? I've tried writing several PerlInputFilterHandlers, all with no success. Will input filters work with a proxy? I've got output filters working with no problem. Any sample code to do what I want, along with the relavent Apache directives would be very much appreciated! The sample code that you need is here: http://perl.apache.org/docs/2.0/user/handlers/filters.html#Connection_Input_Filters I haven't tried to mix filters with proxy, but I see no reason why shouldn't it work. It might not work if proxy is implemented as a filter itself and is running before the modperl filters, need to look at the actual implementation. __ 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: Use of Apache::Directive in BEGIN block
Matisse Enzer wrote:
Using Apache/2.0.45 (Unix) mod_perl/1.99_08 Perl/v5.8.0
on a Redhat 87.0 system
I get the following error:
Can't locate object method lookup via package Apache::Directive at
/webcontent/dev.mycardmaker.com/lib/perl/Doodlelab/Apache/Test.pm line 4.
when I try to start Apache.
Here is the entire contents of Test.pm
BEGIN {
use Apache::Directive;
my $tree = Apache::Directive-conftree();
foreach my $node ( $tree-lookup('PerlSetVar') ) {
# I want to do something here.
}
}
1;
Matisse, your bug report is incomplete, you have missed the report about your
environment as explained at the guidelines (http://perl.apache.org/bugs/). In
the future please include it, it's probably unimportant for this case.
To address this issue upgrade to 1.99_09 or may be you even need the current
cvs, I don't remember when Philippe has fixed that, check the Changes file.
t/response/TestApache/conftree.pm does the testing of this feature and works
just fine in the current cvs.
__
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: Sleeping sessions
Ged Haywood wrote: [...] but at the moment all httpd session freezing in memory and turning to sleeping, 30-40 min and server is overloaded. You must send more information. Read the documentation on the mod_perl site to find out what you need to send. Ouch, that's a lot to read ;) It's better to point people to a simple: http://perl.apache.org/bugs/ 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: RTF/MSword Generation from PERL
Philip M. Gollucci wrote: Hi All, I have an online FAQ. Running under IIS 5.0/Win2k/PerlEx with ActiveState Perl 5.6.1 ... sorry can't run 5.8.0 yet The answers to the FAQ questions contain jpegs, bmps, and gifs Philip, frankly I fail to see anything in your request that has to do with modperl. There are many other appropriate places where you can ask this question. See: http://perl.apache.org/docs/offsite/other.html Let's keep the Signal to Noise ratio high on this list. Thank you. __ 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: [ANNOUNCE] Apache::IncludeHook
Geoffrey Young wrote: hi all... I wanted to let everyone know that I have ported !-- #perl -- SSI tag support to Apache 2.0. it should behave under both prefork and threaded mpms, and work pretty much the same as it did in Apache 1.3, despite the fact that mod_include is now an output filter. while the support is fairly complete, the code is a bit messy and can be refactored. however, I wanted to get something released for people to play with before I needed to move on to something else. geoff++ can you please update this page? http://perl.apache.org/products/apache-modules.html#Porting_CPAN_modules_to_mod_perl_2_0_Status 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 v2 Forking
Cameron B. Prince wrote:
I have a report generator program written in Perl that I need to start from
a CGI. The program takes about 15 minutes to run, so I must fork or double
fork. I have two goals:
1) Have no zombies when the program completes
2) Fork in such a way that restarting Apache doesn't kill the forked
process.
I tried out the code here which is for mod_perl v1:
http://perl.apache.org/docs/1.0/guide/performance.html#Forking_and_Executing
_Subprocesses_from_mod_perl
There are two problems with the code listed in the example:
1) Apache::SubProcess doesn't seem to contain the same methods as the older
version.
most of them aren't needed (they don't exist in the Apache 2.0 API.
2) open isn't working. (I've already been down this road and switched
another call to an external program to use IPC::Run, but that program
doesn't take long and needs no fork.)
what open()? what's not working? please be more specific, show us some code
and the actual error messages. Are you talking about open in
http://perl.apache.org/docs/1.0/guide/performance.html#A_Complete_Fork_Example
?
I took out the parts of the code that caused problems and ended up with
this:
$SIG{CHLD} = 'IGNORE';
defined (my $pid = fork) or die Cannot fork: $!\n;
unless ($pid) {
exec $command;
CORE::exit(0);
}
This works and accomplishes my first goal, but not the second. If I start
the program and restart Apache, the program is killed.
have you detached the session as explained here?
http://perl.apache.org/docs/1.0/guide/performance.html#Detaching_the_Forked_Process
I admit I haven't tried this code from the above url with 2.0 yet (and it'd be
nice to have such a test (hint! hint!)) but I can't see it in your sample, so
I assume that you haven't tried it ;)
Also while you are at it, once you figure out all the quirks if you can help
us porting
http://perl.apache.org/docs/1.0/guide/performance.html#Forking_and_Executing_Subprocesses_from_mod_perl
to 2.0 docs that would be very helpful for those coming after you. 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: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Steve Hay wrote: [...] Having a pointer to where the mod_perl.lib library was installed would be useful. I'm not sure calling it MODPERL_STATIC_LIB_LOCATION would be the best thing on Win32, as it's not a static library as such, but something could be come up with ... Well, if ModPerl::MM does the right thing, a developer will not even need to know where it is located. So probably leaving it as it's now is fine. The only misleading part is that MODPERL_LIB_LOCATION points to the build dir, so it should probably be renamed to reflect that. I'm not sure that's the *only* mis-leading part, but, as you say, if it all works then it shouldn't really matter too much. What other misleading parts are we talking about? The main thing is to get mod_perl.lib installed in the first place under mp1. I remember someone wanted to port ModPerl::MM to mp1, if that happens, than it'd become a non-issue as well ;) __ 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: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Steve Hay wrote: [...] What other misleading parts are we talking about? I'm just getting confused with changes in Apache itself, I think. Apache 1 used to have lib, libexec and modules: lib stored the static .lib's, libexec stored the import libraries for various dll's, and modules stored the .so (aka .dll) files for Apache modules. But with Apache 2, I have only lib and modules. The latter still (rightly) contains just the .so files for Apache modules, so presumably all the static *and* import libraries are thrown together into lib now? Now, my mp2's Apache::BuildConfig contains this: 'MODPERL_AP_LIBDIR' = 'C:\\apache2/lib', 'MODPERL_AP_LIBEXECDIR' = 'C:\\apache2/modules', which I find confusing. The first line there is fine, but the second line seems wrong. One would think that MODPERL_AP_LIBEXECDIR specifies where Apache's libexec directory is, but there isn't one any more! Furthermore, it seems that the files that would have been in it are now in lib? So maybe MODPERL_AP_LIBEXECDIR should say C:\\apache2/lib (that's an ugly mess of back- and forward slashes too), and that should be used as the location to install mod_perl.lib into (since mod_perl.lib is one of these import library things). That would be wrong as things stand, though, because MODPERL_AP_LIBEXECDIR seems to be used as the location to install mod_perl.so, which should indeed be C:\\apache2/modules. Perhaps the simplest thing would be to rename MODPERL_AP_LIBEXECDIR to MODPERL_AP_MODDIR since it specifies where Apache's modules directory is and there isn't a libexec anymore? It's the problem with apxs then, since mp2 just uses the same names as apxs: ~/httpd/prefork/bin/apxs -q LIBEXECDIR /home/stas/httpd/prefork/modules ~/httpd/prefork/bin/apxs -q LIBDIR /home/stas/httpd/prefork/lib I'm not sure if we want to contradict apxs on that. My suggestion is to remove the need for developers to know about those dirs/vars and have it all abstracted behind ModPerl::MM (which already does most of it). If it gets ported to mp1 and uses the same API then no matter what happens behind the scenes it'll do the right thing for the developer. __ 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
(please trim your followups!) Re: mod_perl v2 Forking
whoah! people, please trim the irrelevant stuff in your replies, this thread keeps on growing for no reason. Perhaps you should read http://perl.apache.org/maillist/email-etiquette.html#Extracts_From_Other_Posts if you are new to this list. We want these threads to be useful for those who will later read them in archives. Thank you! __ 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
[Fwd: mod_perl and PHP don't share the environment nicely]
' and 'envtest.c' to files on your machine. Run build
to make envtest. Run ulimit -c to see whether your process limits
are set to allow core dumps. Then run envtest, using the exact
inputs show below (print 1\nRETURNCTRL-Dprint 2\nRETURNCTRL-D).
#---
# BEGIN build
#---
#!/bin/sh
perl=perl
opts=$($perl -MExtUtils::Embed -e ccopts -e ldopts)
if [[ $perl = debugperl ]]
then
opts=$(echo $opts | sed 's/-lperl/-ldebugperl/')
fi
cmd=gcc -g -o envtest envtest.c -Wall $opts
echo $cmd; $cmd
#---
# END build
#---
/* BEGIN envtest.c */
#include stdlib.h
#include string.h
#include assert.h
#include EXTERN.h
#include perl.h
void run_perl(int argc, char *argv[], char **env, char *putenv_arg);
#define VAR1 VAR1=value
#define VAR2 VAR2=value
char *tmpptr = VAR2;
int main(int argc, char *argv[], char **env)
{
char *envptr = malloc(strlen(VAR1) + 1);
strcpy(envptr, VAR1);
/* call putenv with malloc'ed pointer */
run_perl(argc, argv, env, envptr);
/* call putenv with pointer from process's data segment */
run_perl(argc, argv, env, tmpptr);
free(envptr);
exit(0);
}
void run_perl(int argc, char *argv[], char **envptr, char *putenv_arg) {
PerlInterpreter *my_perl = perl_alloc();
perl_construct(my_perl);
PL_exit_flags |= PERL_EXIT_DESTRUCT_END;
perl_parse(my_perl, NULL, argc, argv, envptr);
if (putenv_arg)
assert(putenv(putenv_arg) == 0);
perl_run(my_perl);
perl_destruct(my_perl);
perl_free(my_perl);
}
/* END envtest.c */
$ ./build
gcc -g -o envtest envtest.c -Wall -rdynamic -L/usr/local/lib
/usr/lib/perl/5.8.0/auto/DynaLoader/DynaLoader.a -L/usr/lib/perl/5.8.0/CORE
-lperl -ldl -lm -lpthread -lc -lcrypt -D_REENTRANT -D_GNU_SOURCE -DDEBIAN
-fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/lib/perl/5.8.0/CORE
$ ./envtest
print 1\n -- press return, then ^D
1
print 2\n -- press return, then ^D
Segmentation fault (core dumped)
$ gdb -q envtest core
Core was generated by `./envtest'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libperl.so.5.8...done.
Loaded symbols for /usr/lib/libperl.so.5.8
Reading symbols from /usr/lib/debug/libdl.so.2...done.
Loaded symbols for /usr/lib/debug/libdl.so.2
Reading symbols from /usr/lib/debug/libm.so.6...done.
Loaded symbols for /usr/lib/debug/libm.so.6
Reading symbols from /usr/lib/debug/libpthread.so.0...done.
Loaded symbols for /usr/lib/debug/libpthread.so.0
Reading symbols from /usr/lib/debug/libc.so.6...done.
Loaded symbols for /usr/lib/debug/libc.so.6
Reading symbols from /usr/lib/debug/libcrypt.so.1...done.
Loaded symbols for /usr/lib/debug/libcrypt.so.1
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0 0x401ffeee in __libc_realloc (oldmem=0x804e730, bytes=160) at malloc.c:3408
3408 ar_ptr = arena_for_chunk(oldp);
(gdb) where
#0 0x401ffeee in __libc_realloc (oldmem=0x804e730, bytes=160) at malloc.c:3408
#1 0x401be753 in __add_to_environ (name=0xb5c0 VAR2, value=0x0,
combined=0x8048bf0 VAR2=value, replace=1) at
../sysdeps/generic/setenv.c:145
#2 0x401be686 in putenv (string=0x8048bf0 VAR2=value)
at ../sysdeps/generic/putenv.c:67
#3 0x08048ab7 in run_perl (argc=1, argv=0xb694, envptr=0xb69c,
putenv_arg=0x8048bf0 VAR2=value) at envtest.c:36
#4 0x08048a2f in main (argc=1, argv=0xb694, env=0xb69c) at
envtest.c:22
--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: ensuring singularity of users
Perrin Harkins wrote: On Tue, 2003-09-16 at 12:46, Zack Brown wrote: I'd like to implement something that tries to ensure that one user can't masquerade as multiple users. We talked quite a bit about preventing multiple logins recently. I think it was last week. Check the archives. Perhaps someone would like to summarize these and put a short tutorial on perl.apache.org? This question seems to come back pretty often. __ 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
DynDNS.org -- Press Releases -- Free DNS for the Perl Community
FYI: Free DNS for the Perl Community http://www.dyndns.org/news/releases/archives/2002/09/74.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: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Randy Kobes wrote:
On Fri, 12 Sep 2003, Steve Hay wrote:
Randy Kobes wrote:
[ .. ]
Here's a patch against the Apache-Dispatch Makefile.PL to
allow it to build on Win32
Your patch does the trick for me, except that I had to
rebuild mod_perl too.
The problem is that my installed mod_perl setup (Apache in
C:\apache, Perl in C:\perl5) didn't contain the
mod_perl.lib required. The MODPERL_LIB entry in
Apache::MyConfig said
C:/Temp/mod_perl-1.28/src/modules/win32/Release, which is,
of course, where it was when I was building mod_perl.
I believe that mod_perl 2 now installs the mod_perl.lib
somewhere to solve that kind of problem. Is there an
option in the mod_perl 1 build process to thave that
library installed, or could that be added to the next
release?
That's a good suggestion - you're right that mod_perl 2
installs the mod_perl.lib under the Apache2/ tree, and it
would make sense for mod_perl 1 to do the same, with
Apache::MyConfig adjusted to reflect that. I'll look into
putting together something to do that.
Does it? According to Apache::Build, it should be installed under the apache
tree's lib:
sub modperl_libs_MSWin32 {
my $self = shift;
# mod_perl.lib will be installed into MP_AP_PREFIX/lib
# for use by 3rd party xs modules
$self-{cwd}/src/modules/perl/$self-{MP_LIBNAME}.lib;
}
__
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: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Randy Kobes wrote: On Fri, 12 Sep 2003, Stas Bekman wrote: Steve Hay wrote: Stas Bekman wrote: Randy Kobes wrote: On Fri, 12 Sep 2003, Steve Hay wrote: I believe that mod_perl 2 now installs the mod_perl.lib somewhere to solve that kind of problem. Is there an option in the mod_perl 1 build process to thave that library installed, or could that be added to the next release? That's a good suggestion - you're right that mod_perl 2 installs the mod_perl.lib under the Apache2/ tree, and it would make sense for mod_perl 1 to do the same, with Apache::MyConfig adjusted to reflect that. I'll look into putting together something to do that. Does it? According to Apache::Build, it should be installed under the apache tree's lib: Yes, in my Apache2 setup (the one that I can't get working with Perl 5.8.1...) I have mod_perl.lib in C:\Apache2\lib. I didn't change any of the installation locations. I'd assumed that's what Randy meant, actually - Apache2/lib being under the Apache2/ tree :-) what is mod_perl.lib? a static library? (I guess an equivalent of mod_perl.lo on unix). We don't install it on unix yet, but I think that for consistency it should go to the same place where mod_perl.so is installed to. Which is under the Apache tree. This mod_perl.lib (on Win32) isn't a true static library, containing all the symbol definitions; from what I understand, it just contains the minimal information on symbols needed to allow the application it's being linked with to find the symbols in the dynamic library (in this case, mod_perl.so). I put it under Apache2/lib/ because that's where the Apache2 libs (eg, apr.lib, libapr.lib, mod_dav.lib) are placed. The dynamic libraries are placed either under Apache2/modules/, if it's a module (eg, mod_dav.so), or under Apache2/bin/, such as libapr.dll. Ah, so it's all cool. I have confused Apache2/ with perl's lib sub-directory. Having said that, the BuildConfig.pm doesn't actually seem to refer to the location that the library has been installed into -- like mp1, it refers to the location in which it was built! I have: 'MODPERL_LIB_LOCATION' = 'C:/Temp/modperl-2.0/src/modules/perl/mod_perl.lib', in BuildConfig.pm. Wouldn't it be better for that to be 'C:/Apache2/lib/mod_perl.lib'? Nope, it uses this attribute as a source dir in cp from to: $install .= 'EOI'; # install mod_perl.lib @$(MKPATH) $(MODPERL_AP_LIBDIR) $(MODPERL_TEST_F) $(MODPERL_LIB_LOCATION) \ $(MODPERL_CP) $(MODPERL_LIB_LOCATION) $(MODPERL_AP_LIBDIR) EOI And as you can see it should install the static lib under $(MODPERL_AP_LIBDIR) (which is under the apache tree) purhaps it should be fixed to have a more intuitive name then (s/MODPERL_LIB_LOCATION/MODPERL_LIB_SOURCE_LOCATION/?) or BUILD_LOCATION I'd suggest an even more intuitive: MODPERL_STATIC_LIB_BUILD_LOCATION, since it's a static lib. Purhaps adding a new var MODPERL_STATIC_LIB_LOCATION pointing to where the static lib was installed to will be useful. Having a pointer to where the mod_perl.lib library was installed would be useful. I'm not sure calling it MODPERL_STATIC_LIB_LOCATION would be the best thing on Win32, as it's not a static library as such, but something could be come up with ... Well, if ModPerl::MM does the right thing, a developer will not even need to know where it is located. So probably leaving it as it's now is fine. The only misleading part is that MODPERL_LIB_LOCATION points to the build dir, so it should probably be renamed to reflect that. __ 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: $| doesn't work after upgrade
Tommy Falgout wrote: [...] Here's the logistical info: perl -MCGI -e 'print $CGI::VERSION' -- 2.89 perl -v -- This is perl, v5.8.0 built for i386-linux-thread-multi (with 1 registered patch, see perl -V for more detail) Web Server: [EMAIL PROTECTED] bin]$ httpd -v Server version: Apache/2.0.43 Server built: Oct 11 2002 14:13:44 OS: RH9 Linux tatu 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386 GNU/Linux Brower: Tested with Mozilla 1.4 IE 5.50 Please resubmit the bug report, following the bug reporting guidelines http://perl.apache.org/bugs/ and to save ping-pong cycles, first upgrade to the latest mod_perl: http://perl.apache.org/download/index.html and try again. 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
new in Apache::Test: t/SMOKE -bug_mode
It all started when I have noticed a few core files after running t/SMOKE on modperl-2.0's top-level test suite. I couldn't figure out which test caused them. So I have decided to rewrite the smoker to provide me that information. In the future we might autoextract the backtrace as well. While working on it, I said, we also have a problem of mapping error_log errors to the tests that caused them. So I've added logic to extract only the relevant (added since the last successful test) part of error_log and access_log and print it out, in addition to the output of the client. This mode also turns the tracing level to -trace=debug, so if the test fails and there were any debug printings in the handlers they will be run as well. This should make bug reports much more useful. However it comes at a price of running much slower than the normal 'make test' would do, until Test::Harness::Straps won't provide the callbacks to be run after each test, eventually we might fold it back to 'make test'. but for now if your 'make test' fails, run 't/SMOKE -bug_report'. Of course the normal t/SMOKE run now reports core files as well, as soon as they happen. You will need to update the current modperl-2.0 cvs to get this functionality. Please report any problems that you may have noticed. So here is how the new log will look: /home/stas/apache.org/portland3 t/SMOKE -bug_mode running t/TEST in the bug report mode apache/add_configok apache/cgihandlerok apache/conftree..ok apache/constants.ok apache/cookieFAILED *** run log *** *** setting ulimit to allow core files ulimit -c unlimited; ./TEST -verbose -run 'apache/cookie.t' apache/cookie1..2 # Running under perl version 5.008001 for linux # Current time local: Thu Sep 11 18:45:28 2003 # Current time GMT: Fri Sep 12 01:45:28 2003 # Using Test.pm version 1.24 request has failed (the response code was: 500) see t/logs/error_log for more details dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 1-2 Failed 2/2 tests, 0.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- apache/cookie.t 255 65280 24 200.00% 1-2 !!! error running tests (please examine t/logs/error_log) *** /home/stas/apache.org/portland3/t/logs/error_log *** [Thu Sep 11 18:45:28 2003] [error] [client 127.0.0.1] I shouldn't get the cookie at /home/stas/apache.org/portland3/t/response/TestApache/cookie.pm line 16. *** /home/stas/apache.org/portland3/t/logs/access_log *** 127.0.0.1 - - [11/Sep/2003:18:45:28 -0700] GET /TestApache__cookie?header HTTP/1.0 500 536 apache/cookie2...ok apache/post..ok apache/read..FAILED *** run log *** *** setting ulimit to allow core files ulimit -c unlimited; ./TEST -verbose -run 'apache/read.t' apache/readBareword asdfag not allowed while strict subs in use at apache/read.t line 18. Execution of apache/read.t aborted due to compilation errors. dubious Test returned status 255 (wstat 65280, 0xff00) !!! error running tests (please examine t/logs/error_log) apache/scanhdrs..ok apache/scanhdrs2.ok apache/send_cgi_header...ok apache/subprocessok apache/write.FAILED *** run log *** *** setting ulimit to allow core files ulimit -c unlimited; ./TEST -verbose -run 'apache/write.t' apache/writerequest has failed (the response code was: 500) see t/logs/error_log for more details dubious Test returned status 255 (wstat 65280, 0xff00) !!! error running tests (please examine t/logs/error_log) !!! oh nuts, server dumped core !!! for stacktrace, run: gdb /home/stas/httpd/prefork/bin/httpd -core /home/stas/apache.org/portland3/t/core.7604 *** /home/stas/apache.org/portland3/t/logs/error_log *** [Thu Sep 11 18:46:03 2003] [notice] child pid 7604 exit signal Aborted (6), possible coredump in /home/stas/apache.org/portland3/t api/access...ok api/aplogok api/conn_rec.ok api/lookup_uri...ok api/lookup_uri2..ok api/module...ok api/r_subclass...ok api/request_rec..ok api/response.ok api/rflush...ok api/rutil
Re: porting from mod_perl1 to mod_perl2
I think I got your problem solved, you need to: - print $q-header(); + print $q-header(text/html; charset=utf-8); __ 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: Help: Can't coerce GLOB to string...
[Forwarded from [EMAIL PROTECTED] [EMAIL PROTECTED]]
Hello,
In response to :
Kurt George Gjerde wrote:
BTW: I've fixed my can't coerce GLOB to string problem I had last
week.
Was unrelated to mod_perl (sorry). It seems XML::LibXSLT produced some
errors which went straight to STDERR. Under CGI these ends up in the
error_log but under mod_perl it seems STDERR is just a black hole (?).
Would it be possible to map STDERR to log_error()?
Unless I'm missing something, mod_perl doesn't do anything special with
STDERR
(it does tie STDIN and STDOUT for 'perl-script' handlers). Apache opens
stderr
to error_log, and then everything just works. e.g. if you do:
warn Foo;
or
print STDERR OOOPS\n;
this ends up in error_log, no?
I suppose that XML::LibXSLT redefines STDERR then. Try to see what it
does to
create this problem.
The key to this problem is that the function $parser-parse_string()
cannot take a scalar as argument.
This way it works and doesn't produce Can't coerce ... anymore :
my $sheet = $parser-parse_string('EOT');
?xml version=1.0?
xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
version=1.0
xsl:output method=text indent=no/
xsl:strip-space elements=FILTER_RULE NAT_RULE LOG_RULE/
!-- this XSLT sheet transforms a netfilter XML rule document into an
iptables script --
xsl:template match=NETFILTER
...
EOT
Best regards
Jean Philippe GUILLEMIN
http://shweps.free.fr
[EMAIL PROTECTED]
Re: CPAN module Apache::Emulator
Adam Kennedy wrote: Interesting idea, and I'm fine with it, although I dislike ApacheEmu. Despite being longer, surely it would fit somewhere like Emulate::Apache::XX. That's fine too. I just thought of a namespace starting with ApacheXXX:: so it'll be placed next to Apache:: in the global list of modules... __ 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: porting from mod_perl1 to mod_perl2
Bart Terryn wrote: Stas and all of the others, Stas said: I think I got your problem solved, you need to: - print $q-header(); + print $q-header(text/html; charset=utf-8); Well actually you did not. Probably you looked a bit too fast. (forgivable in view of the numbers of mails you reply to:-) Actually I haven't looked, I have tested with your code. Before setting the header I wasn't getting the unicode chars you put in the form back in the dump. After setting the header it did print out exacly the same unicode character. I didn't have a chance to mess with the hex representations yet. [...] (Oh did I mention already that I have tested only against IE6, because the browser could be the cause as well of this odd(?) behaviour.) I think this is where the weak point is. You need to compare characters on the server side, not trying to rely on the browser, which as you have seen will render them improperly if you didn't set the right header. You have two things happening: read input, send output. The problem can be in any of the two and worse, it can be in both and the error can fix itself when doubled. You need to verify first that the input is read properly, then the same for the output. I have started writing the test for mp2 to verify utf8 input, hopefully I'll finish it soon. __ 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: problem with RPM instalation of Apache and Mod_perl on RedHat and Mason
parvez mohamed wrote: I have RedHat 9, I have installed Apache using rpm wich comes with RedHat9 (httpd-2.0.40-21) then i haveinstalled mod_perl using rpm mod_perl-1.99_07-5 I don't know what version HTML::Mason is relying on (I'll let the mason developers to comment on it), but you probably want to use the latest released mod_perl 1.99_09 and apache 2.0.47 before you start reporting problems which were fixed alredy. You can find rawhide rpm versions of those on rpmfind.net. __ 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: Sending a different protocol header
Geoffrey Young wrote: Perrin Harkins wrote: On Mon, 2003-09-08 at 13:12, Geoffrey Young wrote: actually, the assbackwards slot of the request record is there to indicate that the incoming request used HTTP/0.9, which defines only GET and where no headers are expected in the response. Clearly this works, but wouldn't it be better to implement a protocol handler for IceCast instead? Or is that just overkill for this? [...] but yes, hans, for the record Apache 2.0 and mod_perl 2.0 both support the idea of protocol handlers, if you're interested. see http://perl.apache.org/docs/2.0/user/handlers/protocols.html And an example of how to extend HTTP protocol, without inventing a new one (this example extends HTTP to support invented by me EMAIL protocol): http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlHeaderParserHandler __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Content encoding when filtering proxyed pages
Esteban Fernandez Stafford wrote:
Hello all,
I have a machine acting as a proxy using mod_perl-1.99_09 with apache
2.0.46. This proxy is supposed to filter all html content. So far I
have achieved most of my project's goals. But there is one issue I
can't get straight, this is when the proxy gets a page that is
encoded (like in www.google.com). My first attempt was to DECLINE
filtering such pages, but the $filter-r()-content_encoding() always
gives me 'undef'. Is this something that is not yet implemented or am
I doing something wrong? (See code below) Then I tried looking at
$filter-r()-headers_out()-{'Content-Encoding'} and everything went
just fine!
Looks like it's autogenerated, but probably not working, as I see that the
corresponding call in the test is commented out:
t/response/TestAPI/request_rec.pm:#content_encoding
Need to check why is it so.
On the other hand, is it possible that I could put mod_deflate before
my filter to get the content already decompressed for my filter to
parse?
Sure, you can do that. the mp2 test suite has examples of how to do that
(besides the normal apache docs).
Thanks a lot in advance
I would like to thank the mod_perl community for mod_perl, it has made
the development of this project fun! And it has kept me from having to
go back to C programming. It was a long time since I last did that.
thanks for the kind words ;)
__
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: CPAN module Apache::Emulator
Adam Kennedy wrote: For those interested, I've been doing a general clean up of the code ( shrinking the code size down mainly ), prior to starting further work on it. Code available on request. My intentions is to keep it as light as possible. While Apache::Fake seems to be able to do a very large amount of things, including reading Apache config files by the look of it, I'll be trying to keep this to some minimum set of features. Enough to provide all the standard functionality, but not to do any fancy tricks. One of the ideas was to have a more intuitive namespace for Apache emulators. The suggestion was to introduce a new namespace ApacheEmu:: or similar. So yours will be ApacheEmu::Request and David's Apache::Table emulator, will be ApacheEmu::Table, etc. The logic is that all these modules do not require Apache to run and therefore shouldn't be in the Apache:: namespace. Adam Nigel Wetters wrote: David Wheeler [EMAIL PROTECTED] 09/03/03 05:46am May I suggest that you post a note to the modperl list announcing Apache::Emulator. I think that the folks there might be interested in your work. A couple of years ago, I produced a module that emulated a few of the Apache::Request methods from a CGI environment. The only reason for doing this was that I was writing an adserver (boo hiss) that I wanted to run on both Apache and Netscape webservers, but didn't want to write code in CGI. I released the code to CPAN as Apache::Emulator within a rarely used Adserver distribution. My code wasn't complete, or by any means pleasant, but, I guess it was a good idea because Jorg Walter finished off the job with his excellent, and comprehensive Apache::Fake distrubution. Recently, Adam Kennedy has expressed an interest in adding a few methods to Apache::Emulator, and I dusted off the distribution for him (separating the code from the Adserver I'd written). I think he would like to have Apache::Emulator be a slimmed down version of Apache::Fake, keeping only the most popular features. I'm glad that somepone has taken an interest. I think this repackaging is what raised the interest of a few mod_perl developers. However, at the moment, there is nothing new here. Nigel [EMAIL PROTECTED] -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: apache2, mod_perl: problem with CGI
Philip M. Gollucci wrote:
Stas Wrote:
I believe it's not the problem Bart was talking about. You are most
likely talking about Apache-request failing, which is how it should be
if the GlobalRequest option is not set. Bart's problem was finding
the request method.
If you'll read carefully, you'll see that I'm talking about mod_perl 1.x
not mod_perl 2.
Otherwise, I would completely agree. The _exact_ same code _does_ work
under mod_perl2.
Ah, sorry, so what exact problem you are talking about? Can you post a link to
the HTML version of the relevant section in the guide, I'm not sure what 5.17 is?
I also see that the problem Bart was referring to was fixed in 2.93
Philip M. Gollucci wrote:
I'll disagree on this being a windows only problem in CGI. I'll also
disagree about the version number.
As late as CGI 3.00 this problem exists in Apache 1.3.27 and mod_perl
1.27 on SunOS.
The pdf troubleshooting doc on apache.org site suggest fix (I think
its 5.17) also does _not_ work either
a temp work around I've come up with is
eval {
$query = CGI-new();
};
return 1 if $@;
instead of just
$query = CGI-new();
__
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: apache2, mod_perl: problem with CGI
speeves wrote: Stas Bekman wrote: Thanks that did it. Great. It would be nice though if the minimum rev level of the CGI.pm could be mentioned in the doc. Or maybe it is there somewhere and I skimmed over it. It's a a CGI.pm problem, really. We can't go and support all possible modules that may or may not run under mod_perl 2.0. However we do have this section: http://perl.apache.org/products/apache-modules.html#Porting_CPAN_modules_to_mod_perl_2_0_Status We probably should specify the version number of each of these modules. Can somebody please lookup those modules and send me a patch with the version number which starts to support mod_perl 2.0? No need for Apache::Peek, CGI and CGI::Cookie since I know these versions already. I'm CC'ing Shannon, since he has ported most of the auth modules. Sorry, I wasn't following the thread, so don't know what the patch is for. :( But, here is a listing of the version numbers for the auth mods that are stable, and work with mod_perl2: Apache-AuthenNIS-0.11 Apache-AuthenNTLM-2.04 Apache-AuthenPasswd-0.12 Apache-AuthenSmb-0.70 Apache-AuthExpire-0.38 Apache-AuthNetLDAP-0.25 Apache-AuthPerLDAP-2.01 Apache-AuthzNetLDAP-0.07 Apache-AuthzNIS-0.11 Apache-AuthzPasswd-0.11 Thanks, speeves So these are the versions required to run properly with mod_perl 2.0? Here is an updated table: Module Name Required Dist Package - Apache::AuthExpire Apache-AuthExpire-0.38 Apache::AuthNetLDAPApache-AuthNetLDAP-0.25 Apache::AuthPerLDAPApache-AuthPerLDAP-2.01 Apache::AuthenNIS Apache-AuthenNIS-0.11 Apache::AuthenPasswd Apache-AuthenPasswd-0.12 Apache::AuthenSmb Apache-AuthenSmb-0.70 Apache::AuthzNIS Apache-AuthzNIS-0.11 Apache::AuthzNetLDAP Apache-AuthzNetLDAP-0.07 Apache::AuthzPasswdApache-AuthzPasswd-0.11 Apache::Clean Apache-Clean-2.00_4 (not released) Apache::Peek Apache-Peek-1.01 CGICGI.pm-2.93 CGI::CookieCGI.pm-2.93 (comes in the CGI dist) I can't see Apache-AuthenNTLM-2.04 being ported yet, though. Here is the list of modules that are being in progress of being ported: Module Porters -- Apache::MP3Stas Bekman stas AT stason.org Clemens Schrimpe csch AT Kiez.NET Apache::Scoreboard Stas Bekman stas AT stason.org Apache::VMonitor Stas Bekman stas AT stason.org Apache::AuthenNTLM Shannon Eric Peevey speeves AT unt.edu Apache::Requesthttp://httpd.apache.org/apreq/ Apache::Language Philippe M. Chiasson gozer AT cpan.org Apache::AutoIndex Philippe M. Chiasson gozer AT cpan.org __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: porting from mod_perl1 to mod_perl2
Philip M. Gollucci wrote: If you check out the changes to CGI.pm on Licoln Stiens web site, utf8 was added via a path by someone else 2.99 - 3.00 likely this is the cause. Bart, can you try then with an earlier version? e.g. 2.93 was good for me. You can get it from here: http://www.cpan.org/authors/id/L/LD/LDS/ __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: apache2, mod_perl: problem with CGI
Philip M. Gollucci wrote:
I'll disagree on this being a windows only problem in CGI. I'll also
disagree about the version number.
As late as CGI 3.00 this problem exists in Apache 1.3.27 and mod_perl
1.27 on SunOS.
I believe it's not the problem Bart was talking about. You are most likely
talking about Apache-request failing, which is how it should be if the
GlobalRequest option is not set. Bart's problem was finding the request method.
The pdf troubleshooting doc on apache.org site suggest fix (I think its
5.17) also does _not_ work either
a temp work around I've come up with is
eval {
$query = CGI-new();
};
return 1 if $@;
instead of just
$query = CGI-new();
You don't need a workaround. You need to setup PerlOptions +GlobalRequest if
you get this error. Unless you are talking about something else, in which case
please tell use the exact error you are talking about.
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: apache2, mod_perl: problem with CGI
So these are the versions required to run properly with mod_perl 2.0? Here is an updated table: Module Name Required Dist Package - Apache::AuthExpire Apache-AuthExpire-0.38 Apache::AuthNetLDAPApache-AuthNetLDAP-0.25 Apache::AuthPerLDAPApache-AuthPerLDAP-2.01 Apache::AuthenNIS Apache-AuthenNIS-0.11 Apache::AuthenPasswd Apache-AuthenPasswd-0.12 Apache::AuthenSmb Apache-AuthenSmb-0.70 Apache::AuthzNIS Apache-AuthzNIS-0.11 Apache::AuthzNetLDAP Apache-AuthzNetLDAP-0.07 Apache::AuthzPasswdApache-AuthzPasswd-0.11 Apache::Clean Apache-Clean-2.00_4 (not released) Apache::Peek Apache-Peek-1.01 CGICGI.pm-2.93 CGI::CookieCGI.pm-2.93 (comes in the CGI dist) I can't see Apache-AuthenNTLM-2.04 being ported yet, though. Here is the list of modules that are being in progress of being ported: Hi! Apache-AuthenNTLM-2.04 is indeed ported, I guess I just didn't make a formal announcement. People can download it from the CPAN site under my name. Thanks Shannon, I have updated the page. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] ModPerl-Registry/t/bad_scritps.t returns 403 not 500
Thank you Beau for a complete bug report. a. ModPerl-Registry/t/bad_scritps.t returns 403 not 500. bad_scripts1..1 # Running under perl version 5.008 for linux # Current time local: Thu Sep 4 16:19:34 2003 # Current time GMT: Fri Sep 5 02:19:34 2003 # Using Test.pm version 1.24 # testing : the script hasn't declared its private $r # Failed test 1 in bad_scripts.t at line 13 # expected: 500 # received: 403 not ok 1 c. Error log: [...] The error message is right there: [Thu Sep 04 16:19:34 2003] [error] file permissions deny server execution/usr/local/src/modperl2/modperl-2.0/ModPerl-Registry/t/cgi-bin/r_in herited.pl What perms do you get when you do: ls -l ModPerl-Registry/t/cgi-bin/r_inherited.pl it should be a+rx, e.g. on my machine it's: -rwxr-xr-x1 stas stas 248 Mar 7 19:58 I think when I have added this file to cvs it didn't have the +x bit, which I then have fixed directly in the cvs repository. I have just made a fresh checkout and the perms seem to be correct. May be you have an old checkout of this file, try to do: rm ModPerl-Registry/t/cgi-bin/r_inherited.pl cvs up ModPerl-Registry/t/cgi-bin/r_inherited.pl and try again. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] ModPerl-Registry/t/bad_scritps.t returns 403 not 500
Beau E. Cox wrote: May be you have an old checkout of this file, try to do: rm ModPerl-Registry/t/cgi-bin/r_inherited.pl cvs up ModPerl-Registry/t/cgi-bin/r_inherited.pl and try again. Thanks Stas - Sorry I missed the error. I did the 'rm' and re-cvs'ed - flags correct and test OK. Next I rmeoved my entire source tree and re-cvs'ed. Flags on r_inherit... OK. Test OK. It's a drawback of cvs, which can't update perms if they have changed after checking out the file. One has to delete and re-check out the file. There are three scripts w/o execute permission: not_executable.pl (I guess that's correct) lib.pl local-conf.pl That's fine. So we are all set ;) __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Reply to List
Craig Shelley wrote: Hi, Just wondering why the mailing list has sets the list-post: header to [EMAIL PROTECTED] This can be quite annoying since mail clients like evolution have a Reply to List option which saves a lot of fafing about. Since the list email address appears to be wrong Reply to List cannot be used. [...] Maybe it has not been updated? Good catch, Craig. I have forwarded your request to the list owner (modperl-owner [EMAIL PROTECTED] perl.apache.org), where this kind of requests should be sent to. Watch the headers, I'm sure Ask will fix them asap. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: PATCH porting.pod First Mystery
Brian McCauley wrote: [...] OK, your last post's examples were more to the point of wanting to destroy objects at the end of the request, and hence here is a new summary: - move the perl4 lib solution to the perl_reference.pod - suggest turning a lexical variable declared with my() into a global variable declared with our() to avoid the closure, with the following buts: o if with my() it wasn't crucial to initialize the variables (since my() initialized them to 'undef'), now all variables declared with our() must be explicitly initialized. s/my $counter = 0/our $counter = 0/; [Brian: notice that I prefer *not* to suggest using local() to init vars, and rather have users do that explicitly, which is a good practice] o since the initialization of global variables happens at the beginning of the request, if a variable which contains an object: my $query = CGI-new; is made global: our $query = CGI-new; it won't be destroyed untill the next request. If you wish to make sure that it's destroyed at the end of the request, you must local()'ize the variable: local our $query = CGI-new; - users of perl 5.6 have to use 'use vars' instead of 'our'. So the above examples become: use vars qw($counter); $counter = 0; and: use vars qw($query); local $query = CGI-new; - point to perl_reference.pod for other workarounds/solutions. Please let me know if I have missed something from your last posts suggestions. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: apache2, mod_perl: problem with CGI
Thanks that did it. Great. It would be nice though if the minimum rev level of the CGI.pm could be mentioned in the doc. Or maybe it is there somewhere and I skimmed over it. It's a a CGI.pm problem, really. We can't go and support all possible modules that may or may not run under mod_perl 2.0. However we do have this section: http://perl.apache.org/products/apache-modules.html#Porting_CPAN_modules_to_mod_perl_2_0_Status We probably should specify the version number of each of these modules. Can somebody please lookup those modules and send me a patch with the version number which starts to support mod_perl 2.0? No need for Apache::Peek, CGI and CGI::Cookie since I know these versions already. I'm CC'ing Shannon, since he has ported most of the auth modules. The 'Configuring mod_perl2.0 page for win32' at http://perl.apache.org/docs/2.0/os/win32/config.html would a nice place to mention this. Certainly not there, since it's windows specific and CGI.pm is used on all platforms. However we could link to the URL I have mentioned from other docs. I think porting docs are more relevant, than config. [Fri Sep 05 00:17:12 2003] [error] 1688: ModPerl::Registry: Can't locate object method request via package Apache at C:/Perl/lib/CGI.pm line 269. upgrade your CGI.pm to 2.93 or higher. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: porting from mod_perl1 to mod_perl2
Perrin Harkins wrote: I am fairly sure it is not perl5.8. I'm fairly sure it is. What is your locale set to? Are you on Red Hat? See previous discussions of locale issues on Red Hat 8 and 9 in the list archives. Bart is on win32, AS Perl 5.8. I doubt it's a locale issue, since it's the client who decides what encoding the data is in, it's either CGI.pm (guessing that what he was using to parse the forms) or more low level (io) issues. Bart, can you test whether you have the same problem when a run the same code under mod_cgi in Apache2 (with perl5.8 ofcourse)? If not, that will point the blaming finger towards mod_perl 2.0. Someone volunteers to add a new test? See t/modperl/print_utf8.t t/response/TestModperl/print_utf8.pm for an example of testing the responding with utf8 data. You can probably adopt one of these couples for testing the posting of utf8 data: t/apache/cgihandler.t t/response/TestApache/cgihandler.pm t/modules/cgi.t t/response/TestModules/cgi.pm t/modules/cgiupload.t t/response/TestModules/cgiupload.pm of course you will want to create a new couple of files for this test. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Preloading modules and Perl 5.6.1 vs 5.8.0
I think next I may try and see if perl 5.6.1 can be build on the 5.8.0 system and see what this leads to. I wonder if it could be the newer gcc or glibc? This is quite possible, since the sharing mostly comes from your OS, not specificly from Perl. You may also want to try the latest perl-5.8.1 snapshot, while you are at it, as it'll be released rsn. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] Failed to obtain the MPM name
Beau E. Cox wrote: Hi - 1) Downloaded (via CVS) latest mod_perl source (9/4/2003) 2) Cannot configure: perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2/ MP_INST_APACHE2=1 Reading Makefile.PL args from @ARGV MP_AP_PREFIX = /usr/local/apache2 MP_INST_APACHE2 = 1 Configuring Apache/2.0.47 mod_perl/1.99_10-dev Perl/v5.8.0 Failed to obtain the MPM name at lib/Apache/Build.pm line 185. This is a recent change where we extract the MPM name to know whether to require ithreads enabled Perl or not. 3) Apache2 (2.0.47) configuration (Apache works) $BASE_DIR/$SOURCE_DIR/configure \ --enable-layout=SuSE \ that's probably the problem. You can use MP_AP_PREFIX= only if you install all apache files under the same tree, which is the default layout. Otherwise you should use the MP_APXS option pointing to apxs, which will know the rest of the details about the layout. Please check if it works for you. I've already adjusted the install docs to mention MP_APXS, I suppose we need to put it as the very first one. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Preloading modules and Perl 5.6.1 vs 5.8.0
e-mol Development Team wrote: After some thinking time I decided to compile perl 5.8.0 on the older system that did have 5.6.1. It would seem it has nothing to do with perl 5.8.0. I compiled perl 5.8.0 on the older system and preloading worked just like it should. Now I know that it does not have anything to do with perl or mod_perl but rather the newer gcc and glibc on the newer system. New system: gcc-3.2.2 glibc-2.3.2 Old system glibc-2.2.4 gcc-2.96 Has anyone else had problems with gcc-3.2.2 or glibc-2.3.2 and shared memory? Ask at the glibc list? or may be p5p, as there are quite a few knowledgeable folks over there... Next I am going to try perl 5.8.1 snapshot to see what happens. Probably nothing will change on the sharing front, but you will get a better 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: apache2, mod_perl: problem with CGI
[please don't reply to another thread when starting a new one. don't be surprised if your question is ignored if you do that.] Just trying to get up and running with Apache/2.0.47 (Win32) mod_perl/1.99_10-dev Perl/v5.8.0 Server Have installed AS Perl 5.8 and the mod_perl ppm that Randy provides the world with. Running my mod_perl code using the ModPerl::Registry handler. Now everything is fine until I put the following in my code: use CGI(); my $q = CGI-new(); From that point on I get a servererror and the following entry in the apache logfile: [Fri Sep 05 00:17:12 2003] [error] 1688: ModPerl::Registry: Can't locate object method request via package Apache at C:/Perl/lib/CGI.pm line 269. upgrade your CGI.pm to 2.93 or higher. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Can't get a mod_perl.so...
Geoffrey Young wrote: perl Makefile.PL APACHE_SRC=../apache_1.3.26_modperl/ APACHE_PREFIX=/usr/local/apache EVERYTHING=1 USE_DSO=1 USE_APACI=1 APACI_ARGS='--enable-module=rewrite, --enable-module=info, --enable-module=expires, --disable-module=userdir' DO_HTTPD=1 when I use those options, I end up with /usr/local/apache/libexec/libperl.so but only after I install the package - it's not in my mod_perl source tree. It's never in the mod_perl source, it's in the apache_1.3.26_modperl/src/modules/perl dir. mod_perl copies its src/modules/perl to the apache source dir and compiles it there. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] Failed to obtain the MPM name
Beau E. Cox wrote: $BASE_DIR/$SOURCE_DIR/configure \ --enable-layout=SuSE \ that's probably the problem. You can use MP_AP_PREFIX= only if you install all apache files under the same tree, which is the default layout. Otherwise you should use the MP_APXS option pointing to apxs, which will know the rest of the details about the layout. Please check if it works for you. I've already adjusted the install docs to mention MP_APXS, I suppose we need to put it as the very first one. Yep - MP_APXS=... works, thanks Stas. I have updated the install docs to reflect the ever-changing reality... __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Preloading modules and Perl 5.6.1 vs 5.8.0
e-mol Development Team wrote: I have two servers running Apache 1.3.27 and mod_perl 1.27 both severs are running identical httpd.conf and startup.pl configurations. One is running Perl 5.8.0 the other is running 5.6.1. When I do the preloading of modules on the 5.6.1 system all seems well and shared memory goes up while unshared memory goes down. On the 5.8.0 only the unshared memory goes up, similar to if I did no preloading and just hit the pages that would cause the modules to get loaded. I am looking for ideas on why this may be. Does preloading not like new versions of perl? Am I being a bonehead? Thank you in advance for any assistance. Compare their build options? perl-5.6.1 -V 5.6.1 perl-5.8.0 -V 5.8.0 diff -u 5.6.1 5.8.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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Process exiting prematurely
Flowers, Jay wrote: I am running Windows XP, Apache 2.0.46, mod_perl 1.99, and Perl 5.8. Every request to my Perl script causes the Apache child process to exit. I have not been able to identify the issue. Below I have listed my config file (the number of threads per child is limited to ten for brevity of the log file) and the error log (this includes startup of the server and one request). Jay, I can't see from your error_log what problem you are talking about. Apache always starts and immediately restarts, so what you see is normal. What shows up in the error_log when you issue a request to a registry script? I suppose nothing? There is no segfault, no nothing? What's the exact error message that you get from the system? (I suppose it does that via a pop up window, 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: collecting unique client (computer) specific info?
kfr wrote: Anyone know how to capture the UUID from a request? I've been looking all over the place and cant seem to find any reference to it anywhere ... You mean, you want to generate one? in mod_perl2/apr it'd be: use APR::UUID: my $uuid = APR::UUID-new-format; or from the command line (assuming that you are using the latest cvs): perl -MApache2 -MAPR -MAPR::UUID -le 'print APR::UUID-new-format' __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl and GD.pm segfault
Jason wrote: Embedded Perl version v5.8.0 for Apache/1.3.27 (Unix) PHP/4.3.2 mod_perl/1.28 mod_ssl/2.8.14 OpenSSL/0.9.6b I am trying to use a simple script that will display an jpeg or png image using GD.pm (readily available from CPAN) I am getting [Wed Sep 3 10:41:37 2003] [notice] child pid 832 exit signal Segmentation fault (11) This happens only when the script is loaded in mod_perl... In normal perl/apache it works without the segfault Any Ideas as to why? Not before you show us the segfault backtrace, unless someone can reproduce your problem with the sample script. See: http://perl.apache.org/bugs/ __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: collecting unique client (computer) specific info?
John Saylor wrote:
hi
( 03.09.03 10:42 -0700 ) Stas Bekman:
You mean, you want to generate one? in mod_perl2/apr it'd be:
is there an equivalent in mod_perl1?
I'm sure there are a few modules on CPAN that you can use. Again I'm talking
about generating UUD, not extracting the SSL one. Perrin has replied that you
need $ENV{SSL_SESSION_ID} for the SSL one.
__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Process exiting prematurely
Flowers, Jay wrote: That is the bugger of it, there is no error, it's a behavior that I noticed. Every request is slow because it needs to restart the Apache Child process. It feels much slower than CGI on IIS. Do you get this behavior with some particular script or just any kind? Does the same script work fine as mod_cgi? __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Preloading modules and Perl 5.6.1 vs 5.8.0
[make sure to keep the replies on the list. Thank you!] e-mol Development Team wrote: diff -u 5.6.1.txt 5.8.0.txt The two builds are quite different, I have pointed out below at least a few major differences. [EMAIL PROTECTED] src]# diff -u 5.6.1.txt 5.8.0.txt --- 5.6.1.txt 2003-09-03 14:07:02.0 -0400 +++ 5.8.0.txt 2003-09-03 14:04:21.0 -0400 @@ -1,40 +1,58 @@ -Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: +Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: -osname=linux, osvers=2.4.2-2,archname=i686-linux +osname=linux, osvers=2.4.20-2.48smp, archname=i386-linux-thread-multi +uname='linux str' +config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -g -Dmyhostname=localhost [EMAIL PROTECTED] -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Dotherlibdirs=/usr/lib/perl5/5.8.0 -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr' I'm not quite following, why 5.6.1 was built with -Dusethreads -Duseithreads but below it says: usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef hint=recommended, useposix=true, d_sigaction=define -usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef -useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef -use64bitint=undef use64bitall=undef uselongdouble=undef +usethreads=define use5005threads=undef' useithreads=define usemultiplicity= +useperlio= d_sfio=undef uselargefiles=define usesocks=undef +use64bitint=undef use64bitall=un uselongdouble= +usemymalloc=, bincompat5005=undef OK, so try building 5.8.0 with -Uusethreads (unless you are going to use ithreads) Compiler: -cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', -optimize='-O2', -cppflags='-fno-strict-aliasing -I/usr/local/include' -ccversion='', gccversion='egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)', gccosandvers='' -intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 +cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', Hmm, where did you get these perl from? did you build them yourself? Why -DDEBUGGING is enabled? You certaintly don't want this to be enabled in production. You have it in both perls. +optimize='', +cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' +ccversion='', gccversion='3.2.2 20030213 (Red Hat Linux 8.0 3.2.2-1)', gccosandvers='' +gccversion='3.2.2 200302' +intsize=e, longsize= , ptrsize=p, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 -ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 -alignbytes=4, usemymalloc=n, prototype=define +ivtype='long' +k', ivsize=4' +ivtype='long' +known_ext, nvtype='double' +o_nonbl', nvsize=, Off_t='', lseeksize=8 +alignbytes=4, prototype=define Linker and Libraries: -ld='cc', ldflags =' -L/usr/local/lib' +ld='gcc' +l', ldflags =' -L/usr/local/lib' +ldf' libpth=/usr/local/lib /lib /usr/lib -libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt -lutil -perllibs=-lnsl -ldl -lm -lc -lposix -lcrypt -lutil -libc=/lib/libc-2.1.3.so, so=so, useshrplib=false, libperl=libperl.a +libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil +perllibs= +libc=/lib/libc-2.3.1.so, so=so, useshrplib=true, libperl=libper Your 5.6.1 is built as a static perl, whereas 5.8.0 as a dynamic. +gnulibc_version='2.3.1' Dynamic Linking: -dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' -cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' +dlsrc=dl_dlopen.xs, dlext=so', d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE' +cccdlflags='-fPIC' +ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5', lddlflags='s Unicode/Normalize XS/A' __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] executing subprocesses from mod_perl
Haroon Rafique wrote:
Hi listers,
Just needed a quick opinion:
http://perl.apache.org/docs/2.0/api/Apache/SubProcess.html
suggests that Apache::SubProcess be used for executing subprocesses.
Howerver, in an earlier list message,
http://marc.theaimsgroup.com/?l=apache-modperlm=102541721726752w=2
Stas had suggested that either IPC::Run or Apache::SubProcess could be
used.
I have 2 versions of a mod_perl script using either of the modules. Which
one would be preferred and why?
Some reasons come to mind right away, e.g.,
* IPC::Run may be more mature (version 0.75), so use it.
Don't forget that Apache::SubProcess is just a glue for the C library, which
is quite mature as well. This C library works on all platforms Apache works.
I'm not sure about IPC::Run. Spawning processes on different OSes is quite
different.
* IPC::Run is a separate install, so don't use it.
* Apache::SubProcess is distributed with mod_perl, so use it.
etc...
IPC::Run should be used instead of IPC::Open3, since the latter doesn't work
under mod_perl. You probably should be able to use any of the two (IPC::Run or
Apache::SubProcess). You could try to benchmark to see which one is faster.
Apache::SubProcess is written in C.
Apache::SubProcess has extra features (see appendix B in the practical
mod_perl book and should also be in the guide, but not all were ported yet).
e.g. in mod_perl 1's Apache::SubProcess, you can send the output of system()
to the client:
use Apache::SubProcess qw(system);
my $r = shift;
$r-send_http_header('text/plain');
system /bin/echo hi there;
but this wasn't ported yet.
in 2.0 you can set subprocess env:
$r-subprocess_env-set(SubProcess = $value);
my $out_fh = Apache::SubProcess::spawn_proc_prog($r, $perl, [$script]);
my $output = read_data($out_fh);
Also you may want to use Apache::SubProcess to stress it out and see if there
is something that we need to fix, if it's not used we might not be aware of
existings bugs that the tests don't catch. You can always switch to IPC::Run
if you encounter some 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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Process exiting prematurely
Flowers, Jay wrote: Do you get this behavior with some particular script or just any kind? Does the same script work fine as mod_cgi? All scripts, work the same. They work fine under mod_cgi. Do normal handlers behave the same way? i.e. if you don't use registry but a complete handler: http://perl.apache.org/docs/2.0/user/intro/start_fast.html#Handler_Modules If the problem persists, make sure to submit a complete problem report here and may be someone on Windows XP will be able to help you. For more info see: http://perl.apache.org/bugs/ __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: PATCH porting.pod First Mystery
script that contains, at file scope: open my $file, '', $outfile or die $outfile: $!; What happens if you change that to: use vars qw($file); $file = undef; open $file, '', $outfile or die $!; Well firstly it looks way ugly :-) ! Secondly, it doesn't work under perl 5.6, so the point is moot if it's made clear ;) Much more importantly it doesn't close the file when the script terminates. I didn't suggest that particular use, however the suggestion in the guide is global and implies that it should work. All I can say here is that closing the file explicitly is a good practice, but otherwise you are right. open local our $file, '', $outfile or die $!; This is a much smaller change to the original script. It looks much cleaner. And most importantly it actually works. so does: open our $file, '', $outfile or die $!; no? and it works because you don't need to initialize $file The problem with CWD is not that simple. The trouble with advising people to create Perl4-style library in the [...] But I have already agreed that perl4-style libs solution should be moved to the perl_reference.pod doc... I agree with your arguments. To summarize: - move the perl4 lib solution to the perl_reference.pod - suggest replacing my() with our() to avoid the closure, however this change requires that the variables will be initialized before used in most cases (example of 'open our $foo' which doesn't need to be initialized). you can initialize variables by an explicit assignment of the value, or using the 'local our' trick, which will initialize the variable to under, which is probably not what you want. - for users of perl 5.6 suggest to use 'use vars' instead of 'our'. - point to perl_reference.pod for other workarounds/solutions. Does it sound 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: PATCH porting.pod First Mystery
Perrin Harkins wrote:
To summarize:
- move the perl4 lib solution to the perl_reference.pod
- suggest replacing my() with our() to avoid the closure, however this change
requires that the variables will be initialized before used in most cases
(example of 'open our $foo' which doesn't need to be initialized). you can
initialize variables by an explicit assignment of the value, or using the
'local our' trick, which will initialize the variable to under, which is
probably not what you want.
- for users of perl 5.6 suggest to use 'use vars' instead of 'our'.
- point to perl_reference.pod for other workarounds/solutions.
May I also suggest telling users to pass arguments explicitly to subs,
instead of doing it implicitly? Nearly all of the Registry-related bugs
I see stem from people doing this:
my $cgi = CGI-new();
foo()
sub foo {
$cgi-param(whatever)...
}
They accidentally create a closure this way and then wonder why their
form values never change. Passing $cgi to foo() fixes the problem.
We have that already covered in perl_reference.pod, example multirun3.pl.
Originally all the workarounds were in the porting.pod but then there were too
many of them. so I thought to give just one solution and a pointer to a
document/section with the rest of the solutions. If you think it's worth
mentioning it in porting.pod in addition to the current place, feel free to
adjust it. Your above example prabably more familiar to cgi script writers,
than an abstract $counter exapmle.
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Test fails make test on Debian
Jens Porup wrote: Greetings all, When I try to install Apache::Test on my Debian-based Libranet Linux system, make test fails as below. I have searched the archives--correctly, I hope!--but nothing has turned up. speculation--does this have something to do with Debian calling apache /usr/sbin/apache, as opposed to /usr/sbin/httpd? I've tried creating symlinks between the two possible locations of the executable, and even a t/httpd symlink, but to no avail. Any help with this would be much appreciated. No, it fails due to the fact that you unpacked it under /root, since Apache running with user nobody can't access the files under /root. Move your .cpan directory to /tmp or some other place that is readable by 'nobody' and it'll work. I'll upload a new version soon that detects this problem early and explains it. Some time later we will have a workaround for this. (need to copy some files from t/ to /tmp and run the server from /tmp/t...). Regards, Jens [EMAIL PROTECTED]:~/.cpan/build/Apache-Test-1.03# make test /usr/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -clean *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -clean APACHE_USER= APACHE_GROUP= APACHE_PORT= APACHE= APXS= \ /usr/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -verbose=0 *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -verbose=0 *** root mode: changing the fs ownership to 'nobody' (65534:65534) /usr/sbin/httpd -X -d /root/.cpan/build/Apache-Test-1.03/t -f /root/.cpan/build/Apache-Test-1.03/t/conf/httpd.conf -DAPACHE1 -DPERL_USEITHREADS using Apache/1.3.27 waiting for server to start: . waiting for server to start: ok (waited 0 secs) server localhost:8529 started ping...ok requestNOK 1# Failed test 1 in request.t at line 11 requestNOK 5# Failed test 5 in request.t at line 16 requestNOK 8# Failed test 8 in request.t at line 20 requestNOK 9# Failed test 9 in request.t at line 22 requestFAILED tests 1, 5, 8-9 Failed 4/9 tests, 55.56% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- request.t 94 44.44% 1 5 8-9 *** server localhost:8529 shutdown !!! error running tests (please examine t/logs/error_log) make: *** [run_tests] Error 1 [EMAIL PROTECTED]:~/.cpan/build/Apache-Test-1.03# -- __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: PATCH porting.pod First Mystery
Brian McCauley wrote: [...] Nice, but: +The easiest and the fastest way to solve the nested subroutines +problem is to change Cmy to Clocal Cour for all variables for +which you get the warning. The Chandler subroutines are never ... [...] + local our $counter = 0; local our? That should be either local or our, but not both. No. Do I miss something? Yes. (I tried to explain this in Paris but I was in danger of causing you to miss lunch completely). local() and our() do two quite separate and complementary things. our() (in effect) declares a lexically scoped alias for a package variable. local() restores the old value of a package variable (usually undef) at the end of the current lexical scope. In effect you use local() to undef the variable, instead of explicitly initializing it. Why not doing this explictly? so instead of replacing: my $counter; with: local our $counter; it's probably better to say: our $counter = 0; or if you insist on using both: our $counter; local $counter; # undef $counter later on I show why this is better for user's understanding. The two combined therefore give a package variable two of the most useful properties of a lexical one. Of course a real lexical variable doesn't really become undefined when it does out of scope - it really becomes anonymous, and iff there are no remaining (unweakened) references it then gets GCed. But for file-scoped lexicals in the main script file the difference is usually not that important. Both effectively get killed at the point where global destruction would have taken place. The rest looks good, but that's not the simplest solution as you have to modify the variables. Is there a simpler one? For a typical script with say half a dozen variables the would not remain shared the local our solution requires a dozen keystokes on each of half a dozen lines. Don't forget that our() is not available before perl 5.6. So we can't quite eliminate the previous solution unless you suggest to go with a back-compatible version: use vars qw($counter); local $counter; and of course the proper solution is: use vars qw($counter); $counter = 0; # or undef which is documented in the perl reference section. Granted, the original simplest solution has its troubles. The original simplest solution involved finding (and subsequently maintaining) a globally unique filename then splitting the program in to two parts. Thereafer you have to maintain two files even on CGI servers. I would contend that this simple solution is not simple. If you are going to all that troble you may as well to the extra 804.65m and produce a proper mod_perl handler and a small wrapper to make it work also in a CGI environment. Also, as of mod_perl2, the simple solution is not even, as it stands, a solution as it relied on the script being in the CWD. Remember, we are talking about mp1 guide patching. Not everything that applies to mp1 applies to mp2. e.g., mp2 requires 5.6+, so we indeed can rely on using our() there. And I hope that the problem with CWD will be resolved once Arthur will fix that. If you think that using globals + their initialization is a better solution, which will work well in mp1 and mp2, we can replace the lib.pl solution with it, but should add it to the perl reference section. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: self_url MP2 w/o CGI
Tofu Optimist wrote: Hi folks -- I'm using MP2, and I am trying to avoid loading CGI for 2 reasons: (1) To save memory. (2) When I do load CGI, it fails at the require Apache (line 161), and I'd prefer not to edit CGI on my server. Uck. Given I'm not loading CGI, how can I determine self_url() in MP2? I tried something like this code my $self_uri = APR::URI-parse($r-pool, $r-uri)-unparse; $r-headers_out-set(Location = $self_uri . r2=1); return Apache::REDIRECT; /code but this gives me a partial URL, not the full expansion. $r-construct_url; From the C docs: /* Used for constructing self-referencing URLs, and things like SERVER_PORT, * and SERVER_NAME. */ /** * build a fully qualified URL from the uri and information in the request rec * @param p The pool to allocate the URL from * @param uri The path to the requested file * @param r The current request * @return A fully qualified URL * @deffunc char *ap_construct_url(apr_pool_t *p, const char *uri, request_rec *r) */ AP_DECLARE(char *) ap_construct_url(apr_pool_t *p, const char *uri, request_rec *r); __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: self_url MP2 w/o CGI
Tofu Optimist wrote: Thanks. How do I call construct_uri? You just call $r-construct_url. In your example that would be: $r-headers_out-set(Location = $r-construct_url . r2=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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: self_url MP2 w/o CGI
[please keep the thread on the list!] Tofu Optimist wrote: :( [Tue Sep 02 15:22:53 2003] [error] [client 192.168.1.2] Can't locate object method construct_url via package Apache::RequestRec at /home//mod-perl/Redirect.pm line 59. Do I need to load it or something? in mp2 you need to load modules that contain the methods that you want to use: % lookup construct_url To use method 'construct_url' add: use Apache::URI (); See: http://perl.apache.org/docs/2.0/user/porting/porting.html#Porting_a_Perl_Module_to_Run_under_mod_perl_2_0 You just call $r-construct_url. In your example that would be: $r-headers_out-set(Location = $r-construct_url . r2=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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Custom Log files Under MP2
Tofu Optimist wrote: I would like to append a small line of log information to a file on certain apache2 requests. For this application, I am very concerned about speed, so i'm looking for fast simple solutions. I could stuff the information in the error log as per http://perl.apache.org/docs/2.0/api/Apache/Log.html, and parse it out later off-line, but I'd prefer to reserve the error log for errors. I could stuff the information in the access log, and likewise pull out the data later off-line: how might I get data to the access_log? The most natural place to append the information would be a dedicated file. I've never written to a file from mod_perl, and don't know the correct idiom (flock? etc?) to do so. I'd appreciate any pointers to recipes, modules, etc. to show me the correct (fast, reliable) way to append to a file under MP2. You may want to spend some time with the mp2 docs first. http://perl.apache.org/docs/2.0/user/ Your particular question is answered at these locations: http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlLogHandler http://perl.apache.org/docs/2.0/user/handlers/server.html#Startup_Phases_Demonstration_Module As for flocking, I prefer to do that, even though there are claims that short writes are atomic. It's probably not the same on all io implementations. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: PATCH porting.pod First Mystery
[EMAIL PROTECTED] wrote: In private mail Stas Bekman [EMAIL PROTECTED] writes: oops, that should be the modperl list... at modperl-docs we discuss mostly site/docs techical issues and there are very few people on this list to get enough exposure for this kind of feedback request. Patch for The First Mystery section of the mod_perl porting guide as per my conversation with Stas at YAPC::Europe::2003. Takes out the suggestion of creating a Perl4-style library in the same directory as a means to port CGI scripts. Replaces it with something simpler and more reliable. Nice, but: +The easiest and the fastest way to solve the nested subroutines +problem is to change Cmy to Clocal Cour for all variables for +which you get the warning. The Chandler subroutines are never ... [...] + local our $counter = 0; local our? That should be either local or our, but not both. Do I miss something? The rest looks good, but that's not the simplest solution as you have to modify the variables. Granted, the original simplest solution has its troubles. I've also changed If you put your code into a library or module... to If you put all your code into modules... because if you put your code into a Perl4-style library and then require it in more than one registry script terrible things happen. I don't think this is the place to explain this so I think the guide should just say modules and leave it at that. Probably the library problem should be explained elsewhere in the guide. Once this one is sorted out, a patch for perl_reference.pod will follow. Sure, sounds good to me. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: using -| construct
Michael wrote:
I have a web service that need to get stuff from the system and is
using the following subroutine to retrieve info.
sub systeminfo {
if (open(FROMADMIN,-|)) { # parent
[...]
This works fine for command line exection and from cgi but fails in
modperl (apache 1x).
The problem is that the initial read pipe apparently fails to open
under modperl.
Is there a workaround for this? or am I just missing something
simple?
Use IPC::Run?
__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SOAP::Lite in mod_perl...
Ged Haywood wrote: Hi guys, On Thu, 28 Aug 2003, Perrin Harkins wrote: simran wrote: The above code works perfectly on: * On dev server in a standalone script * On our dev server under: Apache/1.3.27 (Unix) mod_ssl/2.8.12 OpenSSL/0.9.6c DAV/1.0.3 mod_perl/1.27 * Our live server as a standalong script The code does not work on our live server under: * Live Server: Apache/1.3.28 (Unix) mod_ssl/2.8.15 OpenSSL/0.9.6c DAV/1.0.3 mod_perl/1.28 Have you mentioned this to Philippe Chiasson? Beg your pardon, Ged? What this has to do with Philippe? Perrin has already replied that it's a bug in Apache 1.3.28: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22805 __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SOAP::Lite in mod_perl...
Have you mentioned this to Philippe Chiasson? Beg your pardon, Ged? What this has to do with Philippe? Wasn't he organising the release of mod_perl 1.28? He was a release manager, not a person to blame, even if there was a problem with 1.28, which is certainly not the case. If people are moving to a 1.3.28/1.28 combination, I would expect his mailbox to start filling up... That shouldn't be the case, really. One of us wears the release manager hat once in awhile, but we all stand behind each release. All the bugs are to be reported here, and not to the person who has happened to put it on CPAN. We are slowly working on fixing CPAN to support role accounts, where several people can maintain the same package, taking turns on doing releases. And no matter who releases it, all the bug reports will go to one specified place, not the last release manager's mail box. For mod_perl specifically we want to have a CPAN-id modperl where all the packages maintained by the development team will go. That CPAN-id will have an email address of this list, which will protect the last release manager from misdirected email. The packages will also be put into that CPAN-id's homedir on CPAN, and not release manager's one. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
nntp interface to modperl list archives is avalable
I was delighted to discover an nntp gateway news.gmane.org which carries the following three archives: docs-dev: nntp://news.gmane.org/gmane.comp.apache.mod-perl.devel modperl:nntp://news.gmane.org/gmane.comp.apache.mod-perl apreq-dev: nntp://news.gmane.org/gmane.comp.apache.apreq They are much more useful than the normal archives, though it seems that you can go back only 1 year. I have updated the online http://perl.apache.org/maillist/ docs, if you know of other nntp interfaces to modperl lists, please let me know. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: where to find request object in mod_perl2
Igor Ivoilov wrote: Hello all, I have perl programs running under Apache::Registry. Now I need to switch to mod_perl2 and can not find request object. I used to get as $r = Apache-request; But this does not work under mod_perl2. http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache_E_gt_request_ __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: where to find request object in mod_perl2
Paul G. Weiss wrote: The doc you reference says that Apache-request should be avoided because it is expensive. But does it in fact work? Yes. Have you actually read it? That section also explains when it's available. Igor said: this does not work under mod_perl2, without showing any error messages or explaining what kind of problem he has. On Fri, 29 Aug 2003 10:17:57 -0700, Stas Bekman [EMAIL PROTECTED] wrote: Igor Ivoilov wrote: Hello all, I have perl programs running under Apache::Registry. Now I need to switch to mod_perl2 and can not find request object. I used to get as $r = Apache-request; But this does not work under mod_perl2. http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache_E_gt_request_ __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] make test failed
Alan Rafagudinov wrote: Hi! My guess is that you've been hit by this Apache problem: http://httpd.apache.org/docs-2.0/faq/error.html#error.sendfile [...] Thank you, but your advice helped with hooks/trans.t only, ok, I have added this to the troubleshooting section. filter/in_bbs_msg.t is still failed: t/TEST -v filter/in_bbs_msg.t [...] Test returned status 29 (wstat 7424, 0x1d00) [...] [Fri Aug 29 18:10:58 2003] [error] [client 127.0.0.1] File does not exist: /usr/src/httpd_perl/mod_perl-1.99_09/t/htdocs/input_filter.html that means that the filter doesn't work. Please update your cvs and show me the error_log's output when you run: t/TEST -v -trace=debug filter/in_bbs_msg Mine shows: == FILTER CALLED == FILTER READ: GET /input_filter.html HTTP/1.0 == GET line rewritten to be: GET /TestFilter__in_bbs_msg HTTP/1.0 == FILTER CALLED == FILTER READ: Host: localhost.localdomain:8536 == FILTER CALLED == FILTER READ: User-Agent: libwww-perl/5.69 == FILTER CALLED == FILTER READ: As you can see it rewrites a non-existing resource /input_filter.html to an existing one: /TestFilter__in_bbs_msg. For some reason it fails to do that for you. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Problems Installing On Debian - Or Not
than one Apache installed we may pick the wrong one, which may cause even more confusion. IMHO, it's much better to die with a useful hint on how to tell where APXS is. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
please test a new GTop
I'm about to release a new GTop (you need it for Apache::VMonitor), please give it a try http://apache.org/~stas/GTop-0.11.tar.gz and report any problems to me (off list). Thanks. Changes since 0.10: Add support to libgtop 2.0 and automate the picking of the right libraries and include paths. [Stas Bekman] Backport GTop to perl 5.005_03 using ppport.h [Stas Bekman] __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::DProf problems
Brian Hirt wrote: I've installed Apache::DProf, but it seems hardly any of the calls are profiled. dprofpp shouws MOF::Dispatcher::handler as taking up 100% of the time, but there is no information recorded in for calls within that function. MOF::Dispatcher::handler is calling thousands of other functions and there is absolutely no record of any of those calls in tmon.out. Any ideas an what's going on? I'm running mp1.27 and compiled it with EVERYTHING=1 Remember that any PerlHandler that was pulled in before Apache::DProf in the httpd.conf or startup.pl file will not have code-debugging information inserted. Make sure that you load before any code that you plan to profile. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: where to find request object in mod_perl2
Igor Ivoilov wrote: Sorry for not pointing out all details config file FilesMatch \.pl$ SetHandler perl-script PerlHandler ModPerl::Registry::handler PerlOptions +ParseHeaders AddType text/html .pl Options +ExecCGI /FilesMatch my $r = Apache-request; gives Can't locate object method request via package Apache at That's much better. You need to load 'Apache::RequestUtil' Please refer to the compatibility and porting documents which give you all the info that you need: http://perl.apache.org/docs/2.0/user/porting/compat.html http://perl.apache.org/docs/2.0/user/porting/porting.html while my $r = shift; gives an object of type 'Apache::RequestRec' That's correct. Can not find how to reach header_in() from this point Again, it's in: http://perl.apache.org/docs/2.0/user/porting/compat.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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1] consistent segfaults with HTML::Mason
Stephen wrote:
[...]
The intent was to create a handler()
routine suitable for both mod_perl 1 and 2 (prototype of ($$) vs attribute
of : method). However, for some reason or another, handler() was being
called as a regular sub, with one parameter.
I have used the technique documented here:
http://perl.apache.org/docs/2.0/user/porting/porting.html#Method_Handlers
which in short words comes to:
sub handler_mp1 ($$) { mp1 }
sub handler_mp2 : method { mp2 }
*handler = MP2 ? \handler_mp2 : \handler_mp1;
One thing I forgot to mention, is that : method won't work with perl 5.6.
So if you can share your solution, I'd it to that section.
__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] make test failed
Alan Rafagudinov wrote: Hello! 1. Problem Description: Thanks for the detailed report, Alan. Errors while 'make test' was in filter/in_bbs_msg.t and hooks/trans.t [Thu Aug 28 20:34:19 2003] [info] (22)Invalid argument: core_output_filter: writing data to the network [Thu Aug 28 20:34:19 2003] [error] [client 127.0.0.1] File does not exist: /usr/src/httpd_perl/mod_perl-1.99_09/t/htdocs/inpu t_filter.html [...] *** /usr/local/httpd_perl/bin/httpd -V Server version: Apache/2.0.47 Server built: Aug 28 2003 18:59:50 Server's Module Magic Number: 20020903:4 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork -D APR_HAS_SENDFILE My guess is that you've been hit by this Apache problem: http://httpd.apache.org/docs-2.0/faq/error.html#error.sendfile As the URL above suggests, try to add 'EnableSendfile On' somewhere in t/conf/httpd.conf and rerun: t/TEST -v filter/in_bbs_msg.t hooks/trans.t don't run 'make test' as it'll rewrite t/conf/httpd.conf, use t/TEST instead. I wonder why http://httpd.apache.org/docs-2.0/mod/core.html#enablesendfile says that it's on by default. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] make test failed
My guess is that you've been hit by this Apache problem: http://httpd.apache.org/docs-2.0/faq/error.html#error.sendfile As the URL above suggests, try to add 'EnableSendfile On' somewhere in t/conf/httpd.conf and rerun: t/TEST -v filter/in_bbs_msg.t hooks/trans.t don't run 'make test' as it'll rewrite t/conf/httpd.conf, use t/TEST instead. I wonder why http://httpd.apache.org/docs-2.0/mod/core.html#enablesendfile says that it's on by default. Argh, I confused simply use the EnableSendfile directive as to be turned on. It should be: EnableSendfile Off of course. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Source for Apache::Test documentation on perl.apache.org
Garrett Goebel wrote: As I stated in a previous post, I'm coming up to speed on Apache::Test by working from Stas's documentation at http://perl.apache.org/docs/general/testing/testing.html. I remember seeing a few typos on my first pass through the documentation. Now that I've got a simple perl Makefile.PL make make test make install Working with Apache::Test support, I thought I'd go back through the docs with more of an eye to detail. When I run past those typos again, I'd like to be able to submit patches and ask questions. So... Is the source for that document publically available? Yes, there is a documentation repository that you can checkout and get patches against the cvs. See: http://perl.apache.org/download/docs.html that file would be in src/docs/general/testing/testing.pod We also need to improve the Apache-Test manpages, besides the tutorial, so if you do any additions/fixes there, you will need to use the modperl-2.0 cvs repository, available from here: http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution and What would be most appropriate: post patches and questions here, to Stas directly, or somewhere else? Please, post them to the dev list: http://perl.apache.org/maillist/dev.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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Test unable to locate libperl.so?
Garrett Goebel wrote:
I'm trying to come up to speed on Apache::Test. I'm working from Stas's
documentation at
http://perl.apache.org/docs/general/testing/testing.html. My system is
roughly:
gentoo linux 1.4
perl 5.8.0 useithreads=undef useperlio=define
apache 1.3.28
mod_perl 1.3.28
Apache::Test 1.04 (2003/08/28 cvs snapshot)
I ended up having to patch TestConfig.pm so that it could locate
libperl.so. TestConfig.pm's find_apache_module method doesn't try the
/usr/lib/apache-extramodules directory... Which is where Gentoo linux
likes to put it. A few searches on google suggest Mandrake may put
things there as well.
I don't know the story on extramodules... If anyone is familiar with
it please point me to any documentation or rational on why it exists and
what advantage it offers. I hate finding customizations without a clue
as to why they're there.
If a distro changes the default LIBEXECDIR after building apache, (and not
during ./configure) it has to fix apxs to report the new value, so that 'apxs
-q LIBEXECDIR' gets the right value. If it doesn't please report a bug to the
distro maintainers and ask them them fix that package.
Sorry, but I don't think this approach of adjusting to each distro's will
going to work. We already do too much guess-work that I'm thinking of
dropping, since it does more evil than goodness.
Meanwhile symlinking libexec-extramodules = libexec should do the trick.
Anyways what follows is my best guess on a reasonable way to locate it
when trying to find modules.
--- /home/ggoebel/src/mp2/modperl-2.0/Apache-Test/lib/Apache/TestConfig.pm
2003-08-13 17:15:38.0 -0500
+++ TestConfig.pm 2003-08-28 15:17:52.0 -0500
@@ -637,6 +637,7 @@
my @trys = grep { $_ }
($vars-{src_dir},
$self-apxs('LIBEXECDIR'),
+ $self-apxs('LIBEXECDIR').'-extramodules',
catfile($sroot, 'modules'),
catfile($sroot, 'libexec'));
__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Installation problem
[EMAIL PROTECTED] wrote: Hello! Your letter successfully arrived to my mailbox and I'll read it in the nearest future. -- ! . Like we don't have enough spam and virus emails already. If you ask a question in a public forum and expect an answer, please at least consider to turn off any autoresponders that you may have. :( __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
why you should reply to the list
Perrin Harkins wrote: On Tue, 2003-08-26 at 18:41, Bruce Tennant wrote: Can we fix the list so that when a person replies, it defaults to the list address and not the posters? Read the following thread: http://marc.theaimsgroup.com/?l=apache-modperlm=99790842623617w=2 Please advise on another way to tell people to respond to the list and not in private. I used to receive much less off-list replies earlier. Normally when people followup to my reply in private, I don't know what to do about it. I simply bounce it back to the list if it's obvious that the poster just didn't know better. However in some cases an off-list email means that the poster did *not* want it to be seen in public, so I end up asking the person whether she ment to send it to the list in first place, but hit 'Reply' instead of 'Reply-All'. So we have another 2 emails going back in forth. So instead of generating 1 email we end up with 4 in the best case. Now multiply by the number of misdirected emails. Moreover when people correct their mistake they usually end up forwarding the email, they sent to off-list, losing all reference email ids, which breaks the thread in the archives. Purhaps adding a list signature: Always post followups back to the list! will help, but who reads that. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: problem with mod_perl 2.0 + apache 2.0 and proxyreq
John Chiu wrote: Thanks in advance. I've tried all the archives and google'd but I have not found anything that would help. I'm running RH 8.0, httpd-2.0.40-11.5 and mod_perl-1.99_05-3 from the RedHat distribution. I'm trying to create a small proxy module that will check a non-proxy request and depending on stuff dynamically transform it into a proxy request using mod_proxy. 1.99_05 is a way too old. Lots of bugs were fixed since that release. Upgrade to at least 1.99_09 or better the current cvs. 1.99_10 will be released as soon as perl-5.8.1 is released. I'm following the example in Chapter 7 (page 370) of the Writing Apache Modules with Perl and C. I know that the book is based on the older apache 1.3 server and associated mod_perl. However, I have not found anything in my readings to indicate that this would not work any more. my $r =3D shift; [... code snipped ...] BTW, you mailer has mangled the source code, s/=/=3D/ Additionally, a 502 Bad Gateway error was encountered while trying to use an ErrorDocument to handle the request. The apache error log indicates (with some debugging) that it is looping on the GET of goodbye.html. Additional debuging indicates that $r-proxyreq is always 0, so it's looping. My questions are: 1.Did sometime change in apache 2 or mod_perl 2 so that you cannot set proxyreq anymore: ie. $r-proxyreq(1). 2.How do you set proxyreq if $r-proxyreq(1) is not the correct method? 3.Is the logic wrong in this proxy example? How can we possible know what the problem is if you don't show the relevant configuration section? Most likely you have a broken configuration and should advise first the mod_proxy documentation. http://httpd.apache.org/docs-2.0/mod/mod_proxy.html To make sure that the problem is not in mod_perl, I've added a new modules/proxy test to the mp2 test suite, based on that example from the eagle book. Try it and if you succeed to break it, then we will fix it. You will need to retrieve the cvs version in order to get it. http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution (note: I have just committed the test, so if you use the snapshot, which is updated every 6 hours, it may not be there, so use the normal cvs checkout) __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: why you should reply to the list
Larry Leszczynski wrote: On Tue, 26 Aug 2003, Stas Bekman wrote: Please advise on another way to tell people to respond to the list and not in private. I used to receive much less off-list replies earlier. [snip] Purhaps adding a list signature: Always post followups back to the list! will help, but who reads that. Unfortunately I think we've all seen enough unsubscribe me emails to know that people don't read the info that is *already* being added to the outgoing mail... One can argue that it's not obvious that one has to look at the headers to find out the unsubscribe information. Most modern mail-clients hide the headers by default. You need to know that you want to look at them. I think the new signature that Ask has added last week doesn't leave place for such valid excuses ;) Stas, you probably get it worst just because of the volume of mail you send to the list (which we're all grateful for!). Maybe when you do your mod_perl list reading you should just configure your outgoing email with: Reply-to: [EMAIL PROTECTED] Kind of a pain for you though... Hmm, that's an idea. Won't the list software strip this header? I shell try it now. If it works I should just figure out how to add an outgoing mozilla-mail filter to push this header, if the email is sent to the modperl list. Thanks for the idea, Larry! __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: why you should reply to the list
Douglas Theobald wrote: I thought this was a strange behavior for the list messages when I realized that I had replied, accidentally, to Stas personally and not the list. I subscribe to six lists, and mod_perl is the *only* one where my email reader automatically replies to the sender and not the list. All the other lists automatically put the list email address in the Reply-to: of the distributed posts, thus making replying to the list the default. Couldn't that be changed for modperl? Perrin has already replied to this, as we have discussed this many times in the last 7 years: http://marc.theaimsgroup.com/?l=apache-modperlm=99790842623617w=2 While there is no consensus on this dispute please remember to use the 'Reply-All' function/button when replying to the list. It'll work for other lists which use the 'Reply-To' header as well. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1] consistent segfaults with HTML::Mason
Stephen wrote: [...] The GDB backtrace output (from debugging httpd -X) is as follows: (gdb) bt #0 0x808d079 in XS_Apache_dir_config () #1 0x810a7f7 in Perl_pp_entersub () #2 0x8104b24 in Perl_runops_standard () #3 0x80c39fe in Perl_call_sv () #4 0x80c3b42 in Perl_eval_sv () #5 0x80846ce in perl_require_module () #6 0x807f1ac in perl_call_handler () #7 0x807ecb4 in perl_run_stacked_handlers () #8 0x807d7a3 in perl_handler () #9 0x809bb8d in ap_invoke_handler () #10 0x80b185c in ap_some_auth_required () #11 0x80b1cec in ap_internal_redirect () #12 0x8076052 in ap_get_server_built () #13 0x809bb8d in ap_invoke_handler () #14 0x80b185c in ap_some_auth_required () #15 0x80b18c6 in ap_process_request () #16 0x80a817f in ap_child_terminate () #17 0x80a8341 in ap_child_terminate () #18 0x80a84ba in ap_child_terminate () #19 0x80a8b5c in ap_child_terminate () #20 0x80a93bc in main () #21 0x8064a22 in _start () Wearing my bug-tender cap, but not taking the ownership of this bug, I should say that your backtrace could be much more useful if you have had rebuilt apache/perl/mod_perl with debugging symbols enabled. When you do that the trace will show the arguments to the functions. http://perl.apache.org/bugs/ provides the details on how to do that. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1.0] Installation problem
Ged Haywood wrote: Hello again, On Wed, 27 Aug 2003, Alan Rafagudinov wrote: GH Please post the output of GH gcc -v Reading specs from /usr/lib/gcc-lib/i386-asplinux-linux/2.96/specs gcc version 2.96 2731 (ASPLinux 7.1 2.96-85.asp) Make sure to use that compiler to build Perl, mod_perl and Apache. Since he built from source as: perl Makefile.PL APACHE_SRC=../apache_1.3.28/src/ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACI_ARGS='- -prefix=/usr/local/httpd_perl' it's quite sure that he has used the same compiler. However Alan, have you seen that all emails to this list end with this two lines? Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html If you have followed http://perl.apache.org/bugs/, you'd have supplied a proper bug report and Ged won't have to guess-work what compiler you have used. Make sure to always report bugs properly in the future. Alan, as Ged suggested, upgrade your perl to 5.6.1 or 5.8.0 (5.8.1 was not released yet) and try again (you will need to rebuild mod_perl once you did that). __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: File Upload mod_perl to mod_perl2
Issac Goldstand wrote: You might want to look at Apache::Request for mod_perl. It's currently almost ready for mod_perl2... or meanwhile use CGI.pm 2.93 or higher. - Original Message - From: rkl [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 9:51 AM Subject: File Upload mod_perl to mod_perl2 Could anyone advise which file upload method to use that is be written in mod_perl that will be migrated to mod_perl2 at a later time? And, generally, which particular package from mod_perl (1) should be avoided. Any insight will be helpful. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: installing Apache::Test via CPAN impossible as root
Udo Rader wrote:
Am Tue, 26 Aug 2003 16:07:21 + schrieb Stas Bekman:
As you posted in the followup, this is a problem with all Apache:: modules.
The problem originates within Apache, not us.
Didn't know that apache rejects to run as root. Strange (but safe) behaviour.
It starts as root alright, but won't spawn workers as root.
Ideas how to solve this are *very* welcome.
The best idea I have is to serve the htdocs directory from outside the
~root hierarchy. Apache is initially started as root and thus has no
difficulties to get the configuration stuff needed to start up.
A quick (non MSWormOS compatible) fix would be to patch
lib/Apache/TestConfig.pm as follows:
---CUT
--- TestConfig.pm 2003-06-07 01:43:28.0 +0200
+++ TestConfig.pm.docroot_patched 2003-08-27 12:13:26.0 +0200
@@ -214,7 +214,7 @@
$vars-{t_dir}||= catfile $vars-{top_dir}, 't';
$vars-{serverroot} ||= $vars-{t_dir};
-$vars-{documentroot} ||= catfile $vars-{serverroot}, 'htdocs';
+$vars-{documentroot} ||= /tmp/Apache-Test.$$/htdocs;
$vars-{perlpod} ||= $self-find_in_inc('pods') ||
$self-find_in_inc('pod');
$vars-{perl} ||= $^X;
---CUT
this is only needed for root-run tests, which most of us don't do.
Moving the entire t/ directory to temp is IMHO not necessary, but depending on
the test needs it may also be required to copy a cgi-bin directory to /tmp as
well.
Other dirs top-level t/ dirs may need to be copied as well, e.g. t/logs if
they have some custom logs written from the handlers. Ideally it should be
configurable by the developer that uses Apache::Test.
But I agree that it's certainly a good idea to copy only the minimal amount of
files.
For a better solution of course it would also be reasonable to query the ENV
settings that even exist on MSWorm (IIRC) and even better check that directory's
permissions and fallback again to /tmp, if nothing else is found. But this is maybe
something that File::Spec, which nathan mentioned, already does.
Yup, this is going to be the hardest part. We need a good portable test.
Currently I do this check. I have no idea how portable it is. Please tell me
if there is some problem with it.
You can find it in Apache-Test/lib/Apache/TestRun.pm of the current
modperl-2.0 cvs:
sub check_perms {
my ($self, $user, $uid, $gid) = @_;
# test that the base dir is rwx by the selected non-root user
my $vars = $self-{test_config}-{vars};
my $dir = $vars-{t_dir};
my $perl = $vars-{perl};
my $check = qq[sudo -u '#$uid' $perl -e ] .
qq['print -r $dir -w _ -x _ ? OK : NOK'];
warning $check\n;
my $res = qx[$check] || '';
warning result: $res;
unless ($res eq 'OK') {
#$self-restore_t_perms;
error(EOI) die \n;
You are running the test suite under user 'root'.
Apache cannot spawn child processes as 'root', therefore
we attempt to run the test suite with user '$user' ($uid:$gid).
The problem is that the path:
$dir
must be 'rwx' by user '$user', so Apache can read and write under that
path.
There several ways to resolve this issue. For example move
'$dir' to '/tmp/' and repeat the 'make test' phase.
You can test whether the location is good by running the following test:
% $check
EOI
}
}
IMHO again the build dir in general should default to /tmp/cpan_$USER (or
/var/tmp/cpan_$USER if you prefer), so it would be a good thing to change the default
setting of CPAN's initial configuration for future CPAN releases.
In some ways CPAN packages are very similar to SRPMS and I think CPAN could learn
a lot from RPM here.
Well, that is the wrong forum to discuss the CPAN issues, at least because
those who control CPAN.pm aren't listening ;)
__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: perl.apache.org problem
Cees Hek wrote: It looks like something has gone awry with the perl.apache.org website. It is currently pointing to the Apache Portable Runtime website. You can bypass it by going directly to: http://perl.apache.org/index2.html This looks like the result of a change to put up a protest page at the start of every *.apache.org website. Perhaps someone can notify the powers that be to fix the problem. There is no problem, Cees. This is done by the Apache Software Foundation. mod_perl is an ASF project if you didn't know. Have you read what it says on http://perl.apache.org/? __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: problems with Apache::Filter
Josh Chamas wrote: Right, so basically either Apache::Filter Apache::SSI need to be ported to mod_perl 2, IMHO, Apache::Filter does doesn't need to be ported to mp2. You have a native API for filtering. Geoff has posted a an alpha-port of Apache::SSI to the list some time ago. or I need to bundle this functionality directly into Apache::ASP. I would prefer the former, but could do the latter ( its been requested before anyway ). Most likely you need to do the filtering in Apache::ASP by yourself, see the URL to the filters guide I have posted in another followup. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Geoffrey Young wrote:
Stas Bekman wrote:
Craig Shelley wrote:
I'll take a look at it. But you didn't supply a complete bug report
as explained http://perl.apache.org/bugs/. Please do so.
I think I've got this figured out.
the problem is with the r-main logic in mpxs_ap_run_sub_req.
with that logic, what ends up happening is that the data currently being
operated on is explicity flushed. this is bad within a (streaming)
filter where you are expected to call $f-print yourself, as the data is
sent without your permission (you may be operating on it or not want to
send it at all). it also seemed to cause infinite loop in my tests
because the filter was seeing the same data over and over again.
I can't really understand the reason behind the code anyway, since I
can't see anywhere in core where such logic is applied before
ap_run_sub_request - everyone seems to call without regard to where in
the data stream they happen to be, so I don't get why mod_perl should be
any different. indeed commenting it out fixes the problem for me.
however, removing that logic causes api/lookup_uri2.t to fail, but I
suspect this is an issue with puts() rather than the subrequest
mechanism - changing puts() to print() makes everything work just fine.
does puts() write directly to the wire, bypassing filters?
Sorry, but that's cheating ;)
rputs() never flushes data,
print() flushes if $| == 1;
Please don't remove rputs, it's there for a reason.
If you fix lookup_uri2's handler to be:
sub handler {
my $r = shift;
subrequest($r, 'myplan');
local $| = 0;
$r-print(ok 2\n);
subrequest($r, 'ok3');
Apache::OK;
}
You get:
ok 1
ok 3
ok 2
Confused test output: test 3 answered after test 3
ok
which is wrong.
So there is no problem with the r-main logic in mpxs_ap_run_sub_req, it's
there for exactly this reason.
I wonder why $| is on? must have forgotten to localize $| setting somewhere.
anyway, attached is a patch against current cvs - fixes and a few
filtering subrequest tests. note that the patch does not mention the
removal of xs/Apache/SubRequest/Apache__SubRequest.h, which is no longer
needed, so I guess you should remove that file by hand before compiling.
craig - note that this patch affects the autogenerated code, so in order
to get it to work you'll need to apply it, then run make realclean, perl
Makefile.PL, etc.
and you forgot to add to the patch a new file
#t/htdocs/filter/subrequest.txt
core subrequest
regarding new tests, do you mind calling them:
out_str_subreq_core
out_str_subreq_perl
since 'sub' is too confusing, or even better:
out_str_subreq_default
out_str_subreq_modperl
since these correspond to the SetHandler settings.
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Geoffrey Young wrote: the problem is with the r-main logic in mpxs_ap_run_sub_req. with that logic, what ends up happening is that the data currently being operated on is explicity flushed. this is bad within a (streaming) filter where you are expected to call $f-print yourself, as the data is sent without your permission (you may be operating on it or not want to send it at all). it also seemed to cause infinite loop in my tests because the filter was seeing the same data over and over again. That's is the problem with streaming filters. Nothing indicates to mod_perl whether the currently executed filter is a streaming filter or not, in fact I think you can mix and match both methods in the same filter. So $f-print is not expected, really. What you are right about is that mpxs_ap_run_sub_req should flush only if run from the non-filter handler, and do nothing if run from the filter handler. I have somewhere a prototype for the new API which tells what phase we are in, but it's possible that there is a more efficient way to tell the difference. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Geoffrey Young wrote: [...] as I said, nowhere in any of the module shipped with core do I find logic like this - mod_include and mod_cgi both seem to call ap_run_sub_req without flushing the main data stream (though mod_include does split the stream and send the data _prior to the tag_ off). I don't see why mod_perl needs to behave differently in this respect, but if flushing is required for other reasons I can't see, making it a tacit part of $sub-run seems the wrong solution since it goes against the intent of output filters. but that's how it works in mp1, no? Are you required to flush any data before issuing a subrequest? If I remember correctly you aren't. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: installing Apache::Test via CPAN impossible as root
Udo Rader wrote: hi all, I'm trying to setup Apache::Test with our apaches and have run into major troubles. CPAN refuses to install the mod without force, because all tests completely fail. t/logs/error_log then contained error messages like these: -error_log-- [...] [Tue Aug 26 14:23:47 2003] [error] [client 127.0.0.1] (13)Permission denied: access to /index.html failed because search permissions are missing on a component of the path [...] -error_log-- As you posted in the followup, this is a problem with all Apache:: modules. The problem originates within Apache, not us. FWIW, the cvs version of Apache::Test warns you early whether this is going to work or not, rather than just failing during 'make test'. Ideas how to solve this are *very* welcome. As of this moment per your observation you need to either put the data in the directory readable by the apache user, or build/run the tests as a non-root. If you configure your CPAN to put the build dir not under /root, but let's say /tmp/ (probably can come up with a better choice), it'll work. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Craig Shelley wrote: I'll take a look at it. But you didn't supply a complete bug report as explained http://perl.apache.org/bugs/. Please do so. Here is that bug report related to the earlier postings. -8-- Start Bug Report 8-- 1. Problem Description: [...] 3. This is the core dump trace: (if you get a core dump): [CORE TRACE COMES HERE] Thanks, but you have missed the core dump's backtrace. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: installing Apache::Test via CPAN impossible as root
[EMAIL PROTECTED] wrote:
On Tue, 26 Aug 2003 09:07:21 -0700, Stas Bekman wrote:
[snip]
As you posted in the followup, this is a problem with
all Apache:: modules.
The problem originates within Apache, not us.
FWIW, the cvs version of Apache::Test warns you early
whether this is going to
work or not, rather than just failing during 'make
test'.
Ideas how to solve this are *very* welcome.
[snip]
Stas,
One thing we're working on implementing in Apache::PAR
to solve this kind of problem is to use File::Spec's
tmpdir to get the platform specific temp directory.
This function appears to be available in File::Spec at
least as of Perl 5.6.0 as part of the distribution.
This could be used (maybe overridable via a env
variable, etc) to determine a temporary directory to
copy the t/ directory to in cases where permissions
would deny reading from the working directory or a
parent directory. Of course, it would still have to
fail in cases where a temp directory isn't available
(either File::Spec doesn't support the platform or a
new enough version of File::Spec isn't available on an
old version of Perl) and the env variable isn't set,
but should handle almost all common cases.
Once the content is copied, Apache::Test would then use
that directory to serve test files, scripts, etc out
of. This temporary directory could then also be
cleaned up when the Apache server is shutdown.
Of course, I haven't looked at the code for
Apache::Test enough to know whether this would be
easily implemented, but just thought I would throw out
the idea.
Thanks Nathan,
We have discussed this idea at the dev list, and will probably resort to it if
no better solution is found. I didn't mention it on purpose in hope to get
some new, better ideas.
The problem with copy and cleanup to a temp dir is that some project may have
a pretty big t/ directory (mp2's one is almost 2MB and growing), so copying is
going to be quite slow. Another problem is the cleanup, which may not always
work very well.
Moreover, let's say that you run under 'root'. Most likely
File::Temp/File::Spec::tmpdir will return /root/tmp as the temp dir, so it
solves nothing. What we really want is an equivalent of /tmp.
What we could do is prompt root for two inputs: a username of a real user
(e.g. 'stas' on my machine) and a dir where 'stas' can write to (e.g.
/home/stas/tmp) and then copy the files there and use that username to run the
test with.
In my original reply the best advise so far to avoid this problem is to
configure your .cpan dir to be under /tmp in which case running tests as root
is not a problem. However /tmp is often setup to be cleaned up on reboot, so
you may want to configure only 'build_dir' to be on that filesystem, e.g.:
#~/.cpan/CPAN/MyConfig.pm
#
$CPAN::Config = {
'cpan_home' = q[/root/.cpan],
'build_dir' = q[/tmp/.cpan/build],
...
};
__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: problems with Apache::Filter
Drox wrote: Hi I am having troubles trying to install the Apache module Apache::Filter I need this module installed, so I can use Apache::SSI with Apache::ASP I already have mod_perl installed. It seems to be installed ok. But when I try to install or test Apache::Filter, I get the following: Can't locate object method boot via package mod_perl at C:/Perl/site/lib/Apache/Constants.pm line 8 Any ideas? Could it mean that mod_perl is installed incorrectly? But I have checked it and it seems ok. But there is no boot method in the mod_perl directory, for some reason. It seems that you are trying to run mod_perl 1.0 modules with mod_perl 2.0. In order to help us to help you, you must always submit a complete bug report as explained here: http://perl.apache.org/bugs/ __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Craig Shelley wrote: On Tue, 2003-08-26 at 19:03, Stas Bekman wrote: Thanks, but you have missed the core dump's backtrace. I am sorry but I have never used core files before, so forgive me if I have done this all wrong. No worries, this task is not trivial. Your trace is almost perfect. The only missing things are the arguments to the functions in the trace. In order to get the arguments you need to rebuild mp with MP_DEBUG=1 as explained here: http://perl.apache.org/docs/2.0/user/help/help.html#Resolving_Segmentation_Faults (gdb) backtrace #0 0x4051cf58 in modperl_wbucket_flush () from /usr/lib/apache2/modules/mod_perl.so #1 0x4066f5de in XS_Apache__SubRequest_run () from /usr/local/lib/perl/5.8.0/auto/Apache/SubRequest/SubRequest.so Normally you should rebuild perl and apache with appropriate options as explained at the URL above to get the arguments for the perl and apache functions, but in this case the bug is most likely in mod_perl, so only rebuilding mod_perl with MP_DEBUG=1, getting a new segfault and a new trace will do. #2 0x405ad7ef in Perl_pp_entersub () from /usr/lib/libperl.so.5.8 #3 0x405a720a in Perl_runops_standard () from /usr/lib/libperl.so.5.8 #4 0x4054fa32 in Perl_call_sv () from /usr/lib/libperl.so.5.8 #5 0x4054f837 in Perl_call_sv () from /usr/lib/libperl.so.5.8 #6 0x405195da in modperl_callback () from /usr/lib/apache2/modules/mod_perl.so #7 0x4051c7ae in modperl_run_filter () from /usr/lib/apache2/modules/mod_perl.so #8 0x4051cba7 in modperl_output_filter_handler () from /usr/lib/apache2/modules/mod_perl.so #9 0x0807e66b in ap_pass_brigade () #10 0x08084c15 in ap_core_translate () #11 0x08073b0a in ap_run_handler () #12 0x0807401e in ap_invoke_handler () #13 0x0806767f in ap_process_request () #14 0x080638ed in _start () #15 0x0815e3f8 in ?? () #16 0x0004 in ?? () #17 0x0815e3f8 in ?? () I have not included the core file here because it was ~ 3Mb If you need it please let me know That was a wise decision. A core file is not very useful for our purposes if taken away from the setup it was originated from. Not talking about the fact that posting large emails is not appreciated. If such a need rises, one needs to upload the file somewhere on the web and post the URL to that file instead. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Installation problem
Ged Haywood wrote: Hello there, On Mon, 25 Aug 2003, Alan Rafagudinov wrote: I've downloaded apache_1.3.28.tar.gz mod_perl-1.28.tar.gz and unarchive it to /usr/src/httpd_perl for back-end server then when I make perl Makefile.PL APACHE_SRC=../apache_1.3.28/src/ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACI_ARGS='- -prefix=/usr/local/httpd_perl' [snip] modules/psections...ok modules/request.Use of uninitialized value in numeric eq (==) at modules/request.t line 147. Use of uninitialized value in concatenation (.) at modules/request.t line 147. [snip] Can you tell us a bit more about your system? The documentation gives you information about what information you need to give... What compiler was used to build your Perl, and was it the same compiler that you used to build mod_perl and Apache? Folks, please point bug reporters to http://perl.apache.org/bugs/, which provides the exact information we need to help them. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
