Re: mod_Perl script and SSI need advice
Coexec wrote: Hi all, I have a question about how to pass form data with mod_perl and SSI. I have an HTML page with a mod_perl script included. The script creates a form and takes its input and then prints output based on the input (pretty basic). I have the form action set to the script (action=/perl/test.cgi), the problem is that when the form is submitted, the only thing that gets printed to the screen is the cgi output. I could have the mod_perl script process the information and then generate a new URL and appended a Query_string and then redirect($url1?$foo=$bar). I am sure that there is a better way to do this, I just don't know what it is. I'm afraid I don't quite understand your description of the problem. Is it that the SSI is not working, or that the CGI isn't getting the right input, or what? Can you show us some of the code from the HTML page and the CGI script? How are you running the CGI? Apache::Registry? - Perrin
Re: Newbie: how to use PerlSetVar
[EMAIL PROTECTED] wrote: What about namespaces, i.e. how do I avoid stepping on someone else's variable? Prepend some custom string in front of the VarName: PerlSetVar MyApp_Var1 value1 PerlSetVar MyApp_Var2 value2 Also, note that these are scoped within the Location block where they are defined. This means you can actually have different values for different locations, different virtual hosts, etc. - Perrin
Re: RFC: Template::YetAnother
Thomas Klausner wrote: Hi! On Sat, Nov 16, 2002 at 10:43:44AM +0100, Marcin Kasperski wrote: One note: while talking about templating systems for generating HTML, it can be inspiring to take a look at the Zope Page Templates (yes, I know, this is the python/zope world, not perl...). They found the nice idea of injecting loops/ifs etc into HTML in the way which does not spoil HTML markup. There is a simmilar Perl implementation of this called HTML_Tree http://homepage.mac.com/pauljlucas/software/html_tree/ A module based on HTML_Tree is on CPAN under the name of HTML-Seamstress: http://search.cpan.org/author/TBONE/HTML-Seamstress-1.17/Seamstress.pm There is also an implementation that copies the Zope style pretty closely called Petal: http://search.cpan.org/author/JHIVER/Petal-0.77/lib/Petal.pm - Perrin
Re: Executing Apache::Registry cached script from normal mod_perl
Matthew Hodgson wrote: On Fri, 15 Nov 2002, Josh Chamas wrote: Matthew Hodgson wrote: Hi, I have a script which executes under Apache::Registry and resides in /perl/blah.pl. However, it only generates a fragment of a page, and is normally embedded into an html template using SSI with something like: !--#perl sub=Apache::Include arg=/perl/blah.pl -- I am very aware that this would be better implemented as a raw perl module used from apache's startup.pl (and then embedded using something like !--#perl sub=Blah --) - but practically this isn't an option right now. How about just executing this file like this: do $path_to/perl/blah.pl; I guess that just as long as the script is never actually executed under Apache::Registry, and if the only place it's ever do'd from is the plain library, then this is the best solution. :) Presumably if I needed to execute blah.pl from many different libraries as well as actually embed it using !--#perl sub=Apache::Include --, this wouldn't be so great as each instance of it would be compiled separately as part of that particular block of code, thus bloating the apache process horribly. The other problem is that do will compile the script every time, even if it has been run before in that same process. Slow. You might want to look at how Apache::SSI does it. You can copy the include handling code from there. Otherwise, I would suggest copying some code from Apache::RegistryNG to compile it into a subroutine. - Perrin
Re: RFC: Template::YetAnother
Thomas Klausner wrote:
Yes, this is a RFC for Yet Another Templating System. I know that
there are a lot of those around. But this own might be
different/interesting (at least I think/hope so...)
I also posted this on perlmonks:
http://www.perlmonks.org/index.pl?node_id=213300
Ovid on Perlmonks already said some of the things I would have said
about needing a presentation language. For a templating system to be
useful, it has to be able to deal with loops and conditionals. Your
system pushes those into the Perl code, splitting the presentation
control into multiple places. This fails one of my major goals: the
template coders should be able to change the presentation without help
from a Perl coder. What if they decide they don't want to loop through
the links, but rather just print a message saying there are some? What
if they only want to show the first two? What if they want to display a
list with commas between the elements where they didn't use a separator
before? A mature templating system can handle all of these issues
without changing the main Perl module code.
Because IMO, the main reason for using templates is to seperate code
from markup.
It sounds to me like you want one of the HTML attribute ones, like Petal
or HTML::Seamstress. What was wrong with those?
There is one module, CGI::FastTemplate, that does seperate code from
markup completly. But the way different templates are strung together
seems rather comlicated to me.
It's not complicated, but it is somewhat confusing the first time you
look at it. I don't find your approach much easier though.
# generate a new template handler
my $th=Template::YetAnother-new
({
namespace='acme',
template_dir='/projects/acme/templates/',
});
# build up a data structure
$data={
title=$th-title('this is the title'),
breadcrumb=[
$th-link({url='/index.html',text='Home'}),
$th-separator_breadcrumb,
$th-link({url='/acme/index.html',text='Acme'}),
$th-separator_breadcrumb,
$th-link({url='/acme/bleach.html',text='Bleach'}),
],
content=[
$th-element({heading='SYNOPSIS',value='blabla'}),
$th-element({heading='DESCRIPTION',value='foo bar'}),
],
lastmod=scalar localtime,
};
# fill template print
print $th-fill({data=$data});
Isn't your fill method just doing a sort of multi-level join here? All
of the data is passed in already, so there is no reason to delay
evaluation of the templates.
More importantly, your use of AUTOLOAD to treat method calls as file
names looks neat, but is not a good approach. It's limiting (all
templates in one directory!) and has potential security issues with
namespace clashes. These are all just the same method call with a
single argument changed, so why not write them that way?
Here's the same thing written with Template Toolkit. You could use
HTML::Template, CGI::FastTemplate, Text::Template, etc. here with minor
changes:
my $th = Template-new({INCLUDE_PATH = '/projects/acme/templates/');
$th-process-('title.tmpl', {title = 'this is the title'});
$th-process-('link.tmpl', {url = '/index.html', text = 'Home'});
$th-process-('separator.tmpl');
$th-process-('link.tmpl', {url = '/index.html', text = 'Home'});
$th-process-('separator.tmpl');
$th-process-('link.tmpl', {url = '/acme/index.html', text = 'Acme'});
$th-process-('separator.tmpl');
... And so on.
Text::Template allows Perl code to be put in the template, and
HTML::Template/TT allow loops and conditionals, but no one is going to
force you to use them. They are flexible modules. I think you should
look at them more closely before you go off on your own.
- Perrin
Re: Using Perl END{} with Apache::Registry
Justin Luster wrote: After doing some additional testing it appears that this problem only occurs on my Windows machine with Apache 2.0. I tried it on my Linux box Apache 1.3 and things worked fine. That's a key distinction. Please make sure you say mod_perl 2 when that's what you are using. There is actually no module called Apache::Registry in mod_perl 2, so I assumed you meant the 1.x series. - Perrin
Re: problem with session ids
Minas wrote: Recently I installed the Apache::Session module on my server in order to give a kind of identity to my e-shop visitors, seems to work but generates different session ids when I reload the bellow test cgi. What can I do in order to have my visitor the same session id, up to close his web browser. You're going to have to do some debugging to find out why your script isn't working. You use of Apache::Session::File looks okay, except that you don't handle possible errors. Check if the cookie is being set, if the files are being created in /tmp, etc. - Perrin
Re: Using Perl END{} with Apache::Registry
Justin Luster wrote:
I have an included file that Im requiring:
require test.pl;
Without the END { } block if the script cannot find test.pl I get a
Server error 500 and an appropriate error message in the log file. When
I include the END{ } block I get no Server Error and no message in the
log file. It is almost as if the END{ } is overwriting the
ModPerlRegistry error system.
Does it make any difference if you change what's in the END block?
- Perrin
Re: Help mod_perl 1.27 and DB
Tony Simbine wrote: wenn i reload it, then sometimes i get the document or an error. Well, what's the error? Look at your log file. Then look at http://perl.apache.org/docs/1.0/guide/troubleshooting.html and see if the error is listed there. - Perrin
Re: Can't locate object method new via package Apache::Request(via Mason)...SOLVED
DeAngelo Lampkin wrote: And of course the other reason is that if the solution to the problem was so obvious from the error message, somebody would have posted a solution before I figured it out (with help from you guys). There is documentation related to this problem in the troubleshooting section, and if you'd like to generalize it a little so it will be easier for others to find when looking at this type of message, your help would be welcome. The current documentation is here: http://perl.apache.org/docs/1.0/guide/troubleshooting.html#install_driver_Oracle__failed__Can_t_load__DBD_Oracle_Oracle_so__for_module_DBD__Oracle - Perrin
Re: use http-equiv to refresh the page
[EMAIL PROTECTED] wrote: Also, NPH is only implemented in the NS browsers, and was a way for a webserver to send multiple documents inline down to a browser, and was an ancient way to write status pages and such that automagically refreshed themselves. No, that's server push you're thinking of. NPH (non-parsed header) scripts are CGI scripts that talk directly to the client without the server parsing headers and adding others (like the one that says it's Apache). Normally, mod_cgi adds the response line and certain other headers, so it parses your output. This is the same as using mod_perl with the PerlSendHeader option on. NPH script behave like mod_perl with PerlSendHeader off. - Perrin
Re: When using Apache::DBI...
Clinton Gormley wrote: Am I correct in this: Apache::DBI can only really do its stuff when you perform a DBI-connect, so by calling $dbh = DBI-connect(..) during PerlChildInit and then never trying to reconnect, you are defeating the purpose of using Apache::DBI. That's right. To expand on this, when Apache::DBI intercepts a connection request: * it returns a stored live handle which matches the connection credentials * checks that the handle is indeed still live, and if it isn't, reconnects automatically (potentially destroying any $sth's that you have prepared and retained) It also adds a cleanup handler to issue a rollback of any uncommitted work on that database handle after the request completes. So would this be the right balance between efficiency and safety: 1) use Apache::DBI 2) Do my $dbh = DBI-connect() at the beginning of each request (ie as early as required during each request) 3) use my $sth = $dbh-prepare_cached() once as early as required during each request Yes. The call to prepare_cached won't do anything if that statement is already cached. The way I like to do it is to have a utility class that implements a get_dbh() method. Then I just call that when I want one. Inside of that it can do the DBI-connect business and anything else I need done (maybe resetting the isolation level on that connection if I messed with that anywhere). It can also cache the dbh for the length of the request inside of $r-pnotes if I want to avoid multiple calls to Apache::DBI. - Perrin
Re: use http-equiv to refresh the page
Wei Gao wrote: In my perl program executing in Apache web server, I have the following code: use CGI ; $query = new CGI ; $url = http://www.mycite.com ; #The url to refresh. print $query-header(-status='200 Ok', -type='text/html'); print htmlheadmeta http-equiv=\Refresh\ content=\0;URL=$url\ //head/html; Uh, that's not a redirect; that's an ugly proprietary hack. You should be using standard HTTP redirects. See http://search.cpan.org/author/JHI/perl-5.8.0/lib/CGI.pm#GENERATING_A_REDIRECTION_HEADER for more. - Perrin
Re: use http-equiv to refresh the page
Wei Gao wrote:
I have tried print
$query-redirect('http://somewhere.else/in/movie/land') ; before,
which works fine as to redirect the user to the web page. However, if
the user then tries to refresh this page, the CGI script is called
again without any params, which result in Internal Server Error.
You lost me. If you redirect the user to http://mycite.com/, and then
the user reloads, he should be reloading http://mycite.com/. I don't
see any reason why that wouldn't work. Are you saying that reload in IE
goes back to the URL that issued the redirect and reloads that? Even if
it does, it should still be submitting the query string or POST data,
although the user may get a pop-up asking if he wants to submit POST
data again.
Is using meta tag a bad approach?
Yes. It's something that Netscape added to their browser, which others
may or may not add to their browsers. It's not part of any HTTP spec
and isn't guaranteed to work, even on totally correct web browsers.
- Perrin
Re: use http-equiv to refresh the page
Chris Shiflett wrote: A meta tag is not something unique to Netscape I said it was added by Netscape, and I'm pretty sure it was, back in 1.1 or 2.0. As with any other HTML tag, the meta tag does not need to be part of an HTTP specification in order to be valid. Also, it is guaranteed to work on any compliant Web browser. HTML has its own specification, and the latest version describes the meta tag here: http://www.w3.org/TR/html4/struct/global.html#h-7.4.4.2 Look a little further down that page: /*Note.* Some user agents support the use of META http://www.w3.org/TR/html4/struct/global.html#edef-META to refresh the current page after a specified number of seconds, with the option of replacing it by a different URI. Authors should *not* use this technique to forward users to different pages, as this makes the page inaccessible to some users. Instead, automatic page forwarding should be done using server-side redirects./ I might be overzealous about this, but I dislike seeing HTTP-EQUIV meta tags used when actual HTTP headers are available to do the same thing. It's fine if there's a reason for it, but usually people do it because they don't realize they can just send a real header instead.. - Perrin
Re: use http-equiv to refresh the page
Wei Gao wrote: Thanks for the reminder. I think the reason that print $query-redirect(-uri='http://www.mysite.com', -nph=1); is not working, is because my program doesn't seem to know how to handle nph. I am using Apach1.3.26 and Perl 5.6.1. I have use CGI qw(:standard -nph) ; at the beginning of the script. However, when I tried to use nph, the server complains about Bad Header. Is there any known issues that the versions I use don't support nph? Am I missing something? I don't think NPH is related to the problem you're having, but Apache determines if a script is NPH by looking at the prefix of the file. Try naming your script nph-something.cgi and it should support NPH. This is not very well documented, unfortunately. You don't need to use an NPH script to make redirection work. It's also still not clear to me what isn't working for you. When I get redirected in IE and then reload the page, it reloads the page I was redirected to. Since this is all getting pretty far off topic for the mod_perl list, you might want to try asking on a CGI-specific list or on http://perlmonks.org/. - Perrin
Re: use http-equiv to refresh the page
Chris Shiflett wrote: I just wanted to mention that the meta tag as well as its http-equiv attribute are both official parts of the HTML standard and have been for quite some time. Netscape also introduced things like cookies and SSL, but that should in no way discredit the technology. I'm just bitter about Netscape because I worked at a company that made me use frames and JavaScript when the 2.0 version came out. It is also the only option for the pause, then redirect behavior the original poster desired that I can think of.. It is the only way I know to do that, but I didn't think that's what he was trying to do. He had a wait time of 0 in his example. - Perrin
Re: [O] Re: Yahoo is moving to PHP ??
Tony Bowden wrote: ... but I think that there should be a certain level of ability that should be assumed when coding commercially ... My current situation is somewhat unusual because Perl is not the language that the people I am coding with were hired to write. They are mostly Java programmers, and I'm just doing some useful admin and database scripts in Perl because it's so much quicker than doing them in Java. Someone else will eventually have to maintain them, so I write in a way that a novice with a copy of Learning Perl has a hope of understanding. When I work in an environment that is more Perl-centric, I expand the vocabulary of my code more. things like map, hash slices, and even $_ aren't what I could class as advanced Perl ideas. Perl is a large language, and not all of it needs to be used all the time. I wouldn't call $_ advanced, but I know I hate reading code where people use it more than they have to. Hash slices and map are uncommon enough that I had been writing fairly challenging OO Perl for quite a while before I ever saw one. I don't use them when something more basic will do just as well. Correct Perl style is probably not something that any two people will ever agree on. This used to bother me more before I realized that all languages have this problem, even though they try to deny it. I've seen some hideous Java code at this place that really takes the wind out of the Java is more maintainable argument. - Perrin
Re: [O] Re: Yahoo is moving to PHP ??
Franck PORCHER wrote: But for is a lot easier to read and debug, IMHO Is there a significant performance difference in using map instead? My experience is that in most cases, the for construct is used to apply the same treatment to all the elements of an array, whence the map construct. In those cases, the readibility is definitely altered by the index that get in the way. I think you're forgetting that for is just a synonym for foreach. You don't need an index. Of course, this is a quick analysis not taking into account other factors like readibility versus efficiency. In fact, regarding the efficiency of the map construct, I often wondered whether Perl detects map being ran in a void context, so as to give it an iterative interpretation, avoiding to build the output list. It's really not a matter of efficiency, but rather of correctness. Using map in a void context is a mistake. There is a time and place for map: when you want to do something to each element in an array and return the array on the other side. Otherwise, use for, like this: some_function($_) for array;. Even when map is not incorrect, I usually avoid it because it has a tendency to take your code from nice, readable perl to evil hx0r PERL in 3 characters. This is the kind of thing that Yahoo was probably worried about when the decided not to use Perl. - Perrin
Re: [O] Re: Yahoo is moving to PHP ??
Tony Bowden wrote:
It sounds like you're saying that you should only use a subset of Perl
as some programmers may not understand the other parts of it?
That is what I'm saying. I'm aware that this is a controversial opinion
in the Perl world. However, I think it's reasonable to know your
audience and write for them. That's the good part of More Than One Way.
The New York Times writes their articles for a certain reading level,
and I do the same with my code.
Note that different audiences have different levels. You can expect
someone who opens up the code in a module on CPAN to be pretty fearless
about advanced Perl ideas. On the other hand, the people in my current
office are mostly novices so I try to take it easy on them when writing
code for work. I will still use a Schwartzian Transform if I need one,
but I'll put in a comment saying this is a Schwartzian Transform, see
such and such URL for an explanation. Same deal with things like
hash-slices, and I try to avoid using $_ when it isn't necessary.
Given:
sub square { $_[0] ** 2 }
my nums = (1 .. 10);
Which would say is more readable and maintainable?
1)
my squares;
push squares, square($_) for nums;
2)
my squares = nums;
$_ = square($_) for squares;
3)
my squares = map square($_), nums;
I'd go for (3) every time.
So would I, in that situation. It's not that map is so evil, but rather
that I have often seen people overuse it (especially after a
first-reading of Effective Perl), and write confusing code with it by
jamming too much into the map { some stuff } list form.
- Perrin
Re: MOD_Perl Converter
Ged Haywood wrote: On Fri, 1 Nov 2002, Frank Naude (FJ) wrote: but, is there any mod_cgi to mod_perl converter available? Have a look at Apache::Registry. And to address the specific problem you mentioned about initializaing variables, look at Apache::PerlRun. - Perrin
Re: hangs on $ENV{'QUERY_STRING'}
Michael Forbes wrote: Well, I've managed to make some significant progress: I got past that hang (apparently modperl was having problems with the URL b/c some of the values were being passed empty... i.e., stage=4eqtype=Allcont=restrictflags=12... notice that cont has no value. That sounds pretty bad. Maybe you should go back to mod_perl 1.3, which definitely does not have problems with that. My next problem, which took four hours to track down, is that it turns out that mod_perl is choking on null values being retrieved from MySQL. I'm using DBI for the interface, and the actual fetch_row is performing exactly the way it should... but when it tries to do anything with my scalar once it has a null in it, it just chokes sits there until it times out. Are you using the pre-fork MPM? If not, do you know if your DBD driver is threadsafe? - Perrin
Re: Yahoo is moving to PHP ??
Mithun Bhattacharya wrote: http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm If nothing else this should be atleast generate some thoughts ?? It does: hooray! Yahoo is moving from a proprietary server-side scripting tool to an open source one. Great news for all of us, since they will help legitimize open source (the largest site in the world runs on it) and maybe feed good ideas back to the open source world. (Of course Yahoo has used other open source tools forever.) If you look at the performance graphs they made, mod_perl comes in neck and neck with PHP. We always see mod_perl go faster than PHP in Joshua's tests, but Yahoo was testing with this Ioncube cache that keeps PHP code in memory (like mod_perl). The performance tests were so close that a little optimization on the mod_perl side might actually turn it around. They didn't make their decision on performance though. They seem to have been most influenced by the idea that perl allows too much flexibility in coding style, although I can't see how PHP is going to help with that. They also say they plan to continue using lots of perl in all the places they use it now: off-line processing, filling in the includes and dbm files that the server-side script assembles. Perl is not being removed. - Perrin
Re: [OT] Re: Yahoo is moving to PHP ??
Tom Servo wrote: Check out their online map site, they do use Python for that. I'm actually surprised they didn't go with Python, because the people I know there love it. If their backend data processing ever gets moved from Perl to something else, it would probably be moved to Python. - Perrin
Re: Yahoo is moving to PHP ??
Mithun Bhattacharya wrote: No it is not being removed but this could have been a very big thing for mod_perl. Can someone find out more details as to why PHP was preferred over mod_perl it cant be just on a whim. Think about what they are using it for. Yahoo is the most extreme example of a performance-driven situation. They have so much volume that they are willing to write things in C++ just to get the speed that is required. They pre-process and cache things as much as they possibly can. The server-side scripting language they use is basically a glorified include processor. They pull in pre-built include files and read things out of dbms with it. That's all. The real application stuff is built in other languages. (At least this is the impression I get from the paper and from talking to people there.) Given that, PHP is a reasonable fit. It's fast, has a less flexible syntax, and uses less memory than mod_perl. They also have more of a need than most people to integrate with C/C++, and I've been told that it's easier to hack those into PHP. Think about the implications of the memory graph. If they can run 5 more apache children at once on PHP because of its lower memory consumption, 5 * 4500 = 22500 more users they can handle at any given moment! Also how does one go about justifying the fact that Ioncube cache is doing a better cacheing than any mod_perl based solution ?? Sorry, I read that wrong. It was actually mod_perl that had the best performance. The cache they use works just the same as Perl's normal operation, i.e. once some code is compiled it stays in memory and doesn't need to be compiled again. You don't have to do anything to get that in Perl. - Perrin
Re: Same $dbh under different pids?
harm wrote:
On Wed, Oct 30, 2002 at 06:05:51PM +0800, Philippe M. Chiasson wrote:
For the same reason that running this:
$ perl -e'fork; { $foo = {}; print $$:$foo\n}'
1984:HASH(0x804c00c)
1987:HASH(0x804c00c)
produces this for me, every single time I run this program
You are assuming that if (0x804c00c) is equal in different processes,
they must be pointers(or references, or handles) to the same thing. And
it is not the case ;-)
Wait, ins't it the case? That number is supposed to be the location in
memory. It seems like these are all pointing to the same hash. I can't
explain how that would happen though, based on the code shown here.
- Perrin
Re: Same $dbh under different pids?
Mrs. Brisby wrote:
$ perl -e '$foo = {}; fork; print $$:$foo\n;'
18161:HASH(0x80fd254)
18162:HASH(0x80fd254)
$ perl -e 'fork; $foo = {}; print $$:$foo\n;'
18163:HASH(0x80fd254)
18164:HASH(0x80fd254)
I expected the first. I didn't expect the second. Thanks for the
explanation.
- Perrin
Re: DBD::Oracle/Windows2000 OK from prompt, not mod_perl?
Larry Leszczynski wrote: I'm having a problem on Windows 2000 where DBD::Oracle works fine from perl on the command prompt but not from inside mod_perl. I think it is a problem loading DLLs but I can't figure out what's different running under mod_perl. The machine is running: ActiveState perl 5.6.1 build 633 Apache 1.3.26 (prebuilt) mod_perl 1.27_01-dev (Randy Kobe's build) DBD-Oracle8 (ActiveState ppm) You can't just mix and match like that. Modules that you want to use under mod_perl have to be built against the same perl that mod_perl was built with. If there is a DBD::Oracle with Randy's distro, use it. Otherwise, you need to build DBD::Oracle with the same perl he used, or build mod_perl with ActiveState 633. - Perrin
Re: Yahoo is moving to PHP ??
Cristóvão Dalla Costa wrote: Perrin Harkins wrote: They also have more of a need than most people to integrate with C/C++, and I've been told that it's easier to hack those into PHP. What a joke. Have you written C extensions for both Perl and PHP and think Perl is easier? Most people complain about XS being challenging. The picture might be different when SWIG and Inline::C are taken into account, but I've never used them so I couldn't say. In general, it makes sense that a simple language would be simple to extend with C. That's why people like TCL. - Perrin
Re: Yahoo is moving to PHP ??
Iain 'Spoon' Truskett wrote: In general, it makes sense that a simple language would be simple to extend with C. That's why people like TCL. They do? =) Sure. That's why Vignette used TCL: adding your own C commands to the language is easy. Probably the same story for AOLServer. - Perrin
Re: Apache::Clean, Apache::Compress, mod_gzip/deflate, cross sitescripting and more.
Richard Clarke wrote: Before I embark on a day exploring the pros and cons of today's cleaning/compression tools, I wondered if any of you could give me some feedback about your own experiences within the context of medium/large scale web sites/applications (E-Toys etc). We didn't use compression at eToys. There were two main reasons for this. First, it was still a fairly experimental idea at the time, and I had seen browser compatibility problems when hitting some sites that used it. (I believe these have been fixed since then.) Second, more than half of our content was served from the mod_proxy cache, and I'm not aware of a compression tool that works with that. Is there any advantage to using modules like HTML::Tree or HTML::Parser to remove information (i.e. removing autoexecuting javascript tags and any other CSS issues) from user submitted information. No, the best approach is to not attempt to filter user input at all but escape everything when you display it. Then if a user enters HTML characters they will just show up literally in the output. The only time you can't do it this way is if there are certain HTML characters you want to accept. - Perrin
Re: code evaluation in regexp failing intermittantly
Rodney Hampton wrote: I really only need 3 tags: one to link the templates together, one to bring in images, and one to call code that can by dynamically inserted. Like an eval, or a subroutine call? Either way, this is all covered by most of the other systems. Even Apache::SSI can do this. Every item in my application's database (templates, images, and other files) has user and group permissions that need to be checked on access. Thus, any templating system that did caching is pretty much out of the running because as soon as I revoke a user's privileges or change permissions on the item, I want access to change immediately. The only one that has built-in caching of results is Mason, and it won't do it unless you tell it to. All other references to caching mean caching the template parsing. That wouldn't be an issue for this. I'm guessing from your previous post that these things are accessed by calling a subroutine from the templates, and the subroutine does the access checking. That should be no problem. Also, when an advertiser makes a change to one of his/her templates, it needs to propogate immediately. All of them handle that. They check for changes, usually by stat-ing the template files. Additionally, I need to track users so I had to be able to establish and maintain a session so this was a definate requirement. Session tracking has nothing to do with templates. Systems like Embperl and Apache::ASP (and now Mason) integrate it, but that's because they are much more than just template systems. With a typical pipeline arhcitecture, you would handle the session in your code and then pass the data (including whatever session data you need) off to the template. Also, I needed to be able to selectively protect certain areas of the application with login screens (not necessarily the same one depending on where you navigate). Access control also has nothing to do with templates. You can use something like Apache::AuthCookie for this, or you can handle it directly in your perl code. I've done some benchmarking on what I've built already and am satisfied with the results. It's easy to write a fast templating system. What's hard is writing a fast templating system that has no bugs, and can adapt to future needs. It doesn't take long before you find you need more features: whitespace control, a more powerful if/else construct, a way to format dates, etc. That's why the modules on CPAN seem big. They have been extended to handle most of the real-world problems that people need to solve with templating systems. Anyway, I'm not trying to say that what I'm doing is better or worse than what has come before. I just happen to have different requirements and I didn't think that the other systems out there were going to be both lightweight and allow me to meet my need for access control. I'm pretty sure that there are modules on CPAN that do just what you need. If you already have a working system, then go with it. If you find yourself having to revisit the code because you need to add things or are finding bugs or performance problems, consider benefitting from someone else's hard work. - Perrin
Re: Making a module-It can't be this hard.
Robert Covell wrote: I simply want to make a module so I can reuse a common header instead of manually changing each page. Under mod-perl how do you simply create a module that I can use/require/include that I can call a subroutine/function to generate some html based on the page you are on. It works 5 out of 10 times. When it fails I get: [Fri Oct 25 14:24:05 2002] [error] Undefined subroutine Apache::ROOTvirusmailcenter_2erolet_2ecom::index_2epl::DisplaySection called at /mnt/data1/www/htdocsM/mailcenter/index.pl line 410. It sounds like you are using perl4-style libs that don't declare a package name. You can find a description of the problem and some solutions here: http://perl.apache.org/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs The basic fix is to give your modules unique package names. See the perlmod man page for more on package names. - Perrin
Re: [newbie] How do I send a custom HTTP::Response?
Chris Pizzo wrote: The documentation tells me how to create a new response object but how do I reply to a request using my custom response? HTTP::Response? That's an LWP thing, not a mod_perl thing. Maybe you're a little confused here? Tell us what you're trying to do. - Perrin
Re: [newbie] How do I send a custom HTTP::Response?
Chris Pizzo wrote: OK, I am getting a request from a server and I need to respond with an XML doc. So your mod_perl handler is getting an HTTP request and you want to send back an XML document? No problem, just send it. Set the content-type if you need to. There's no trick to it. See the mailing list archives for more on this. - Perrin
Re: code evaluation in regexp failing intermittantly
Rodney Hampton wrote: Let me preface it by stating that I'm building a very simple templating application. [...] Not satisfied, I wanted to make it possible to do something like: % code_ref Util::Test_Util::test_expand % and have it swap in the text output from the sub into the template. That way, unlike other templating applications, I could get away from writing my own mini language and use the full power of perl in a sub called by a simple tag in the template. Do you realize that almost every templating system on CPAN already does this? If you are doing this because you think you've hit on a new feature, stop now and download one of those. If you're doing it because hacking perl is fun and you're in no rush, then go ahead and have a good time. - Perrin
Re: AuthCookie questions
Christian Gilmore wrote: Hi, Michael. Let me try again with more specifics. I'm required to mash my service into another organization's authentication scheme, ditching my own secure methods for their cross-domain unencrypted, unsigned cookie. [...] On a side note, if anyone finds the proposed design lacking for security or anything else, please let me know. It sounds like you are already aware that it lacks security. The important thing to remember about cookies is that unless you use some kind of cryptographic signature to verify them you have absolutely no idea if the cookie came from your site or not. People can very easilly put whatever they want in a cookie to send to your site usingone of the thousands of HTTP testing programs and libraries, and if you use that cookie as a key to a data structure they may be able to gain access to other people's data. Even if you use a crypto signature they can still sniff someone else's legit cookie off the wire, but at least you can prevent them from tampering with the contents of the cookie. Never trust the client. - Perrin
Re: Handler Access to vars created by other modules. (modperl 2.0)
Erich Oliphant wrote: I am having difficulty accessing this variable (via the ENV hash). I decided to make it a PerlLogHandler and register it REALLY_LAST, thinking that mod_unique_id would've exported UNIQUE_ID prior to that. However, that does not seem to be the case :) Something is wrong with your mod_unique_id setup. The mod_unique_id variable should in %ENV from the beginning. - Perrin
Re: [OT] Perl vs. PHP..... but where is mod_perl?
[EMAIL PROTECTED] wrote: Btw when I mean escalate, i mean that the odds of any browser getting a segfaulting page were increased, not that they are random - a particular request - URI,User-Agent,Accept,Cookie, etc combo - consistently segfaults, at least for a few days. Then it's probably fixable, but the people who could fix it are mostly off working on mod_perl 2. While trying to debug this we replaced Apache::Cookie (i'm not certain if every instance of which, but I think we did) with regexes against $r-header_in(Cookie), to no avail. At this point we are using Apache::Cookie and not overriding Apache::Subrequest::run(), and this is working without the segfaults. But, we just recently tried to add an additional call to Apache::Cookie for our ad system and they all came right back. Then, again, I would stop using Apache::Cookie. You don't need it, and using it seems to cause problems.. - Perrin
Re: [OT] Perl vs. PHP..... but where is mod_perl?
Chris Winters wrote: On Fri, 2002-10-18 at 17:46, Tobyn Baugher wrote: As someone fairly new to mod_perl could you make a suggestion of a good alternative to Apache::Cookie? I was using it just because, like Apache::Request, it was *there*. The pure-perl CGI::Cookie works fine. That's a good one, and so is CGI::Simple::Cookie. - Perrin
Re: Do all apache childs create persistant mysql connections?
John Cameron wrote: Thankyou! We are using connect_on_init, so this may explain our problem. What happens if I turn off connect_on_init? Do I need to change our code in any way? Or will the connection be made automatically? The connection will be made when you first do a DBI connect in that process. When you use connect_on_init, it is made when the child process spawns. You would still be advised to move the static files to another server. - Perrin
Re: Do all apache childs create persistant mysql connections?
John Cameron wrote: 2) Does Apache create a new mysql connection/process for EVERY child apache process that is spawned? It creates one in each process that uses the database. I assume some apache processes are spawned to handle simple non-database actions such as retrieving a graphic or static html file. Because we're using Apache::DBI, does this mean that even these little processes are creating a big mysql process? No, if they never use the database they will never create a connection (unless you use connect_on_init). Of course you have no way of keeping the static file requests to a single process, so it's likely that each process is serving some static files and some dynamic requests that require database handles. This is bringing us to our knees. Any help or comments, no matter how obscure, would be greatly appriciated! Use a reverse proxy as described in the mod_perl documentation to keep static requests from tying up database connections. Use the MaxClients setting to liit the total number of apache children, and thus the total number of MySQL connections. Make sure you are always using the exact same connection info, or you could be opening multiple database connections per child. - Perrin
Re: Apache::AuthcookieDBI issue - NS broswers display login form incorrectly?
George Valpak wrote: The browser is getting what appears to be the right html for the login form, but it thinks the content-type is text/plain for some reason. This sounds like a known bug in IE: if it doesn't get a content-type header it will guess based on the file extension. Netscape does not have this bug. I tried adding a meta tag in the html template to no avail: meta http-equiv=content-type content=text/html You can't do that, it needs to be a real header. I also tries setting the header directly in the response in my login.pl file immediately before sending the header: $r-header_out(content_type= text/html); $r-send_http_header; Try $r-content_type(text/html) instead of header_out. - Perrin
Re: [OT] Perl vs. PHP..... but where is mod_perl?
[EMAIL PROTECTED] wrote: This is a bug introduced by having to insert workarounds for segfaults caused by Apache::Cooke/mod_perl. I've been asking for help with this issue for off and on for months now. I suggest you stop using Apache::Cookie and see if the segfaults go away. There are pure Perl modules that handle cookies well, and it's not an expensive operation. Apache::Cookie is probably overkill in most situations. - Perrin
Re: repost: [mp1.0] recurring segfaults on mod_perl-1.27/apache-1.3.26
Ed wrote: Could be bad hardware. Search google for Signal 11. That's actually pretty rare. Segfaults are usually just a result of memory-handling bugs in C programs. - Perrin
Re: current state of conf/code, feedback?
Paul Simon wrote: I was cruising with Apache::DBI, definitely better than the way I had it, but now suddenly I'm getting this error: DBD::ODBC::dr FETCH failed: handle 1 is owned by thread 1e90bdc not current thread b0f18c (handles can't be shared between threads and your driver may need a CLONE method added) at C:/Perl/site/lib/Apache/DBI.pm line 64. What's going on? You'd be better off asking on the DBI list, but it looks to me like your DBD is not thread-safe, or else you opened a connection before the fork (in startup.pl). - Perrin
Re: Can I parse content that has been returned to user by simplecgi script?
Ruslan U. Zakirov wrote: I want to upgrade my project with implementing some feature. Project was writen for mod_cgi, but I would like to parse content that was generated by my scripts to implement something like SSI or Apache::UCase and etc. You can't do that. However, you can run your CGI scripts under Apache::PerlRun and then use Apache::Filter on them to do things like SSI. This will also make them much faster. - Perrin
Re: Apache::DBI for persistent connections
Paul Simon wrote: I was under the impression that Apache::DBI isn't compatible for this set up: win2000 + apache2.0.42 + perl5.8 + mod_perl1.99 For a multi threaded environment, isn't Apache::DBIPool necessary? I'd rather use Apache::DBI. Apache::DBIPool doesn't actually exist yet. Apache::DBI will work correctly in a threaded environment if your DBD is thread-safe. Remember, no variables are shared between Perl threads unless you explicitly share them. - Perrin
Re: current state of conf/code, feedback?
Paul Simon wrote: I currently have CGI pages caching on the client side, which is helping some, but I'm also going to experiment with CGI::Cache. There are some mod_perl specific version of this too, like the one from the mod_perl Developer's Cookbook (Apache::CacheContent), but these are mod_perl 1.x and probably require work to get them running on mod_perl 2. Traditionally this has mostly been done with a caching reverse proxy, and that's another angle you could try. What kind of trouble is there for having use DBI and use HTML::Template in both startup.pl and Snoopy.pm (besides being redundant)? None. That is the right thing to do, because it preloads the modules (by having them in startup.pl) and documents the dependencies (by putting in Snoopy.pm). Since Snoopy.pm is the meat and pototoes, should it also be in startup.pl? Yes. Does declaring Class variables, such as the DBI handle, offer any benefits (or pain) of a shared connection? You're getting yourself into major trouble there. You should use Apache::DBI instead. The way you have it now (with the connection code in the main section of Snoopy.pm), that database connection will be created when you use the module in startup.pl. Apache will then fork and multiple children will try to share the same $DBH. Disaster. Also, your solution will not try to reconnect if it loses its connection. Apache::DBI will. And you are creating a closure here with your $DBH which might come back to bite you later if your module gets automatically reloaded when you change it. - Perrin
Re: Is there an easy way to trace / debug Apache::DBI (Postgres)leaks?
Kirk Bowe wrote: Unfortunately after a couple of hours of moderate use Postgres reaches its max_clients level (which is set below max httpds in httpd.conf) This is usually caused by mistakes in your connection calls where they have slightly different connect info resulting in multiple connections. At this point there's no work being done, so presumably the handles aren't being freed. Database handles are not supposed to be freed. That's the point of Apache::DBI. However, you should only have one per httpd process. Does anyone have any tips on how to, at this point, go about detecting where the handle leak might be (which I'm presuming is the problem)? http://perl.apache.org/docs/1.0/guide/databases.html#Debugging_Apache__DBI should Template::Toolkit be avoided altogether when using mod_perl and database connectivity? TT is not related to this. It works great with mod_perl. - Perrin
Re: Apache::DBI and CGI::Application with lots of modules.
Eric Frazier wrote: Here is the kind of thing that is driving me nuts. Please see: http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remed ies_for_Inner_Subroutines If what this says is true, then either I don't have a closure type problem, or else what is says isn't true. That documentation refers to one particular problem involving nested subs. You don't need to have nested subs to have closures, and closures may not even be the problem. You need to do some debugging. Narrow things down by verifying your assumptions one by one. Is CGI.pm really giving you the values you expect? (Some people have experienced issues with params not being reset when using CGI.pm in certain ways.) Is your SQL query being built correctly each time? Is the data that you're passing to the template correct? Throw in some warn statements. Run it in the debugger if you need to. - Perrin
Re: Apache::DBI and CGI::Application with lots of modules.
Eric Frazier wrote: I wanted the DBH to be global since just about every sub in Holds does a query of some sort. Three options: 1) Pass it to every sub 2) Make a utility sub that returns a dbh and call it from each sub. (Sounds like you already made one of these.) 3) Stuff it in $r-pnotes(), where it will get cleaned up after each request. What is the problem with the my $holdcheck = new Holds() type of syntax? I never read anything about that either way. It's been discussed quite a bit in various places. It is now documented in the perlobj man page: http://perldoc.com/perl5.8.0/pod/perlobj.html#Indirect-Object-Syntax - Perrin
Re: Apache Hello World Benchmarks Updated
Josh Chamas wrote: Set MaxRequestsPerChild to 100 for applications that seem to leak memory which include Embperl 2.0, HTML::Mason, and Template Toolkit. This is a more typical setting in a mod_perl type application that leaks memory, so should be fairly representative benchmark setting. Maybe I'm more careful about memory growth than some people, but 100 sounds a bit on the low side to me. I use Apache::SizeLimit instead of MaxRequestsPerlChild, but I'm pretty sure every child serves more requests than that. Did it seem to affect the performance numbers much? Incidentally, I hate to call this stuff memory leaks, since it's usually just normal growth as memory gets used. Calling it leaks implies that memory is being wasted as a result of mistakes with pointers or some such. When people hear memory leaks they go running for stuff like Apache::Leak, thinking they can find some problem and fix it, which is usually not the case. - Perrin
Re: Apache::DBI and CGI::Application with lots of modules.
I'm just going to point out a few problems. These are not all related
to your questions.
package Holds;
The case of Holds doesn't match the example sub you posted above. I'm
assuming that was a typo.
use strict;
use Carp;
use warnings;
use QueryPrint;
use vars qw($dbh $processed_hnd $status_hnd);
use gentimeid; # generate time id based
sub new {
my $invocant = shift;
my $class = ref($invocant) || $invocant;
That looks like voodoo code copied from a man page. If you call this as
Holds-new(), you don't need that junk about ref. (And most people
recommend against the new Holds syntax.)
my $self = { _ };
bless ($self, $class);
$dbh = db_connect();
You don't seem to need this. You aren't using the database handle for
anything in this sub and you aren't gaining anything by calling it here.
sub GetProcessed {
my $self = shift;
This has a bug, somtimes the cached query doesn't stick around.
If you lose your database connection, Apache::DBI will reconnect. Any
prepared queries will be lost. You *must* prepare every time, but see
below...
sub db_connect {
require DBI;
You don't need that. You should have already loaded it in startup.pl.
my $dbname = 'CS';
my ($dbuser, $dbpasswd) = ('myuser', 'mypass');
Probably should be in a config file, rather than buried in here.
my $dbh = DBI-connect(DBI:mysql:$dbname, $dbuser, $dbpasswd)
or die can't connect: $DBI::errstr\n;
# we need these waiting for queries, so we are going to prepare them ahead of
time, and yes
# horror of horror they will be global. Sorry Mom I tried :(
$processed_hnd = $dbh-prepare_cached(select ord_tpak_processed from orders
where ord_num=?) or confess(can't get tpak processed);
$status_hnd = $dbh-prepare_cached(select is_hold_set,holdstate from
holds where ord_num=?) or confess(can't get hold status);
#DBI-trace(2,/usr/local/apache/htdocs/out.log);
return $dbh;
Don't put those in globals. The prepare_cached call already stores them
for the life of your database connection. Apache::DBI will keep that
connection alive (in a global hash) as long as it can and reconnect if
the connection is lost. If the connection does get lost, the statement
handles in these globals will stop working. You do recreate them every
time since you call this sub every time, but you could lose the
connection between the time this sub is called and the time you use
these handles.
2. Every once in a while I get an out of memory error.
You can control process growth over time in a number of ways. They are
documented in the mod_perl guide.
3. My main search result page is getting cached, the closure type of
problem.
Are you using any modules that have subs with sub ref prototypes, like
Error.pm? That can do it.
All I have read says that because I am using oop
modules and use strict along with use vars that should not happen.
It's actually really easy to create closures. Here is a closure:
my $holdtype = $q-param('holdstate');
display_holdtype();
sub display_holdtype {
print holdtype: $holdtype in process $$\n;
}
This will always print whatever the value was the first time, no matter
what you change it to later. (The first time for that process, that
is.) Watch out for things like that. You should always pass params
explicitly.
4. I know the way I have done these db connects is sloppy. But I can't seem
to find a better way. Could I make one db_connect sub,and inherite it all
though my modules?
Make one sub that returns a database handle and use it from everywhere.
Doesn't need to be inherited, you can just stick it in a module that
all the other modules call.
Hope some of that was helpful,
Perrin
Re: [OT] migrating from Apache to iPlanet; any mod_perl counterpart?
Paul wrote: What I mean is that before I had a custom access handler installed to use MySQL without resorting to state management other than the http NCSA Basic Authentication header You should be able to do that with FastCGI. Not sure about PersistentPerl. You'd have to ask the author. - Perrin
Re: [OT] migrating from Apache to iPlanet; any mod_perl counterpart?
Paul wrote: Looks like the FastCGI binaries are only available for Windows versions. We'll be on Sun Solaris, but I can probably recompile the source, if that doesn't cause the open-source police to come get me. I'm afraid it's not as obvious how to do it as it is with mod_perl. You may need to ask on the mailing list. I still think we're miscommunicating, though. We weren't even using Apache::Registry; the CGI speed improvement of mod_perl is only of incidental interest to us. The API hooks were what we were using. FastCGI (as I understand it, e.g., from http://www.fastcgi.com/devkit/doc/fastcgi-whitepaper/fastcgi.htm ) doesn't offer any API Everything offers an API. CGI is an API. If I understand correctly, you just want to write a custom access control thingy. FastCGI calls that an authorizer and it is documented in that whitepaper. - Perrin
Re: [OT] migrating from Apache to iPlanet; any mod_perl counterpart?
Paul wrote: I know there are servlets, but I was led to believe that I would almost be able to drop my mod_perl modules into the iPlanet server, as if it has some equivelent functionality. If so, I can't find any evidence of it, and I'm rather skeptical. I think your only hope is FastCGI, or PerlEx if you're running it on Windows. - Perrin
Re: [OT] migrating from Apache to iPlanet; any mod_perl counterpart?
Perrin Harkins wrote: Paul wrote: I know there are servlets, but I was led to believe that I would almost be able to drop my mod_perl modules into the iPlanet server, as if it has some equivelent functionality. If so, I can't find any evidence of it, and I'm rather skeptical. I think your only hope is FastCGI, or PerlEx if you're running it on Windows. Wait, there is also PersistentPerl (formerly SpeedyCGI), and Matt's PPerl. Both on CPAN. - Perrin
Re: [OT] migrating from Apache to iPlanet; any mod_perl counterpart?
Paul wrote: The problem isn't so much the registry as the API. Any use of the Apache API would have to be rewritten. There is no way around that. I don't know how I'm going to do all that with iPlanet/LDAP without a lot of recoding, probably in Java. :( There's nothing you've mentioned so far that requires Java. It would be much faster to port it to FastCGI or the like. - Perrin
Re: [OT] migrating from Apache to iPlanet; any mod_perl counterpart?
On Thu, 2002-10-10 at 14:43, Paul wrote: There's nothing you've mentioned so far that requires Java. It would be much faster to port it to FastCGI or the like. I just meant that iPlanet's internal API was probably going to require Java or C, and not Perl. FastCGI and PersistentPerl are both working equivalents to mod_perl with similar capabilities and performance. They should work just fine with iPlanet. I can redo most of it as CGI if necessary, but some of that will require slieght-of-code like embedding data in cookies or hidden form elements I don't see why that would be any different from what you currently have. Any state mechanism requires cookies, URLs, or hidden form values for maintaining at least a unique ID on the client side. There is no other way to do it. I just prefer having all the data from the engine available from the request object, and I'm gonna miss that. Again, I don't understand what you think you're going to lose. All the basic data available under mod_perl is available under everything else as well, albeit with a slightly different API. - Perrin
Re: Forking process
Aaron Johnson wrote: So in a nutshell - Create a temp (flag) file - Generate and send the HTML to the browser which includes a meta refresh - Add the temp file to their session data (or something similar) - Exec a process and send the temp file name to it - On page refresh look to see if the temp (flag) file still exists and if so create a new waiting page ( meta refresh ), otherwise deliver end results. Randal has a description of this process -- with code -- here: http://www.stonehenge.com/merlyn/WebTechniques/col20.html It's for CGI, but all the principles are the same. - Perrin
Re: memory usage problem!
Also, try to find an alternative to loading all that data into memory. You could put it in a dbm file or use Cache::FileCache. If you really have to have it in memory, load it during startup.pl so that it will be shared between processes. - Perrin Anthony E. wrote: look into Apache::Resource or Apache::SizeLimit which will allow you to set a maximum size for the apache process. both can be added to your startup.pl --- Plamen Stojanov [EMAIL PROTECTED] wrote: Hi all, I have a ig mem usage problem with perl. I load 2Mb data from a database in perl hash and perl takes 15Mb memory. As I use this under mod_perl - perl never returns this memory to the OS. I must set a little number for MaxRequestsPerChild in order to restart perl interpreter not to eat a lot of memory. Is there any solution to avoid such memory usage?
Re: memory usage problem!
Eric wrote: What about in the case of a big query result? That is where it seems like you can get killed. Riding a bike without a helmet will get you killed; big query results are no problem. All you have to do is write your program so that it pages through results rather than loading them all into memory at once. The only time this becomes difficult is when you need to load a large BLOB fram the database. - Perrin
Re: memory usage problem!
Rodney Broom wrote: From: Eric [EMAIL PROTECTED] What about in the case of a big query result? I may have come into this thread a bit late, but can't you just undefine the storage when you're done with it? $data = $sth-fetchall_arrayref; #... do some stuff; $data = undef; That will release the memory from that lexical so that perl can use it elsewhere, but it will not release it back to the OS. It's a good idea though, in any situation where you occasionally load large chunks of data into a scalar. (Not a good idea if you load large chunks of data into that scalar on most requests.) - Perrin
Re: figures/resources on content via apache SSI vs. database-driven(perl DBI)
grant stevens wrote: I think all I'm asking about is a performance comparison for a site comprised of 95% static content between Apache SSI and a mod_perl db/template system. Well, mod_include (SSI) is the best choice if it meets your needs. A modern OS will cache your include files in RAM and the whole thing will be very fast. Yes, some perl templating systems cache content in memory and might manage to squeeze out some pages slightly faster, but you will pay for that with hugely increased memory consumption which reduces the number of requests you can handle in parallel. In the end, throughput from a server running mod_include will probably be significantly higher. Apache::SSI is about the same speed as mod_include (on apache 1.x) but uses much more memory. If you are just serving static files, stick with mod_include. The real reason people use templating systems beyond SSI is that they require more power and flexibility. At the point where you start needing to do things with dynamic content, you should probably kiss SSI goodbye. By the way, SSI (or something very close to it) is pretty much the only way to go if you have thousands of unique static files. A system like Mason or Template Toolkit that caches the files in memory would quickly blow up in that situation, and you would end up needing to work around it by keeping most of the pages on disk and loading them at request time, just like SSI. - Perrin
Re: identifying a unique browser session
Martin Moss wrote: How would I go about identifying if a user logs in from 2 different browsers? Can you be more specific? Do you mean two browser windows, or two different browser programs on the same machine, or two different machines? I Have a Session object, but I want to hold data within that session object that identifies which browser a user is using. So I can confirm that a user who provides a session key in their cookie, is checked and that that session key matches that browser. If you issue each user a unique cookie, then each separate browser will have a separate identifying ID. I can't tell what the problem is from your description. Maybe you're looking for something like Apache::AuthTicket? - Perrin
Re: Apache::SharedMem
[EMAIL PROTECTED] wrote: We are using IPC::MM and it works great. IPC::MM is the fastest game in town. It's only drawback is that the data is not persistent, so if you want your cache to persist across restarts it won't work for you. Apache::SharedMem and all the other modules based IPC::ShareLite or IPC::Shareable are slow. If IPC::MM won't work for you, I'd suggest MLDBM::Sync, Cache::FileCache, or Cache::Mmap. - Perrin
Re: perl script not reloading
Michael Grant wrote: It seems that as I work on my script, Apache doesn't reload it when the script changes on disk. Are you using Apache::Registry? It only reloads the main file, not any modules you might be using. For that, you need to use Apache::Reload or Apache::StatINC (as Nigel pointed out). (if so, it should be documented in the mod_perl_traps man page). It's all documented here: http://perl.apache.org/docs/1.0/guide/ - Perrin
Re: [Q][LONG] using IPC::Shareable to cache data, Apache doesnt start
Juan Natera wrote: The worst of all is that Apache simply doesnt start, and I get no error message at all. The error might be on the console, or you could try capturing it and writing it to a file. However, I suggest you ditch IPC::Shareable since it's dog slow. Use MLDBM::Sync, Cache::FileCache, IPC::MM, or Cache::Mmap. - Perrin
Re: modules and pragmas - part II
[EMAIL PROTECTED] wrote: At the first request each instance prints out the no_xhtml-header, but at the second call the no_xhtml-pragma is forgotten and the xhtml-header is printed out. Are you setting $CGI::XHTML to 0 somewhere? btw and OT : in the previous thread there have been rumours about better things than the CGI-module. What could you recommend instead ? (compatible modules prefered cause I really use the sticky- and nostickyfeatures :) There are many. The most compatible is CGI::Simple. If you need CGI stuff but not the HTML generation, you can use Apache::Request or CGI_Lite. - Perrin
Re: same module with different pragmas
[EMAIL PROTECTED] wrote: In the sets of applications that runs under mod_perl on our webserver we need the same modules twice, but with different pragmas. app1: use module qw(standard pragma1); app2: use module qw(standard pragma2); now, of course - whichever application is needed first it loads the module with the mentioned pragma. Later - when the second app wants to load the module, mod_perl uses the already module with the wrong pragma. The problem is that CGI.pm is a bunch of nasty old code that uses global variables like they were going out of style (which they are). The simplest solution might be to stop using CGI.pm and switch to something faster and cleaner. However, failing that you may have to hack the CGI.pm code a little to make a way to turn the XHTML header on and off. (Although, can't you just use -no_xhtml all the time?) Is there any trick around this problem or do I need to copy the module and alter its name ? That won't help. It's about the module namespace, not the file name. - Perrin
Re: top for apache? [OT]
Nigel Hamilton wrote: It would be great to have a similar tool for mod_perl/apache. The closest thing available is a combination of mod_status and Apache::Status. If you haven't tried these yet, give them a shot. They provide a good deal of information. - Perrin
Re: Apache::Session and user sessions
Todd W wrote: Im looking at Apache::Session and trying to figure out what it does. It provides shared storage of a hash of data, and gives you a unique ID that you can tie to a user. From what I can tell, Apache::Session will only give generic sessions, of which I know nothing about the user untill they give me information during that particular session. It's just a storage mechanism. Typically the procedure is that one a user identified herself with some kind of login process, you put her user ID (a primary key to a database table) into the session, and keep it as a key for accessing that data. I have a table with some basic user information (first name, last name, address, phone number, etc...). That's permanent data, not session data. Session data is transient. What i did was created the two columns, and hoped it would work without the id column being the primary key. It won't. All of the Apache::Session data is in a blob in the a_session column. It has no access to the other columns. So now Trying to decide what to do, in a perlHeaderParserHandler Ill just get an id from Sys::UniqueID, send it to the browser each request in a cookie or whatever, then use DBI::Tie to reinstate the session for each request. (Thinking about it, that sounds easier than Apache::Session anyways) Isn't your user table referenced by a user ID? You have to connect the user ID to a browser somewhere. The normal way to do this is give the browser an ID (the session ID) and then store the relationship with Apache::Session. If you have no other transient data besides the user ID, you can skip Apache::Session and just send a user ID cookie. Make sure you have security in place to prevent people from simply entering another user ID in their cookie and gaining access to another person's information. By the way Tie::DBI is slow. Writing some kind of module for accessing your specific user table would be faster. - Perrin
Re: mod_perl 2.x vs. mod_perl 1.x benchmarks
Josh Chamas wrote: I just did a benchmarks to compare mod_perl + apache versions 1 2. Cool. Any idea why bytes/hit is lower on apache 2? Are some headers being omitted? - Perrin
Re: Error messages in Apache::Registry
William McKee wrote:
The way that most people would recommend in A::R or anything else is to
trap errors with eval blocks and then handle them appropriately.
I thought I was doing that at a global level by throwing an error with
die() that was caught by CGI::Carp. I'm realizing that it isn't so simple.
Matt wrote some stuff for the guide explaining why the die handler is
not the best approach. Basically, it means all errors will be treated
the same.
Oh, so if I handle the error myself, I should unset $@?
No, I think I was wrong about that. You shouldn't need to unset it
yourself.
One of the the members of the CGI::Application mailing list suggested
using Graham Barr's Error module and a wrap around the instantiation
script. It's an interesting approach which I'm going to take a look at
today.
I don't recommend that. There's no reason to use Error instead of just
an eval block. It can be this simple:
eval {
... your code here ...
};
if ($) {
... print nice error page with $ message ...
}
This will only work if you turn off all the DIE handlers.
I still am having no luck. I've walked through the execution with the
debugger and am finding that Carp::longmess_heavy is catching my die()
calls despite the fact that I have set `local $SIG{__DIE__} = \mydie;`.
As you discovered, this seems to be interference from the debugger. I'm
not sure how to turn that off, although you could probably look at
perl5db.pl and edit it.
- Perrin
Re: performance regarding mod_perl vs mod_c with embedded perl
Pierre Laplante wrote: I do not use mod_perl with CGI emulation. Actually PerlSetupEnv is on by default. Put PerlSetupEnv Off in your httpd.conf. Here is my mod_perl code: You are not running the same Perl code in both situations. Under mod_perl, you are using Apache::File and various methods of the perl version of the request record ($r). In your mod_c version, you do those things in C. That will make a difference. You seem to be using Error.pm to trap errors in the mod_perl version and normal eval/die constructs (called from C) in the mod_c version. Error.pm will slow things down a little. Also, if you are not handling any phases of the request other than the content handler, you can improve the speed of mod_perl by compiling it without the hooks for the other phases. - Perrin
Re: Morning bug w/out using Apache::DBI?
Your problem doesn't sound like something that Apache::DBI would cause. Deadlock problems are caused by conflicting updates, which could only be coming from your code. I'm not positive but maybe it seemed like there were stale handlers lying around that weren't being closed If you put database handles in globals or in closures, or in some data structure (like an object) that gets put into a global, it will stay around just like it does with Apache::DBI. Is it possible you did something like partially read a set of results and leave the rest dangling? You could try putting some $sth-finish() statements in your code to deal with this. Regardless, I was wondering what a solution would be for this situation. Currently, I do not do a ping if a handler goes stale and attempt a reconnect. Should I implement this feature? No, you would just be rewriting Apache::DBI. - Perrin
Re: performance regarding mod_perl vs mod_c with embedded perl
Pierre Laplante wrote: If I compiled a c module that embed a perl interpreter and I benchmark this again the same module in mod_perl I got a big difference in favor of mod_c. It will be hard for anyone to give you a good answer unless you post the code that you benchmarked. At a guess, I would say that mod_perl is probably doing more work in order to give you access to apache internals. You also may not have configured mod_perl for best performance. For example, if you have it configured to emulate CGI by setting up environment variables that will take more time. - Perrin
Re: lame load balancer, mod_proxy, and sticky sessions
[EMAIL PROTECTED] wrote: The idea to modify mod_proxy.c is probaly the most convenient solution. Instead of configure backend machine from the ProxyPass setting, you may specifically assign it to the one in the cookie, which takes only a few lines of code to change --- well, plus extra steps to handle the cookie. But you're not accounting for the possibility of server failure on the backend. A proper load-balancer (including the open source ones and mod_backhand) would detect dead servers and handle the failover to another server. Building this yourself is probably not worth it, with so many open source solutions already available. - Perrin
Re: mod_perl statistics on securityspace.com
Mark Coffman wrote: I can't imagine that mod_perl will ever be the major scripting language since it, by nature, is unrestrictive. On a multi-user/multi-host server, I think I'd rather PHP be run than mod_perl, simply because I don't want sites stepping on each other's toes and have to worry about restarting httpd. Isn't PHP just as dangerous as mod_perl when run in the server process (as opposed to CGI mode) on a multi-user virtual host server? - Perrin
Re: lame load balancer, mod_proxy, and sticky sessions
Calbazana, Al wrote: I'd like to know if it is possible to use mod_proxy as a sticky session manager. It's possible in the sense that you could write a sticky session manager and glom it onto mod_proxy. It's certainly not there right now. If you just want a free load-balancer, take a look at one of the many open source projects out there like http://linux-ha.org/. - Perrin
Re: lame load balancer, mod_proxy, and sticky sessions
Ask Bjoern Hansen wrote: On Fri, 6 Sep 2002, Perrin Harkins wrote: Calbazana, Al wrote: I'd like to know if it is possible to use mod_proxy as a sticky session manager. It's possible in the sense that you could write a sticky session manager and glom it onto mod_proxy. It's certainly not there right now. Uh, couldn't a combination of mod_backhand and mod_rewrite (using cookies) do it? I believe mod_backhand could do it alone, but that's not mod_proxy. None of the approaches I've seen for using mod_rewite with mod_proxy for load-balancing handle the high-availability part, i.e. removing servers that have gone down from rotation, but mod_backahand does, and it handles sticky sessions. - Perrin
Re: Apache::PerlRun weird behavior?
Stas Bekman wrote: I think I've had enough coffee. PerlRun recompiles the code on each request, meaning that it re-runs any BEGIN blocks on each request. Meaning that My::Config will re-import %CF afresh. That makes sense. I was thinking that keeping track of which BEGIN blocks had run was somehow separate from the compilation process, but that seems pretty unlikely now that I think about it. Since use is almost the same as: require+import. require won't be called because the module will be already in %INC, but import will be always called. PerlRun resets %INC after each run, meaning that it should be compiling the used module again. That doesn't explain why he's having trouble though. - Perrin
Re: Apache::PerlRun weird behavior?
valerian wrote: So the weird thing is that it runs fine the first time, but when I reload the page, it doesn't show the variable I imported from My::Config Try changing this: use My::Config; to this: require My::Config; import My::Config; BEGIN blocks are only run once in PerlRun/Registry, and PerlRun clears the current namespace after each request, erasing the aliases created by import. In general, you'd be better off just avoiding aliases and Exporter altogether, since they waste memory and can cause confusion. Of course I can't explain why this worked for Stas. Maybe there is something about the specific versions of Perl/mod_perl that affects this. - Perrin
Re: Filehandles
Justin Luster wrote: Does anyone know anything about flock and mod_perl? Yes. There is no problem with flock and mod_perl. However, if you were to open a filehandle in startup.pl and then use that same filehandle after forking, that could be a problem. Personally I would suspect Windows in this case. I don't know about XP, but Windows 95/98/ME did not have a working flock. If XP is based on the NT code, it may not have that problem. Even so, I would try testing that first, or maybe asking about it on Win32 perl mailing list. - Perrin
Re: Filehandles
Chris wrote: XP is based on the NT Kernel, and should have a working flock. I believe In recent versions of 5.6.1 flock() is emulated on the 9x kernel as well. However this doesn't mean mod_perl supports it It does actually, since mod_perl is Perl. Thanks for the flock clarification. - Perrin
Re: Filehandles
Justin Luster wrote: The load tester that I'm using works fine with my script outside of mod_perl. Does it work when running them concurrently under CGI? When multiple concurrent users began hitting the script under mod_perl, using Apache::Registry or Apache::RunPerl all heck breaks loose. Hmmm, which version of mod_perl are you using? If you're using 2.x, I can't help you there since I've never tried it on Win32. Maybe Randy will have some ideas. If you have 1.x, there is no concurreny under mod_perl -- requests are serialized. - Perrin
Re: Filehandles
Justin Luster wrote: The stress tool that I'm using is from Microsoft and is a free download. That isn't quite what I asked. Which version of mod_perl are you using? There is a setting in this tool called Concurrent Connections (threads). Regardless, mod_perl 1.x does not support multiple concurrent users on Windows. It will serialize those requests. - Perrin
Re: Filehandles
Chris wrote: I think he said mod_perl 2 in his inital post. Oops, you're right, I totally missed that. Sorry Justin. - Perrin
Re: Done before?
Narins, Josh wrote: Before I proceed, are there ANY content management/templating systems that RELY EXCLUSIVELY on TAG ATTRIBUTE (name=value) nomenclature to allow interaction between template and perl code? Of course. HTML_Tree (http://homepage.mac.com/pauljlucas/software/html_tree/) works this way and is mentioned in my templating guide (http://perl.apache.org/docs/tutorials/tmpl/comparison/comparison.html). There is a more recent module based on the same idea, HTML::Seamstress, available on CPAN. - Perrin
Re: Apache::Session - What goes in session?
Ask Bjoern Hansen wrote: The performance? I don't remember the exact figure, but it was at least several times faster than the BerkeleyDB system. And *much* simpler. In my benchmarks, recent versions of BerkeleyDB, used with the BerkeleyDB module and allowed to manage their own locking, beat all available flat-file modules. It may be possible to improve the flat-file ones, but it even beat Tie::TextDir which is about as simple (and therefore fast) as they come. The only thing that did better was IPC::MM. - Perrin
Re: Apache::Session - What goes in session?
Peter J. Schoenster wrote: If I'm using Apache::DBI so I have a persistent connection to MySQL, would it not be faster to simply use a table in MySQL? Probably not, if the MySQL server is on a separate machine. If it's on the same machine, it would be close. Remember, MySQL has more work to do (parse SQL statement, make query plan, etc.) than a simple hash-based system like BerkeleyDB does. Best thing would be to benchmark it though. - Perrin
Re: Apache::Session - What goes in session?
md wrote:
I haven't looked at the cache modules docs yet...would
it be possible to build cache on the separate
load-balanced machines as we go along...as we do with
template caching?
Of course. However, if a user is sent to a random machine each time you
won't be able to cache anything that a user is allowed to change during
their time on the site, because they could end up on a machine that has
an old cached value for it. Sticky load-balancing or a cluster-wide
cache (which you can update when data changes) deals with this problem.
everything seems so user specific...
That doesn't mean you can't cache it. You can do basically the same
thing you were doing with the session: stuff a hash of user-specific
stuff into the cache. The next time that user sends a request, you
check the cache for data on that user ID (you get the user ID from the
session) and if you don't find any you just fetch it from the db.
Pseudo-code:
sub fetch_user_data {
my $user_id = shift;
my $user_data;
unless ($user_data = fetch_from_cache($user_id)) {
$user_data = fetch_from_db($user_id);
}
return $user_data;
}
I would be curious though that if my choice is simply
that the data is stored in the session or comes from
the database with each request, would it still be best
to essentially only store the session id in the
session and pull everything else from the db? It still
seems that something trivial like a greeting name (a
preference) could go in the session.
Your decision about what to put in the session is not connected to your
decision about what to pull from the db each time. You can cache all
the data if you want to, and still have very little in the session.
This might sound like an academic distinction, but I think it's
important to keep the concepts separate: a session is a place to store
transient state information that is irrelevant as soon as the user logs
out, and a cache is a way of speeding up access to a slow resource like
a database, and the two things should not be confused. You can actually
cache the session data if you need to (with a write-through cache that
updates the backing database as well). A cache will typically be faster
than session storage because it doesn't need to be very reliable and
because you can store and retrieve individual chunks of data (user's
name, page names) when you need them instead of storing and retrieving
everything on every request. Separating these concepts allows you to do
things like migrate the session storage to a transactional database some
day, and move your cache storage to a distributed multicast cache when
someone comes out with a module for that.
The only
gotcha would be that the calendar would need to update
every day, at least on the current month's pages.
The cache modules I mentioned have a concept of timeout so that you
can say cache this for 12 hours and then when it expires you fetch it
again and update the cache for another 12 hours.
Even though there are some preset pages, the user
can change the names and the user can also create a
cutom page with its own name.
No problem, you can cache data that's only useful for a single user, as
I explained above.
Not
to mention that between the fact that the users' daily
pages can have any number of user selected features
per page and features themselves can have archive
depths of anywhere from 3 to 20 years, there's a lot
of info.
No problem, disks are cheap. 400MB of disk space will cost you about as
much as a movie in New York these days.
- Perrin
Re: Apache::Session - What goes in session?
[EMAIL PROTECTED] wrote: We are investigating using IPC rather then a file based structure but its purely investigation at this point. What are the speed diffs between an IPC cache and a Berkely DB cache. My gut instinct always screams 'Stay Off The Disk' but my gut is not always right.. Ok, rarely right.. ;) Most of the shared memory modules are much slower than Berkeley DB. The fastest option around is IPC::MM, but data you store in that does not persist if you restart the server which is a problem for some. BerkeleyDB (the new one, not DB_File) is also very fast, and other options like Cache::Mmap and Cache::FileCache are much faster than anything based on IPC::Sharelite and the like. I have charts and numbers in my TPC presentation, which I will be putting up soon. - Perrin
Re: Mod_perl Application Development
Jonathan Lonsdale wrote: 2. Distinct content handlers each with their own Location directive. Could be a pain to maintain the server config. You would typically have a single handler that covers one application with many screens, so instead of having an entry there for every template you would have a just a small number of entries for applications like a shopping cart or a message board. The applications then manage which template to send out on each request using their own internal logic. Things like CGI::Application and Apache::PageKit are a formalization of this approach. People often seem to get bent out of shape about putting a few Location directives in httpd.conf, but I find it simple to manage and like doing this the standard way. Having Location directives lets you use all of the normal Apache config options for access control, customized logging, etc. without inventing your own config system. There are exceptional situations (a requirement to add new handlers without a restart, for example), but most people will be just fine doing it the old-fashioned way. - Perrin
Re: Apache::Session - What goes in session?
md wrote: Currently I'm putting very little in the session Good. You should put in as little as possible. what I am putting in the session is more global in nature...greeting, current page number, current page name... That doesn't sound very global to me. What happens when users open multiple browser windows on your site? Doesn't it screw up the current page data? I'm pulling a lot of info from the database and I wonder if my design is sound. Optimizing database fetches or caching data is independent of the session issue. Nothing that is relevant to more than one user should ever go in the session. Now I need to add global modules to the page which will show user info like which pages they have created and which features are being emailed to the user. These modules will display on every page unless the user turns them off. That sounds like a user or subscriptions object to me, not session data. It seems that since this info wouldn't change very often that I should put the data in the session... No, that's caching. Don't use the session for caching, use a cache for it. They're not the same. A session is often stored in a database so that it can be reliable. A cache is usually stored on the file system so it can be fast. Things like the login status of this session, and the user ID that is associated with it go in the session. Status of a particular page has to be passed in query args or hidden fields, to avoid problems with multiple browser windows. Data that applies to multiple users or lasts more than the current browsing session never goes in the session. - Perrin
Re: Apache::Session - What goes in session?
md wrote: I don't think global was the term I should have used. What I mean is data that will be seen on all or most pages by the same user...like Hello Jim Okay, don't put that in the session. It belongs in a cache. The session is for transient state information, that you don't want to keep after the user logs out. Current page name and id are never stored in db, so different browser windows can be on different pages... I thought your session was all stored in MySQL. Why are you putting these in the session exactly? If these things are not relevant to more than one request (page), they don't belong in the session. They should just be in ordinary variables. That sounds like a user or subscriptions object to me, not session data. Once again, I shouldn't have used the term global. This is the subscriptions info for a single user...that's why I had thought to put this in the session instead of pulling from the db each page call since the data will rarely change. You should use a cache for that, rather than the session. This is long-term data that you just want quicker access to. I am using TT caching for the templates, but I'm not sure how to cache the non-session data. Template Toolkit caches the compiled template code, but it doesn't cache your data or the output of the templates. What you should do is grab a module like Cache::Cache or Cache::Mmap and take a look at the examples there. You use it in a way that's very similar to what you're doing with Apache::Session for the things you referred to as global. There are also good examples in the documentation for the Memoize module. There are various reasons to use a cache rather than treating the session like a cache. If you put a lot of data in the session, it will slow down every hit loading and saving that data. In a cache, you can just keep multiple cached items separately and only grab them if you need them for this page. With a cache you can store things that come from the database but are not user-specific, like today's weather. What about something like default page id, which is the page that is considered your home page? This id is stored permanently in the db (lasts more than the current current browsing session) but I keep it in the session since this also rarely changes so I don't want to keep hitting the db to get it. I would have some kind of user object which has a property of default_page_id. The first time the user logs in I would fetch that from the database, and then I would cache it so that I wouldn't need to go back to the database for it on future requests. - Perrin
Re: Apache::Session - What goes in session?
md wrote: We are using a load-balanced system; I shoudl have mentioned that earlier. Won't that be an issue with caching to disk? Is it possible to cache to the db? There are a few ways to deal with this. The simplest is to use the sticky load-balancing feature that many load-balancers have. Failing that, you can store to a network file system like NFS or CIFS, or use a database. (There are also fancier options with things like Spread, but that's getting a little ahead of the game.) You can use MySQL for caching, and it will probably have similar performance to a networked file system. Unfortunately, the Apache::Session code isn't all that easy to use for this, since it assumes you want to generate IDs for the objects you store rather than passing them in. You could adapt the code from it to suit your needs though. The important thing is to leave out all of the mutually exclusive locking it implements, since a cache is all about get the latest as quick as you can and lost updates are not a problem (last save wins is good enough for a cache). The modules will consist of a pages module with the names of all the pages the user has created (with links) and a emails module which will display all the features that the user is getting via email. These modules will be displayed on every page. You can see that almost everything is user-specific. The relationships to the features and pages differ by user, but there might be general information about the features themselves that is stored in the database and is not user-specific. That could be cached separately, to save some trips to the db for each user. Right now I'm storing the page names/ids in a hash ref in the session (the emails module isn't live yet), but I thought that I would change that and only store the module id and pull the names from the db (if the user hasn't turned off the module) with each page call. You can cache the names too if you want to, but keeping them out of the session means that you won't be slowed down by fetching that extra data and de-serializing it with Storable unless the page you're on actually needs it. It's also good to separate things that have to be reliable (like the ID of the current user, since without that you have to send them back to log in again) from things that don't need to be (you could always fetch the list of pages from the db if your cache went down). - Perrin
Re: variables not changing with modperl??
darren chamberlain wrote: Make those global symbols ($cookie, $user, and $hash) lexical (declare with my) and the code will both compile and do what you expect (i.e., not maintain values from call to call). That's what I was thinking too. Also, it's really not a good idea to do your own parsing of the input and cookies. You should use one of the CGI modules or Apache::Request and Apache::Cookie for this. Writing your own routine for this is just asking for security problems and bugs. - Perrin
Re: variables not changing with modperl??
Ken Y. Clark wrote: As for this and Perrin's comment about parsing on your own, the point is that you've written a lot of code that has already been written and debugged by a lot of really smart people. There's no reason for you to be reading STDIN and spliting and all that. If you're using mod_perl, then you really should do yourself a favor and read up on Apache::Request and Apache::Cookie for doing all this stuff. Even if you are just using CGI, you shouldn't write your own parsing code like this. Rather than try to explain why, I'll point you to this article on the subject: http://perlmonks.org/index.pl?node_id=51012 - Perrin
