RE: mod_perl advocacy project resurrection
This has been a really interesting thread. I would like to contribute my own experiences as I am currently sitting on both sides of the fence. In my spare time, what little there is, I operate a web hosting service for NZ Christian churches, organisations and ministries. This endeavour also operates as a ministry and hence comes under some very real constraints, the biggest being a very low budget. I can not afford to run top-end servers so must make the best of fairly modest equipment. I can not afford to hire programmers, so I do all the system admin and programming myself. I opted for Perl as I was reasonably comfortable with it and wanted an environment where I could build what I needed quickly and it would be relatively easy to look after. In the early days, I used to pull my hair out trying to get each new release of apache and mod_perl running, the problem was usually compounded by adding SSL. The arrival of Ralph's mod_ssl and the more recent apache and mod_perl distributions have helped heaps. What do I do with mod_perl, at this time it serves 3 purposes 1. It allows me to use my PostgreSQL database for web authentication (AuthDBI), 2. It offers database connection persistence, 3. It operates as a CGI accelerator. I haven't needed to work directly with mod_perl but have some things I would like to use it for next year. But my own site is only one of 150 odd on the server and I am the only one using mod_perl, a couple of sites use PHP, why ? The simple answer is - I can. It is my environment and I have control over the whole shooting match, I can fiddle the apache config as necessary, I can easily add perl .pm's as needed. I am technically competent and used to working with non-trivial technologies. I work in the IT department of one of NZ's Universities, I have been here for years and consequently have watched and been involved with technologies that have come and gone. The latest area that our applications people are working with is using the web to deliver information from and interacting with our student management system, a large Ingres Database. The current application is run as a CGI and is written as a monolithic perl programme. Simply put, it is a disaster. The people who wrote it, learned perl as they went, and being fair to them, it works. Their architecture enabled them to add functions reasonably quickly, but the application does not scale. They are not using any database connection persistence at all and multiple concurrent session very quickly kill the web server, a high-end Compaq alpha. This application has seen us through the last 12 months but is hopefully to be replaced. With what ? Well, it would seem that no amount of arguing by the systems programmers or myself is going to be successful in getting them to continue with perl, but in a mod_perl environment. They are going to go the Java way, the reasons have all been stated in this thread before; Market hype, its an expensive solution so it must be good, its a cool new technology, you can't get good perl programmers, its what is being used by everyone else, we don't understand mod_perl ( they don't understand the java solution either ), we can buy the business logic we don't have to build it ... I like the perl/mod_perl solution, it works well for me, I believe it is also an appropriate technology for solving enterprise problems. The biggest hurdle we have faced in trying to get it considered has been market perception. If we had been able to find recognised or well-known enterprise/corporate/large site implementations to use as reference sites, it might have helped. To be able to say that site X uses a mod-perl solution and they are using Ingres/Oracle/Sybase or whatever and getting umpteen thousand hits a day gives the technology creditability. The Microsoft and Java marketing machines have given their technologies credibility (whether they deserve it or not is irrelevant). The decision has been made, unfortunately, so much of this is now water under the bridge but a list of reference sites might help others construct better cases for their management. -- Glen Eustace, Systems Engineer - Networking. Information Technology Services, Turitea, Massey University, Palmerston North, NZ. Ph: +64 6 350 5799 x 2707, Fax: +64 6 350 5607 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Followup: mime-type headers
The foibles of IE and the Win OSes has proven to be beyond me :-( Thanks to those that offered various solutions, each worked but not on all combinations of IE version and Win version. My solution, in the end, has been to generate the PDF to a temporary file, in the document tree and issue a 'Location:' header back to the browser. This seems to work in all cases and I clean up the temporary files with a cron job every hour. Not as elligant a solution as generating data directly back to the browser but it is better to have something that works. In one response, it was mentioned that the header 'Window-target:' doesn't work with IE either, which I was also trying to use. Other than using JScript in the calling page, is there anyway to do this with IE that works. -- Glen Eustace, Systems Engineer - Networking. Information Technology Services, Turitea, Massey University, Palmerston North, NZ. Ph: +64 6 350 5799 x 2707, Fax: +64 6 350 5607 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mime-type headers
You see, IE is smarter than the web site authors of the world. It insists that the document URL end in an approprate extension to do the right thing. A typical workaround is to just append "/foo.pdf" to your URL and let your Apache::Registry script ignore the PATH_INFO that is the result of that. Thanks, I though it was going to be something STUPID, like this. Is there a header I can use that will tell IE another file name 'FIlename: xxx.pdf' or something? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mime-type headers
I've found ?.pdf to work just as well to fool IE and your artificially created PATH_INFO filename will then stick if a user does a save as. This is an absolute crock, but it works a treat. I now have form action="AcctMgmt.epl?.pdf" method=post" Thanks. Glen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mime-type headers
Or I think even this may work: Content-Disposition: inline; filename=somefile.pdf This works too. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Failure to find function in Apache::SSI using DBI
I installed Apache::SSI last night as I needed a quick way of including some
costing info in a page (from my dbase) that already used std SSI.
The install worked fine, my extension seems to be fine but when my code
runs, I get an unexpected error.
[Thu Nov 16 21:45:33 2000] [error] [Thu Nov 16 21:45:33 2000] null: Can't
locate object method "selectrow_array" via package "GodZoneSSI" at
/usr/local/godzone/modperl/GodZoneSSI.pm line 27, GEN0 chunk 1.
The DBI-connect would appear to work, but perl complains it cannot find the
$dbase-selectrow_array function in my code.
The code is pathetically small.
Startup script for apache
#! /usr/bin/perl
#
# Preload the packages used by the various .epl scripts.
#
# The main apache process will compile these into its name space and they
# will therefore be immediately available to the child apache processes.
#
BEGIN {
use Apache();
use lib ('/usr/local/godzone/modperl');
}
use strict;
# Check that the environment is appropriate
$ENV{ 'GATEWAY_INTERFACE' } =~ /^CGI-Perl/ ||
die("GATEWAY_INTERFACE is NOT Perl !!" );
# Common Packages
use Apache::Registry();
use Apache::Constants();
use CGI qw( -compile :all );
use CGI::Carp();
use DBI;
use Apache::DBI();
#
# That's all folks
#
1;
-
My SSI Module
-
#! /usr/bin/perl
#
#
# This module extends the base SSI functionality by adding GodZone
# specific directives.
#
#
# Modification History
# 16 Nov 2000 AGE First Written
#
package GodZoneSSI;
use DBI();
use Apache::SSI();
@ISA = qw( Apache::SSI );
#
# Resource Cost Lookup
#
# !--#ResCost zone=n code=nnn --
sub ssi_rescost {
my( $self, $oParm ) = @_;
my( $oDBase ) = DBI-connect( 'dbi:Pg:dbname=admin', '?', '??' );
my( $oDBase, $iResCode, $iZone ) = @_;
my( @iAmount )= $oDBase-selectrow_array( END_SQL );
SELECT rate_internal, rate_local, rate_national, rate_international
FROM resource
WHERE code = $oParm{ code }
END_SQL
my( $iAmt ) = $iAmount[ $oParm{ zone }];
my( $szAmt ) = $iAmt 0 ? sprintf( "(\$%.2f)", -( $amt/100 ))
: sprintf( "\$%.2f", ($amt/100));
1 while ( $szAmt =~ s/(\d)(\d\d\d)(?!\d)/$1,$2/);
$oDBase-disconnect();
return( $szAmt );
}
$ENV{ 'PATH' } = '/usr/bin:/bin';
#
# End of Module
#
--
Glen Eustace, Systems Engineer - Networking.
Information Technology Services, Turitea, Massey University, Palmerston
North, NZ.
Ph: +64 6 350 5799 x 2707, Fax: +64 6 350 5607
Failure to find function in Apache::SSI using DBI
I installed Apache::SSI last night as I needed a quick way of including some
costing info in a page (from my dbase) that already used std SSI.
The install worked fine, my extension seems to be fine but when my code
runs, I get an unexpected error.
[Thu Nov 16 21:45:33 2000] [error] [Thu Nov 16 21:45:33 2000] null: Can't
locate object method "selectrow_array" via package "GodZoneSSI" at
/usr/local/godzone/modperl/GodZoneSSI.pm line 27, GEN0 chunk 1.
The DBI-connect would appear to work, but perl complains it cannot find the
$dbase-selectrow_array function in my code.
The code is pathetically small.
Startup script for apache
#! /usr/bin/perl
#
# Preload the packages used by the various .epl scripts.
#
# The main apache process will compile these into its name space and they
# will therefore be immediately available to the child apache processes.
#
BEGIN {
use Apache();
use lib ('/usr/local/godzone/modperl');
}
use strict;
# Check that the environment is appropriate
$ENV{ 'GATEWAY_INTERFACE' } =~ /^CGI-Perl/ ||
die("GATEWAY_INTERFACE is NOT Perl !!" );
# Common Packages
use Apache::Registry();
use Apache::Constants();
use CGI qw( -compile :all );
use CGI::Carp();
use DBI;
use Apache::DBI();
#
# That's all folks
#
1;
-
My SSI Module
-
#! /usr/bin/perl
#
#
# This module extends the base SSI functionality by adding GodZone
# specific directives.
#
#
# Modification History
# 16 Nov 2000 AGE First Written
#
package GodZoneSSI;
use DBI();
use Apache::SSI();
@ISA = qw( Apache::SSI );
#
# Resource Cost Lookup
#
# !--#ResCost zone=n code=nnn --
sub ssi_rescost {
my( $self, $oParm ) = @_;
my( $oDBase ) = DBI-connect( 'dbi:Pg:dbname=admin', '?', '??' );
my( $oDBase, $iResCode, $iZone ) = @_;
my( @iAmount )= $oDBase-selectrow_array( END_SQL );
SELECT rate_internal, rate_local, rate_national, rate_international
FROM resource
WHERE code = $oParm{ code }
END_SQL
my( $iAmt ) = $iAmount[ $oParm{ zone }];
my( $szAmt ) = $iAmt 0 ? sprintf( "(\$%.2f)", -( $amt/100 ))
: sprintf( "\$%.2f", ($amt/100));
1 while ( $szAmt =~ s/(\d)(\d\d\d)(?!\d)/$1,$2/);
$oDBase-disconnect();
return( $szAmt );
}
$ENV{ 'PATH' } = '/usr/bin:/bin';
#
# End of Module
#
--
Glen Eustace, Systems Engineer - Networking.
Information Technology Services, Turitea, Massey University, Palmerston
North, NZ.
Ph: +64 6 350 5799 x 2707, Fax: +64 6 350 5607
RE: Failure to find function in Apache::SSI using DBI
Derrr... Dumb error, never trust a cut and paste. I copied in one two many lines from the original program.
Re: Hooking onto the core
After trying alot of thing, the following is what I ended up with. It allows all of the ENV REDIRECT_* variables to be accessed by the cgi script and all in all did exactly what I wanted. Because I didn't get a lot of help from either of my earlier postings, I assummed that either others had not already done this. My ProxyError.cgi returns a icely formated page with some useful info to the client. The cgi is on the Proxy server and it is the same for every virtual site. VirtualHost 130.123.128.10 ServerName planning.massey.ac.nz ServerAlias planning Alias /Error /usr/local/massey/www.support/wwwroot ErrorDocument 501 /Error/ProxyError.cgi ErrorDocument 502 /Error/ProxyError.cgi ProxyPass / http://pn-pc31.massey.ac.nz/ ProxyPassReverse / http://pn-pc31.massey.ac.nz/ /VirtualHost -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Glen Eustace, Systems Engineer - Networking, Computing Services, Massey University, Private Bag 11222, Palmerston North, N.Z. Ph: +64 6 350 5161, Fax: +64 6 350 5607, Mobile +64 25 500 321 Pvt Ph: +64 6 356 2562
RE: Hooking into core
Once again, I don't seem to have been very successful in describing my problem. I'll try again. I am using mod_proxy, as a reverse proxy, i.e. so that I can push inbound requests to a bunch of backend servers. This works great, as most of you probably already know, until one of the back end servers dies. Depending on the error, this is reported back to the client as either a 500 Proxy Error or 502 Proxy Error, with a little but not much more info. It is not possible to use the standard ErrorDocument approach as if one attempts to use a relative URI ( so that one can use the REDIRECT_* variables ) one gets a loop because the server isn't there ( thats why we got an error in the first place ). If one does an absolute URI, one can not do anything smart with the page displayed. I would like to be able to do two things 1. When there is no alternative service, display a nice page with appropriate content. 2. If the same page can be delivered from one of the other servers, automatically redirect the request to one of them. i.e. don't show the user an error message at all. Any suggestions appreciated. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Glen Eustace, Systems Engineer - Networking, Computing Services, Massey University, Private Bag 11222, Palmerston North, N.Z. Ph: +64 6 350 5161, Fax: +64 6 350 5607, Mobile +64 25 500 321 Pvt Ph: +64 6 356 2562
