Re: Use of Apache::Directive in BEGIN block
On Thu, 2003-09-18 at 13:52, Matisse Enzer wrote: 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. We need more information about your system. Please take a look at the bug reporting guidelines here: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems - Perrin
Re: ensuring singularity of users
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. I'm looking into Captchas Are you trying to prevent multiple people from using the same account, or one person from having multiple windows open, or anyone from using bots? My impression so far is that there's no 100% effective way to do it. That's correct, unless you have control over the client machines. You can require cookies, which will tell you if multiple users on separate browsers are sharing a login, but that's about all you can do without possibly breaking your system for someone. - Perrin
Re: ensuring singularity of users
On Tue, 2003-09-16 at 14:42, Zack Brown wrote: I want to prevent one person from having multiple accounts. Okay. That's correct, unless you have control over the client machines. You can require cookies, which will tell you if multiple users on separate browsers are sharing a login, but that's about all you can do without possibly breaking your system for someone. Someone can appear to be multiple people by disabling cookies though. That's why I said require cookies: you reject all requests from people who don't allow cookies, and then you use the cookies for tracking. A moderately tech-savvy user can delete your cookie and log in again under a separate account, but people who are scared of opening up prefs and messing with cookie management (or people who simply don't care enough to bother) will be stopped. If you have a fixed set of clients who are definitely not using proxies, you can use IP instead of cookies. I want to ensure that if person A registers to use a site, they are not able to register again using a different login Ask them for a credit card then. There's no other way that will really work 100% of the time. - Perrin
Re: Apache::Session permissions problem
Eric, Sorry if I came off overly critical. Many people have had problems trying to use Mason with Apache::Session because of that article. This is why on the Mason website the link to that article describes it as outdated and steers people to newer documentation. (It probably should also steer them to the new handler...) Eric Schwartz wrote: Beggars can't be choosers, and all that, but would you mind telling me what handler you're talking about? I looked around for session handling and Mason, and that article was the best one I found in terms of explaining how it worked and how to use it. Did you look on the Mason site, http://masonhq.com/? That's the best place to find information on Mason. A search for session on that site includes a reference to MasonX::Request::WithApacheSession, available from CPAN. This is mentioned in the administrator's manual that comes with Mason. It's possible that you have an old version of Mason that predates this. Apache::Session::DBI (which is what the article refers to) is ancient and should not be used. How can I know this? The documentation for Apache::Session::DBIStore (which A::S::DBI refers to) doesn't say anything about being obsolete or deprecated. Is there an archive of received wisdom somewhere I should be checking to validate articles like the one I found? The latest Apache::Session on CPAN is version 1.54, released in October 2001. The last release that included a module called Apache::Session::DBI was version 1.03, released two years earlier. I'm not certain what CPAN.pm would do if you told it to install Apache::Session::DBI. It might install the old one, which would be very unfortunate. Is that how you installed it? You shouldn't use the IPC locking in Apache::Session. You didn't mention which database you're using, but most of them have alternative ways of doing locking. In my opinion, the locking approach taken in Apache::Session is not a good one for the average web site and you should simply turn it off by using the NullLocker. How? By using Apache::Session::Flex. The configuration for MasonX::Request::WithApacheSession also lets you do this. It's not particularly obvious from the documentation I can find that it's going to be used, or how to select alternative methods. Look at the source and you'll see it. It's all much clearer in the more recent release though. I installed Apache::Session from CPAN, and the docs refer to PosixFileLocker SysVSemaphoreLocker and NullLocker, but no perldocs for those modules are on my system. The Apache::Session::PosixFileLocker and Apache::Session::SysVSemaphoreLocker modules are included with Apache::Session (although both are obsolete and only part of the old version that you installed). They have no documentation, so perldoc will not find them. The later equivalents (Apache::Session::Lock::File) do have docs. 'perldoc Apache::Session::DBI' says it uses A::S::PosixFileLocker, not A::S::SysVSemaphoreLocker. Are the docs wrong, or the code? The docs are wrong. You can see it refers to the semaphore locker if you look at the source. Basically, you stumbled across an old article that referred to an obsolete version of Apache::Session, and all of your problems stem from that. If you get a later version and check out the Mason handler and the newer documentation on masonhq.com, I think it will all start to make sense to you. - Perrin
RE: Apache::Session permissions problem
Is there a, or are there initiatives to keep an 'accurate' document repository? The field of knowledge is too broad for any one person to maintain, especially since the main people who maintain the site docs are quite busy building mod_perl 2. This is why we count on individuals stepping up and sending in corrections to outdated things they find in the docs. I personally like perl.apache.org as a starting point, but it is quite restricted to mod_perl and mod_perl alone. (This is not meant as a rude remark!). Should and could this be broader containing links to interesting articles on 'well known subjects'? There are quite a few links to other sources on perl.apache.org. My basic rule of thumb is to start with the most specific source of documentation. In your case, since you are trying to use Mason, you should look on the Mason site. There you would have found a note that the article you read is outdated, and a link to the current docs:http://masonhq.com/user/adpacifico/ApacheSessionMason.html PS: Apache::Session::DBI might be ancient, when I did some research for this mail I stumbled upon http://perl.apache.org/docs/1.0/guide/snippets.html#An_example_of_using_Apac he__Session__DBI_with_cookies. Perhaps it is a good beginning to try to keep/get outdated and ancient stuff from Our Main Source of Information? Yes, it would definitely be good to update or remove that snippet. A patch would certainly be appreciated. - Perrin
Re: Apache::Session permissions problem
I found a pretty useful article at http://www.linuxjournal.com/article.php?sid=4143 on how to use Apache::Session with Mason. I'm afraid that is not a very good article. It's out of date, and shows poor error handling. If you want to use sessions with Mason, you should be using the session handler that Mason provides. That is available on CPAN and is supported on the Mason list. Apache::Session::DBI (which is what the article refers to) is ancient and should not be used. Permission denied at /Library/Perl/Apache/Session/SysVSemaphoreLocker.pm line 46. Which seems to indicate it isn't. I STFW, and found several people who seem to have had the same problem I have, but the solutions proffered involve ipcs and ipcrm, which don't exist on my Mac OS X 10.2.6 system. You shouldn't use the IPC locking in Apache::Session. You didn't mention which database you're using, but most of them have alternative ways of doing locking. In my opinion, the locking approach taken in Apache::Session is not a good one for the average web site and you should simply turn it off by using the NullLocker. Suggestions are more than welcome; I'm not quite sure how Session::SysVSempaphoreLocker got involved in the first place, since I don't explicitly reference it. Apache::Session::DBI uses it for locking. - Perrin
Re: AIX perfomance
On Fri, 2003-09-12 at 09:35, Rafael Garcia-Suarez wrote: Benchmarking simple CPU-intensive perl scripts shows that they tend to be consistently slower in user time on AIX. Are these mod_perl scripts or just Perl? If you benchmark some simple Perl scripts that don't run under mod_perl and they show the same trend, then you can eliminate mod_perl as a possible source of the problem. You should also verify that your versions of Perl, apache, and mod_perl are exactly the same on both systems. - Perrin
Re: Portability Question
On Mon, 2003-09-08 at 23:29, Philip M. Gollucci wrote: I haven't really had a hard time with this except: CGI.pm ($query = CGI-new()) What about it? Is it not working? Spreadsheet::WriteExcel (0.26 or less for Win2k/ISS5.0PerlEx current is .40 most likely not thread safe) GD.pm (ActiveState only has GD1.x for 5.6.1 and compile errors for GD2.x on 5.8.0) XML::Simple (Active State5.6.1 is only at 1.06 missing some critical features from the current ~2.05) DateTime modules (datetime.perl.org ActiveState 5.6.1 has nothing... I think 5.8.0 might have some) Building your own .ppm files seems like the only way to solve these. use lib qw(...) (ISS automagically adds . to this. Under unix, this is not the case First thought, use FindBin, but its not thread safe, so mod_perl2.x fails. Only anwser I've come up with is to have an installation script edit a place holder in the main file You could use a config file or an environment variable, but what is the problem with FindBin exactly? I haven't heard about it not being thread safe before. However, caching is much more beneficially in IIS5.0/PerlEx then apache1.x/mod_perl1.x (rarely if ever get server by the same child in Apache) In apache 1.x on Win32, you always get the same child since there is only one. With 1.x on FreeBSD, the allocation will basically round-robin through all of your live apache children. - Perrin
Re: Sending a different protocol header
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? - Perrin
Re: Help wanted with locations / configuration
On Mon, 2003-09-08 at 11:51, Steve Hay wrote: Thus, I want to have something like this: /myproject [mp1] /myproject/component1 [mp1] /myproject/component2 [mp1] ... /myproject/images [static] /myproject/javascript [static] /myproject/stylesheets [static] The question is: What is the best way to configure this? Others have already given good advice, but I would add that your URLs and your filesystem don't need to be tied tightly together. You could just alias the static files to somewhere else: Alias /static/images /myproject/images Then you can simply refer to them in URLs as /static/images/foo.jpg. Alternatively, you could use a Location setting for your dispatcher that has nothing to do with your files: Location /wild/and/crazy/path/for/handlers SetHandler perl-script PerlHandler MyProject-dispatcher /Location Then you can call /wild/and/crazy/path/for/handlers/component1 and it will work as long as your dispatcher is smart enough to ignore the beginning path. (Apache::Dispatch is.) - Perrin
Re: 'die' in a CleanupHandler
On Mon, 2003-09-08 at 16:10, Ray Zimmerman wrote: Just curious ... what happens if I call 'die' in a mod_perl handler (especially a CleanupHandler)? Does it actually kill the apache child or does something catch the exception before that happens? The latter. Your 'die' is caught by mod_perl. Is there something you're trying to do? - Perrin
Re: Apache on windows XP
On Fri, 2003-09-05 at 13:17, Niranjan Patel wrote: I am getting the following error running Apache 1.3 on a windows XP machine. Are you running mod_perl? If so, how did you install it? If not, you need to ask your question on another list. The list for general apache user help can be found on the apache.org website. This list is for mod_perl users. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session and pnotes
Sorry, I missed this message until now... On Tue, 2003-09-02 at 14:21, Xavier Noria wrote: Let's assume a new user comes to the website. We set up a session for him and put the session id in a cookie to be sent in the response. As you know, somewhere in the request cycle of that particular request Apache::Session::Oracle stores the session in the database. It happens when the session object gets destroyed. The problem I am facing is that if the session is stored in pnotes() it doesn't end up in the database. When the user comes back that id corresponds to no row in the sessions table. Okay, the problem is not pnotes. The pnotes stuff gets cleared at the end of every request, so it would save then, after the user disconnects. Probably what's happening is that you have a scoping problem somewhere in your code that deals with pnotes and it is keeping the session object from going out of scope. One thing you can try is explicitly saving the session, using the method described in the Apache::Session documentation. If that works, it means you just have to find your scoping problem. Maybe you can locate it by removing code bit by bit until the problem goes away. If you can make a very short script that demonstrates the problem, you can post it here and we'll help you find it. - Perrin -- 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
On Fri, 2003-09-05 at 19:14, Bart Terryn wrote: PS: some might say that this has nothing to do with mod_perl I would say that, but it's okay, you didn't know. 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. - Perrin -- 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
On Fri, 2003-09-05 at 21:36, Stas Bekman wrote: Bart is on win32, AS Perl 5.8. Oops, sorry Bart, I missed that. Even so, I'm suspicious that 5.8 and all of its unicode changes are involved somehow. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Cookie Code
On Thu, 2003-09-04 at 16:56, Tim Edwards wrote: I'm sending 3 cookies. The first one goes properly. The second two get print to the screen. Same script run under normal perl works fine. Suggestions? Show us the mod_perl part of your apache config. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: collecting unique client (computer) specific info?
On Wed, 2003-09-03 at 12:22, kfr wrote: Anyone know how to capture the UUID from a request? According to the mod_ssl manual, it is stored in an environment variable called SSL_SESSION_ID. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: collecting unique client (computer) specific info?
On Wed, 2003-09-03 at 15:03, John Saylor wrote: is there an equivalent in mod_perl1? Use Data::UUID from CPAN or mod_unique_id. Note that this (and the mod_perl 2 approach Stas posted) has nothing to do with identifying the actual client, which is what the original question on this thread was about. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: PATCH porting.pod First Mystery
On Wed, 2003-09-03 at 21:24, Stas Bekman wrote:
[...]
In effect you use local() to undef the variable, instead of explicitly
initializing it. Why not doing this explictly?
Firstly it's conceptually neater to use local. I want to think of the
variable as local rather than as a global variable that needs to be
explicitly reset.
local is perl4-ism, nowadays it's used only for localizing special perl
variables, like $|.
I agree, using local, and especially local our is pretty strange. It
may work, but I wouldn't want to encourage people to do that in their
code.
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.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session and pnotes
Xavier Noria wrote:
It seems, however, that Apache::Session objects stop being stored when I
put the session in pnotes() with a code analogous to this:
Can you tell us more about the problem is? What do you see when you
take the session hash back out of pnotes?
my $r = Apache::Request-instance(shift);
No need to involve Apache::Request just for this. Your handler should
be getting $r passed to it.
tie my (%session), 'Apache::Session::Oracle', undef,
{Handle = $class-dbh(), Commit = 1};
$r-pnotes(session = \%session);
Show us the code you use to get it back.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session extra record not write to Mysql db.
James.Q.L wrote:
before i had three fields in table sessions : a_session,id,time in the DB.
Did you add code of your own to update the time column?
and updating table etc from the program was working just fine. however, after i added
one more
field (username) to the sessions table through phpmysql, updating it in the program
seems has no effect on the username record. no problem on others.
Do you understand what Apache::Session does? It simply use Storable to
turn the whole hash of values into a single binary chunk and stores it
all in the a_session field. It uses the id field to find the session
again. It will not update any other fields unles syou hack the code
yourself.
$session{'test'} = time();## this doesn't update 'test'
That updates the field test in the session, which is stored as part of
the column a_session in the database.
$session{'uname'} = $uname if $uname; ## this doesn't update 'uname'
Same as above -- it updates the uname value of the session.
$session{'time'} = time();## this updates 'time' record
But it doesn't update the time column in the database unless you hacked
the Apache::Session code to do that.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session extra record not write to Mysql db.
On Tue, 2003-09-02 at 00:13, James.Q.L wrote:
--- Perrin Harkins [EMAIL PROTECTED] wrote:
Did you add code of your own to update the time column?
no.
Maybe you added the time column as an automatic timestamp column? There
is no time column in the schema described in the Apache::Session
documentation.
and from my phpmysql, you can see the time record.
id a_session time unametest
0543f2dc8dd196c5adeb29f18113f88d 2003090122521800
Is that a real column, or just a last-modified time that phpmysql adds
in somehow?
and indeed as you said in record a_session it stores the session data. so if i
understand
correctly, i don't add _new_ column to the sessions table, instead i call
$session{'username'} =
'username' which add it to the column a_session.
That's right.
i know Apache::Session can't do session managerment directly. but i found out that
when a user
session timeout, the record also gone automatically.is tied(%session)-delete;
delete the session?
Apache::Session has no concept of timeouts so it never deletes sessions,
but you can delete sessions manually with the delete method that you're
talking about.
By the way, you might find it easier to use CGI::Session. It works fine
with mod_perl, and it directly supports things like timeouts.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session and pnotes
On Tue, 2003-09-02 at 05:02, Xavier Noria wrote:
Can you tell us more about the problem is? What do you see when you
take the session hash back out of pnotes?
I have dumped the hash in a content handler and it seems to be OK.
Okay, then what is the problem that you're asking for help with here?
When a request is received the session id is retrieved from a cookie.
The schema (with some irrelevant checks removed) would be this:
my %cookies = Apache::Cookie-fetch;
my $cookie = $cookies{COOKIE_NAME()};
my $session_id = $cookie-value;
my %session;
eval {
tie %session, 'Apache::Session::Oracle', $session_id,
{Handle = $class-dbh(), Commit = 1};
};
Okay, but I was asking how you get it back from pnotes.
That code works all right if \%session is not stored in pnotes(), but if
it is put the session is not read back from the database and I have
checked from a database client that there is no new row written.
Sorry, I don't understand what you're saying here. What you should be
doing is fetching the session once, putting it in pnotes, and getting it
from pnotes for the rest of the request.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
RE: collecting unique client (computer) specific info?
On Tue, 2003-09-02 at 14:23, kfr wrote: Yes, sorry. I have a site that allows my customers to become members via monthly credit card subscription. The problem is we've been getting fraudulent credit card transactions and need some mechanism to detect a user who is a repeat offender so I can detect them trying to submit yet another bogus CC for access. Okay, that makes sense. Unfortunatey, there's no foolproof way that I'm aware of. To begin with, you can try using a cookie. This will stop anyone who is not very technical. Beyond that, I have heard that there's some kind of unique identifier in SSL that you may be able to use. I know this because the f5 big/ip load balancers used it. Check into that. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: collecting unique client (computer) specific info?
On Tue, 2003-09-02 at 13:24, kfr wrote: Any one out there know of some way, either from java or SLL or some other combination, to collect any kind of machine specific information from a web client logging into a site with SSL (Apache/mod_perl mod_ssl)? I need to find some way to uniquely identify a 'machine', like possible grabbing it's mac address would be ideal but obviously that can't be done ... Any clues? Perhaps you could explain what you're trying to do? - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::DProf problems
On Sat, 2003-08-30 at 15:34, Brian Hirt wrote:
i'll double check, but i'm fairly certain it's loaded first.
If you post your conf, we could probably help you more.
what if a module is loaded after the fact, but like this: eval { use
$module };
Doesn't matter. You just have to initialize the debugger. I do this by
calling Apache::DB-init because I don't want to actually profile
anything during startup but I do need the debugger turned on when I
compile code at startup for DProf to work.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SOAP::Lite in mod_perl...
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 It could be the same change in apache 1.3.28 that is causing problems for Bricolage. See this bug report: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22805 To verify it, you can build a copy of your dev server that is identical except for using apache 1.3.28 and see if that fails as well. If you're feeling ambitious, you can try the patch attached to that bug report. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::DProf problems
On Fri, 2003-08-29 at 17:11, Brian Hirt wrote: I've installed Apache::DProf, but it seems hardly any of the calls are profiled. You probably compiled that code before you initialized the debugger. Add a call to Apache::DB-init before you load your modules, as described in the Apache::DB docs. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Modules Problem
On Thu, 2003-08-28 at 16:09, Tim Edwards wrote:
I in the process of switching my scripts over to Mod Perl.
I decide since Mod Perl doesn't like Sub routine in the the main program I'd
export make Modules out of the more come ones.
Just to be clear, mod_perl has no problem with subroutines inside of the
main program. Apache::Registry has issues with it but only if you are
using lexically scoped variables and declaring them outside of your subs
rather than passing all parameters to the subs.
In other words, don't do this with Apache::Registry:
my $cgi = CGI-new();
foo();
sub foo {
my $input = $cgi-param('input');
}
That breaks because $cgi is not passed to foo(), so it becomes a closure
and will always be the same as it was the first time the script was run.
Error:
Undefined subroutine main::CISCHeader called at /var/www/perl/test.pl line
5.
Here the Module Located in the ModPerl Directory under the a directory
listed int eh @inc:
package ModPerl::Rules1;
sub CISCHeader {
print Content-type: text/plain\n\n;
print mod_perl rules!\n;
return 1;
}
1;
The Script:
#!/usr/bin/perl -w
use strict;
use ModPerl::Rules1;
CISCHeader();
Your module doesn't export the CISCHeader sub, so you have to call it
with the full name: ModPerl::Rules1::CISCHeader(). If this doesn't make
sense to you, you should read the perlmod man page that explains how
modules and packages work.
- Perrin
--
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
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. I actually couldn't care less what the reply-to header for the list is, since I will just reply all as I always have. I posted the reference to the earlier thread because anyone who wants to bring it up should at least be aware of what was said in previous discussions. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Use of uninitialized valued in concatenation....
On Fri, 2003-08-22 at 17:23, B. Fongo wrote: I have a file (output_tab.pm) that I use to generate tables dynamically. Even though it serves its purpose, it goes on generating this error: Script_name.pl: Use of uninitialized value in concatenation (.) or string at output_tab.pm line 42. This is a standard perl error message. It is not related to mod_perl. You can look in the perldiag man page for a more complete explanation. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Loading perl modules from same directory
On Wed, 2003-08-27 at 14:48, js wrote: My question is, why isn't Apache2/Mod_perl finding the library to load, if the PM file is in the same directory as the perl-script? This is a mod_perl 2 issue, which is documented here: http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache__Registry___C_Apache__PerlRun__and_Friends There is a workaround for it on that page as well. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Installation/test problems - mod_perl-1.27
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 - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache 2.0.47, mod_perl.c
On Thu, 2003-08-21 at 03:38, John Francis Lee wrote: I have the existing apache rpm 2.0.40 installed on rh 8.0 Not finding an rpm for apache 2.0.47, I downloaded, compiled and installed the source. What are you trying to do? Are you trying to get mod_perl working? You mentioned CGI scripts before. If you're not trying to run mod_perl, the mod_perl RPMs are not going to help you much. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Trouble getting mod_perl and apache running with Apache::DBI
On Mon, 2003-08-18 at 11:33, K Old wrote: My problem was that I was not declaring PerlModule Apache::DBI in httpd.conf BEFORE my PerlRequire /etc/httpd/conf/startup.pl. Also, I was doing a use Apache::DBI in my startup.pl file, which I shouldn't have done. Sorry, that is not correct. It's fine to do PerlModule Apache::DBI or do a use Apache::DBI in startup.pl. You should not do both of them, and you should make sure you load Apache::DBI in one of these ways before loading anything that uses DBI. This is all in the Apache::DBI documentation. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Trouble getting mod_perl and apache running with Apache::DBI
On Fri, 2003-08-15 at 10:34, K Old wrote: What's happening is that with use Apache::DBI uncommented in either the httpd.conf or startup.pl Apache does not start. Do you have something in your code that connects to a database during startup? That could be a problem. Also, what's the point of use vars qw($dbh %session); in your startup.pl? Do you actually know what package these are being declared in? Probably not one that you will be using later in your scripts. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Odd Reload Behavior
On Sat, 2003-08-16 at 01:46, Cory 'G' Watson wrote: %somehash = (); This declaration is outside of any subroutines. Okay, so your subs that refer to it are now closures. That could be part of the issue. If you make %somehash a real global, it might help. I re-attacked this problem by adding a caller() check in App, and it proved to me that App was indeed being loaded twice. Once by my startup.pl (use App ();), and _again_ by an eval. caller() couldn't point me to the spot of code that was doing this, other than telling me it was a 'require App;'. I started flipping switches and localized it to PerlFreshRestart being on. When I turn it off, the eval() happens _before_ my startup.pl use() and subsequence call to App-load(). Well, first of all, you're just asking for trouble if you turn on PerlFreshRestart. Don't do it. Do you hava anything like a PerlModule App in your httpd.conf? You haven't actually shown us your real conf, startup, or code, so I'm just guessing here. Are you no longer having problems now that you turned off PerlFreshRestart? - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Odd Reload Behavior
On Sun, 2003-08-17 at 22:15, Cory 'G' Watson wrote:
No, I only had a 'use App;' in my startup.
Your startup comes before the virtual host sections then?
When I added a caller() to the top of my module, I saw the initial
startup.pl use(), and then a later eval() that I couldn't track. When I
turned OFF PerlFreshRestart, the order was reversed (eval() before
startup.pl's use()) and my problem, of course, went away.
I assumed from the beginning that this was something of my own doing, I
just wanted to know why my ignorance was causing to happen. It seems that
PerlFreshRestart causes some difference in the loading of my modules.
As I understand it, the only thing that PerlFreshRestart does is clear
%INC when you restart the sever (with a USR1 signal), kind of like this:
while (($k, $v) = each(%INC))
{
delete($INC{$k}); eval(require $k);
}
I don't know where that eval call would be coming from with PerlFreshRestart
off. That's why I was wondering if you had PerlModule call somewhere in
httpd.conf.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Problem reloading modules
On Thu, 2003-08-14 at 14:04, Jean-Sebastien Guay wrote: Try doing a fully-qualified sub call instead of importing. Err, that would actually be a pretty massive change to my codebase. Changing all the somesub calls to Hybride::Module::somesub would be a pain, not to mention too much typing. There has to be another solution, isn't there? I'm asking you to try it and see if it works. A possible solution if that is the problem is to make all the modules that import it reload as well. You can do that with a touch file. - Perrin
Re: Problem reloading modules
On Thu, 2003-08-14 at 13:41, Jean-Sebastien Guay wrote: Is there anything unusual about the way you call this sub (AUTOLOAD, function ref, etc.)? Not at all. It is imported with use Hybride::Projects qw(getImage other imports); I think that's the problem. You are creating an alias to the sub here, and when it gets reloaded the alias is still pointing to an old version. Try doing a fully-qualified sub call instead of importing. - Perrin
Re: Problem reloading modules
On Thu, 2003-08-14 at 11:43, Jean-Sebastien Guay wrote: And I can see in the error_log that $image is still the absolute path (D:/htdocs/images/project/prefix/bob.jpg in our example) even after the change. I don't see anything wrong with that chunk of code. If you restart the server, does it pick up the change? Is there anything unusual about the way you call this sub (AUTOLOAD, function ref, etc.)? Reloading modules is not foolproof. Perl doesn't actually support it, so things like Apache::Reload fake it by removing the module from %INC and making it get compiled again. This usually works for things in the symbol table, but people have reported problems in the past with things that keep references to lexicals (closures) and other somewhat magical features. However, your code here looks pretty vanilla and seems like it should be working fine with Reload. - Perrin
Re: Problem reloading modules
On Thu, 2003-08-14 at 14:29, Jean-Sebastien Guay wrote: I'm asking you to try it and see if it works. Ok, I tried it and it works. I guess we need to add this to the docs: Apache::Reload will have problems if you import subs from a module you are trying to reload. The file that imports it is not a module, it's the actual script. Apache::Registry? Just do a touch on the script file and Registry will reload it. You could hack your own Apache::RegistryNG subclass that would just reload everything when Apache::Reload triggers, but it's probably not worth it. - Perrin
RE: HTTP POST: parameters empty when usingModPerl::Registry(okaywhen using ModPerl:PerlRun)...
On Thu, 2003-08-07 at 23:56, Steve Bannerman wrote: I was thinking of the subroutine as a method on a class and that the objects in the class had a cgi instance associated with them. That's a good way of doing things, but you would have to structure your code a little differently. If that appeals to you, I recommend you take a look at CGI::Application. There's an article about it here: http://www.perl.com/pub/a/2001/06/05/cgi.html - Perrin
Re: Problem reloading modules
On Thu, 2003-08-14 at 15:01, Jean-Sebastien Guay wrote: Could something in Apache::Registry be implemented to integrate it better with Apache::Reload? Something along the lines of keeping track of which modules a certain script use()s, and at request time, checking if Apache::Reload has reloaded one of those since the last request and if so, reload the script itself? It's somewhat tricky to know what modules you've imported from. Maybe through overloading use(). The thing is, I don't use Registry or Apache::Reload so I don't have much motivation to do it. (I just restart my server, since it only takes a second.) If you're interested in working on it, we could discuss possible approaches on the list and review your patch. - Perrin
Re: PerlModule options?
On Tue, 2003-08-05 at 04:55, [EMAIL PROTECTED] wrote: loads the module but doesn't import the symbols since it is equivalent to the use Foo::Bar (). Therefore I should use use Foo::Bar in each program only to make the import. Correct. Is there other way to load the module and import the symobols specified in @EXPORT at mod_perl reloading time, without adding a special line in each and every script using them? No, that would be Bad. By putting a use Foo in each module that wants to import functions from Foo, you are explicitly saying please pollute my namespace to Foo. That sort of thing shouldn't happen unless you request it. Perhaps some options passed to PerlModule though adding (...) doesn't help since PerlModule expects a list of modules. There's no way it could since PerlModule has no way of knowing what namespaces you are going to want polluted. - Perrin
Re: Problem reloading modules
On Thu, 2003-08-14 at 15:33, Jean-Sebastien Guay wrote: In a week or so I'll have a bit more free time, and I might try implementing it. I'll start by reading up on mod_perl internals... :-) Actually, all you need to read is the code for Apache::Registry or ModPerl::Registry (depending on which you are using) and the code for Apache::Reload. These are all pure perl modules. However, there will always be things that Apache::Reload doesn't handle. For example, you might import functions from one module into another module, as opposed to importing into a Registry script. My advice is to avoid importing things at all, but I know that many people really love importing and will not want to give it up. - Perrin
Re: Problem reloading modules
On Thu, 2003-08-14 at 15:10, Stas Bekman wrote: OK, I've written a proper entry for the man page, Jean-Sebastien can you please verify that it all works, as I wrote it without testing. Thanks. http://perl.apache.org/docs/2.0/api/Apache/Reload.html#Problems_with_Scripts_Running_with_Registry_Handlers_that_Cache_the_Code Thanks Stas! I think you have a little mistake here: @EXPORT = qw(set_colour); That should be @EXPORT = qw(colour); - Perrin
Re: Problem reloading modules
On Thu, 2003-08-14 at 11:24, Jean-Sebastien Guay wrote: I'm using Apache::Reload, and I can see that my modified module is getting reloaded (with ReloadDebug On), but the program still uses the old code. How can you tell? Can you post some sample code? You might be doing something that doesn't work when reloaded, like closures. - Perrin
Re: Apache::Session
On Thursday 14 August 2003 8:06 am, Joelle Nebbe wrote: What i do is store both the remote IP and the user agent HTTP parameters in the session when the session is created. Whenever a new request comes in with that session I check that those havent changed. So, you don't care about AOL users then? They can change IPs on every request as they get routed between proxies. I also check referrer to make sure people are coming from a page that makes sense. Not much of a barrier to anyone who cares enough to bother coding up a cross-site scripting attack. If you need even better security there's ssl, or storing unique, random'challenge-response' style tokens into pages that have to be sent back on the next connection That's an idea. You could try making every cookie good for only one use, and send a new one out every time. Ultimately though, I think the answer is that sites with sensitive information can't leave themselves open to CSS attacks. - Perrin
RE: HTTP POST: parameters empty when usingModPerl::Registry(okay when using ModPerl:PerlRun)...
On Thu, 2003-08-07 at 03:36, Steve Bannerman wrote: So with respect to your explanation about the long running perl system, am I to understand that the old version of the saveFile() subroutine uses a reference to a different $cgi instance that the $cgi instance in the main body of the script? It uses a reference to the $cgi variable that was in scope when saveFile() was compiled. As I said, I'm new to perl but that seems to be an awfully strange behavior of the language...if true, shouldn't the compilation (of the subroutine) fail because it references an undeclared variable ($cgi)? But it doesn't reference an undeclared variable; it references the original $cgi that was available when the sub was compiled. Closures are a feature of Perl. You can read about them in general in perlfaq7 and the perlref man page: http://www.perldoc.com/perl5.8.0/pod/perlfaq7.html#What's-a-closure- http://www.perldoc.com/perl5.8.0/pod/perlref.html Note that those both talk a lot about anonymous subs, but any sub can be a closure if it refers to a lexical variable defined in an enclosing scope. There is some mod_perl specific stuff on this here: http://perl.apache.org/docs/general/perl_reference/perl_reference.html#my___Scoped_Variable_in_Nested_Subroutines If you had warnings on, you would have received a message about $cgi not staying shared. In brief terms, what happens is that your program creates a lexical called $cgi, then saveFile() refers to it, locking in that variable as the $cgi that will always be referenced by saveFile(). At the end of the script $cgi goes out of scope and disappears, but saveFile() keeps referencing it. In a CGI program this is not a problem, because Perl exits and the process quits. In mod_perl, the code gets run again and saveFile() still refers to the original $cgi. There are a number of ways to solve this problem, but I prefer the one I showed you. Explicitly passing all arguments to subs is well established as a best practice in programming. What you were doing with $cgi before is basically treating it as a global. So, I'd suggest you turn on warnings, turn on strict, and embrace the good practice of passing variables to your subs. - Perrin
Re: [ANNOUNCE] Apache::ASP v2.55 released
Josh Chamas wrote: The latest version of Apache::ASP v2.55 has been released. The biggest improvement is no longer loading Apache::compat for running under mod_perl2. Has this affected the performance measurements you made earlier in any way? - Perrin
RE: PerlModule options?
On Tue, 2003-08-05 at 15:57, [EMAIL PROTECTED] wrote: Thanks for your answer, this should do it indeed. Super! Somehow I didn't think about perl sections... Perl sections will not work for this. If you do it there, the symbols you want will only get imported into the Apache::ReadConfig namespace. You will not be able to call them in other scripts without importing them there too. - Perrin
Re: Re[2]: Multiple select
On Tue, 2003-08-05 at 13:29, Alan Rafagudinov wrote: Please small example of using Apache::Request. $r-content; $r = Apache-request; does not work :-( That's not Apache::Request, that's an Apache object. Please read the documentation: http://perl.apache.org/docs/1.0/guide/porting.html#Converting_to_use_Apache_Perl_Modules http://search.cpan.org/author/JOESUF/libapreq-1.2/Request/Request.pm Or just use CGI.pm or something similar like CGI_Lite. - Perrin
RE: HTTP POST: parameters empty when using ModPerl::Registry(okay when using ModPerl:PerlRun)...
On Wed, 2003-08-06 at 04:50, Steve Bannerman wrote:
However, it doesn't really explain why the root problem exists. The way I
think about it, the creation of a new CGI object should create a new set
of slots for instance data.
That would make sense, but very little about CGI.pm actually works in
the way you would expect. It's a very bizarre module because of the
dual functional and object interface, and it uses lots of globals even
if you are only calling the OO interface. If possible, I would suggest
you consider using CGI::Simple instead, which is a drop-in replacement.
Maybe I don't understand the object paradigm in perl correctly; however, I
do understand it very well in general. Thus, it seems like a defect in
either perl (the language) or CGI.pm.
It's a problem with CGI.pm, not with your understanding of Perl OO.
I believe I see the source of your troubles in the code that you
posted. You are creating a closure by using a lexical variable and then
accessing it from within a sub. This is a no-no with any long-running
system like mod_perl. You can get away with it in a standard CGI
environment (or PerlRun) because it just exits after each request
instead of running the same code again.
Here is the offending section:
my $cgi = new CGI;
saveFile();
sub saveFile {
my $inputfile = $cgi-param('file');
... etc ...
}
Change it to this:
my $cgi = new CGI;
saveFile($cgi);
sub saveFile {
my $cgi = shift;
my $inputfile = $cgi-param('file');
... etc ...
}
I think that will do it.
- Perrin
Re: Multiple select
On Tue, 2003-08-05 at 12:34, Alan Rafagudinov wrote: Hello! I have the next html code: select name=sel_name multiple option Smth_1 ... option Smth_n /select User is able to select many values in the list, how can I get all of them in my mod_perl script? Use Apache::Request or CGI.pm. - Perrin
Re: handlers versus scripts, SSI difference
On Mon, 2003-08-04 at 04:05, gerard uolaquetalestem wrote: But it seems to be that with modperl as DSO this directive does not work, and that Apache::include is only a modperl1.x funcionality, so discarted in mod perl 2. I don't think this has anything to do with DSO vs. static. Apache::Include and Apache::SSI are the two ways of doing includes of mod_perl scripts in mod_perl 1.x and they have not been ported to mod_perl 2 yet. If you are using apache 2, you should look at using the apache 2 version of mod_include, which can be used as a filter. Take a look at the documentation here: http://httpd.apache.org/docs-2.0/mod/mod_include.html So this is my question. Are perlhandlers better than CGI registry scripts in speed but not in funcionality??? Perl handlers have better speed and functionality than CGI scripts running under Registry, but that has nothing to do with SSI. - Perrin
Re: Skipped Tests (was: handler help)
On Fri, 2003-08-01 at 22:53, Tofu Optimist wrote: Then as root I used CPAN to install Bundle::WWW, LWP, and HTML::Parser. Had some troubles, used the force option, and plowed ahead. (Maybe I should have stopped here at the first FYI, this was probably also because of the locale issue. Best to make it a global change so you won't have to set it every time you want to run (or install) perl stuff. - Perrin
Re: Current directory
On Mon, 2003-08-04 at 09:32, Jean-Sebastien Guay wrote: But I still get the same message... [Mon Aug 04 09:31:57 2003] [error] Global $r object is not available. Set: PerlOptions +GlobalRequest in httpd.conf at D:/Perl/lib/CGI.pm line 307. Compilation failed in require at D:/htdocs/_startup.pl line 33. Is there anything else I can check other than the CGI.pm version? First, check your conf file to be sure you have this turned on. There are docs related to it here: http://perl.apache.org/docs/2.0/user/config/config.html#C_GlobalRequest_ You can test it by writing a little handler (or Registry script) that calls Apache-request(). That should return an Apache::RequestRec object if all is well. If it doesn't, you may have an old mod_perl 2 build or you may have found a bug. If you can't get that to work, there is also the direct approach which is to pass a RequestRec object to CGI.pm when you call the new() method. Registry scripts get a RequestRec object passed to them as their first param, so you can just shift it into a variable (usually called $r) and pass it as CGI-new($r). - Perrin
Re: Current directory
On Mon, 2003-08-04 at 12:08, Jean-Sebastien Guay wrote: Doesn't all this require that I actually get a running Apache server first? The error message shows up when I try to start up the Apache service! What? That shouldn't happen unless something is calling CGI-new in your startup, which is a bad thing to do. Maybe some script you're loading is doing that. Try to figure out what's doing it. As I understand it, the _startup.pl script tries to require() CGI.pm, which gives the error message. What happens if you comment out CGI.pm from your startup.pl? - Perrin
Re: handler help
On Fri, 2003-08-01 at 07:02, Tofu Optimist wrote: I'm a linux newbie. I freshly installed RH 9. I built perl 5.8.0 from source. Go and change your locale from UTF8 to en_US or C. See this for why: http://archive.develooper.com/[EMAIL PROTECTED]/msg97360.html As non-root, I downloaded source for Apache 1.3.28 and mod_perl 1.28 and built them, using the instructions here http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_of_a_Basic_mod_perl_Installation Okay... [Thu Jul 31 18:34:08 2003] [error] [client 192.168.1.2] Can't locate object method content_type via package Apache::RequestRec at /usr/lib/perl5/site_perl/5.8.0/Apache/HandlerTest.pm line 6.! That's mod_perl 2. (There is Apache::RequestRec in mod_perl 1.) You must have an older one on your box and you are trying to run this handler with it. Figure out where you installed mod_perl 1 and use that instead. - Perrin
Re: Skipped Tests (was: handler help)
On Fri, 2003-08-01 at 10:31, Tofu Optimist wrote: [1] How do I find *everything* on the box related to perl / apache / mod_perl, both 1 and 2, both the RH install and from my own ftp / tar / make fumblings? Well, you can run updatedb and then use locate to look for things like apachectl and Apache.pm. [2] How do I uninstall everything from [1], so I can start fresh? There is no simply way to uninstall software that you installed from source. There are things you can do though. First uninstall any apache or mod_perl rpms. Then you can clear out all the Apach::* modules from your perl lib, and delete all the web server stuff (which is typically installed under a single directory). [3] I'd prefer to use modperl 2 and apache 2, as that is what my ISP is using. Okay, then stop reading docs for mod_perl 1. And I think I'd prefer to use RH rpm to install them, as again, that is what my ISP did. Don't do that. mod_perl 2 is basically in alpha right now and changes every day. If you plan to run it, you must keep on top of development. The rpms for mod_perl 2 are ancient at this point. [4] Is a full uninstall enough, or should I reinstall RH itself? The latter is more complete, but if you don't see any more httpd.conf files or Apache:: modules, you have probably cleaned things close enough. - Perrin
Re: [mp1] Apache::Reload questions...
On Fri, 2003-08-01 at 11:10, Roger Davenport wrote: I've been working with Apache::Reload and Registry and have been unable to get any cache flushing to work. (I've added debug messages in Registry to show cache use or reloading). Can you tell us what you are trying to reload and how you know it is isn't happening? Keep in mind, Apache::Reload has nothing to do with reloading Registry scripts. That reloading is handled entirely within Registry itself. - Perrin
Re: Cookies, CGI::App, and mod_perl
On Fri, 2003-08-01 at 13:04, petersm wrote: When running under mod_perl the cookie is no where to be seen. Do some debugging. Look at the traffic going back and forth. Test it with GET or lynx. See if the cookie header is being sent. If I understand this correctly, then C::A uses CGI to set the cookie and CGI should set it correctly if I'm running under mod_perl right? Right, although I don't think C::A knows or cares at all about cookies. This is just between you and CGI.pm. I've seen a lot on forums to use Apache::Cookie, but how do I do that within C::A? You don't need to use Apache::Cookie, but if you want to you should be able to use it in the normal documented way. C::A should not have any bearing on this. - Perrin
Re: Module caching
On Fri, 2003-08-01 at 13:42, Scott wrote: I have looked at Apache::Reload and Apache::StatINC And what was wrong with them? You should know that there is no perfect way to reload a Perl module. It just isn't a feature of the language. Those two modules come as close as you can get without actually starting a new interpreter, but it is still possible for some code (especially code using closures) to interact badly with them. - Perrin
Re: Cookies, CGI::App, and mod_perl
[ Please keep it on the list... ] On Fri, 2003-08-01 at 14:06, petersm wrote: Perrin Harkins [EMAIL PROTECTED] wrote Do some debugging. Look at the traffic going back and forth. Test it with GET or lynx. See if the cookie header is being sent. Thanks for the suggestion. I used wget and tried it with the mod_perl stuff in the config and without. Without, wget gave me the header with the cookie. With, wget did not have a cookie in the header. Both returned the correct HTML. Maybe some a glance at my config file could help. So here's the relavant portion. Thanks... PerlModule Apache::StatINC Location /operations/projects/menagerie AddHandler perl-script .cgi PerlHandler Apache::Registry PerlSendHeader On allow from all PerlInitHandler Apache::StatINC PerlSetVar StatINCDebug On PerlSetEnv PERL5LIB /development/operations/projects/ /Location That looks okay to me. Maybe it's something about the way you've structured your code. Try reducing it down to a small snippet that you can post. You may also want to ask on the CGI::Application list. - Perrin
Re: Skipped Tests (was: handler help)
On Fri, 2003-08-01 at 16:24, Tofu Optimist wrote: Am I going to have problems following the MP 2.0 install instructions http://perl.apache.org/docs/2.0/user/install/install.html if I don't nuke the current perl first? No, you should be fine. However, I have also simply installed a new perl on top of the one shipped by RH with no problems. (I did this because I wanted to use 5.6.1 rather than 5.8.0.) You will be blowing the RPM system by doing that, so it's not an advisable way to handle a large cluster of machines, but it works fine if you just need to get a quick dev environment bootstrapped. - Perrin
Re: Current directory
On Fri, 2003-08-01 at 15:46, Jean-Sebastien Guay wrote: I see only disadvantages to having to specify absolute paths in both these cases. For one, I have another web server running on port 8080, which I use to test my scripts on, and whose DocumentRoot is D:/htdocs-dev. So if I had to manually change the paths each time I copied files over from the development DocumentRoot to the production one, I would go crazy. There are dozens of possible answers to this. I typically put things relative to the web server root, which is described here: http://perl.apache.org/docs/1.0/api/Apache.html#Apache_E_gt_server_root_relativerelative_path___ Another approach would be to look up the directory that your script is in and either chdir to that or pass it to your modules and have them use it. There are also common approaches like passing some kind of application root either in an environment variable or in httpd.conf with a PerlSetVar. - Perrin
Re: GlobalRequest
On Fri, 2003-08-01 at 14:20, Jean-Sebastien Guay wrote: [Fri Aug 01 13:49:05 2003] [error] Global $r object is not available. Set: PerlOptions +GlobalRequest in httpd.conf at D:/Perl/lib/CGI.pm line 269. Make sure you have the very latest CGI.pm. There were some changes related to mod_perl 2 recently. - Perrin
Re: Current directory
On Fri, 2003-08-01 at 16:59, Jean-Sebastien Guay wrote:
Unfortunately, this doesn't seem to work. Even if I put the PerlSetVar
statement before my PerlRequire statement like so:
PerlSetVar SCRIPT_ROOT D:/htdocs
PerlRequire D:/htdocs/_startup.pl
the module, which is then loaded from _startup.pl, sees only undef when I
try to print $ENV{SCRIPT_ROOT};
You're thinking of PerlSetEnv. PerlSetVar values are retrieved
differently. Take a look at this:
http://perl.apache.org/docs/1.0/guide/config.html#PerlSetEnv_and_PerlPassEnv
Note that you can also just do this:
Perl
$MyConfig::SCRIPT_ROOT = 'foo';
/Perl
And then in your module:
my $root = $MyConfig::SCRIPT_ROOT;
- Perrin
Re: Skipped Tests (was: handler help)
On Fri, 2003-08-01 at 17:46, Tofu Optimist wrote: Ack!! My perl build failed. [...] Failed Test Stat Wstat Total Fail Failed List of Failed --- ../lib/Locale/Codes/t/all.t 20 2 10.00% 9-10 ../lib/Locale/Codes/t/languages.t 59 1 1.69% 22 42 tests and 406 subtests skipped. Failed 2/712 test scripts, 99.72% okay. 3/68552 subtests failed, 100.00% okay. You didn't follow my earlier advice about changing the locale, did you? I wasn't kidding about that. You can't build perl 5.8.0 successfully on a RH 9 system unless you change the locale. Note that 5.8.1 does not have this problem and is about to be released. - Perrin
Re: Accessing environment variables prior to invoking the contenthandler.
On Thu, 2003-07-31 at 15:44, Mark Deepak Puttnam wrote: I have used the following code in the in my handler and I still do not get the values. Do you get anything at all? HTTP_REFERER is not always sent by browsers. - Perrin
Re: Accessing environment variables prior to invoking thecontenthandler.
On Thu, 2003-07-31 at 16:15, Mark Deepak Puttnam wrote: Only PERL_SEND_HEADER=On. No other env. variables. And you haven't turned off PerlSetupEnv in your httpd.conf? - Perrin
Re: Accessing environment variables prior to invoking the contenthandler.
On Thu, 2003-07-31 at 15:44, Mark Deepak Puttnam wrote:
sub handler {
my $r=shift;
my $env=$r-subprocess_env;
%ENV=%$senv;
my $referer=$ENV{'HTTP_REFERER'};
x
}
Come to think of it, you should just use the Apache API for this:
my $referer = $r-header_in(Referer);
- Perrin
Re: Working directory of script is / !
On Tue, 2003-07-29 at 07:23, Stas Bekman wrote: That's correct. This is because $r-chdir_file in compat doesn't do anything. The reason is that under threaded mpm, chdir() affects all threads. Of course we could check whether the mpm is prefork and do things the old way, but that means that the same code won't work the same under threaded and non-threaded mpms. Hence the limbo. Still waiting for Arthur to finish porting safecwd package, which should resolve this problem. When he does finish it, won't we make the threaded MPM work just like this? It seems like it would be reasonable to get prefork working properly, even if the threaded MPM isn't ready yet. - Perrin
RE: no_cache(1) and still cached?
On Fri, 2003-07-25 at 04:32, Frank Maas wrote: But the idea of setting the Expiry header back in time is appealing... Come to think of it, I have never had problems with mod_proxy caching thing I didn't want cached. Quite the opposite -- I had to be very careful with Expires headers to get anything cached at all. I think you might be mis-diagnosing the problem here. Maybe it's an issue on the backend instead. - Perrin
Re: Database Connections Global Variables
On Fri, 2003-07-25 at 14:55, Levon Barker wrote: If I have a $dbh global variable in a particular module that I 'use'. I know that Apache::DBI will give a cached connection to the module to use. There is no need to use a global. Apache::DBI caches it for you. If you put it in a global, then Apache::DBI doesn't get to do its ping. But what if I do something like $dbh-commit(); Is it possible that I am committing data for another session by accident? At the end of each request, Apache::DBI issues a rollback for any uncommitted transactions. That means that the only things that could be committed are things that you did earlier in the current request. And remember, these are not shared between processes, so there's no need to be worried about interference from other requests. - Perrin
Re: Mixing Apache::Filter with other mods like mod_php
On Thu, 2003-07-24 at 12:48, Crispin Bivans wrote: Situation: I have a custom templating package that will lookup translation texts based off of keywords so we can use 1 html file for all 8-9 languages. I've made it part of an Apache::Filter list that also run's Apache::SSI so that any server side includes in the html file will also get run. There is also some mod_php code (a php require line that pulls in a different page graphic everytime they refresh the page) that I need to also 'run' as part of the web page. [...] How can I make this work? You can't in apache 1.x. In apache 2.x there is the ability to filter content in this way, but the filtering done in 1.x by Apache::Filter is really just at the mod_perl level so it can't deal with additional apache modules. The only way to actually get the PHP code to run is to make a separate request with something like LWP back to the server to run a PHP page, or maybe run it through the separate PHP executable with a system call. - Perrin
Re: no_cache(1) and still cached?
On Thu, 2003-07-24 at 09:55, Frank Maas wrote: What I found was that sometimes users got served 'cached' dynamic pages. Although the server should not cache the page it looked like this happened whenever two requests were received at (nearly) the same time by the server. What happens if you use Expires headers instead of the no_cache() stuff? - Perrin
Re: Application design patterns
On Thu, 2003-07-24 at 09:20, Frank Wiles wrote: I too would like to would like to have a better understanding of how MVC can be applied to mod_perl. Maybe even HelloWorld sized example showing how all of the different components interact? There's one of those in my original article. I'm not really sure what to add to it beyond what's there. You can also read previous discussions on this from the mailing list archives and the docs for CGI::Application, Apache::PageKit and OpenInteract which all talk about it to some degree. If you can ask something more specific, I'll try to answer. - Perrin
Re: [MP2] Placing Apache::RequestRec Apache::RequestIO APR::Table use statements in startup.pl
On Thu, 2003-07-24 at 04:32, Jamie Krasnoo wrote: Will placing Apache::RequestRec Apache::RequestIO APR::Table in startup.pl to load them up for multiple handlers have any bad side effects? I noticed that when I load them via startup.pl the handlers that use them don't complain that they don't have the use statements within the module code and still work as normal. I like to put use() statements for all required modules in each module that needs them. It's good documentation. When you tune your system for performance, you will put all of these in startup.pl to improve shared memory, but there's no need to take them out of the other modules: use() staments for modules that have already been loaded simply skip the require() part and run the import(). - Perrin
Re: Application design patterns
On Thu, 2003-07-24 at 02:18, Eric Sammer wrote:
where did you (Perrin) keep
objects like your database handle (assuming DBI, but please correct
otherwise) and any objects that could be reused (TT, XML parser objects,
et al)?
People seem to ask about this frequently, but I don't think we did
anything especially interesting there. We just had a simple class full
of accessors for these resources that would call factory methods the
first time and then cache the result as appropriate.
For example, to get a DBI handle you would call something like this:
sub get_dbh {
my $r = Apache-request();
my $dbh = $r-pnotes('ESF_DBH');
if (!$dbh) {
$dbh = ESF::Service::DB-new();
$r-pnotes('ESF_DBH', $dbh);
}
return $dbh;
}
This caches the database handle for the rest of the request (one
Apache::DBI ping per request should be enough).
For the Template Toolkit object we want to cache it for the life of the
process, so it would be something like this:
use vars qw($Cached_Template_Object);
sub get_template {
if (!defined $Cached_Template_Object) {
$Cached_Template_Object = Template-new();
}
return $Cached_Template_Object;
}
We also did things in there like setting the include path for the
current request, but you get the idea. These are all class methods in
the ESF::Util class.
I see a reference to a utility style class (ESR::Util, IIRC), but after
rereading a number of articles and design pattern books, I'm reluctant
to go with a handle holder object as I've done in the past.
Gang of Four got you spooked? If you have something that works and
doesn't cause problems elsewhere in your code, don't fret about it.
What I'd like is to have my model (as in MVC) objects reuse the
process or maybe even server shared objects without doing any of these:
1. Using a singleton utility class
2. Needing to pass objects to model objects' new() in teh controllers
3. Instantiating the objects in the model classes themselves
All of those sound legit to me, as long as you don't duplicate code
between the objects. I would choose #1, personally.
I guess I could use a class to just act as a namespace to hold the
objects and create them at server startup time and use a module like
IPC::MM, File::Cache, or Cache::Mmap but that feels kludgy and offers no
encapsulation for the objects themselves.
No, you can't share things like this between processes. Things with XS
code, open sockets, filehandles, etc. are not shareable.
I think the way we did it in the above code (don't fetch it until it's
asked for and then cache it as long as you safely can) is a good
approach, but you could refine it by having it set up some things in the
child init hook.
Perrin - Have you ever considered revealing more about the Etoys project
or just the concepts as you applied them? It would be nice to peek at
some of the details. Or, is this an NDA situation or some such thing?
Well, I don't have permission to go posting big chunks of code, but in
terms of the generally applicable ideas, I think the article covered
most of it. The rest has to do with database work and patterns for
building model objects, and I hope to cover that in the article version
of the talk I gave about object-relational mapping tools at this year's
Perl Conference.
The biggest thing the article didn't cover is the ideas used by the guys
coding the more interactive parts of the application to express the
state machine implemented by each of their modules in a declarative data
structure. This was largely invented by Adam Sussman, who is at
TicketMaster now. It was similar to what you see in CGI::Application
and some of the other frameworks.
- Perrin
Re: Application design patterns
On Thu, 2003-07-24 at 15:17, Eric Sammer wrote: Maybe a stupid question, but what would be the functional difference between dumping the object after each request like you say and using the same method as you describe for the TT object below? I ask because I'm currently treating both objects the same way in two or three of my larger applications. I would assume this is to catch premature database shutdown or network trouble between an app server and database (cluster) on a request by request basis? Is this a performance related choice or an Apache::DBI best practices thing? Apache::DBI already caches it. It will ping the handle to make sure it's active and then hand it back to you. This extra level just skips the ping if we've already done it on the current request. If you simply put the handle in a global, it will not get ping-ed on each requests and you'll have all kinds of problems when connections time out. Another approach to the same issue is to use the setPingTimeOut() method of Apache::DBI. The rest has to do with database work and patterns for building model objects, and I hope to cover that in the article version of the talk I gave about object-relational mapping tools at this year's Perl Conference. Is this past tense and if so, is the article up somewhere? Just curious... I already gave the talk, but have not completed the article yet. - Perrin
Re: Application design patterns
On Thu, 2003-07-24 at 17:22, Garrett Goebel wrote: Perrin Harkins wrote: The biggest thing the article didn't cover is the ideas used by the guys coding the more interactive parts of the application to express the state machine implemented by each of their modules in a declarative data structure. This was largely invented by Adam Sussman, who is at TicketMaster now. It was similar to what you see in CGI::Application and some of the other frameworks. Has anyone written an article on it? On state machines as a model for web apps? Probably. And there is this article about CGI::Application: http://www.perl.com/pub/a/2001/06/05/cgi.html You can also read the fairly extensive docs for CGI::Application, Apache::PageKit, OpenInteract, CGI::MxScreen, and others. None of these require you to read code. Essentially, people have looked at the core concepts of web applications -- screens, transitions between screens, expected input on each screen -- and come up with various ways to define them with a data structure instead of with code. Whether or not this is a good idea depends partly on what your application does. Apps that do lots of browsing/publishing don't gain as much from this as ones that have lots of interactivity and forms. I don't have a background in CS. Welcome to the club. This isn't rocket science. After sifting through google searches I turned up the following article: Essay on Web State Machines by Charles Stross http://www.antipope.org/charlie/attic/webbook/essays/statemach.html That one seems to be about managing persistent data, which is a different topic. Interactive Web Applications Based on Finite State Machines http://www.math.luc.edu/~laufer/papers/isas95.pdf That's more like it. - Perrin
Re: templating system opinions (axkit?)
[EMAIL PROTECTED] wrote: Change that to: !-- TMPL_VAR APPNAME_USER_FIRST_NAME -- You mean TMPL_VAR APPNAME_USER_FIRST_NAME don't you? Or did I miss the secret stealth hide-your-tags-in-html-comments feature? :-) You missed it: http://search.cpan.org/author/SAMTREGAR/HTML-Template-2.6/Template.pm#NOTES - Perrin
Re: Application design patterns
On Wed, 2003-07-23 at 18:18, Aleksandr Guidrevitch wrote: Are there some common application design patterns using mod_perl + TT2 ? Any links would be greatly appreciated There are tutorials on the Template Toolkit site, a recent perl.com article about TT and Class::DBI, and my article: http://perl.apache.org/docs/tutorials/apps/scale_etoys/etoys.html - Perrin
Re: Sharing objects
On Wed, 2003-07-23 at 18:21, Aleksandr Guidrevitch wrote: What are common patterns of sharing data beetween apache processes, for example I'd like to share some indexes. Also, I'd like to avoid complex sycronyzation process (currently IPC::Sahreable seem to be the right thing) No, IPC::Shareable is slow. You are better off with one of these: MLDBM::Sync Cache::Mmap BerkeleyDB (with native locking) Cache::FileCache IPC::MM - Perrin
Re: Sharing objects
Aleksandr Guidrevitch wrote: Actually I think to use Cache::FileCache as the storage backend. But I need to have Cache keys to be sorted by various criteria. I strive to avoid re-reading Cache::* keys and sort them each time, but to share somehow sorted lists beetween apache processes (as they could be huge). However, having an extra key like keys_sorted_by_* in Cache::FileCache will probably solve the problem. It could, but if that's a large list it could be slow. Cache::FileCache will serialize each cache value with Storable, and in this case the value will be one big array. A different approach would be store a separate BerkeleyDB index as a BTree with a custom sorting function, or share your array as a BerkeleyDB recno database (serial records accessed like an array). - Perrin
Re: caching questions
On Tue, 2003-07-22 at 02:13, Tom Schindl wrote: Sorry to step in here, but could I use any of the caching modules you mentionned in mod_perl2? I can't vouch for the thread safety of these modules, but all of them should work in prefork mode. - Perrin
Re: Which way is right for precompiling code in Apache perlhandler:
They are equivalent. You can use either one. - Perrin
Re: Apache::DBI and temporary tables
On Tue, 2003-07-22 at 17:15, Michael A Nachbaur wrote: If I do a $dbh-disconnect, I know it will be ignored by Apache::DBI, but is it smart enough to pass something back to the database server telling it that it can purge temporary data? No. If you come up with a way to do that, you can add it as a cleanup handler. - Perrin
Re: problems with Perl under windows, apache
On Mon, 2003-07-21 at 12:22, Erik Browaldh wrote: I have a script under windows with apache that doesnt seems to work. Are you running it under mod_perl? If so, please tell us if it's mod_perl 1 or 2, and include the info listed at the report problems link on http://perl.apache.org/. We really can't guess much without seeing your code. - Perrin
Re: templating system opinions
On Mon, 2003-07-21 at 12:22, Kip Hampton wrote: And don't forget that, with AxKit, you can use Apache::ASP, Mason, or any Apache::Filter-aware handler to provide content for AxKit to transform and TT2 as a transformational language. Oh, and there's XPathScript, too, which, although its only one part of AxKit, is really a novel templating/trasformation language all on its own... Why choose one when you can have 'em all? :-) Well, no offense to AxKit, but having multiple templating systems in a single project is something that I specifically work to avoid. It complicates things and typically hurts performance. If I had an Apache::ASP app and wanted to use XSLT, I would just use the built-in support for it. If I had a Mason app, I would use XML::libXSLT directly. - Perrin
Re: templating system opinions (axkit?)
On Mon, 2003-07-21 at 12:14, Patrick Galbraith wrote: I get so tired of Java types talking about how perl is just a scripting language.. it's not an application platform/server like Dynamo/WebSpere/insert $$$ java non-OS app here. I even tried to crack a particular Orielly java book and was turned off on a statement like Perl is good for proto-typing but not a full application server. Yes, there are a lot of prototypes getting millions of pageviews a day and generating signicifican revenue. I'd like to see perl/mod_perl reclaim some of the lost ground. Yahoo and Amazon both use perl much more than they use Java. eBay is going Java (from C++), but it's costing them millions and taking years. Ticket Master and CitySearch are both Perl. It looks to me like there is very little evidence to support the claim that Java is in any way better for building high-volume sites. - Perrin
Re: Question to mod_perl gurus. Take 1 minute. Just choose rightanswer from list!
On Mon, 2003-07-21 at 07:31, wrote: so the question: which sub main_deck will be executed? 1. Hi, it's SCRIPT_1! 2. Bye, it was SCRIPT_2! I think #2, because it was the last one eval'ed, and you can only have one sub with a given name in one package namespace. Apache::ePerl does not really support the use of in-line subs. You have to put them in a separate module. - Perrin
RE: Need help, Global Hash corruption under mod_perl in perl5.8.0!?!
On Mon, 2003-07-21 at 02:51, wrote: I have done code deparsing of eperl scripts saved in Cache all started with package Parse::ePerl; use strict 'refs'; print(qq[?xml version=1.0?\n]); so they all have the same package name. Can it cause a bug? Ap::Registry keeps different package name for every script.. It means that all globals and subs are shared between all of your scripts. It could cause a bug if you use the same names for globals or subs in multiple scripts. - Perrin
RE: Need help, Global Hash corruption under mod_perl in perl5.8.0!?!
On Mon, 2003-07-21 at 02:41, wrote: I'm using only Apache::ePerl which allows me use Perl in the the way like PHP, since I don't need Mason or EmbPerl html features for small WAP resources. I think you should consider using a system that is actually supported. Embperl, Apache::ASP, Text::Template, and Mason all have similar syntax to ePerl. There are lots of other things on CPAN that might be even closer in syntax, but are not as widely used and well supported. I just can't understand where the Apache::ePerl bug can be -- it so simple and so clear module.. and it worked on older perl! You should go through the change log for Perl 5.8 then, since something that changed between 5.6 and 5.8 must be causing problems for you. where is all community? it's so silent in the conference. what the language perl programmers migrated to? JSP, PHP? :( Are you asking why more people aren't responding to your question? Probably because almost no one uses ePerl any more. - Perrin
Re: Calling a mod_perl method from whithin a CGI script
On Sun, 2003-07-20 at 17:15, Eric Ricardo Anton wrote: Since I can't port the scripts from mod_cgi to mod_perl, how can I make a CGI script call a mod_perl method? You can't. When you run a script under mod_cgi, mod_perl functions are not available. However, you could try running your scripts under Apache::Registry, and then you'd be able to use the mod_perl API. - Perrin
Re: Variables
Dennis Stout wrote: Is there a way I could get these variables populated on server start and never loaded again unless the database was changed? So in my subroutine for posting an event that changed it I could call repopulate_queue_hash and have it redo the hash, so changes still happened without a restart, but the hash itself is just passed from the root apache process to the children? You can load it into globals at startup and their values will be shared by all children until you write to them. You could also load it separately in each child process in the init hook. However, you'd probably be better off using MLDBM::Sync, so that all changes are shared immediately. It's quite fast, and since it uses a tied interface it would be easy to switch your code to use globals if it turns out not be fast enough. - Perrin
Re: Variables
Dennis Stout wrote: So in startup.perl put my %queue_list = list_queues; my %tech_list = list_techs; and so on? Then each process would get a copy of the hash? No, those are lexicals, not globals. Something like this: package MyCompany::Globals; use vars qw(%queue_list %tech_list); %queue_list = list_queues; %tech_list = list_techs; Then from other code you can use them as %MyCompany::Globals::queue_list. After reading the perldoc for MLDBM, and reviewing my deadline for the project of today, I think I'll just use globals for now. MLDBM::Sync is really easy to use, but if its okay for the data to be out of date then the globals thing is fine. I suggest you avoid shenanigans with killing off processes quickly, since your performance would be terrible. Instead, create a cleanup handler which runs after each request. Keep a timestamp (a global variable that will persist) in each handler of how long it's been since you last updated the data. If it's longer than 5 minutes, refresh the data. The cleanup handler runs after the client is disconnected, so it doesn't matter if it takes a few seconds. - Perrin
Re: does pnotes() work at all in 1.27?
On Thu, 2003-07-17 at 16:51, Mark Maunder wrote: And then install those as a content and logging phase handler. If you have the time and the interest. I've tried this and the logging handler comes up with nothing in pnotes. I've also checked that it's not a sub request. Did you get any further with this? I've never heard of any problems with pnotes(), but I also don't have a 1.27 installed to check it with. Does it work if you just set and read a note in the same handler? - Perrin
