Re: Subrequests
Miroslav Madzarevic wrote:
Is it possible that my perl script (Apache::Registry,
Apache::PerlRun, HTML::Mason or whatever) could run multiple
times with same parameters when the user just invokes the URL
once (for example clicks on A tag) and if so how can I prevent
this from happening.
if(!$r-is_main()) {
return;
}
--
Pierre Phaneuf
Re: CGI Upload/download question
Medi Montaseri wrote: Can I somehow influence this behavior such that the user will indeed see something like MyFile.txt.returned or MyFile.txt.processed in the dialog box. Add a Content-Disposition header like this: Content-Disposition: attachment; filename=MyFile.txt.returned I don't remember for sure, but I think a Content-Length header might help browsers evaluate the time remaining for the download. By the way, the reason for the crazy MIME type, is to prevent the browser to render it. I'm trying to achive a complete upload-process-download. Perhaps there is an standard MIME type that I should use. There is a standard type for that function, application/octet-stream. Of course, whatever you set the Content-Type header to, Internet Explorer could cheerfully ignore it if the extension is associated on the client machine, but that's not your problem anymore I guess... ;-) -- Pierre Phaneuf
Re: modperl growth
Paul DuBois wrote: I think all the recent RedHats come with mod_perl as a DSO by default. I just looked on a RH 7.2 machine. It has the AddModule line in the default httpd.conf, but no mod_perl.so in the modules directory. I think the DSO in a separate mod_perl RPM package. -- Pierre Phaneuf
Re: mod_perl BOF
Stas Bekman wrote: Last week I was presenting mod_perl at the Linux World Show in Singapore and we had a really nice social event with a babe belly dancer... hey, Gunther was dancing with her... just look at his happy face :) Man, when I see stuff like that, I know I'm in the right business. :-)) -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: PerlRestartHandler
Robin Berjon wrote: Yes, I stole the content from the as yet unpublished Tk and mod_perl books that I got to review and I'm writing "Applications mod_perl-Tk: le probleme du monadisme heuristique chez Leibniz, Quine, et Bekman" for the Sorbonne University Press. Ouch! Just reading the titles makes my head hurt! LOL! (I'm french canadian) Hmm, Tk from mod_perl, that would be weird. :-) -- Pierre Phaneuf Systems Exorcist
Re: Getting a Cache::SharedMemoryCache started
DeWitt Clinton wrote: The other question is whether or not to share the cache instance itself globally. Technically, this is up to you. Personally I wouldn't bother, considering the overhead of instantiating the cache is so low that I would rather keep it local to the handler (as I did above). I tend to only share data globally in mod_perl handlers very judiciously, and even then I wrap the data in an object that provides accessor methods. For an example of an object that wraps shared data, check out Cache::MemoryCache, which simply caches data inside the process. Wouldn't this cause the cache to be torn down and rebuilt for every request??? -- "The camel has not evolved to smell good. Neither has Perl." -- Larry Wall
Chromium
Did anyone try the Chromium Apache-based web server? More specifically (and topically), does it work with mod_perl? http://www.chromium.com/ -- "I've run DOOM more in the last few days than I have the last few months. I just love debugging ;-)" -- Linus Torvalds
Re: [OT] ApacheCon BOF
Steve Reppucci wrote: Some folks spend way too much time looking for something to be offended by, again IMHO. I'm pretty sure that for any thing you might find, I would be able to find someone offended by it. Let's no do anything too obvious (a camel ramming up stuff up Bill Gates ass would probably be a bad choice :-) ) and we'll do fine. -- "Perl appeals to the other side of your brain, whether that's associate, artistic, passionate, or merely spongy." -- Larry Wall
Re: understanding memory via ps -ely | grep http
[EMAIL PROTECTED] wrote: What's about FreeBSD? If shared memory is not compiled in kernel of FreeBSD I cant use GTop module because of absant of shared memory. So I dont know is there performance affect or not. You do not have shared memory enabled in your kernel? Any reason? I'd say that most Unix machines in the world have use for shared memory at some point in time, it's a pretty safe thing to enable. Anyway, the "share" thing in GTop is not about "SysV shared memory IPC", but rather about memory shared between related processes (if they load the same libraries for example, the kernel could share the read-only parts of the library between the two processes instead of loading two copies, thus saving memory). -- "There are two major products that come out of Berkeley: LSD and Unix. We don't believe this to be a coincidence." -- Jeremy S. Anderson
Re: [NQ] Newbie Question about mod_perl
"Differentiated Software Solutions Pvt. Ltd.," wrote:
I have written two mod_perl programs whose output is same (through
browser).
I want to know what are the difference between them! If there is any
difference then what are the pros and cons in using both of them?
The second program is taking advantage of the PerlSendHeader feature.
This is mostly a compatibility feature, I would tend to think that it
might be slightly slower (because mod_perl has to watch for the empty
line).
The first program should be a very small amount faster, as far as I
know, but the second has a partial advantage of portability to
non-mod_perl regular CGI environment. I say "partial", because you test
for $ENV{MOD_PERL}, which you don't need to do.
--
"The number of Unix installations has grown to 10, with more expected."
-- The Unix Programmer's Manual, 2nd Edition, June 1972
Re: book recommendations?
Paul Evad wrote: I know a lot of the good O'Rielly books are showing some age (1999 publishing date). Anyone out there have a copy of "Writing Apache Modules with Perl and C", is it still relevant enough with the current apache mod_perl distro's to be worthwhile getting? Yeah, it still mostly is. Apache 2.0 and the accompanying mod_perl 2.0 will be a whole new ball of wax though, but they're not here yet anyway (hey Doug, going to make a second edition for 2.0 I hope?). It's a great book. I found the O'Reilly mod_perl quick reference booklet quite useful at time. Easy to carry around, packed with all the information (no fluff or explanation, like the man pages), useful. -- "Whip me. Beat me. Make me maintain AIX." -- Stephan Zielinski
segfault on subrequest?
I have a PerlTransHandler that is very simple:
sub handler {
my($r) = @_;
my($info);
$info = $r-lookup_file('/home/pp/pierre.jpg')-content_type();
warn("content type is $info\n");
return DECLINED;
}
But it causes a segfault when invoked... I removed the
"-content_type()", so that I should normally see something like
"Apache::SubRequest=SCALAR(0x815eb54)", but it also crashes.
I tried using the exact same handler as a PerlHandler and as a
PerlHeaderParserHandler instead, and it works perfectly. I was thinking
that calling lookup_uri from within a PerlTransHandler might be a bad
idea (infinite loops!), but I would have thought that lookup_file would
be ok...
Okay, maybe everyone will jump in my face about this: this is on an
updated Red Hat 7.0 system, using Red Hat's Apache and mod_perl RPM
packages.
--
Pierre Phaneuf
http://www3.sympatico.ca/pphaneuf/
Re: Read on closed file handle?
David Jourard wrote: Found my error after I had my sandwich. Lesson to keep from this: eat your sandwich! :-) -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: Newbie Questions
julie wang wrote:
I'm new to Modperl. I been programming as a perl programmer (not the best,
but I'm trying to improve) and been told to try and code using mod_perl. I
got ORA's book on Apache Modules and was reading about how to code using
mod_perl. Am I right to assume mod_perl is more Apache conf. than anything
else? (if using Apache::Registry) I been coding perl using the -w flag as
well as "use strict". I shouldn't need to alter how I code Perl, right?
Well, yes, you at least have to take care of some additionnal things.
The most important thing to know is that your code could be called a
number of time before being "reset", where a regular CGI script is
called only once and dies right after, which let you have some
sloppiness that you can no longer afford with mod_perl.
Imagine that this code:
my($var) = 0;
sub handler {
my($r) = @_;
$r-content_type('text/plain');
$r-send_http_header;
$var = $var + 1;
print "\$var is $var\n";
return OK;
}
What you'll have with this is that you'll basically get a random number
for every requests. If you want to start this script assuming that $var
is 0, then set $var to 0 at the beginning.
Is there anyway to test if the server is running in mod_perl or not? I know
this is one of the FAQ questions, but I didn't really understand. I am
using exit(0); and exit; to terminate my perl scripts. What should I
replace that with if it is advise not to do so when using mod_perl?? The
FAQ suggests using "goto" kind of statement. I rather not use that. What
other alternatives do I have? Thanks!
In Apache::Registry scripts, the environment variable GATEWAY_INTERFACE
is set to 'CGI-Perl/1.1'.
In recent enough mod_perl, 'exit' (with or without parameter) is
overridden and will not hurt the server, but the cleaner way to exit an
Apache::Registry handler is with 'return'. I *think* you can return
something like "return REDIRECT" or "return SERVER_ERROR" if you want,
but I'm not sure (I only use PerlHandler scripts, not Apache::Registry).
--
Pierre Phaneuf
http://www3.sympatico.ca/pphaneuf/
Re: uri to filename
Nikolaus Rath wrote: As described in the other mail, i have a TransHandler wich modifies the URI. But this doesn't work correctly. After modifying the URI, do you return DECLINED or something else? -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: Modifying $r-uri
Nikolaus Rath wrote: I want to modify $r-uri in a Handler. Is the PerlTransHandler hook early enough? I think the handler must be called before the Location Sections in the apache config are used to build the dir_config struct. Yes, I think PerlTransHandler is early enough (that's why you can't put them in Location). -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: Authentication handlers
Cees Hek wrote: So instead of storing a y/n in the database, store a unique string that is used as the realm, and clear it when they log out. Now everytime you send the Authenitication required header, send the unique realm for this user that you stored in the database, and if it doesn't exist, generate a new one. Good one! The only bad thing I see is that the realm is visible in the dialog box the user see, isn't it? Seeing a random string might be a bit unsettling for the user, but there is no technical reason for it not to work. -- Pierre Phaneuf Systems Exorcist
Re: Authentication handlers
"Paul J. Lucas" wrote: Is there any means of removing the username and password from the browsers cache. $r-nocache(1); No, I think he's talking about the "basic" authentication information, that browsers keep in memory until they are stopped. I think that if you give them an AUTH_REQUIRED, it might clear the password, but that would also make the authentication dialog box appear on their machine, which would be rather confusing. Personally, I use cookies for authentication instead, you can remove those at will. -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: Authentication handlers
Bill Moseley wrote: i'm using mod_perl authentication handler, where the user's credentials are checked against a database and in the database i have a flag which tells the login status (y|n), but aftr the user logs out the status is changed to n , my problem is that after logging out if the user goes one page back and submits the browser sends the username and password again , and the status is changed to y . Is there any means of removing the username and password from the browsers cache. I guess I don't understand you setup. If you have a database entry that says they are logged out why don't you see this when they send their request and return a "Sorry, logged out" page? The problem here is that the first basic authentication is not any different from the next ones, so if he marks the user as logged out, going to an page requiring authentication will simply mark the user as logged in. You could try various tricks still, with accordingly varying degrees of success. While you might have a number of pages protected by basic authentication, make only *one* of them actually mark the user as logged in. For example, that might be /login. An example user session might look like this: - go to / - click on the "login" link, sending him to /login - /login is protected, so browser queries the user for authentication - /login sees the basic authentication header, marks the user as logged in - user do whatever he wants - user is logged out After this point, if the user goes to any protected web page, even though the basic authentication header is actually correct, he should get a AUTH_REQUIRED response, because he isn't marked as logged in by the database. The only page with the power to make the user logged in is /login. There is a security problem with this. The user/password combo is *not* cleared from the browser! If someone logs out, then a passer-by uses the same browser to log into the site, he will not get any question asked and will be identified as the previous user! Basic authentication is annoying. They forgot to put a way to revoke the thing when they designed it. Eh, that's life... -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
PerlModule vs use in a Perl section
I was using Apache::Status to learn a bit about what is loaded by my server, and I am wondering about a detail... If I put this: Perl use Apache::Foo; /Perl Or this: PerlModule Apache::Foo I would expect the two to behave the same, but they don't! The "use" in the Perl section does as I was expecting (the module and everything it loaded was right there), but while the PerlModule seemed to change something (Apache::Util was loaded, which I use in my Apache::Foo module), Apache::Foo itself wasn't on the list of loaded modules! Using a "+" when installing the PerlHandler (like this: "PerlHandler +Apache::Foo") did load the module as expected. Now, why aren't modules loaded with PerlModule not showing up in the loaded modules list of Apache::Status? Thanks! -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
path_info *again*! help!!!
So I have this very clean Red Hat 7.0 system: [root@tetine httpd]# rpm -V apache mod_perl [root@tetine httpd]# I download the Apache::TreeBrowser module from http://modperl.com/ and put the TreeBrowser.pm file in /etc/httpd/Apache (which I just created). At the very end of /etc/httpd/conf/httpd.conf, I add the following four lines: Location / SetHandler perl-script PerlHandler Apache::TreeBrowser /Location I restart my web server (with "/etc/init.d/httpd restart"), wait a little, then go fiddle with it. *** It doesn't work. *** The first part of path_info is "eaten" somewhere. Let me explain: If I start at the root (http://127.0.0.1/), everything looks fine, path_info is "/". I click on "bark". Now it's not fine, path_info still says "/", URL says "/bark/" (just like my location bar in my browser) and the web page says that I am at the "Tree Root" node. Now, if I click *again* on "bark", I am now at /bark/bark/, the path_info is "/bark/", the URL is "/bark/bark/" and the web page says that I am at the "bark" node. The translated path says /var/www/html/bark, even though there is no such directory, of course. Now for the most interesting: If I change the Location / into a Location /tree, EVERYTHING IS FINE. So this seems to be an exceptional case that happens only at /!?! So what's going on here?!? -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: cron for mod_perl?
Ask Bjoern Hansen wrote: So: What is the task at hand (more than "run something at certain intervals" (which is what cron(8) is for)). I am building a web something-something (I don't know what's the current buzzword for that, you know, the big integrated things) similar to the ArsDigita Community System (ah, I bet this helped a lot more! :-) ). My first occurence of this need was about expiring session keys from the database. At first, I was about to do a little query that run from a cleanup handler every so many seconds, but after that, I was stealing some more ideas from ACS (it's a very good idea, but AOLserver and Tcl, ick!), and I was getting jealous of the AOLserver scheduler, which they use abundantly. For example, you can check a list of URLs at regular interval to see if your machines are up (and get a warning if some are not), or you can send warnings to users when their car is about to get towed away because of parking regulations. :-) Anyway, from fussing around in ACS, it came to me that a general scheduler is a pretty good idea, so I set to it. More about the rationale in another reply to Matt Sergeant... [1] http://perl.plover.com/Questions.html Very good one, I almost died of a chocolate-covered banana indigestion. :-) -- "The 3 great virtues of a programmer: laziness, impatience and hubris." -- Larry Wall
Re: cron for mod_perl?
Ask Bjoern Hansen wrote:
I guess two persons "simpler" aren't always the same: I find it easier
laying out a table and querying it than hacking something to fiddle with
my crontab safely.
As far as I know, crontab -e is perfectly safe.
"crontab -l | foo" and "foo | crontab -" are your friends.
Ah yes. The problem with this is between the "crontab -l" and the
"crontab -". You have to parse the crontab, find your own entry without
disturbing other entries, mix in your new/modified entry, etc... Not
that it's impossible, but I don't like this very much and I find
INSERT/SELECT/UPDATE easier.
Also, I'm not totally sure a piped open would be okay in Apache, since
this has a fork() underneath. Probably that it cannot be done in the
obvious straightforward way, 'open("crontab -l |")'. I would have to go
through the Apache subprocess API and do things I'd rather not be doing
(hey, I was the one annoyed by path_info not being translated for me :-)
).
Call me lazy. :-)
--
"MSDOS didn't get as bad as it is overnight -- it took over ten
years of careful development." -- [EMAIL PROTECTED]
Re: cron for mod_perl?
Matt Sergeant wrote: as for putting cron into Apache: I don't understand why that's wanted in the first place. When connecting to the database outside the httpd it doesn't matter if it goes a little slow. And having separate programs to do the maintenance would easily be much simpler than trying to drop everything into the httpd. Its just a convenience thing. I've wanted to be able to do this too, for example to have emails go off at a particular interval. So yes, it can be done as cron + URI, but I'm just jealous of AOLServer's ability to do it all in one. This is especially important for a shrink-wrapped type application, where asking people to install a crontab entry is just another pain in the installation process (note that cron might be different on different OS's, and so might the shell be, so this is a real problem for some people - whereas if it were in Apache we'd know the platform). Same reasons here for wishing for this. By the way, it could even be done as "cron + perl script that does the job directly (outside of Apache)", but I'm trying to integrate things, so that you start one DBMS daemon and N Apache servers (on different machines, of course), and you have the application running. As you mention, there is also the problem of being cross-platform. Apache and mod_perl runs on Windows, but I would have to make people get themselve a cron for Windows? I think that I *will* make an Apache::Schedule module, but much less ambitious and more closely related to the way Apache and mod_perl do things. What about this summary: Apache::Schedule let you register callbacks (per Apache child process) that will be called after a given amount of time has passed, either once or repeatedly. Callbacks will be called at the next request after the required time, or at child exit time. Would anyone find that useful? Of course, you can always run it from cron. Or make yourself a daemon. Or use POE. Or use Zope. Or (even) use AOLserver. TMTOWTDI. Is there a mod_perl for AOLserver? ;-) -- "Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn
Re: cron for mod_perl?
Stas Bekman wrote: I might be barking at the wrong tree, but why cron? Why don't you use at(1). you don't need to parse crontab for that, and you can spawn processes with whatever intervals on demand. basically you can call at(1) itself at the end of at() so you can do the same as crontab. Yes, at is much better suited, but you still have the problem of forking under Apache (possible, but hairy) and systems where there is no at. -- "The camel has not evolved to smell good. Neither has Perl." -- Larry Wall
Re: cron for mod_perl?
Tim Bunce wrote: Apache::Schedule let you register callbacks (per Apache child process) that will be called after a given amount of time has passed, either once or repeatedly. Callbacks will be called at the next request after the required time, or at child exit time. Would it work even if the server is not getting any requests? And if so, how? No, that's the problem. :-) That's where my idea of a cron job that does a HEAD request on an URL that has the cleanup handler installed every 30 minutes (say) comes from, so that there is a minimum level of service. But while I would mention that in the README, that is outside the scope of the perl module to do and left to the individual user. The restriction would be clearly documented, and here's a way to help out with it, but if it doesn't do what you want, don't use it (or tell us how to improve it). AOLserver has it easy, being in a single process and having this scheduler tied in at the select() level, it never misses a beat and is always on time (to a few tens or hundreds of milliseconds, if the server is not overloaded). Apache is more complicated, with multiple child processes that die after a while and don't know about each other (and cannot depend on one particular child process to be there) and so on. You could put something in the Apache parent process, but that would require a new hook in Apache itself. That would be cool, but still not free of problems: - the parent process often runs with root privileges, do we run the scheduled callback as root inside the parent process? - if we do, if it is long running, you could have problems with Apache Maybe it could register an URL to invoke on itself? Anyway, I'm not enough into Apache to do something like *that*, even though I'd love to... -- "I've run DOOM more in the last few days than I have the last few months. I just love debugging ;-)" -- Linus Torvalds
Re: cron for mod_perl?
Vivek Khera wrote: PP Ah yes. The problem with this is between the "crontab -l" and the PP "crontab -". You have to parse the crontab, find your own entry without Very limited thinking going on here. The crontab program honors the EDITOR environment variable. Now... setenv EDITOR=myscript then run crontab -e. Poof. Atomic update. That's what I intended to do (that's why I didn't mention concurrency problems), but you still have to fork, which is hairy under mod_perl. With appropriate Perl modules for the cron files, this should be trivial. But then, you probably aren't doing this from mod_perl... Well, yes, why? :-) -- "I've run DOOM more in the last few days than I have the last few months. I just love debugging ;-)" -- Linus Torvalds
Re: cron for mod_perl?
Perrin Harkins wrote: The original post didn't say that the goal was to modify the scheduled jobs dynamically from mod_perl, and that does add a new wrinkle. I still think a good Perl interface to cron would be more obvious and more reliable. Sorry, maybe I didn't make that quite clear. Yes, it is a goal. For example, to take an example from the ACS, a user can add or remove parking warnings from the web site. I could write a file somewhere and have another process in cron process that file every once in a while, but I would like direct and immediate feedback/effect. This could be simply an Apache::Cron module or something like that, to ease the task of add/modifying/removing cron jobs from mod_perl, I agree. -- "As usual, this being a 1.3.x release, I haven't even compiled this kernel yet. So if it works, you should be doubly impressed." -- Linus Torvalds
Re: cron for mod_perl?
Vivek Khera wrote: With appropriate Perl modules for the cron files, this should be trivial. But then, you probably aren't doing this from mod_perl... PP Well, yes, why? :-) You really want to have your web server writing files that execute arbitrary programs at arbitrary times? Sounds risky. Well, I'd like to keep this as little arbitrary that I can. For examples of what I'd like to be able to do: http://tz.arsdigita.com/ http://remindme.arsdigita.com/ http://uptime.arsdigita.com/uptime/ The last one fetches URLs from the web. As for risky: this is just as risky as using mod_perl at all. What is run is controlled by the script, so it's not 100% arbitrary, if you can help it. If it was inside Apache, then it wouldn't be arbitrary programs, it would restricted to the server. -- "You can have my Unix system when you pry it from my cold, dead fingers." -- Cal Keegan
Re: cron for mod_perl?
Perrin Harkins wrote: Well, if I call the "check for things to do" URI every minute, then I'll be just fine. Many times, I'll just check and find nothing to do Huh? Why would you call it if there's nothing to do? Are you thinking you'll write a cron-ish task/timing spec for your Perl app and just use the cron triggers as a constant clock? Yes, exactly. My plan is to have a table with the tasks in my database, and check expired tasks in a cleanup handler. I'll have to lock the table, so that only one process does that. I'll also query the database only every so often, not at every request cleanup. The more hits I get, the more accurate the "cron" will be, but I think I will use a cron trigger a request to have a minimum level of accuracy (could be every half-hour, just to make sure we're never late by more than that, or whatever is appropriate). Anything better? -- "Unix gives you just enough rope to hang yourself -- and then a couple of more feet, just to be sure." -- Eric Allman
Re: idea modules info
Svante Srmark wrote: ConfigDBI i Config via DBI and Perl MARKIM Oracle's new Apache-based application-server stores its config in the database. It might be good for some ideas. Any pointer to information? -- "A Perl script is correct if it gets the job done before your boss fires you." -- Larry Wall
Re: cron for mod_perl?
Perrin Harkins wrote: Yes, exactly. My plan is to have a table with the tasks in my database, and check expired tasks in a cleanup handler. I'll have to lock the table, so that only one process does that. I'll also query the database only every so often, not at every request cleanup. Well, by frequently hitting your web server and having it look in the database to decide to do nothing, you're putting a lot of unnecessary stress on your server. What's wrong with making individual cron jobs that call individual URLs (think of it as RPC) to cause actions on your web server exactly when you want them done? Doesn't that sound a whole lot simpler? I think you are over-evalutating the stress on my server. With the speediest time base I was talking about (once per minute cron job), that would be 1440 HEAD requests per day, each requiring 1 simple database query that will most probably return no row at all (a query that returns many rows is slower, because it has to transmit these rows). Many sites with database-driven pages have multiple complex queries on some pages and run in the millions of page-views per day. As for the simplicity, having multiple individual custom cron jobs is simpler than one single generic cron job? But still, I don't like my solution very much either. My problem lies in the case where I get a lot of hits, I want to be careful of what I run in my cleanup handler (if I hit the database at every cleanup, I'll start piling up daemons if I get plenty of hits). I was thinking of having a variable with a timestamp of when we last checked the database, and getting into a cleanup handler, we'd hit the database only if it was more than a minute ago that we checked. -- Implementation: n., the fruitless struggle by the talented and underpaid to fulfill promises made by the rich and ignorant.
Re: cron for mod_perl?
Perrin Harkins wrote: Sure, but why waste resources? Because it's easy? :-) As for the simplicity, having multiple individual custom cron jobs is simpler than one single generic cron job? Yes, much simpler, at least for the scheduling and dispatching part. Instead of designing database tables to hold timing info on jobs and code to check it that is smart enough to remember when it last ran and prevent race conditions, you can write a simple crontab with one call to wget per job. The actual implementation of the jobs is pretty much identical either way. I guess two persons "simpler" aren't always the same: I find it easier laying out a table and querying it than hacking something to fiddle with my crontab safely. Do it whatever way suits you. I'm just suggesting that you try the lazy way if possible. I could mash the two together: have a single URL trigger that looks up the tasks to do in a database, but have it schedule it's next run itself using "at". Whew, there *is* a whole lot more than one way to do it! :-) I was thinking of having a variable with a timestamp of when we last checked the database That will have to be some sort of shared memory or file-based thing, since you won't be using the same process each time. I was intending on being lazy and let a bunch of processes find out there is nothing to do because one of them already did the work. ;-) Ahh, the joy of wasting resources... Would anyone be interested in seeing an Apache::Schedule, with an API similar to the Tcl API in AOLserver? http://aolserver.com/docs/tcldev/tapi-114.htm http://aolserver.com/docs/tcldev/tapi-113.htm http://aolserver.com/docs/tcldev/tapi-115.htm -- "We make rope." -- Rob Gingell on Sun Microsystem's new virtual memory.
Re: idea modules info
Mark Imbriaco wrote: What is the usual process for one that would like to help with a "i" module? Is there any code done, or some message/thread that I could be pointed to, discussing the idea, things like that? I developed some code to do this a VERY long time ago, but the code was quite specific to my needs (virtual hosting) and I never got around to generalizing it. If you're interested in taking over the module list entry for this one, I have absolutely no problems with that. Send it to me, I'll take a look! I don't garantee I can take it over, but if I use it, I probably will be able to maintain it (as part of my day job). -- "How should I know if it works? That's what beta testers are for. I only coded it." -- Linus Torvalds
Re: idea modules info
Mark Imbriaco wrote: What is the usual process for one that would like to help with a "i" module? Is there any code done, or some message/thread that I could be pointed to, discussing the idea, things like that? I developed some code to do this a VERY long time ago, but the code was quite specific to my needs (virtual hosting) and I never got around to generalizing it. If you're interested in taking over the module list entry for this one, I have absolutely no problems with that. Send it to me, I'll take a look! I don't garantee I can take it over, but if I use it, I probably will be able to maintain it (as part of my day job). I don't even have the code any more -- it was written three jobs ago and the company it was written for doesn't even exist anymore. :) Sorry. Okay, no problem. Could you write up a quick summary of how it worked (or how a rewrite should work)? If that was discussed on this mailing list already, you could give me a pointer to a thread instead... -- "The only 'intuitive' interface is the nipple. After that, it's all learned." -- [EMAIL PROTECTED] (on user interfaces)
Re: trouble with path_info
Pierre Phaneuf wrote:
Does anyone has an idea about this? I think I have proper behavior from
my perl handler by installing it at the root of the server, but this is
no real solution!
What I am doing wrong here???
I'm really stumped with that one. How come Apache::Registry gets the
right information and I don't??? I tried doing the exact same thing, to
no avail.
I built the smallest possible testcase I could (attached to this
message, just fix the /home/pp/tmp in httpd.conf and startup.pl into
wherever you unpack this, if you want to try it out).
Ideally, http://localhost/perl/test/foo and http://localhost/test/foo
would both say the same thing ("path_info: /foo"). On my machine, they
don't.
http://localhost/virtual/ should also say "Path information =/" at the
bottom. On my machine, it says "Path information =/virtual/".
--
"World domination. Fast." -- Linus Torvalds
cron for mod_perl?
Is there a way to have a Perl function called at some point in time, like I think AOLserver can do in Tcl (but I don't want to do either AOLserver or Tcl!)? I thought about checking the time in a PerlCleanupHandler, but this would be in each Apache subprocess and I want this to get called only once. The precision is not so important (unless we're talking hours later or something like that!). I thought of having a table of jobs in my PostgreSQL database and (carefully avoiding race conditions with transactions/locking) checking if the next job was due to be run, but that doesn't "smell" very good. I could run the query only on the condition that a minute has passed since the last time we did it, but still, I'm not sure. I would like to know if anyone already did that or have any idea on how to do that more properly? -- "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence." -- Edsger W. Dijkstra
Re: trouble with path_info
Matt Sergeant wrote: Does anyone has an idea about this? I think I have proper behavior from my perl handler by installing it at the root of the server, but this is no real solution! What I am doing wrong here??? I'm really stumped with that one. How come Apache::Registry gets the right information and I don't??? I tried doing the exact same thing, to no avail. Because Apache::Registry has a real file, so the fixup handler puts the right thing in path_info. Without a real file and a fixup handler you don't get the right information in path_info, you have to figure it out by hand. That would make the Apache::TreeBrowser example in the eagle book wrong, isn't it? Doug, is there something I'm missing about installing Apache::TreeBrowser? -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: trouble with path_info
Matt Sergeant wrote: That would make the Apache::TreeBrowser example in the eagle book wrong, isn't it? Yes, that example seems incorrect to me. Hmm... Strange... It actually *works* at http://modperl.com/tree/ and I downloaded its source code from http://modperl.com/book/source/! Doug, is there something you forgot? Errata? Or, again, something we are forgetting? I made a PerlFixUpHandler that simply shave $r-location from the front of $r-path_info, if you install it in the same directory as Apache::TreeBrowser (or other similarly written handler), it make them work fine. PS: Please don't post large attachments to the list in future - send us a link to a place we can see the code you are using on the web. Sorry! I took extra care to make the package as small as possible, but I understand the rule, thanks! -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: trouble with path_info
Matt Sergeant wrote: I'm really stumped with that one. How come Apache::Registry gets the right information and I don't??? I tried doing the exact same thing, to no avail. Because Apache::Registry has a real file, so the fixup handler puts the right thing in path_info. Without a real file and a fixup handler you don't get the right information in path_info, you have to figure it out by hand. As a side-note, I guess it's most probably the translation handler that puts the right thing in path_info. My workaround is a fixup handler, since there is no actual filename to translate, and you can't put a translation handler just in a Location anyway. Thanks for your help! -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: cron for mod_perl?
Is there a way to have a Perl function called at some point in time, like I think AOLserver can do in Tcl (but I don't want to do either AOLserver or Tcl!)? I thought about checking the time in a PerlCleanupHandler, but this would be in each Apache subprocess and I want this to get called only once. The precision is not so important (unless we're talking hours later or something like that!). Matt Sergeant wrote: Pretty much what you've already found out - Apache has no "cron" like daemon. One way you can do it is fork off a sub-process and run some sort of Cron perl module (I think there's a Cron module on CPAN, or you can run cron-like features with POE). Hmm, too bad, that would have been easy to implement in the Apache core request processing loop (it's build into the core of AOLserver). I'll look to make sure, but I think this will be possible in Apache 2.0. Anyway, that doesn't fix my problem for now. Isn't forking off from Apache rather nasty? I saw something to that effect somewhere in the eagle book and on some web pages, but I think there are ways to do that without causing problems. Perrin Harkins wrote: The common way to do it is to just use the real cron facility (assuming you are on unix) and have it call a URL on your server using LWP. I am on a Unix-like system, but I wanted the events to be updated by the web server itself, so that I could use the Apache::DBI cached connection to the DBMS (I want to store the events in there). This seems good, exposing a URL that a cron job would fetch every minute (or something like that). I don't like much the idea of exposing an URL like that (could be used to cause a DoS, accessing the DBMS like crazy, but I guess this is a problem for any database-driven web site), but I can always restrict the URL to 127.0.0.1... Vivek Khera wrote: Set up a handler and have a cron job "GET" the URL for it. Yeah, I think that's what I'll do! You already have the "GET" program from the lwp package while installing mod_perl. I have the mod_perl RPM that comes with Red Hat, and I can't find the LWP anywhere. Not that I can't install it or use wget instead... Thanks everyone! -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: trouble with path_info
Matt Sergeant wrote: Hmm... Strange... It actually *works* at http://modperl.com/tree/ and I downloaded its source code from http://modperl.com/book/source/! Right, but the directory /tree might exist on their server - you never know... I found the visible trigger. I didn't have a DocumentRoot *at all* in my configuration, but it didn't matter, as everything I have is served from handlers in Location sections (or even in the root of the configuration file!). If I would hit / directly (without the root PerlHandler), I would get a notice about /usr/htdocs not existing in my error log (that's the default DocumentRoot). I intented to verify the idea that having an actual /tree directory would help matters, so I proceeded to set a DocumentRoot in my configuration, figuring I'd then create the appropriate directory. Behold! Everything worked as in the book, without the directory! It just needed to have something *valid* as the DocumentRoot (I tried setting the DocumentRoot to something invalid, it doesn't work). Now, I do not completely understand this. Am I right when I say that nothing on the filesystem is needed to locate a Location handler? IMHO, a Location handler should be able to get its path_info resolved without any filesystem access (thus, without any dependency on having a valid DocumentRoot), and the current behavior would be a bug. I think the trouble might be more into Apache itself than in mod_perl. Right now, I consider my problem fixed, but I feel that this might be a real bug. I'll go submit something to the Apache bug tracking system later... -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: cron for mod_perl?
Matt Sergeant wrote: Isn't forking off from Apache rather nasty? I saw something to that effect somewhere in the eagle book and on some web pages, but I think there are ways to do that without causing problems. Yes, its a pain. I suggest using the ways detailed below. My only problem with those ways is that its not controlled from your application generally, unless you write your own cron-a-like in Perl, and access your datastore to get the configuration. Well, if I call the "check for things to do" URI every minute, then I'll be just fine. Many times, I'll just check and find nothing to do, but it'll be under "enough" application control. You might contrieve adding a cron entry as being "outside the application" though... I would really like putting this in a cleanup handler, but the problem I see is if I don't get any hit for too long (which might happen for an internal web site, say over the weekend), I might miss events. I'll probably have a combination of both approaches... I am on a Unix-like system, but I wanted the events to be updated by the web server itself, so that I could use the Apache::DBI cached connection to the DBMS (I want to store the events in there). The cached connection will be used, just as it would for the rest of your application. Also note that HTTP::GHTTP loads a *lot* faster than LWP, and executes faster too. And yes, you can restrict that URL to localhost, or password protected. I was thinking of using wget with "-O /dev/null". :-) As for the cached database connection, I knew about that, but I was thinking of the forking approach (where there was no cached connection available (not that it couldn't be cached!)). -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: trouble with path_info
Matt Sergeant wrote: Well you should read how Apache works. See http://httpd.apache.org/docs/sections.html It should clear things up for you. Thank you, very interesting! -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
trouble with path_info
I spent two days trying to make my "virtual document" PerlHandler work from various locations, which I had thought to be really easy, by simply looking at the path_info to determine what virtual document to bring up. No go. In just about every cases that I could do, I have $r-path_info identical to $r-uri! I freaked out after a while, thinking I must have been doing something wrong here, so I downloaded the Apache::TreeBrowser module from the modperl.com site, installed it as the sole handler in my server (no translation handler or *anything* else). I installed it just like in the Eagle book. Where on http://www.modperl.com/tree/ I see this: URI = /tree/ Path information =/ On my server (http://foobar/virtual) I see this: URL = /virtual Path information =/virtual What the heck??? I was expecting path_info to be blank there, then getting a redirect to /virtual/ (and having just a slash in there). I think that I know what I might be doing wrong though: I'm running Apache 1.3.14 and mod_perl 1.24_01 from the Red Hat "RawHide", on a Red Hat Linux 7.0. 1.24_01 is a development version, right? :-) In any case, this might be a problem developers might want to hear about... -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: trouble with path_info
Geoffrey Young wrote: I spent two days trying to make my "virtual document" PerlHandler work from various locations, which I had thought to be really easy, by simply looking at the path_info to determine what virtual document to bring up. No go. In just about every cases that I could do, I have $r-path_info identical to $r-uri! you may want to check out this thread: http://marc.theaimsgroup.com/?t=9790472865w=2r=1 and $r-location() Actually, I want to do the exact *inverse* than this guy! :-) But I agree that stripping off $r-location() from $r-uri() would give something workable, and that's what I have been doing, but the thing is that $r-path_info() should *already* work, and none of this should be needed! Apache::TreeBrowser *doesn't work* here, because of this problem, for example. I could put that $r-location() workaround in it, but it would be just that, a workaround, because on Doug's web server, it works. -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: trouble with path_info
darren chamberlain wrote: In just about every cases that I could do, I have $r-path_info identical to $r-uri! If you are installing your handler as such: Location / SetHandler perl-script PerlHandler My::Package /Location Then what you are seeing is correct. What does the relevent httpd.conf snippet look like? Just like in the eagle book (page 143): Location /virtual SetHandler perl-script PerlHandler Apache::TreeBrowser /Location And I'm totally unable to get what you see on page 137. :-( I will try with a non-development mod_perl now. :-) -- "Unix gives you just enough rope to hang yourself -- and then a couple of more feet, just to be sure." -- Eric Allman
Re: trouble with path_info
Pierre Phaneuf wrote: Then what you are seeing is correct. What does the relevent httpd.conf snippet look like? Just like in the eagle book (page 143): Location /virtual SetHandler perl-script PerlHandler Apache::TreeBrowser /Location And I'm totally unable to get what you see on page 137. :-( I will try with a non-development mod_perl now. :-) I just tried going back to the RPMs that came with Red Hat 7.0, no go either (Apache 1.3.12, mod_perl 1.24). -- "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." -- [EMAIL PROTECTED]
path_info in my perl handler
Did some more testing: $ENV{PATH_INFO} from a CGI script is okay, and so
is $r-path_info() from an Apache::Registry script. Why does the
PerlHandler one doesn't work right then?
--
"The 3 great virtues of a programmer: laziness, impatience and hubris."
-- Larry Wall
trouble with path_info
I'm really stumped with that one. How come Apache::Registry gets the
right information and I don't??? I tried doing the exact same thing, to
no avail.
I built the smallest possible testcase I could (attached to this
message, just fix the /home/pp/tmp in httpd.conf and startup.pl into
wherever you unpack this, if you want to try it out).
Ideally, http://localhost/perl/test/foo and http://localhost/test/foo
would both say the same thing ("path_info: /foo"). On my machine, they
don't.
http://localhost/virtual/ should also say "Path information =/" at the
bottom. On my machine, it says "Path information =/virtual/".
Help!!!
--
"Back in 1997, I grepped over a huge number of messages and collected
some damned lies, I mean, statistics, on what kind of In-Reply-To
headers they contained." -- Jamie W. Zawinski
mod_perl-trouble.tar.gz
