Francesc Guasch [EMAIL PROTECTED] wrote:
I have a mod_perl server and I need to add a cgi application
outside mod_perl, nagios.
I followed the guide and when I try to use the cgis, the
binary files are displayed instead of executed.
Frank Maas wrote:
Comparing your post and that of others, I
It does work - I use it on http://pics.beamartyr.net/ Remember that it's a
tricky sorta configuration - you must configure it within a location block
which will be the thumbnail directory, and specify the real source
directory:
Example: The below configuration maps /home/me/pictures to
Hi List,
I am running Apache with some perl scripts and currently I am passing
configuration variables using SetEnv, for example:
SetEnv FOO BAR
In the code:
my $foo_config = $ENV{FOO};
The problem is that I need to share these configuration variables with
mod_perl handlers. However in
In which request phase you try to access envar ? If you using
MP1 it doesn't happen until the fixup phase (from the guide).
Ok, this clears things up... I needed two config variables for my
PerlInitHandler. Well, it's only a couple of variables that aren't
likely to change once set, so I guess
I can do this (changing the new() call to accept $r). My understanding is
that client code will need to be changed to take advantage of this, right?
The other issue is that it will only work with the OO form of CGI, which many
people (including myself) don't use.
I would prefer a more
I currently have the following
configuration in my httpd.conf file:
PerlRequire
/usr/local/apache/conf/startup.pl Alias /perl/
/usr/local/apache/cgi-bin PerlTaintCheck
On PerlWarn
On PerlFreshRestart On
PerlTransHandler Apache::SessionManager PerlFreshRestart
On
Location
/perl
Jason Jolly wrote:
When I stop/start the server and run a script with the following code:
foreach $item (@INC) {
print ($item . br);
}
I only get the output:
/usr/local/lib/perl5/5.8.0/sun4-solaris
/usr/local/lib/perl5/5.8.0
Did I send out something weird? My version looks like this:
# Turn on special checking for Doug MacEachern's modperl
if (exists $ENV{MOD_PERL}) {
eval require mod_perl;
if (defined $mod_perl::VERSION) {
if
The URL
http://martynov.org/tgz/HTTP-WebTest-2.02.tar.gz
has entered CPAN as
file: $CPAN/authors/id/I/IL/ILYAM/HTTP-WebTest-2.02.tar.gz
size: 87462 bytes
md5: 20478775a4bafb6c5cad2ca1fcd4e9ea
NAME
HTTP::WebTest - Testing static and dynamic web content
DESCRIPTION
This
--
mod_perl digest
February 24, 2002 - March 24, 2003
--
Recent happenings in the mod_perl world...
Features
o
Stas Bekman wrote:
So can flushing be held off until either (1) blank line is printed,
(2) the 8k buffer fills, or (3) send_http_header is called?
1) is relevant only for handler that print headers, rather than set them
2) absolutely not, what if you want to flush data before?
3)
Lincoln Stein wrote:
I can do this (changing the new() call to accept $r). My understanding is
that client code will need to be changed to take advantage of this, right?
That's correct. $r should be explicitly passed. However the CGI-side code
doesn't have to specific to mod_perl 2.0. CGI
Lincoln Stein wrote:
Did I send out something weird? My version looks like this:
# Turn on special checking for Doug MacEachern's modperl
if (exists $ENV{MOD_PERL}) {
eval require mod_perl;
if (defined $mod_perl::VERSION) {
Hi Sean,
It sounds like a great idea, but it's not going to happen soon. My first
priority is to get Apache::MP3 working with mod_perl 2.0 while maintaining
compatibility with mod_perl 1.0.So much has changed between the two
versions that I've basically given up on maintaining all my
Mark James wrote:
Stas Bekman wrote:
So can flushing be held off until either (1) blank line is printed,
(2) the 8k buffer fills, or (3) send_http_header is called?
1) is relevant only for handler that print headers, rather than set them
2) absolutely not, what if you want to flush data before?
Lincoln Stein wrote:
Sorry for the slow turnaround, but it's an aspect of having 200 new e-mails
every day.
Here's a new version of CGI.pm 2.92 prerelease. Please give it a try on
mod_perl1 and mod_perl2 systems.
It passes all tests on linux. Hopefully others will test on other platforms.
While we are at the CGI.pm issue, I was thinking that those who stick with
CGI.pm because of its extended all-in-one functionality (request parsing/ HTML
generation), but unhappy about request parsing speed, could benefit by
integrating Apache::Request in CGI.pm to do the request parsing. So if
Lincoln Stein wrote:
Hi Sean,
It sounds like a great idea, but it's not going to happen soon. My first
priority is to get Apache::MP3 working with mod_perl 2.0 while maintaining
compatibility with mod_perl 1.0.So much has changed between the two
versions that I've basically given up on
Lincoln Stein wrote:
How about making CGI.pm a subclass of $r? (optionally of course, by
dynamically changing @ISA), so instead of returning $q it'll return $r,
after re-blessing it.
Sounds interesting. What would be the advantage of that?
The advantage is that
- you don't have to keep around
On 3/24/03 7:08 PM, Stas Bekman wrote:
In the future I can see someone extending Apache::Request to handle CGI.pm's
HTML generation in C, so the two could be replace each other.
I've always thought that HTML generation does not belong in CGI.pm, so I
don't see duplicating that functionality in
Stas Bekman wrote:
While we are at the CGI.pm issue, I was thinking that those who stick
with CGI.pm because of its extended all-in-one functionality (request
parsing/ HTML generation), but unhappy about request parsing speed,
could benefit by integrating Apache::Request in CGI.pm to do the
Gunther Birznieks wrote:
Stas Bekman wrote:
While we are at the CGI.pm issue, I was thinking that those who stick
with CGI.pm because of its extended all-in-one functionality (request
parsing/ HTML generation), but unhappy about request parsing speed,
could benefit by integrating
22 matches
Mail list logo
