On Mon, 2003-06-02 at 09:05, cap wrote:
> i have an application that uses CGI and sets the cookie values as a hashref.
> im then attempting to retreive the values with Apache::Cookie with:
>
> $cookies = Apache::Cookie->fetch;
>
> $ccokies is a hashref so i should be able to get the individual values with:
>
> $cookies->{uid};
>
> right? however, this doesn't appear to work.
I see the problem. There is mistake in the Apache::Cookie
documentation, but the correct way to do this is shown in the mod_perl
guide:
http://perl.apache.org/docs/1.0/guide/porting.html#Converting_to_use_Apache_Perl\
_Modules
Change your last line to this:
my $uid = defined $cookies->{'uid'} ? $cookies->{'uid'}->value() :
undef;
- Perrin
arunappa@... wrote:
> -------------8<---------- Start Bug Report ------------8<----------
> 1. Problem Description:
>
> apache crashes when accessing this modperl script:
>
> package Apache::hello;
>
> use strict;
>
> use Apache::RequestRec ();
> use Apache::RequestIO ();
> use Apache::Const -compile => 'OK';
>
> sub handler {
> my $request = shift; # what does shift operate on @_?
> $request->content_type('text/html');
>
> $request->print(<<END);
> <HTML>
> <BODY>
> <H1>Hello There</H1>
> </BODY>
> </HTML>
> END
>
> return Apache::OK;
> }
>
> 2. Used Components and their Configuration:
>
> *** using
/usr/download/modperl/mod_perl-1.99_09/t/../lib/Apache/BuildConfig.pm
> *** Makefile.PL options:
> MP_AP_PREFIX => /usr/httpd20
> MP_COMPAT_1X => 1
> MP_GENERATE_XS => 1
> MP_INST_APACHE2 => 1
> MP_LIBNAME => mod_perl
> MP_USE_DSO => 1
> MP_USE_STATIC => 1
that's only a beginning of the report. Where is the rest? Why is it so hard to
copy-n-paste the report? OK, I'll do that for you.
> 3. This is the core dump trace: (if you get a core dump):
>
> Apache crashes but does not dump core. I set unlimit to unlimited,
> made sure the filesystem from which 'httpd -X' is run has enough free space.
> Still no core. Could not find Bad::Segv module either in modperl or in
> CPAN and therefore could not try to dump using a script like core_dump.pl
> mentioned in 'Debugging mod_perl C Internals' document.
Yeah, I need to update the Bad::Segv part. It's called Debug::DumpCore.
> I was able to run 'httpd -X' from inside gbd and got a stack trace:
>
> (gdb) bt
> #0 0x402f1f47 in modperl_wbucket_write ()
> from /usr/httpd20/modules/mod_perl.so
> #1 0x40638701 in mpxs_Apache__RequestRec_print ()
> from
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/Apache/RequestIO/R\
equestIO.so
> #2 0x406368c6 in XS_Apache__RequestRec_print ()
> from
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/Apache/RequestIO/R\
equestIO.so
> #3 0x403868c5 in Perl_pp_entersub ()
> from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
> #4 0x4037f059 in Perl_runops_standard ()
> from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
> #5 0x40327139 in S_call_body ()
> from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
> #6 0x40326eb6 in Perl_call_sv ()
> from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
> #7 0x402ed4e2 in modperl_callback () from /usr/httpd20/modules/mod_perl.so
> #8 0x402ed9e4 in modperl_callback_run_handlers ()
> from /usr/httpd20/modules/mod_perl.so
> #9 0x402edc25 in modperl_callback_per_dir ()
> from /usr/httpd20/modules/mod_perl.so
> #10 0x402e9105 in modperl_response_handler_run ()
> from /usr/httpd20/modules/mod_perl.so
> #11 0x402e9325 in modperl_response_handler_cgi ()
> from /usr/httpd20/modules/mod_perl.so
> #12 0x0807b67e in ap_run_handler (r=0x81a9268) at config.c:195
> #13 0x0807bb96 in ap_invoke_handler (r=0x81a9268) at config.c:401
> #14 0x0806baab in ap_process_request (r=0x81a9268) at http_request.c:288
> #15 0x08067ce9 in ap_process_http_connection (c=0x816d458) at http_core.c:293
> #16 0x08084476 in ap_run_process_connection (c=0x816d458) at connection.c:85
> #17 0x0807a234 in child_main (child_num_arg=1080249231) at prefork.c:696
> #18 0x0807a3de in make_child (s=0x80b6178, slot=0) at prefork.c:736
> #19 0x0807a437 in startup_children (number_to_start=5) at prefork.c:808
> #20 0x0807ab29 in ap_mpm_run (_pconf=0x8079b10, plog=0x80ebb50, s=0x80b6178)
> at prefork.c:1024
> #21 0x0807f842 in main (argc=2, argv=0xbffffa74) at main.c:660
> #22 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
The problem with this trace is that it doesn't show the arguments. You need to
build mod_perl with MP_DEBUG=1 and generate it again.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@... http://use.perl.orghttp://apacheweek.comhttp://modperlbook.orghttp://apache.orghttp://ticketmaster.com
Please bear with me -- I have recently picked up Apache2 and now trying
out mod_perl2
I see Apache::Status listed under the mod_perl2 docs -
http://perl.apache.org/docs/2.0/api/Apache/Status.html
But I only see mod_perl 1.27 on the CPAN site;
Is there another place to obtain a mod_perl2 type module?
( I did search the archives as best I was able - but I only see
postings about Apache::Status since 1999... )
I am not real sure I want to install mod_perl1 over my mod_perl2
Apache2 server code...
???/Sx ?
WC -Sx- Jones wrote:
>
> Please bear with me -- I have recently picked up Apache2 and now trying
> out mod_perl2
>
> I see Apache::Status listed under the mod_perl2 docs -
> http://perl.apache.org/docs/2.0/api/Apache/Status.html
>
> But I only see mod_perl 1.27 on the CPAN site;
mod_perl-1.99_09 is not indexed by PAUSE, hence you can't see it. (because of
_09). If you have installed it, you already have it. It's part of the distro.
> Is there another place to obtain a mod_perl2 type module?
>
> ( I did search the archives as best I was able - but I only see postings
> about Apache::Status since 1999... )
Grab it from here:
http://perl.apache.org/download/index.html
> I am not real sure I want to install mod_perl1 over my mod_perl2 Apache2
> server code...
;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@... http://use.perl.orghttp://apacheweek.comhttp://modperlbook.orghttp://apache.orghttp://ticketmaster.com
On Monday, June 2, 2003, at 08:29 PM, Stas Bekman wrote:
> WC -Sx- Jones wrote:
>> I see Apache::Status listed under the mod_perl2 docs -
>> http://perl.apache.org/docs/2.0/api/Apache/Status.html
> mod_perl-1.99_09 is not indexed by PAUSE, hence you can't see it.
> (because of _09). If you have installed it, you already have it. It's
> part of the distro.
You mean Apache::Status is in the mod_perl-1.99_09 build I downloaded ?
???/Sx ?
On Monday, June 2, 2003, at 09:19 PM, Stas Bekman wrote:
> Have you looked?
>
> http://perl.apache.org/dist/mod_perl-2.0-current/lib/Apache/Status.pm
Yes, of course. :)
My question: Was it not installed when I built mod_perl2 ?
So, on my server I looked for Apache --
[ results edited to remove ../docs and $HOME matches ]
# find / -name Apache -print
...
/usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris-thread-multi-64int/
auto/Apache
/usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris-thread-multi-64int/
Apache
...
Then I looked for Status -
# find / -name Status -print
( nothing is returned... )
Therefore it was not built when I installed mod_perl 2.
-Sx-
On Monday, June 2, 2003, at 09:19 PM, Stas Bekman wrote:
> http://perl.apache.org/download/index.html
Shouldn't there be a warning about mod_perl2 and CPAN then? CPAN
"definitely" wants to download and install mod_perl1 -- even over a
valid mod_perl2 installation...
Regarding the following off the "Other Modules" link on the download
page:
> There are several other Perl modules that you might wish to have
> installed, to take full advantage of mod_perl functionality. Provided
> you have Andreas König's CPAN.pm module, simply run:
>
> cpan> install Bundle::Apache
>
> This will fetch and install mod_perl and related packages for you all
> at once. Otherwise, once you've installed mod_perl see the listing by
> running
>
> % perldoc Bundle::Apache
I mean I have already built and used mod_perl2 now for a week -- can I
cast a vote to have CPAN updated?
-Sx- :)
Ignore me -
On Monday, June 2, 2003, at 09:37 PM, WC -Sx- Jones wrote:
> Yes, of course. :)
>
> My question: Was it not installed when I built mod_perl2 ?
I found (something) at
/usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris-thread-multi-64int/
Apache/Status.pm
Now all I have to do is figure out why it doesn't seem to want to
work...
Sorry/Sx
WC -Sx- Jones wrote:
>
> On Monday, June 2, 2003, at 09:19 PM, Stas Bekman wrote:
>
>> Have you looked?
>>
>> http://perl.apache.org/dist/mod_perl-2.0-current/lib/Apache/Status.pm
>
>
>
> Yes, of course. :)
>
> My question: Was it not installed when I built mod_perl2 ?
>
>
> So, on my server I looked for Apache --
> [ results edited to remove ../docs and $HOME matches ]
>
> # find / -name Apache -print
> ...
> /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris-thread-multi-64int/
> auto/Apache
> /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris-thread-multi-64int/
> Apache
> ...
>
> Then I looked for Status -
>
> # find / -name Status -print
it should be either:
find / -name Status.pm -print
or
find / -name "Status*" -print
> ( nothing is returned... )
>
>
> Therefore it was not built when I installed mod_perl 2.
run 'make install' and see whether it gets installed. I think if you correctly
use find's syntax you will find it.
It sure thing gets installed on my machine:
find /home/stas/perl/blead | grep Apache/Status.pm
/home/stas/perl/blead/lib/site_perl/5.9.0/i686-linux/Apache/Status.pm
/home/stas/perl/blead/lib/site_perl/5.9.0/i686-linux/Apache2/Apache/Status.pm
The first one is from mod_perl-1.27 distro, the second one is from
mod_perl-1.99_09 distro.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@... http://use.perl.orghttp://apacheweek.comhttp://modperlbook.orghttp://apache.orghttp://ticketmaster.com
WC -Sx- Jones wrote:
>
> On Monday, June 2, 2003, at 09:19 PM, Stas Bekman wrote:
>
>> http://perl.apache.org/download/index.html
>
>
>
> Shouldn't there be a warning about mod_perl2 and CPAN then? CPAN
> "definitely" wants to download and install mod_perl1 -- even over a
> valid mod_perl2 installation...
>
> Regarding the following off the "Other Modules" link on the download page:
>
>> There are several other Perl modules that you might wish to have
>> installed, to take full advantage of mod_perl functionality. Provided
>> you have Andreas König's CPAN.pm module, simply run:
>>
>> cpan> install Bundle::Apache
>>
>> This will fetch and install mod_perl and related packages for you all
>> at once. Otherwise, once you've installed mod_perl see the listing by
>> running
>>
>> % perldoc Bundle::Apache
>
>
>
> I mean I have already built and used mod_perl2 now for a week -- can I
> cast a vote to have CPAN updated?
CPAN is updated. But it's not indexed. It won't get indexed untill mod_perl
2.0 is released (that's _ is dropped from the distro name) and we aren't ready
for this yet.
You can get it from my CPAN dir:
http://search.cpan.org/author/STAS/mod_perl-1.99_09/
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@... http://use.perl.orghttp://apacheweek.comhttp://modperlbook.orghttp://apache.orghttp://ticketmaster.com
WC -Sx- Jones wrote:
> Ignore me -
>
> On Monday, June 2, 2003, at 09:37 PM, WC -Sx- Jones wrote:
>
>
>> Yes, of course. :)
>>
>> My question: Was it not installed when I built mod_perl2 ?
>
>
> I found (something) at
>
> /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris-thread-multi-64int/
> Apache/Status.pm
>
>
> Now all I have to do is figure out why it doesn't seem to want to work...
because it's a version for mod_perl 1. You should have used Apache2 to get the
new module. See:
http://perl.apache.org/docs/2.0/user/intro/start_fast.html#Configuration
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@... http://use.perl.orghttp://apacheweek.comhttp://modperlbook.orghttp://apache.orghttp://ticketmaster.com
Haroon Rafique wrote:
> system details are posted as cut-and-paste from t/REPORT output at the end
> of the email.
>
> Background:
>
> 1. make test passes 100% with 1.99_08
> 2. make test fails to start the webservers with 1.99_09
> 3. make test fails to start the webservers with 1.99_10-dev (cvs)
Right, the new feature was introduced in 1.99_09
> In the case of 1.99_09, following happens after running "make test"
>
> [Mon Jun 02 15:55:16 2003] [error] Invalid CODE attribute:
> TestFilter::out_init_basic at
> /home/haroon/src/build/mod_perl-1.99_09/t/filter/TestFilter/out_init_basic.pm
> line 33
> BEGIN failed--compilation aborted at
> /home/haroon/src/build/mod_perl-1.99_09/t/filter/TestFilter/out_init_basic.pm
> line 33.
> Compilation failed in require at (eval 21) line 3.
I hate when this happens :( I remember seeing this problem at some point, but
I wasn't able to reproduce it since then. I have exactly the same perl build
as in your report. The only difference is that I've built it with:
-Doptimize='-g'. I'm not sure if it'd make any difference. But can you try
building a custom perl using -Doptimize='-g' and all the options that you had:
> config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686
> -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red
> Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux
> -Dvendorprefix=/usr -Dsiteprefix=/usr -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'
and give it another try?
Anybody else sees this problem?
Another difference from perl -v is
- libc=/lib/libc-2.2.92.so, so=so, useshrplib=true, libperl=libperl.so
- gnulibc_version='2.2.92'
+ libc=/lib/libc-2.2.5.so, so=so, useshrplib=true, libperl=libperl.so
+ gnulibc_version='2.2.5'
but I doubt this has anything to do with it.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@... http://use.perl.orghttp://apacheweek.comhttp://modperlbook.orghttp://apache.orghttp://ticketmaster.com
Well, here's what I have to do to get direct access to values from the
original cookie hash:
my $cookies = Apache::Cookie->fetch;
my %hash = defined $cookies->{'session'} ? $cookies->{'session'}->value :
undef;
Strange. Thanks for the lead.
>-----Original Message-----
>From: Perrin Harkins [mailto:perrin@...]
>Sent: Monday, June 02, 2003 2:41 PM
>To: thecap@...
>Cc: modperl
>Subject: Re: Apache::Cookie
>
>
>On Mon, 2003-06-02 at 09:05, cap wrote:
>> i have an application that uses CGI and sets the cookie values
>as a hashref.
>> im then attempting to retreive the values with Apache::Cookie with:
>>
>> $cookies = Apache::Cookie->fetch;
>>
>> $ccokies is a hashref so i should be able to get the individual
>values with:
>>
>> $cookies->{uid};
>>
>> right? however, this doesn't appear to work.
>
>I see the problem. There is mistake in the Apache::Cookie
>documentation, but the correct way to do this is shown in the mod_perl
>guide:
>http://perl.apache.org/docs/1.0/guide/porting.html#Converting_to_us
>e_Apache_Perl_Modules
>
>Change your last line to this:
>
>my $uid = defined $cookies->{'uid'} ? $cookies->{'uid'}->value() :
>undef;
>
>- Perrin
>
cap wrote:
> Well, here's what I have to do to get direct access to values from the
> original cookie hash:
>
> my $cookies = Apache::Cookie->fetch;
> my %hash = defined $cookies->{'session'} ? $cookies->{'session'}->value :
> undef;
>
> Strange. Thanks for the lead.
That's a bogus code. Obviously you are running without warnings mode on. Add:
use warnings;
and you will see why it is bogus. Perhaps your cookie was always valid so you
didn't notice it. Howerer:
perl -lwe '%h = undef'
Name "main::h" used only once: possible typo at -e line 1.
Odd number of elements in hash assignment at -e line 1.
Use of uninitialized value in list assignment at -e line 1.
>>-----Original Message-----
>>From: Perrin Harkins [mailto:perrin@...]
>>Sent: Monday, June 02, 2003 2:41 PM
>>To: thecap@...
>>Cc: modperl
>>Subject: Re: Apache::Cookie
>>
>>
>>On Mon, 2003-06-02 at 09:05, cap wrote:
>>
>>>i have an application that uses CGI and sets the cookie values
>>
>>as a hashref.
>>
>>>im then attempting to retreive the values with Apache::Cookie with:
>>>
>>>$cookies = Apache::Cookie->fetch;
>>>
>>>$ccokies is a hashref so i should be able to get the individual
>>
>>values with:
>>
>>>$cookies->{uid};
>>>
>>>right? however, this doesn't appear to work.
>>
>>I see the problem. There is mistake in the Apache::Cookie
>>documentation, but the correct way to do this is shown in the mod_perl
>>guide:
>>http://perl.apache.org/docs/1.0/guide/porting.html#Converting_to_us
>>e_Apache_Perl_Modules
>>
>>Change your last line to this:
>>
>>my $uid = defined $cookies->{'uid'} ? $cookies->{'uid'}->value() :
>>undef;
>>
>>- Perrin
>>
>
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@... http://use.perl.orghttp://apacheweek.comhttp://modperlbook.orghttp://apache.orghttp://ticketmaster.com
On Mon, 2 Jun 2003, Slava Bizyayev wrote:
> I guess, your problem is out of Apache::Dynagzip. Please, try to follow:
>
> 1. Make sure your script is producing correct response under
> Apache::Registry.
Yes it does
>
> 2. Make sure your script does not have any internal conditional branches on
> whether it runs under Apache::Registry, or under Apache::RegistryFilter ->
> Apache::Dynagzip.
>
No it doesn't
> 3. Do your transition from Apache::Registry configuration to
> Apache::RegistryFilter -> Apache::Dynagzip configuration by simple
> replacement of the line:
>
> PerlHandler Apache::Registry
>
> with the following two lines:
>
> PerlHandler Apache::RegistryFilter Apache::Dynagzip
> PerlSetVar Filter On
>
Okay now it works! So problem was in my httpd.conf file.
Now I only have
<Directory /usr/local/systems/work/>
# AUTH
AuthType Apache::Authenticate
AuthName protected
PerlAccessHandler Apache::OpenAccess
PerlAuthenHandler Apache::Authenticate->authenticate
require valid-user
<Files *.html>
PerlSendHeader On
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
</Files>
## DYNA
<Files *.pl>
PerlSendHeader On
SetHandler perl-script
PerlHandler Apache::RegistryFilter Apache::Dynagzip
PerlSetVar Filter On
Options +ExecCGI
#PerlSetVar LightCompression On
# Below not needed ??
#PerlSetVar UseCGIHeadersFromScript Off
#PerlSendHeader Off
#PerlSetupEnv On
</Files>
</Directory>
> You may optionally add light compression finally if you want. You are not
> supposed to change any other settings.
>
But if I turn on PerlSetVar LightCompression On the problem comes back.
I had tested having this line commented out but it made no difference.
Anyway good that it is working.
Thanks.
Regards
Scott
> 4. Let us know details of what you finally have.
>
> Thanks,
> Slava
>
>
> ----- Original Message -----
> From: "Scott Alexander" <mod_perl@...>
> To: <modperl@...>
> Sent: Monday, June 02, 2003 5:26 AM
> Subject: Missing html code using dynagzip
>
>
> > Hi,
> >
> > When using
> >
> > <Files *.pl>
> > SetHandler perl-script
> > PerlHandler Apache::RegistryFilter Apache::Dynagzip
> > PerlSetVar Filter On
> >
> > PerlSetVar LightCompression On
> > Options +ExecCGI
> >
> > PerlSetVar UseCGIHeadersFromScript Off
> > PerlSendHeader Off
> > PerlSetupEnv On
> > </Files>
> >
> > this setup with NN 6+ the code ends with
> >
> > </html></html> (yes twice) and in IE 6.0 it has just </html (missing the
> > last '>' With NN 4.8 it is the same as IE 6.0.
> >
> > Does anyone know why this happens?
> >
> > I've tried putting all my output into one print statement. Makes no
> > difference.
> >
> > Scott
> >
> >
> >
> >
> >
> >
>
From: "Scott Alexander" <mod_perl@...>
To: "Slava Bizyayev" <sbizyaye@...>
Cc: <modperl@...>
Sent: Tuesday, June 03, 2003 12:31 AM
Subject: Re: Missing html code using dynagzip
> Okay now it works! So problem was in my httpd.conf file.
>
> Now I only have
>
> <Directory /usr/local/systems/work/>
>
> # AUTH
> AuthType Apache::Authenticate
> AuthName protected
> PerlAccessHandler Apache::OpenAccess
> PerlAuthenHandler Apache::Authenticate->authenticate
> require valid-user
>
> <Files *.html>
> PerlSendHeader On
> SetHandler perl-script
> PerlHandler Apache::Registry
> Options +ExecCGI
> </Files>
>
> ## DYNA
> <Files *.pl>
> PerlSendHeader On
> SetHandler perl-script
> PerlHandler Apache::RegistryFilter Apache::Dynagzip
> PerlSetVar Filter On
> Options +ExecCGI
> #PerlSetVar LightCompression On
>
> # Below not needed ??
> #PerlSetVar UseCGIHeadersFromScript Off
> #PerlSendHeader Off
> #PerlSetupEnv On
These depend on your global settings, and on requirements of your script
only. You should never add them for Apache::Dynagzip exclusively.
> </Files>
> </Directory>
>
> But if I turn on PerlSetVar LightCompression On the problem comes back.
> I had tested having this line commented out but it made no difference.
Wow! Sounds like the first bug in Compress::LeadingBlankSpaces...
Let's talk about that. Compress::LeadingBlankSpaces is prutty simple class.
It is not that important when your content is really gzipped, because blank
spaces are compressed very effectively. It is mostly required for some old
and buggy clients who does not understand gzip really (NN-4.X for instance).
BTW do you use Apache::CompressClientFixup? It should help to serve NN-4.X
appropriately.
Back to Compress::LeadingBlankSpaces, could you send me your version number?
Thanks,
Slava
Hi -
I'm working on an embedding project, and using mod_perl
as a tutorial (OK, I'm sometimes blatantly stealing code :)).
My tests on a WIN32 box (Win2K) are somewhat flaky.
Linux is solid. A grep of mod perl source on WIN32 led me
to so pretty strange "environment array" spoofing based upon
#ifdef USE_ENVIRON_ARRAY in modperl_perl.c.
The only greps to USE_ENVIRON_ARRAY are in
modperl_perl.c. NO greps in the Perl source. NO references
(that I could find) on the mod_perl web site.
Does anyone know if this is used? If so, where can I look to get
an idea of what it is for (my guess is to tell whether or not to
pass the environment array to perl_... calls)?
Aloha => Beau;
Version 3.1 of CGI::Application is now available via CPAN!
Download site for CGI::Application:
http://search.cpan.org/dist/CGI-Application/
CHANGES SINCE VERSION 3.0:
- Changed dump_html default run-mode to be referenced by name
instead of sub-ref. This allows dump_html() to be overridden
in sub-class.
- Added current run-mode to output of dump() and dump_html().
(Thanks to Mark Stosberg for the suggestion.)
- Added example of doing an HTTP redirect (suggested by Sam Tregar)
- Fixed bug where non-CGI.pm query objects couldn't be set
at initialization time via the new() method. (Thanks to Steve
Hay for the catch.)
- Added header_type("none") to suppress HTTP header output.
(Thanks to Steve Comrie for the suggestion.)
- Numerous typos corrected in POD.
- Added cgiapp_postrun() hook. This hook allows run-mode output
to be "pipelined" through optional filters, modifying the
content and HTTP headers if so desired.
Read the article "Using CGI::Application" on Perl.com for an
overview of this module and its usage:
http://www.perl.com/pub/a/2001/06/05/cgi.html
CGI::Application is intended to make it easier to create sophisticated,
reusable web-based applications. This module implements a methodology
which,
if followed, will make your web software easier to design, easier to
document, easier to write, and easier to evolve.
CGI::Application builds on standard, non-proprietary technologies and
techniques, such as the Common Gateway Interface and Lincoln D. Stein's
excellent CGI.pm module. CGI::Application judiciously avoids employing
technologies and techniques which would bind a developer to any one set
of tools, operating system or web server.
The guiding philosophy behind CGI::Application is that a web-based
application can be organized into a specific set of "Run-Modes." Each
Run-Mode is roughly analogous to a single screen (a form, some output,
etc).
All the Run-Modes are managed by a single "Application Module" which is
a
Perl module. In your web server's document space there is an "Instance
Script" which is called by the web server as a CGI (or an
Apache::Registry
script if you're using Apache + mod_perl).
CGI::Application is an Object-Oriented Perl module which implements an
Abstract Class. It is not intended that this package be instantiated
directly. Instead, it is intended that your Application Module will be
implemented as a Sub-Class of CGI::Application.
If you have any questions, comments, bug reports or feature suggestions,
post them to the support mailing list! To join the mailing list, simply
send a blank message to "cgiapp-subscribe@...".
--
Jesse Erlbaum
The Erlbaum Group
jesse@...
Phone: 212-684-6161
Fax: 212-684-6226
Hello,
I'm using redhat 8.0 (mod_perl-1.99_05-3, httpd-2.0.40-11.3). I created
a custom handler for http responses, and I get this error in httpd log:
[Tue Jun 03 07:42:53 2003] [error] [client 127.0.0.1] Can't locate
object method "header_in" via package "Apache::RequestRec" at
/usr/lib/perl5/site_perl/sgi/apache/cgi/init.pm line 27.!, referer:
http://localhost:8080/main.html
BUT, I have other redhat 8.0 implementation with the same handler and
does not have this problem.
Any suggestions....
Thanks...
Alejandro
Hello!
after being a long time away (over 4 years since my last post on this
list), I started again with some development with mod_perl for this
company that I currently work for.
I'm having some trouble with CGI.pm working with mod_perl2. I searched
the mailing-list for this and I found many different point of views for
this problem, some say it should work, and some say it doesn't. I've
tested it and it really doesn't work "as is". This guy clearly says
that CGI.pm is incompatible with mod_perl2:
http://marc.theaimsgroup.com/?l=apache-modperl&m=103619647305553&w=2
This isn't really a big problem, but I have 3 ways out:
1) help make CGI.pm compatible with mod_perl2 if at all possible
2) replace all CGI.pm calls with simple homemade cgi functions (not
difficult, it's just that we have to correct many scripts that already
count on CGI.pm), or use that "Apache::compat" thing
3) downgrade apache to 1.3.27 and mod_perl to 1.27 and be happy
Option 3 seems okay, excect for the fact that I am that kind of Linux
user that is always upgrading everything to the latest version possible.
This applies to linux kernel, apache, etc. I don't really have a reason
to do this, but I have always done it anyway.
So to use apache 1.3.27 and mod_perl 1.27 goes against my nature. Am I
going to hell if I do this? Seriously, does mod_perl2 offer much more
features and benefits then mod_perl1? I really only care for speed and
stability for simple perl scripts that use CGI/DBI/DBD::mysql modules.
Is it okay if I use mod_perl and apache 1.x today, or it's better to
move to 2.x already?
Thanks, Henrique.
Hi there,
On Tue, 3 Jun 2003, Henrique Pantarotto wrote:
> 3) downgrade apache to 1.3.27 and mod_perl to 1.27 and be happy
>
> Option 3 seems okay, excect for the fact that I am that kind of Linux
> user that is always upgrading everything to the latest version possible.
> This applies to linux kernel, apache, etc. I don't really have a reason
> to do this, but I have always done it anyway.
You're nuts. I'd fire you. :)
Just out of interest, which kernel are you using?
> I really only care for speed and stability for simple perl scripts
> that use CGI/DBI/DBD::mysql modules.
Well *real* Linux users only code in C and assembler - that'll give you the
speed...
> Is it okay if I use mod_perl and apache 1.x today, or it's better to
> move to 2.x already?
By and large, 1.x is what the business world is using, and 2.x is
not-quite-bleeding-edge. Before Stas jumps on me again, there's not a
lot wrong with it, but I won't be using it for anything that involves
money until things have settled down quite a lot.
Have you asked your employer what he thinks about it?
73,
Ged.
Henrique Pantarotto wrote:
> I'm having some trouble with CGI.pm working with mod_perl2.
What trouble are you having?
> This guy clearly says
> that CGI.pm is incompatible with mod_perl2:
>
> http://marc.theaimsgroup.com/?l=apache-modperl&m=103619647305553&w=2
That was 7 months ago. A lot has changed.
Keep in mind, CGI.pm doesn't entirely work with mod_perl 1. It uses
global variables internally, so it has to clear them with a cleanup
handler, and there are issues around subrequests.
> This isn't really a big problem, but I have 3 ways out:
>
> 1) help make CGI.pm compatible with mod_perl2 if at all possible
>
> 2) replace all CGI.pm calls with simple homemade cgi functions (not
> difficult, it's just that we have to correct many scripts that already
> count on CGI.pm), or use that "Apache::compat" thing
You could try CGI::Simple, which has the same (OO) interface as CGI.pm.
> 3) downgrade apache to 1.3.27 and mod_perl to 1.27 and be happy
That would work fine as well.
> Seriously, does mod_perl2 offer much more
> features and benefits then mod_perl1? I really only care for speed and
> stability for simple perl scripts that use CGI/DBI/DBD::mysql modules.
It offers many new features, which are described here:
http://perl.apache.org/docs/2.0/user/intro/overview.html#What_s_new_in_mod_perl_\
2_0
The most common reasons for switching at this point are to get filtering
or to get multi-threading on Win32.
> Is it okay if I use mod_perl and apache 1.x today, or it's better to
> move to 2.x already?
Many people are stil developing on 1.x, including me, and there is a new
release of it due out any day. Go ahead, if that makes you more
comfortable.
- Perrin
On Today at 12:03pm, SB=>Stas Bekman <stas@...> wrote:
SB>
SB> > In the case of 1.99_09, following happens after running "make test"
SB> >
SB> > [Mon Jun 02 15:55:16 2003] [error] Invalid CODE attribute:
SB> > TestFilter::out_init_basic at
SB> >
/home/haroon/src/build/mod_perl-1.99_09/t/filter/TestFilter/out_init_basic.pm
SB> > line 33 BEGIN failed--compilation aborted at
SB> >
/home/haroon/src/build/mod_perl-1.99_09/t/filter/TestFilter/out_init_basic.pm
SB> > line 33. Compilation failed in require at (eval 21) line 3.
SB>
SB> I hate when this happens :( I remember seeing this problem at some
SB> point, but I wasn't able to reproduce it since then. I have exactly
SB> the same perl build as in your report. The only difference is that
SB> I've built it with: -Doptimize='-g'. I'm not sure if it'd make any
SB> difference. But can you try building a custom perl using
SB> -Doptimize='-g' and all the options that you had:
Hi Stas,
Unfortunately I only have developer access on that machine. Since I don't
have root access does this mean that first I might have to install perl as
a regular user in my home directory and then install mod_perl built
against the locally built perl?
SB>
SB> > config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686
SB> > -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc
SB> > -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr
SB> > -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr
SB> > -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid
SB> > -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog
SB> > -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005
SB> > -Uversiononly -Dpager=/usr/bin/less -isr'
SB>
SB> and give it another try?
SB>
SB> Anybody else sees this problem?
SB>
We could wait and see if anyone else has the same problem.
SB> Another difference from perl -v is
SB> - libc=/lib/libc-2.2.92.so, so=so, useshrplib=true, libperl=libperl.so
SB> - gnulibc_version='2.2.92'
SB> + libc=/lib/libc-2.2.5.so, so=so, useshrplib=true, libperl=libperl.so
SB> + gnulibc_version='2.2.5'
SB>
SB> but I doubt this has anything to do with it.
SB>
Cheers,
--
Haroon Rafique
<haroon.rafique@...>
Sorry, I've just hit a wrong button...
----- Original Message -----
From: "Slava Bizyayev" <sbizyaye@...>
To: "Scott Alexander" <mod_perl@...>
Sent: Tuesday, June 03, 2003 9:41 AM
Subject: Re: Missing html code using dynagzip
> ----- Original Message -----
> From: "Scott Alexander" <mod_perl@...>
> To: "Slava Bizyayev" <sbizyaye@...>
> Sent: Tuesday, June 03, 2003 4:06 AM
> Subject: Re: Missing html code using dynagzip
>
>
> > Well only by experiment I noticed the problem went away. The
> > Compress::LeadingBlankSpaces reduced the bytes sent by still abit.
>
> I'm glad to know that...
>
> > Could the problem be caused by some other setting I have in httpd.conf
> > file?
>
> Difficult to say blindly...
>
>
> Thanks,
> Slava
>
it works just fine in my app, and 'just fine' maybe all that i need. do you
have a better solution, or are you just pointing out the error?
>-----Original Message-----
>From: Stas Bekman [mailto:stas@...]
>Sent: Monday, June 02, 2003 10:08 PM
>To: thecap@...
>Cc: Perrin Harkins; modperl
>Subject: Re: Apache::Cookie
>
>
>cap wrote:
>> Well, here's what I have to do to get direct access to values from the
>> original cookie hash:
>>
>> my $cookies = Apache::Cookie->fetch;
>> my %hash = defined $cookies->{'session'} ? $cookies->{'session'}->value :
>> undef;
>>
>> Strange. Thanks for the lead.
>
>That's a bogus code. Obviously you are running without warnings
>mode on. Add:
>
>use warnings;
>
>and you will see why it is bogus. Perhaps your cookie was always
>valid so you
>didn't notice it. Howerer:
>
>perl -lwe '%h = undef'
>Name "main::h" used only once: possible typo at -e line 1.
>Odd number of elements in hash assignment at -e line 1.
>Use of uninitialized value in list assignment at -e line 1.
>
>
>
>
>>>-----Original Message-----
>>>From: Perrin Harkins [mailto:perrin@...]
>>>Sent: Monday, June 02, 2003 2:41 PM
>>>To: thecap@...
>>>Cc: modperl
>>>Subject: Re: Apache::Cookie
>>>
>>>
>>>On Mon, 2003-06-02 at 09:05, cap wrote:
>>>
>>>>i have an application that uses CGI and sets the cookie values
>>>
>>>as a hashref.
>>>
>>>>im then attempting to retreive the values with Apache::Cookie with:
>>>>
>>>>$cookies = Apache::Cookie->fetch;
>>>>
>>>>$ccokies is a hashref so i should be able to get the individual
>>>
>>>values with:
>>>
>>>>$cookies->{uid};
>>>>
>>>>right? however, this doesn't appear to work.
>>>
>>>I see the problem. There is mistake in the Apache::Cookie
>>>documentation, but the correct way to do this is shown in the mod_perl
>>>guide:
>>>http://perl.apache.org/docs/1.0/guide/porting.html#Converting_to_us
>>>e_Apache_Perl_Modules
>>>
>>>Change your last line to this:
>>>
>>>my $uid = defined $cookies->{'uid'} ? $cookies->{'uid'}->value() :
>>>undef;
>>>
>>>- Perrin
>>>
>>
>
>
>--
>
>
>__________________________________________________________________
>Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
>http://stason.org/ mod_perl Guide ---> http://perl.apache.org
>mailto:stas@... http://use.perl.orghttp://apacheweek.com
>http://modperlbook.orghttp://apache.orghttp://ticketmaster.com
>
>
On Tue, 2003-06-03 at 13:08, cap wrote:
> it works just fine in my app, and 'just fine' maybe all that i need.
The point is, it shouldn't work. You should not be getting a hash.
What should work is this:
my $session = defined $cookies->{'session'} ?
$cookies->{'session'}->value : undef;
The larger issue is fixing the Apache::Cookie docs. I would attempt to
patch it if I understood what it's doing. Does anyone know what the API
is returning when you call fetch()? An Apache::Table? Some other kind
of object? It looks pretty bizarre to me, and it certainly isn't doing
what the docs show.
- Perrin
well, the (long) wait is now over - "Practical mod_perl" is here.
weighing in at a whopping 924 pages, "Practical mod_perl" really needs no
introduction for those that are already familiar with the mod_perl Guide.
however, from the ORA catalog description:
"From writing and debugging scripts to keeping your server running without
failures, the techniques in this book will help you squeeze every ounce of
power out of your server. True to its title, this is the practical guide to
mod_perl."
O'Reilly has a sample chapter online
http://www.oreilly.com/catalog/pmodperl/chapter/ch06.pdf
the book's official website is
http://www.modperlbook.org/
where you will find links to ways to purchse the book.
kudos Stas and Eric!
--Geoff
Geoffrey Young wrote:
> well, the (long) wait is now over - "Practical mod_perl" is here.
>
> weighing in at a whopping 924 pages, "Practical mod_perl" really needs
> no introduction for those that are already familiar with the mod_perl
> Guide. however, from the ORA catalog description:
>
> "From writing and debugging scripts to keeping your server running
> without failures, the techniques in this book will help you squeeze
> every ounce of power out of your server. True to its title, this is
> the practical guide to mod_perl."
>
> O'Reilly has a sample chapter online
>
> http://www.oreilly.com/catalog/pmodperl/chapter/ch06.pdf
>
> the book's official website is
>
> http://www.modperlbook.org/
>
> where you will find links to ways to purchse the book.
>
> kudos Stas and Eric!
>
> --Geoff
>
>
I have a mod_perl book but I am looking forward to one that includes
mod_perl. I believe, corporate IT should take a serious look at using
mod_perl. It is time for the heads to come out of the sand. I am
interested in creating a presentation for my employer. I need
information that reeks (yes I want it to stink) with credibility. Any
pointers in this regard is welcome.
Send Email
