Re: problem of persistance
Stas Bekman wrote:
Arnaud Blancher wrote:
thank you
it's seems to be ok.
i ll read again closure in camel book !
See also:
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Understanding_Closuresthe_Easy_Way
ok
first, i suppose i can't forbiden closure in my script !
but it was a good option for me !
second
the little probleme is when i test script with
perl -wc ./test.pl
i have no warning ... so that no easy to see
it will a problem under MP
when i put all my script in a
sub run {
...
}
i see the potential problem of mod perl but it's not a really good solution
to change the script every times i want to test !
but i see the warning :-)
third
i put a 'use warning' in the script.
In the apache error log i see the warning. that's ok
but i must restart the serveur when i change a module, that's more boring .
is it better way to test ?
At this time, there noting in the
http://perl.apache.org/docs/2.0/devel/debug/perl.html
:-(
maybe i'm the once to bug !
Arnaud.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[MP2] problem with persistance in CGI.pm params
Hi,
Until yesterday I retrieved input variables to my CGI scripts myself.
Now I need to do file uploads so decided to use CGI.pm (3.05).
Unfortunately I'm getting a problem where if I restart the server and
run the program it get s variables fine but on all subsequent request it
still only ever sees the original input parameters.
I'm using httpd-2.0.50, mod_perl-1.99_14 and perl5.8.3 on Debian.
To try and find my problem i created a small script :
#!/cp/apps/bin/perl
use CGI;
use strict;
use warnings;
my $q = CGI->new();
my $params = $q->Vars();
print "Content-type: text/html\n\n";
foreach my $key (keys %{$params}) {
print "Key : $key - Param $params->{$key}";
}
It behaves exactly like my main program. I've been through as much of
the Mod_perl docs as I could understand and searched google to no avail.
I found some information in the CGI.pm docs but none of it appears to
be applicable here.
I have also tried getting my $r = Apache->request; and passing it to
CGI->new() but all I get back is :
Key : Apache::RequestRec - Param SCALAR(0x82a13f8)
I would really appreciate if someone can point out where I'm going wrong.
Thanks,
Ewan.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: problem of persistance
Arnaud Blancher wrote: [...] third i put a 'use warning' in the script. In the apache error log i see the warning. that's ok but i must restart the serveur when i change a module, that's more boring . is it better way to test ? Are you looking for http://perl.apache.org/docs/2.0/api/Apache/Reload.html? At this time, there noting in the http://perl.apache.org/docs/2.0/devel/debug/perl.html :-( maybe i'm the once to bug ! Arnaud. Reclaim Your Inbox! http://www.mozilla.org/products/thunderbird -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] patch for addvar/setvar merging
> So I trimmed a few lines out of the patch, ran the tests again, and > this time I will cut and paste it into the message: hi. I'm starting to review this now but I can't get the patch to apply. can you please re-post the patch as an attachment and make sure that it's a unified diff with context - it doesn't look like a context diff, which makes it difficult for me to read on it's own. the patch should apply cleanly against current cvs with [mod_perl-2.0]$ patch -p0 < perlsetvar.patch thanks --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [ANNOUNCE] Apache::Session::Memcached 0.02
On Fri, 17 Sep 2004 10:45:18 -0400 Perrin Harkins <[EMAIL PROTECTED]> wrote: Hi Perrin, > Enrico Sorcinelli wrote: > > I'm glad to announce Apache::Session::Memcached. > > This module provides a way to use memcached as Apache::Session storage > > implementation > > I wouldn't recommend using memcached for storing sessions. Memcached is > explicitly unreliable storage. It is built with the premise that you > won't put anything into it that you care about losing. > If it gets full, > it will simply drop data from storage. The mechanism for failover > across multiple machines also counts on being able to lose all the data > from one machine without it being a big deal. Yes, I know. Probably, a RDBMS as session datastore is currently best (and economical) solution for multiple frontends. Another solution is a load-balancer with sticky sessions. I'm investigating in order to search fastest datastore, so, I wrote also A::S::M since I worked with memcached in the past and I there was not a Apache::Session implementation (moreover, this has been a good exercise in order to better hacking in deep Apache::Session :-)) I've done some basic benchmarks using Apache::Session::Flex with different datastores and memcached is very fast when sessions number grows (see below). > Memcached would be better suited to acting as a write-through cache for > session data that you store in a database. Please, can you better explain? Tnx, for comments! ;-) by - Enrico --- my Apache::Session(::Flex) benchmark results *** *** 10 *** *** Store: File, Times: 50 the code took: 0 wallclock secs ( 0.05 usr + 0.01 sys = 0.06 CPU) Store: Memcached, Times: 50 the code took: 0 wallclock secs ( 0.15 usr + 0.00 sys = 0.15 CPU) Store: MySQL, Times: 50 the code took: 1 wallclock secs ( 0.18 usr + 0.03 sys = 0.21 CPU) Store: DB_File, Times: 50 the code took: 0 wallclock secs ( 0.07 usr + 0.01 sys = 0.08 CPU) Store: SharedMem, Times: 50 the code took: 0 wallclock secs ( 0.11 usr + 0.00 sys = 0.11 CPU) *** *** 100 *** *** Store: File, Times: 100 the code took: 0 wallclock secs ( 0.09 usr + 0.02 sys = 0.11 CPU) Store: Memcached, Times: 100 the code took: 1 wallclock secs ( 0.14 usr + 0.04 sys = 0.18 CPU) Store: MySQL, Times: 100 the code took: 0 wallclock secs ( 0.38 usr + 0.00 sys = 0.38 CPU) Store: DB_File, Times: 100 the code took: 1 wallclock secs ( 0.22 usr + 0.02 sys = 0.24 CPU) Store: SharedMem, Times: 100 the code took: 0 wallclock secs ( 0.32 usr + 0.00 sys = 0.32 CPU) *** *** 1000 *** *** Store: File, Times: 1000 the code took: 1 wallclock secs ( 0.79 usr + 0.21 sys = 1.00 CPU) Store: Memcached, Times: 1000 the code took: 2 wallclock secs ( 1.21 usr + 0.08 sys = 1.29 CPU) Store: MySQL, Times: 1000 the code took: 5 wallclock secs ( 2.98 usr + 0.17 sys = 3.15 CPU) Store: DB_File, Times: 1000 the code took: 3 wallclock secs ( 1.73 usr + 0.29 sys = 2.02 CPU) Store: SharedMem, Times: 1000 the code took:19 wallclock secs (18.11 usr + 0.94 sys = 19.05 CPU) *** *** 1 *** *** Store: File, Times: 1 the code took:21 wallclock secs ( 9.33 usr + 11.12 sys = 20.45 CPU) Store: Memcached, Times: 1 the code took:20 wallclock secs (12.45 usr + 1.09 sys = 13.54 CPU) Store: MySQL, Times: 1 the code took:41 wallclock secs (29.34 usr + 1.25 sys = 30.59 CPU) Store: DB_File, Times: 1 the code took:33 wallclock secs (14.90 usr + 1.89 sys = 16.79 CPU) Store: SharedMem, Times: 1 the code took:2657 wallclock secs (2450.79 usr + 196.40 sys = 2647.19 CPU) -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[patch] Problem using Apache::Session::SharedMem with Apache::Session::Flex
Hi, lately, I used Apache::Session::SharedMem 0.05 and I found a little bug using it with Apache::Session::Flex. I attached a very simple patch. Also, i suggest to add some tests into the distro in order to use also Apache::Session::Flex by - Enrico A-S-SM_0.05.patch Description: Binary data -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Apache-AuthenNTLM-2.07 and ModPerl 1.99_16
Fails as Apache-AuthenNTLM attempts to use Apache::Connection::remote_host
to alter the remote hostname so it can check to see if is the same
connection when it is next called:
>From AuthenNTLM.pm:
539 # we cannot attach our object to the connection record. Since in
540 # Apache 1.3 there is only one connection at a time per process
541 # we can cache our object and check if the connection has changed.
542 # The check is done by slightly changing the remote_host member, which
543 # persists as long as the connection does
544 # This has to be reworked to work with Apache 2.0
545 if (ref ($cache) ne $class || $$conn != $cache -> {connectionid} || $conn ->
remote_host ne $cache->{remote_host})
546 {
547 $conn -> remote_host ($conn -> remote_host . ' ') ;
548 $self = {connectionid => $$conn, remote_host => $conn -> remote_host} ;
This breaks in 1.99_16, but AuthenNTLM suggests it has ModPerl 2 support
written in, so is this something that has changed recently?
I'm also not exactly sure why there are three checks (ie. that there is a
cache object, that the cache object connection id is the same as the
current, and then that the (altered) remote host name is the same in
both). I would have thought it would be enought to compare the
connectionid, but this seems to stay the same between connections..?
Any ideas?
ta,
Chris
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache-AuthenNTLM-2.07 and ModPerl 1.99_16
Chris Hughes wrote:
Fails as Apache-AuthenNTLM attempts to use Apache::Connection::remote_host
to alter the remote hostname so it can check to see if is the same
connection when it is next called:
From AuthenNTLM.pm:
539 # we cannot attach our object to the connection record. Since in
540 # Apache 1.3 there is only one connection at a time per process
541 # we can cache our object and check if the connection has changed.
542 # The check is done by slightly changing the remote_host member, which
543 # persists as long as the connection does
544 # This has to be reworked to work with Apache 2.0
545 if (ref ($cache) ne $class || $$conn != $cache -> {connectionid} || $conn ->
remote_host ne $cache->{remote_host})
546 {
547 $conn -> remote_host ($conn -> remote_host . ' ') ;
548 $self = {connectionid => $$conn, remote_host => $conn -> remote_host} ;
See
http://gossamer-threads.com/lists/engine?list=modperl&do=search_results&search_forum=forum_4&search_string=%22Report+on+mp2+accessors+in+apache_structures.map%22&search_type=AND
This method is defined read-only. But it's suggested to make it
read/writeable again (see last message from stas).
The change has been introduced here:
http://cvs.apache.org/viewcvs.cgi/modperl-2.0/xs/maps/apache_structures.map?r1=text&tr1=1.41&r2=text&tr2=1.42&diff_format=h
And is also menntionned into the changelog
http://perl.apache.org/dist/mod_perl-2.0-current/Changes of 1.99_15.
I really have no idea about Apache-AuthenNTLM but to make it working
again you could apply the patch below and rebuilt your mod-perl. As far
as I can tell from the last mail from Stas it's going to be
read/writeable in future if one volunteers to write tests :-).
Tom
This breaks in 1.99_16, but AuthenNTLM suggests it has ModPerl 2 support
written in, so is this something that has changed recently?
I'm also not exactly sure why there are three checks (ie. that there is a
cache object, that the cache object connection id is the same as the
current, and then that the (altered) remote host name is the same in
both). I would have thought it would be enought to compare the
connectionid, but this seems to stay the same between connections..?
Any ideas?
ta,
Chris
Reclaim Your Inbox!
http://www.mozilla.org/products/thunderbird
Index: apache_structures.map
===
RCS file: /home/cvspublic/modperl-2.0/xs/maps/apache_structures.map,v
retrieving revision 1.48
diff -u -r1.48 apache_structures.map
--- apache_structures.map 17 Sep 2004 00:07:24 - 1.48
+++ apache_structures.map 20 Sep 2004 17:15:58 -
@@ -106,7 +106,7 @@
< local_addr
< remote_addr
< remote_ip
-< remote_host
+ remote_host
- remote_logname
< aborted
keepalive
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache-AuthenNTLM-2.07 and ModPerl 1.99_16
> I really have no idea about Apache-AuthenNTLM but to make it working
> again you could apply the patch below and rebuilt your mod-perl.
> As far
> as I can tell from the last mail from Stas it's going to be
> read/writeable in future if one volunteers to write tests :-).
I originally suggested that change as a result of reviewing the map
structures after running into this same problem on a different method of a
read only accessor breaking an existing module. So I am due some flak
here for suggesting other methods be read-only, as it has broken something
else. Maybe I can volunteer to write tests for those methods as a way of
making amends.
Here's a patch for AuthenNTLM.pm which uses $conn->notes, instead of
modifying $conn->remote_host, to compare the connections. I don't have a
working NTLM setup but maybe give this a go and see how it works.
--- AuthenNTLM.pm 2004-09-20 12:44:03.028383768 -0400
+++ AuthenNTLM.pm 2004-09-20 12:58:02.975692368 -0400
@@ -542,14 +542,23 @@
# The check is done by slightly changing the remote_host member, which
# persists as long as the connection does
# This has to be reworked to work with Apache 2.0
-if (ref ($cache) ne $class || $$conn != $cache -> {connectionid} ||
$conn ->
remote_host ne $cache->{remote_host})
-{
- $conn -> remote_host ($conn -> remote_host . ' ') ;
-$self = {connectionid => $$conn, remote_host => $conn ->
remote_host} ;
-bless $self, $class ;
- $cache = $self ;
- print STDERR "[$$] AuthenNTLM: Setup new object\n" if ($debug) ;
+if (ref ($cache) ne $class || $$conn != $cache->{connectionid} ||
+(!MP2 && $conn->remote_host ne $cache->{remote_host}) ||
+(MP2 && $conn->notes ne $cache->{notes}))
+{
+if (!MP2) {
+$conn->remote_host ($conn -> remote_host . ' ') ;
+$self = {connectionid => $$conn,
+ remote_host => $conn -> remote_host} ;
}
+elsif (MP2) {
+$conn->notes($$self);
+$self = {connectionid => $$conn, notes => $conn->notes};
+}
+bless $self, $class ;
+$cache = $self ;
+print STDERR "[$$] AuthenNTLM: Setup new object\n" if ($debug) ;
+}
else
{
$self = $cache ;
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] patch for addvar/setvar merging
Rici Lake wrote: > On 17-Sep-04, at 4:55 PM, Stas Bekman wrote: > >> I'd rather not add new directives, but have: > > > On reflection, I think I agree. It is possible to achieve virtually > the same effect with > > PerlSetVar foo "" > > So I trimmed a few lines out of the patch, ran the tests again, and > this time I will cut and paste it into the message: while my head is still spinning from all of this, I've reviewed the patch and committed it with only a few style changes. boy, I'm glad I took the time to write all those merge tests while it was all still fresh in my head :) nice work rici. thanks a million. --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: PerlSetVar's not showing up in $r->dir_config
Geoffrey Young wrote: > > Scott Fagg wrote: > >>I have lines like this in my .htaccess file : >> >>AuthName AD >>AuthType Arup::AuthCkLDAP >> >>PerlSetVar ADPath / >>PerlSetVar ADLoginScript /login.perl >> >>.. and i'm using AuthCookie.pm. It picks up on the 'AD' value for >>AuthName, but cannot see the PerlSetVar values. > > > PerlSetVar merging is currently broken, specifically for multiple > inheritance (like .htaccess files and ) - see the archives if > you want the long explanation. I really, really plan to fix this "soonish." > look for it in the next mod_perl release, or in early october in CVS. this has been fixed in current cvs. please give the latest mod_perl sources a try and report back if you are still seeing improper merge behavior. --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mp2: PerlSetVar not working?
Geoffrey Young wrote:
>>Now, to make it fail:
>>put this on the end:
>>
>>
>>$Location{"/"} = {
>> AuthType => 'Basic',
>> AuthName => 'Foo',
>> PerlAuthenHandler => 'Apache::Kinnetics::Authenticate',
>> 'require' => 'valid-user'
>>};
>>
>
>
> yeah, I see it now - it's the same (known) bug somebody was bitten by
> earlier this week.
>
> basically, PerlSetVar and PerlAddVar do not merge properly for overlapping
> containers. in your situation the is merging with your
> (or whatever). the same bug holds for
> merges and .htaccess files, for instance. server-level to directory-level
> merges work just fine, as you can see from the test case.
>
> anyway, it is on my short list of things to do, but it's actually a complex
> bug that is now in its second iteration. but I expect to get around to
> fixing it "soonish".
this has been fixed in current cvs. please give the latest mod_perl sources
a try and report back if you are still seeing improper merge behavior.
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] and AuthDBI PerlAuth(en|z)Handler failing
Geoffrey Young wrote: >>I however have some sub-locations under /protectedthing: >>-CUT- >> >> SetHandler perl-script >> >> PerlResponseHandler Some::Nice::mp2::Handler >> > > >>After enabling debug in AuthDBI I see that it is correctly invoked as a >>PerlAuth(en|z)Handler for "/protectedthing/topsecret", but it gets no >>configuration data passed (Auth_DBI_data_source etc.) for the >>sublocation. >> >>... I am completely lost here ... >> >>Any ideas? > > > yes :) > > merging for PerlSetVar/PerlAddVar is broken at the moment. specifically, > the kind of merging you want to do - overlapping containers - does not work > at all. this has been fixed in current cvs. please give the latest mod_perl sources a try and report back if you are still seeing improper merge behavior. --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [ANNOUNCE] Apache::Session::Memcached 0.02
On Mon, 2004-09-20 at 12:21, Enrico wrote: > I've done some basic benchmarks using Apache::Session::Flex with different > datastores and memcached is very fast when sessions number grows (see below). Either the MySQL store needs some work, or your MySQL server is performing very differently from mine. When I run benchmarks (with my own caching code) between Memcached and MySQL, there is hardly any difference. With a little bit of adjustment, the BDB store would beat all of the others, but it would not work for multi-machine environments. > > Memcached would be better suited to acting as a write-through cache for > > session data that you store in a database. > > Please, can you better explain? Sure. With a write-through cache you send all reads to the cache and all writes to both the cache and the database. That way, if you have an application that reads more than it writes, you will get excellent performance, but you also get the safety of a backing store in the database. If your read request to the cache doesn't find the record, you check the database to see if there was one that the cache dropped for some reason. I'm not sure that was very clear explanation. I can show you pseudo-code if you like. What I would love to see is a version of Apache::Session that can take a Cache::Cache class to use for a write-through cache. I will be releasing a Cache::Cache subclass for Memcached soon, as well as some other caching options. This would allow Apache::Session users to take advantage of caching without changing their existing backing storage. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Best way to distinguish between mod_perl 1 and 2
I'm looking for the best, most reliable way to determine if I'm running
under mod_perl 1 or 2, or not under mod_perl at all. I suppose I can look
at $ENV{'MOD_PERL'}, but that reminds me a bit too much of a user-agent
style opaque string that I may not be able to trust or predict. Also, what
if I see "mod_perl/1.99" in that string? It just seems odd.
So, any other suggestions? This needs to be code I can run even outside any
mod_perl environment. I'll wrap it in an eval if I have to, but the low
overhead of looking at $ENV{'MOD_PERL'} is kind of attractive...
-John
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: problem of persistance
On Mon, 2004-09-20 at 06:41, Arnaud Blancher wrote: > i see the potential problem of mod perl but it's not a really good solution > to change the script every times i want to test ! Perl is not going to warn you about this because it is actually legal to do it this way in perl. There's no way for Perl to know that you didn't intend for the variables you put in the closure to keep their values between requests. The best thing to do is to always pass all variables (except constants) to all of your subs, or switch to an object-oriented coding approach. The kind of coding where you just use variables that are in scope from a subroutine without passing them explicitly to the sub is a bad practice because it means your subroutines are "tightly coupled" to the surrounding code and it makes it difficult to move them into modules or to debug them. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Best way to distinguish between mod_perl 1 and 2
Are you looking for this:
-->8--
use constant MP2 => ($mod_perl::VERSION >= 1.99_12);
-->8--
Tom
John Siracusa wrote:
I'm looking for the best, most reliable way to determine if I'm running
under mod_perl 1 or 2, or not under mod_perl at all. I suppose I can look
at $ENV{'MOD_PERL'}, but that reminds me a bit too much of a user-agent
style opaque string that I may not be able to trust or predict. Also, what
if I see "mod_perl/1.99" in that string? It just seems odd.
So, any other suggestions? This needs to be code I can run even outside any
mod_perl environment. I'll wrap it in an eval if I have to, but the low
overhead of looking at $ENV{'MOD_PERL'} is kind of attractive...
-John
Reclaim Your Inbox!
http://www.mozilla.org/products/thunderbird
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Best way to distinguish between mod_perl 1 and 2
Hi,
!please always reply to the mailing list so the thread doesn't get broken!
well mp uses this value internally and many CPAN-Modules do so either.
Versions
mp1 = VERSION < 1.99
mp2 = VERSION >= 1.99
The real syntax would be:
->8-
use mod_perl; ## exists in mp1 and mp2
## set the constant to 0 if mp1 and to 1 if mp2
## but also subversions are working like this e.g. >= 1.99_12 which
## means the version the version must be at least 1.99_13
use constant MP2 => ($mod_perl::VERSION >= 1.99);
BEGIN {
if( MP2 ) {
require Apache::Const;
Apache::Const->import(-compile =>
'HTTP_UNAUTHORIZED','HTTP_INTERNAL_SERVER_ERROR','DECLINED','HTTP_FORBIDDEN','OK');
} else {
require Apache::Constants;
Apache::Constants->import('HTTP_UNAUTHORIZED','HTTP_INTERNAL_SERVER_ERROR','DECLINED','HTTP_FORBIDDEN','OK');
}
}
## proceed with your code
->8-
Tom
John Siracusa wrote:
On Mon, 20 Sep 2004 21:19:58 +0200, Tom Schindl <[EMAIL PROTECTED]> wrote:
Are you looking for this:
-->8--
use constant MP2 => ($mod_perl::VERSION >= 1.99_12);
-->8--
I don't know. What is that? :) Is that the "officially blessed" way
to do this, or just another alternative that happens to work? Also,
what's the equivalent for MP1? "$mod_perl::VERSION < 1.99_12"?
-John
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [MP2] problem with persistance in CGI.pm params
I have upgraded to perl 1.99_16, perl 5.8.5 and apache 2.050 but am
still seeing the same problem.
I just uploaded my test script to another server and the first time I
ran it with no parameters, it showed parameters that were previously
passed to a different program.
Could there be something in the way I have configured Apache that is
causing this. From what I can see CGI.pm is supposed to work as normal
with no changes under MP2.
Apache2 is configured with :
StartServers 1
MinSpareServers 1
MaxSpareServers 1
MaxClients 5
MaxRequestsPerChild 0
.
LoadModule perl_module modules/mod_perl.so
PerlModule Apache2
PerlRequire /cp/etc/httpd/mod_perl.pl
.
Alias /eventxcel/ "/cp/cpfiles/eventXcel/"
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
Order allow,deny
Allow from all
$r->args() and $ENV{'QUERY_STRING'} both contain the correct values but
what comes back from CGI makes no sense.
Ewan.
Arnaud Blancher wrote:
Ewan Bain wrote:
Hi,
Until yesterday I retrieved input variables to my CGI scripts myself.
Now I need to do file uploads so decided to use CGI.pm (3.05).
Unfortunately I'm getting a problem where if I restart the server and
run the program it get s variables fine but on all subsequent request
it still only ever sees the original input parameters.
I'm using httpd-2.0.50, mod_perl-1.99_14 and perl5.8.3 on Debian.
To try and find my problem i created a small script :
#!/cp/apps/bin/perl
use CGI;
use strict;
use warnings;
my $q = CGI->new();
my $params = $q->Vars();
print "Content-type: text/html\n\n";
foreach my $key (keys %{$params}) {
print "Key : $key - Param $params->{$key}";
}
i test it on perl 1.99_16, perl 5.8.5, apache 2.050 on fedora 2
no problem's for me !
Arnaud.
It behaves exactly like my main program. I've been through as much of
the Mod_perl docs as I could understand and searched google to no
avail. I found some information in the CGI.pm docs but none of it
appears to be applicable here.
I have also tried getting my $r = Apache->request; and passing it to
CGI->new() but all I get back is :
Key : Apache::RequestRec - Param SCALAR(0x82a13f8)
I would really appreciate if someone can point out where I'm going wrong.
Thanks,
Ewan.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [MP2] problem with persistance in CGI.pm params
On Mon, 2004-09-20 at 19:17, Ewan Bain wrote: > I have upgraded to perl 1.99_16, perl 5.8.5 and apache 2.050 but am > still seeing the same problem. Is there any chance you could have an older version of CGI.pm in your @INC somewhere? Try printing $CGI::VERSION and see what you get. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Best way to distinguish between mod_perl 1 and 2
On Mon, Sep 20, 2004 at 10:53:09PM +0200, Tom Schindl wrote:
> Hi,
>
> !please always reply to the mailing list so the thread doesn't get broken!
>
> well mp uses this value internally and many CPAN-Modules do so either.
> Versions
>
> mp1 = VERSION < 1.99
> mp2 = VERSION >= 1.99
>
> The real syntax would be:
>
> ->8-
> use mod_perl; ## exists in mp1 and mp2
>
> ## set the constant to 0 if mp1 and to 1 if mp2
> ## but also subversions are working like this e.g. >= 1.99_12 which
> ## means the version the version must be at least 1.99_13
> use constant MP2 => ($mod_perl::VERSION >= 1.99);
>
> BEGIN {
> if( MP2 ) {
> require Apache::Const;
> Apache::Const->import(-compile =>
> 'HTTP_UNAUTHORIZED','HTTP_INTERNAL_SERVER_ERROR','DECLINED','HTTP_FORBIDDEN','OK');
> } else {
> require Apache::Constants;
>
> Apache::Constants->import('HTTP_UNAUTHORIZED','HTTP_INTERNAL_SERVER_ERROR','DECLINED','HTTP_FORBIDDEN','OK');
> }
> }
>
> ## proceed with your code
> ->8-
>
> Tom
>
>
> John Siracusa wrote:
> >On Mon, 20 Sep 2004 21:19:58 +0200, Tom Schindl <[EMAIL PROTECTED]> wrote:
> >
> >>Are you looking for this:
> >>-->8--
> >>use constant MP2 => ($mod_perl::VERSION >= 1.99_12);
> >>-->8--
> >
> >
> >I don't know. What is that? :) Is that the "officially blessed" way
> >to do this, or just another alternative that happens to work? Also,
> >what's the equivalent for MP1? "$mod_perl::VERSION < 1.99_12"?
> >
> >-John
I use the following, avoiding the need to pull in mod_perl.pm
unless the MOD_PERL environment variable exists.
use constant MOD_PERL => exists($::ENV{'MOD_PERL'})
? (require('mod_perl.pm'), $mod_perl::VERSION >= 1.99)
? $mod_perl::VERSION
: 1
: 0;
and then the Perl optimizer will take care of optimizing
away my simple tests for
(MOD_PERL) == 0 (not mod_perl)
(MOD_PERL) == 1 (mod_perl 1)
(MOD_PERL) > 1 (value 1.99 and above for mod_perl 2 and above)
Cheers,
Glenn
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
