Re: binary cgi mess ( repost )
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 see that you use Authentication through mod_perl. What happens if you completely disable Authentification? Do you still experience the same nice try Frank. I didn't think about it. I added basic auth from a passwd file. I made sure the password was different so I was using the new config. I'm afraid it didn't help, what a pity. -- frankie
Re: Apache::GD::Thumbnail Question
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 http://foo.bar/pictures/ and generates on-the-fly thumbnails in http://foo.bar/pictures/mythumbs/ Alias /pictures/ /home/me/pictures Directory /home/me/pictures Order allow,deny Allow from all /Directory Location /pictures/mythumbs SetHandler perl-handler PerlHandler Apache::GD::Thumbnail /Location Remember that it only works on JPEGs. Issac - Original Message - From: Steven A. Adams [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 24, 2003 3:06 AM Subject: Apache::GD::Thumbnail Question Does anyone use this handler to make on-the-fly thumbs? I've used the standard example code in my apache (1.3.27 with MP1) and it seems to ignore the handler. Any suggestions? -- Steven A. Adams [EMAIL PROTECTED]
SetEnv / PerlSetEnv issue
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 mod_perl handlers $ENV{FOO} is undef
despite the SetEnv directive.
So of course I tried PerlSetEnv so that I can use the dir_config()
method of the Apache object. But then $ENV{FOO} doesn't work in the CGI
script.
Everything works ok if I do:
SetEnv FOO BAR
PerlSetEnv FOO BAR
But I would like to avoid duplicating config values for obvious
maintenability issues...
Can anyone think of a way to doing a super SetEnv directive that would
set FOO in both %ENV (for CGI scripts) and in $r-dir_config() ?
Thanks for your help,
--
Building a better web - http://www.mkdoc.com/
-
Jean-Michel Hiver
[EMAIL PROTECTED] - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
Re: SetEnv / PerlSetEnv issue
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 it's bareable to have them duplicated :-/. Thanks very much, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Re: the deprecation of Apache-request in mp2
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 transparent way to obtain the current request. Is there no low-overhead way of getting at this? Lincoln On Thursday 13 March 2003 07:00 pm, Stas Bekman wrote: One more issue with CGI.pm and mp2, and other modules as well. CGI.pm is using Apache-request. The setting/retrieval of the global request record under threads is expensive, so the use of Apache-request is deprecated in mp2. If CGI.pm can be changed to optionally accept $r (as an argument to new(), plus a special accessor to set later) and use it instead, this will improve the performance if Apache-request is not set. Notice that it's the enabling of 'PerlOptions +GlobalRequest' (it's on by default with 'SetHandler perl-script') that is half of the performance hit (store), and the actual use of Apache-request (get) is the second half. See: http://perl.apache.org/docs/2.0/user/compat/compat.html#C_Apache_E_gt_reque st_ http://perl.apache.org/docs/2.0/user/config/config.html#C_GlobalRequest_ __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Addition of directory to @INC variable via startup script/mod_perl
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 SetHandler
perl-script PerlSendHeader On
PerlHandler Apache::Registry
Options
ExecCGI /Location
And here are the contents of the startup.pl
script:
#!/usr/bin/perl
use strict;
use lib
qw(/usr/local/apache/require);
use
Apache::Registry(); use CGI(); use
CGI::Session(); use CGI::Carp(); use
DBI(); use Net::LDAP();
$ENV{MOD_PERL} or die
"not running under mod_perl!";
1;
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
/usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris
/usr/local/lib/perl5/site_perl/5.8.0
/usr/local/lib/perl5/site_perl .
?? I can't seem to find any rhyme or
reason why the directory "/usr/local/apache/require" isn't on the @INC
array?
Any help is greatly
appreciated.according to all documentation I can find this should actually
work. I'm hoping that I'm doing something terribly stupid :).
thnx,
~j
Re: Addition of directory to @INC variable via startup script/mod_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
/usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris
/usr/local/lib/perl5/site_perl/5.8.0
/usr/local/lib/perl5/site_perl
.
?? I can't seem to find any rhyme or reason why the directory
/usr/local/apache/require isn't on the @INC array?
When do you run that script? And why do you have PerlFreshRestart on?
- Perrin
Re: CGI.pm and friends port to mp2
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 ($mod_perl::VERSION = 1.99) {
$MOD_PERL = 2;
require Apache::RequestRec;
require Apache::RequestUtil;
require APR::Pool;
} else {
$MOD_PERL = 1;
require Apache;
}
}
}
Lincoln
On Thursday 13 March 2003 06:21 pm, Stas Bekman wrote:
Lincoln Stein wrote:
Please find enclosed a beta version of CGI.pm 2.92. I would appreciate
it if people could test it on both mod_perl 1 and mod_perl 2, as well as
under normal CGI scripts too ;-)
Thanks Lincoln. 'make test' passes with mp1 and mp2, however the test
suites aren't exhaustively cover CGI.pm's functionality. So we really need
your help guys to give it a good test in the real apps.
In case anyone wonders why I fiddled with the check for the presence of
modperl, this is because some people write scripts that shell out to
command-line scripts that invoke CGI.pm in order to generate HTML (don't
ask me why). Without the additional checking, CGI.pm sees the MODPERL
environment variable, tries to load mod_perl outside the Apache
environment, and summarily crashes.
Ahm, I'm not quite sure that this does what you say it should:
if (exists $ENV{MOD_PERL}) {
require mod_perl;
if (defined $mod_perl::VERSION ($mod_perl::VERSION = 1.99)) {
# mp2
} else {
# mp1
}
}
because if it's not defined, it'll fall through to the else block, assuming
that the external script is running under mp1. Shouldn't it be:
if (exists $ENV{MOD_PERL}) {
require mod_perl;
# mod_perl handlers may run system() on scripts using CGI.pm
# - make sure so we don't get fooled by inherited $ENV{MOD_PERL}
if (defined $mod_perl::VERSION){ # for shell scripts
if ($mod_perl::VERSION = 1.99)) {
# mp2
} else {
# mp1
}
}
}
also it's probably a good idea to add a note, why this check is done, so
not to forget in the future and optimize it away ;)
I still haven't heard any response as to why I should move to MP2! I
wasn't just being cranky, I'm curious.
You want to move to MP2, if one of the following reasons apply:
- you are stuck with Apache2
- you want to use i/o filters
- you want to write your own protocol handlers
- you want to use a threaded mod_perl
- you are stuck with win32 (mp1 is unusable on win32, serialization)
and there is a whole bunch of new functionality available, which will be
too long to list here and partially described on the website.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Lincoln D. Stein Cold Spring Harbor Laboratory
[EMAIL PROTECTED] Cold Spring Harbor, NY
Re: [ANNOUNCE] HTTP-WebTest 2.02
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 module runs tests on remote URLs containing Perl/JSP/HTML/JavaScript/etc. and generates a detailed test report. This module can be used as-is or its functionality can be extended using plugins. Plugins can define test types and provide additional report capabilities. This module comes with a set of default plugins but can be easily extended with third party plugins. CHANGES SINCE LAST STABLE VERSION 2.01: BUG FIXES: * Fixed bug when test reports were not send when multiple email addresses were specified as test report recipients (test parameter 'mail_addresses'). Thanks to Amit Kaul for a bugreport and a patch. * New versions of LWP add Client-Peer header in all responses what breaks one of tests in the self-testing suite. This test was supposed to be fixed by the previous release but apparently it wasn't. -- Ilya Martynov, [EMAIL PROTECTED] CTO IPonWEB (UK) Ltd Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net Personal website - http://martynov.org
[DIGEST] mod_perl digest 2003/02/24
-- mod_perl digest February 24, 2002 - March 24, 2003 -- Recent happenings in the mod_perl world... Features o mod_perl status o module announcements o mailing list highlights o mp2 porting tips o links o problem reporting guidelines mod_perl status o mod_perl - stable: 1.27 (released June 1, 2002) [1] - development: 1.27_01-dev [2] o Apache - stable: 1.3.27 (released October 3, 2002) [3] - development: 1.3.28-dev [4] o mod_perl 2.0 - beta: 1.99_08 (released January 10, 2002) [5] - development: (from cvs) [6] o Apache 2.0 - stable: 2.0.44 (released January 18, 2003) [7] o Perl - stable: 5.8.0 (released July 18, 2002) [8] - development: none [9] module announcements o Apache::Clean 2.02b - interface to HTML::Clean for mod_perl 2.0 [10] o Apache::SessionX 2.00b5 - provides default and named Apache::Session configuration and lazy operation [11] o Apache::VMonitor 0.8 - visual system and processes monitor [12] o Bricolage 1.5.1 (devel) - content management system based on HTML::Mason and Template Toolkit [13] o HTTP::WebTest 2.01 - testing static and dynamic web content [14] o Loggerithim 6.3.1 - system monitoring package [15] o Uttu 0.05 - web interface driver / application framework framework [16] mailing list highlights o Apache Hello World Benchmarks 1.02 [17] mp2 porting tips o Porting modules to mod_perl 2 documentation updated [18] o perl.apache.org documents [19] o Apache::compat [20] links o The Apache/Perl Integration Project [21] o mod_perl documentation [22] o Apache modules on CPAN [23] o _Writing Apache Modules with Perl and C_ homepage [24] o _mod_perl Developer's Cookbook_ homepage [25] o Other mod_perl-related books [26] o mod_perl news and advocacy [27] o mod_perl list archives - modperl@ [28] - dev@ [29] - docs-dev@ [30] - advocacy@ [31] problem reporting guidelines Whenever you have a problem that you want to ask about on the modperl list, please be sure to read the instructions on how to report problems: For mod_perl 1.0 [32] For mod_perl 2.0 [33] For your convenience, these are located in the shortcuts menu on all pages at http://perl.apache.org/. You will save yourself and us a lot of time by following the instructions on these pages. Thank you! happy mod_perling... --James [EMAIL PROTECTED] -- [1] http://perl.apache.org/dist/ [2] http://cvs.apache.org/snapshots/modperl/ [3] http://www.apache.org/dist/httpd/ [4] http://cvs.apache.org/snapshots/apache-1.3/ [5] http://perl.apache.org/dist/mod_perl-1.99_04.tar.gz [6] http://cvs.apache.org/snapshots/modperl-2.0/ [7] http://www.apache.org/dist/httpd/ [8] http://www.cpan.org/src/stable.tar.gz [9] http://www.cpan.org/src/README.html [10] http://mathforum.org/epigone/modperl/croxdwimpprei [11] http://mathforum.org/epigone/modperl/vandootwei [12] http://mathforum.org/epigone/modperl/smyheldpel [13] http://mathforum.org/epigone/modperl/twatheebu [14] http://mathforum.org/epigone/modperl/quomclyzham [15] http://mathforum.org/epigone/modperl/thenzingblimp [16] http://mathforum.org/epigone/modperl/trahpitix [17] http://mathforum.org/epigone/modperl/smaiswycrer [18] http://mathforum.org/epigone/modperl/jomloaclal [19] http://perl.apache.org/docs/2.0/devel/porting/porting.html [20] http://perl.apache.org/docs/2.0/api/Apache/compat.html [21] http://perl.apache.org/ [22] http://perl.apache.org/docs/ [23] http://www.cpan.org/modules/by-module/Apache/ [24] http://www.modperl.com/ [25] http://www.modperlcookbook.org/ [26] http://perl.apache.org/docs/offsite/books.html [27] http://www.take23.org/ [28] http://perl.apache.org/maillist/modperl.html#Searchable_Archives [29] http://perl.apache.org/maillist/dev.html#Searchable_Archives [30] http://perl.apache.org/maillist/docs-dev.html#Searchable_Archives [31] http://perl.apache.org/maillist/advocacy.html#Searchable_Archives [31] http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems [32] http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems
Re: [mp2] CGI redirects incorrectly handled?
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) send_http_header doesn't exist in Apache2/mod_perl2
I didn't realise that mp2 doesn't use send_http_header. That explains
the appearance of wb-r-content_type in the mp2 code. So is it
true that if headers are sent using the API then no output filtering
and transmission occurs until the 8k buffer is either filled or flushed
(explcitly or after exit)?
Only in the case that your handler is configured with:
PerlOptions +ParseHeaders
*and*
it prints headers ala:
print Content-type:
In all other cases where headers are set via the API, e.g.
$r-content_type, $r-headers_out, etc, there is no such a thing as the
handler has send an empty line signaling the end of sending headers,
because it never sends any headers at all, but uses api to set them.
Is +ParseHeaders always indicative of explicit header printing, or
can it also be set when using the API? If the former, then yes, if
+ParseHeaders is set flushing could be held off until a blank line is seen.
With the current mp2 code, if you decide to
wait for the end of headers before doing cgi parsing and flushing then
the code is assuming that either the headers are less than 8k or that any
Status header is in the first 8k. Otherwise the code would have to
be re-written to use continuous (spilling and merging) buffer buckets
like mod_cgi. It can hold off on flushing indefinitely.
That approach will break this handler:
sub handler {
my $r = shift;
$r-content_type('text/plain');
$r-rflush; # send something to the client immediately
long_job();
return Apache::OK
}
However notice that it doesn't have to set content_type() because some
earlier handler could have done that and that should work as well:
sub handler {
my $r = shift;
$r-rflush; # send something to the client immediately
long_job();
return Apache::OK
}
So as you can see, this handler doesn't tell us when it's done with
headers.
OK, you may say that that previous handler should have marked the end of
headers settings, but that would be wrong if the response handler wants
to set other headers as well.
Do we now agree that the event of end of sending headers is possible
only in the case explained at the top?
Yes, the key I was missing is that mp2 no longer uses send_http_header.
Can you just lock out flushing when nothing has been printed and
content_type is undefined? (You impliy above that the content_type
setting is persistent, so the script would have to undef it if necessary.)
Then all the user script has to do is to make sure any Status header is
either printed or set via headers_out in the first batch of
printing/setting code before flush is called (again).
Re: the deprecation of Apache-request in mp2
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 should be able to do that with either version of mod_perl. In this case the user code can be ported to work with both versions of mod_perl. 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. The other issue is that it will only work with the OO form of CGI, which many people (including myself) don't use. You can still have an accessor function to set $r: use CGI; CGI-r($r); I would prefer a more transparent way to obtain the current request. Is there no low-overhead way of getting at this? Not, under threaded mpm. Since the code should work the same with threaded and non-threaded mpm, it's a problem for any 2.0 code. The problem with Apache-request is that it involves storing and retrieving data from the TLS (thread local storage), which is slow. So while the functionality is there, sites that are looking for high performance will want to pass $r, rather than rely on Apache-request. Of course one can argue, that sites looking for high performance should use Apache::Request (which is not quite there yet, for 2.0). So if this argument is valid and you don't feel like changing the API, that's cool too. May be in the future. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: CGI.pm and friends port to mp2
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) {
if ($mod_perl::VERSION = 1.99) {
$MOD_PERL = 2;
require Apache::RequestRec;
require Apache::RequestUtil;
require APR::Pool;
} else {
$MOD_PERL = 1;
require Apache;
}
}
}
That's not what you have sent before ;) But it looks OK in the most recent
version.
A few more comments.
- I have suggested to add a note explaining why we don't rely on
$ENV{MOD_PERL}. I'm sure the reason will be forgotten in the future.
if (exists $ENV{MOD_PERL}) {
eval require mod_perl;
# mod_perl handlers may run system() on scripts using CGI.pm
# - make sure so we don't get fooled by inherited $ENV{MOD_PERL}
if (defined $mod_perl::VERSION){ # for shell scripts
- why eval string:
eval require mod_perl;
shouldn't it be:
eval { require mod_perl };
?
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: shim silence in Apache::MP3
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 mod_perl scripts until I have a big chunk of free time (unlikely to happen soon, if ever). Lincoln On Monday 24 March 2003 08:05 am, Sean M. Burke wrote: Me and Chris Nandor and Joe Johnston were just nattering on about frilly little nicities would like (or have liked) in Apache::MP3. And I just thought of one, hooboy! Namely: maybe an option for inserting 2s of silence between tracks, or maybe just between tracks in different directories. What do you think? Somewhere around here I have some mp3s and oggs of absolute silence, of various runtimes, and even one with a runtime of 4 minutes 33 seconds, of course. -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Re: [mp2] CGI redirects incorrectly handled?
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? 3) send_http_header doesn't exist in Apache2/mod_perl2 I didn't realise that mp2 doesn't use send_http_header. That explains the appearance of wb-r-content_type in the mp2 code. I'm not quite happy yet about the current situation with send_http_header API removal. Currently an explicit call to $r-content_type (only in mod_perl handlers) turns the headers parsing off, if it was on. Which works fine as a replacement for $r-send_http_header. However it's possible that some earlier phase calls $r-content_type and the response phase still wants to *print* its headers, rather than use API to set them. If that's the case, we are in trouble. I'll be soon working on providing the API for PerlOptions and other config options. And while most of these things are read-only, I'm thinking that I might be able to add a read/write accessor for ParseHeaders. So one can turn the parsing on and off, disregarding what was the setting in httpd.conf. I believe that would be the perfect solution, since it'll give developers a total flexibility. So is it true that if headers are sent using the API then no output filtering and transmission occurs until the 8k buffer is either filled or flushed (explcitly or after exit)? That's correct. Though the headers are really sent by the Apache core http output filter, once we send the response body. Only in the case that your handler is configured with: PerlOptions +ParseHeaders *and* it prints headers ala: print Content-type: In all other cases where headers are set via the API, e.g. $r-content_type, $r-headers_out, etc, there is no such a thing as the handler has send an empty line signaling the end of sending headers, because it never sends any headers at all, but uses api to set them. Is +ParseHeaders always indicative of explicit header printing, or can it also be set when using the API? If the former, then yes, if +ParseHeaders is set flushing could be held off until a blank line is seen. See my plan and current situation explanation above. Do we now agree that the event of end of sending headers is possible only in the case explained at the top? Yes, the key I was missing is that mp2 no longer uses send_http_header. Can you just lock out flushing when nothing has been printed and content_type is undefined? (You impliy above that the content_type setting is persistent, so the script would have to undef it if necessary.) Then all the user script has to do is to make sure any Status header is either printed or set via headers_out in the first batch of printing/setting code before flush is called (again). As I suggested earlier, I think the solution is to ignore rflush calls if we expect to parse headers and they weren't parsed yet. However if the buffer overflows, we have not much choice but to send it out. But I think that this will be a satisfactory solution. Also since close($fh) always flushes in mod_cgi, I think you can get rid of the explicit flush for good. Since mod_perl's CLOSE is no-op, it won't cause the flush (at least for now). __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: CGI.pm and friends port to mp2
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. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
speeding up CGI.pm
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 Apache::Request is available CGI.pm could re-alias its args(), params(), etc. functions to call Apache::Request functions instead. What do you think? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: shim silence in Apache::MP3
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 maintaining all my mod_perl scripts until I have a big chunk of free time (unlikely to happen soon, if ever). Looks like a good opportunity for folks who want to get up to speed with mp2 to help CPAN developers port their modules to 2.0. I'm sure Lincoln will appreciate to get a patch that makes Apache::MP3, and his other modules work with mp2. Lincoln, please correct me if I'm wrong ;) On Monday 24 March 2003 08:05 am, Sean M. Burke wrote: Me and Chris Nandor and Joe Johnston were just nattering on about frilly little nicities would like (or have liked) in Apache::MP3. And I just thought of one, hooboy! Namely: maybe an option for inserting 2s of silence between tracks, or maybe just between tracks in different directories. What do you think? Somewhere around here I have some mp3s and oggs of absolute silence, of various runtimes, and even one with a runtime of 4 minutes 33 seconds, of course. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: the deprecation of Apache-request in mp2
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 two instances: $r and $q. - assuming that CGI.pm-specific code is not used one can transparently switch between Apache::Request and CGI.pm, by just changing: $r = Apache::Request-new($r); $r = CGI-new($r); And of course Apache::Request is a subclass of Apache ($r) and it works pretty well. 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. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: the deprecation of Apache-request in mp2
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 an extended $r as a useful goal. Better to separate the HTML stuff (preferably into HTML widget objects, IMO) from request parsing and response formulation and delivery. -John
Re: speeding up CGI.pm
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 request parsing. So if Apache::Request is available CGI.pm could re-alias its args(), params(), etc. functions to call Apache::Request functions instead. What do you think? From an outsider's perspective, I agree. For some previous discussion (April 16, 2000) http://marc.theaimsgroup.com/?l=apache-modperlm=95587404903236w=2
Re: speeding up CGI.pm
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 Apache::Request in CGI.pm to do the request parsing. So if Apache::Request is available CGI.pm could re-alias its args(), params(), etc. functions to call Apache::Request functions instead. What do you think? From an outsider's perspective, I agree. For some previous discussion (April 16, 2000) http://marc.theaimsgroup.com/?l=apache-modperlm=95587404903236w=2 If something can be made faster with very little effort, why not doing that? Certainly the degree of performance improvement depends on how heavy the request parsing is, but you get a better speed overall. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
