RE: DSO mod_perl and preloading
> > All these tips and benchmarks on optimising mod_perl by preloading used > modules/DBD-drivers etc. are great. However, I have seen warnings about > preloading modules if mod_perl is loaded as a DSO. (e.g for > HTML::Embperl). Does this still apply? My setup is > redhat6.2/perl-5.6/mod_perl-1.23. > This was true before mod_perl 1.22. So there should be no problem with your setup Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: Memory usage for libareq uploads
On Tue, 6 Jun 2000, Jeremy Howard wrote: >... > > Well, I'm facing this problem now. The parms() method (or parse() or > anything else that calls parms()) chews up enormous amounts of memory > when uploading large files. I like to give my webmail users freedom to > upload pretty much whatever size attachments they like, but that means my > Apache processes grow very large, and never shrink again. > > What can I do to avoid this? I know I can use one of the various > directives that kills off large processes, but that seems a bit > aggressive... Has anyone got any sample code that spins off file upload > activity to an external CGI and then returns to a mod_perl handler when > the dirty work is done? ...Or is there some new code out there (or coming > Real Soon Now) that avoids this whole issue? What I do is kill the child process after uploading is finished: $r->child_terminate(); Not an elegant way, but it works for the time being. Jie
Memory usage for libareq uploads
Way back in the annals of history (well, err, 24 Feb 2000, anyway) there was some discussion about uploads chewing up memory in libareq... Jim Winstead said: Is it just me, or is it pretty dodgy code? It allocates memory like its going out of style (it doesn't appear to reuse any of the buffers it allocates from the pool), resulting in server processes that balloon up to five times the uploaded file's size. Its also appears to be flat-out slow because of all the extra work it is doing. Just an observation. I (or a coworker if I'm lucky :) will be rolling up my shirt-sleeves and diving in tomorrow. This is just my found-the-leak-now-I-get-to-sleep-on-it-and-hope-it-was-fixed- already-or-I'm-being-dumb mail. to which Doug replied: it's pretty dodgy code :) the multipart buffer code in libapreq is actually just a translation from CGI.pm's Perl code to C. notice the comment: /*XXX: we can optimize this loop*/ meaning, I'm aware it's not reusing the buffer, but it's using a subpool which is cleared at the end of multipart_buffer_fill, each call to that should be no more than 4k or so. I have a recent mail (not to the list) from somebody who experienced the balloon, looked into it, and thinks that ap_clear_pool() is not working. anyhow, my plan is to get 1.22 out, then revisit libapreq, then onto modperl-2.0 Well, I'm facing this problem now. The parms() method (or parse() or anything else that calls parms()) chews up enormous amounts of memory when uploading large files. I like to give my webmail users freedom to upload pretty much whatever size attachments they like, but that means my Apache processes grow very large, and never shrink again. What can I do to avoid this? I know I can use one of the various directives that kills off large processes, but that seems a bit aggressive... Has anyone got any sample code that spins off file upload activity to an external CGI and then returns to a mod_perl handler when the dirty work is done? ...Or is there some new code out there (or coming Real Soon Now) that avoids this whole issue? TIA, Jeremy -- Jeremy Howard [EMAIL PROTECTED]
Re: Solution for: Re: $ENV{PATH} set by mod_perl script affects mod_cgi scripts
[EMAIL PROTECTED] (Ben Cohen) wrote:
>{begin quote}
>
>I assume you are running with Apache:Registry?
>
>You could also save off the $ENV{PATH}...
>
>
>Go to the line that reads:
>
> eval { &{$cv}($r, @_) } if $r->seqno;
>
>
>And before it have something like
>
>$ENV{OLD_PATH} = $ENV{PATH}
>
>and after it
>
>$ENV{PATH} = $ENV{OLD_PATH}
>
>
>{end quote}
A better solution would be to do "local $ENV{PATH} = $ENV{PATH};". Let
Perl clean up after you, especially if your script dies in mid-run.
The same technique is used for $^W in RegistryNG.
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
Re: Apache::Dispatch
[EMAIL PROTECTED] (Christopher Lee) wrote: >There's a real live working example if anybody wants it, called "Wing", >available from your local friendly CPAN. > >The module is used as an IMAP interface but the main module handles everything >except logins, the url is used to pass commands around, the one I'm looking at >at the moment is > >http://server1.herald.ox.ac.uk/wing/cmd/ball/x/compose > >The "wing/cmd" tells the module that this is a call for the function called >(in this case) "cmd_compose" with the parameters "ball" (a username) >(x is a dummy used for other functions I think). > >Internally the module takes 'compose' and prefixes it with 'cmd_', >evals the string as a soft reference to a function and returns an error >code if the function doesn't exist, or runs the function if it does. > >It only lets a strict subset of functions run (it always appends a "cmd_" to >the name) so internal functions are safe . That step is *crucial* to the security of the system. Without it, browsers could call any method in the module, including ones that aren't meant to be called. D, W.R.! By specifying the cmd_ prefix you're essentially adding a "public" declaration to these subroutines, albeit a fairly ugly one. In general, when accepting arbitrary user input you want to make sure there are only a very few access points to the code, then make sure you have very tight validation of the data in those access points. Taint mode comes to mind as one tool in the belt. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Solution for: Re: $ENV{PATH} set by mod_perl script affects mod_cgi scripts
Thanks to all for the helpful suggestions.
Gunther Birzniek from the list suggested a solution that I've
now tried and it works perfectly:
{begin quote}
I assume you are running with Apache:Registry?
You could also save off the $ENV{PATH}...
Go to the line that reads:
eval { &{$cv}($r, @_) } if $r->seqno;
And before it have something like
$ENV{OLD_PATH} = $ENV{PATH}
and after it
$ENV{PATH} = $ENV{OLD_PATH}
{end quote}
This was certainly a weird bug ( I think it was a bug ).
Even setting PerlSetEnv in httpd.conf didn't help.
The PATH would be properly set until the first time a mod_perl
script modified its PATH at which point all other
scripts including mod_cgi scripts would 'inherit' this
new PATH.
The reason the mod_perl script modifying its path was to appease
the perl taint checking and help ensure a more secure environment.
I could be totally mistaken in doing this and for some strange
reason mod_perl scripts in my install seem to run with taint checking
on by default.
Thanks again to all those who responded with very
helpful suggestions,
-Ben
--
DO NOT LOOK INTO LASER
WITH REMAINING EYE
(random sig #14)
Re: Wierd user agent strings
you can put whatever bogus strings you want in the user-agent field if you are using something like lwp-request. they are probably either: a ) total shenanigans b) unicode or someother character set -- ___cliff [EMAIL PROTECTED] Renzo Toma wrote: > Good question, we have a database for browser usage analysis. It currently > holds roughly 55.000 unique tags. A good 4000 of em are bogus strings like > posted below. So I love to hear some theories too! > > Oh fyi, May's score was 80% MSIE, 18% NS.. > > Cheers, > > -Renzo > > > Does anyone know what User-Agent strings like these may mean: > > > > (r\177xx\303\203x0\226H > > (r\177xx\303\203xT\365G > > (r\177xx\303\203xt]D > > (r\210xP\223G > > (r\210x\354\250D > > (r\210xx\303\214xH?E > > (r\210xx\303\214xP+E > > (r\210xx\303\214xXCE > > (r\210xx\303\214x\$EE > > (r\210xx\303\214x\204VF > > (r\210xx\303\214x\204yG > > (r\210xx\303\214x\20\256E > > > > (where \210 etc are octal character values). > > > > Tim. > > > >... > __... __ > ... ... > .. .. Renzo Toma http://www.veronica.nl > Veronica Digitaal B.V. unix.modperl.apache.sql.mason > ... _ >.
Hits not getting recorded
Question: Does anyone apart from me have a problem with hits getting recorded? My access logs are 0. Using perl 5.6.0 Apache 1.3.12 PHP 3.0.15
compiling mod_perl with PERL_STATIC_EXTS
Hi all-
I'm trying to build mod_perl 1.21_02 (w/ apache 1.3.12) with GD statically
linked.
I've tried running
perl Makefile.PL PERL_STATIC_EXTS='GD' EVERYTHING=1 USE_APACI=1
APACI_ARGS='--prefix=/usr/local/bb/httpd, --enable-module=proxy'
and I get:
gcc -DLINUX=2 -DMOD_PERL -DUSE_PERL_SSI -Dbool=char -DHAS_BOOL
-DUSE_HSREGEX -DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED `./apaci`\
-o httpd buildmark.o modules.o modules/standard/libstandard.a
modules/proxy/libproxy.a modules/perl/libperl.a main/libmain.a
./os/unix/libos.a ap/libap.a regex/libregex.a lib/expat-lite/libexpat.a -lm
-lcrypt -rdynamic -L/usr/local/lib
/usr/local/bb/perl/lib/5.00503/i686-linux/auto/DynaLoader/DynaLoader.a
-L/usr/local/bb/perl/lib/5.00503/i686-linux/CORE -lperl -lnsl -lndbm -lgdbm
-ldb -ldl -lm -lc -lposix -lcrypt
modules/perl/libperl.a(perlxsi.o): In function `xs_init':
perlxsi.o(.text+0xb4): undefined reference to `boot_GD'
collect2: ld returned 1 exit status
make[3]: *** [target_static] Error 1
The version of Perl is 5.005_03. I have built GD and statically linked it
to Perl.
When I run:
# perl -MExtUtils::Embed -e ldopts -- -std GD
-rdynamic -L/usr/local/lib
/usr/local/bb/perl/lib/site_perl/5.005/i686-linux/auto/GD/GD.a
/usr/local/bb/perl/lib/5.00503/i686-linux/auto/DynaLoader/DynaLoader.a
-L/usr/local/bb/perl/lib/5.00503/i686-linux/CORE -lperl -lnsl -lndbm -lgdbm
-ldb -ldl -lm -lc -lposix -lcrypt -L/usr/lib/X11 -L/usr/X11R6/lib
-L/usr/local/lib -lgd -lpng -lttf -lz -ljpeg -lm -lX11 -lXpm
Running this command (this was pulled from one of Doug M. earlier posts):
# perl -MExtUtiles::Embed -e xsinit -- -std GD
# cat perlxsi.c
EXTERN_C void xs_init _((void));
EXTERN_C void boot_GD _((CV* cv));
EXTERN_C void boot_DynaLoader _((CV* cv));
EXTERN_C void
xs_init(void)
{
char *file = __FILE__;
dXSUB_SYS;
newXS("GD::bootstrap", boot_GD, file);
/* DynaLoader is a special case */
newXS("DynaLoader::boot_DynaLoader", boot_DynaLoader, file);
}
It seems like the GD.a library can't be located by the linker for some
reason. I've set my LD_LIBRARY_PATH, LD_RUN_PATH environment variables, and
I've tried modifying the Makefile to include the path to the GD.a
(/usr/local/bb/perl/lib/site_perl/5.005/i686-linux/auto/GD)
Any suggestions? Sorry, I'm kinda new at all of this.
Thanks in advance.
--Tim
Re: $ENV{PATH} set by mod_perl script affects mod_cgi scripts
On Sun, 4 Jun 2000, Ben Cohen wrote:
> The problem is that when a mod_perl script modifies the PATH
> environment variable, this change seems to become global and
> affects even plain old mod_cgi scripts.
While I also wonder (as another respondent did) why a mod_perl script would
need to alter its 'PATH', I can think of a couple solutions that might work:
Probably the simplest is to localize your $ENV{'PATH'} changes
(i.e. local $ENV{'PATH'} = '/bin:/usr/bin' ) in your code.
More complicated and less nice solution:
Write a FixupHandler that sets the PATH to some 'clean' value.
Something like this:
sub handler {
my $r = shift;
$ENV{'PATH'} = '/bin:/usr/bin';
$r->subprocess_env('PATH', $ENV{'PATH'}); # just to be sure mod_cgi gets it
return DECLINED;
}
...and then have it triggered by a in your httpd.conf.
Re: [performance/benchmark] $| and multiprint
Your benchmarks with $| unset aren't addressing flushing.
The flush may be happening after the benchmark has finished.
I suspect (without looking at the source) that when $| is unlocalized,
in the last set of results, that may be triggering a flush.
Also, the two outputs are not the same. One has newlines.
Finally, you should also consider the
print $fh "...", "...", "..." ...
case.
Tim.
On Mon, Jun 05, 2000 at 08:20:50PM +0300, Stas Bekman wrote:
>
> Here is the benchmark that tests two things: buffered vs unbuffered code
> and multi-statement print vs single statement print styles. Here are the
> code and results:
>
> use Symbol;
> my $fh = gensym;
> open $fh, ">/dev/null" or die;
> use Benchmark;
>
> sub multi_print{
> print $fh "";
> print $fh "";
> print $fh "";
> print $fh "Test page";
> print $fh "";
> print $fh "";
> print $fh "";
> print $fh "";
> print $fh "Hello";
> print $fh "";
> print $fh "";
> print $fh "foo";
> print $fh "";
> print $fh "";
> print $fh "";
> }
>
> sub single_print{
> print $fh qq{
>
> Test page
>
>
>
> Hello
>
> foo
>
>
> };
> }
>
> timethese
> (500_000, {
> multi_print_unbuffered => sub {local $| = 1; multi_print() ;},
> multi_print_buffered=> sub { multi_print() ;},
> single_print_unbuffered => sub {local $| = 1; single_print();},
> single_print_buffered => sub { single_print();},
> });
>
> Benchmark: timing 50 iterations of multi_print_buffered,
> multi_print_unbuffered, single_print_buffered, single_print_unbuffered...
> multi_print_buffered: 13 wallclock secs (11.09 usr + 0.17 sys = 11.26
> CPU)
> multi_print_unbuffered: 18 wallclock secs (16.50 usr + 0.31 sys = 16.81
> CPU)
> single_print_buffered: 2 wallclock secs ( 2.83 usr + 0.06 sys = 2.89
> CPU)
> single_print_unbuffered: 8 wallclock secs ( 7.75 usr + 0.26 sys = 8.01
> CPU)
>
> But if I put:
> timethese
> (500_000, {
>multi_print_unbuffered => sub {local $| = 1; multi_print() ;},
>multi_print_buffered=> sub {local $| = 0; multi_print() ;},
>single_print_unbuffered => sub {local $| = 1; single_print();},
>single_print_buffered => sub {local $| = 0; single_print();},
> });
>
> Benchmark: timing 50 iterations of multi_print_buffered,
> multi_print_unbuffered, single_print_buffered, single_print_unbuffered...
> multi_print_buffered: 18 wallclock secs (15.79 usr + 0.65 sys = 16.44
> CPU)
> multi_print_unbuffered: 18 wallclock secs (16.57 usr + 0.37 sys = 16.94
> CPU)
> single_print_buffered: 7 wallclock secs ( 7.23 usr + 0.12 sys = 7.35
> CPU)
> single_print_unbuffered: 9 wallclock secs ( 7.57 usr + 0.32 sys = 7.89
> CPU)
>
> There is no difference between buffered and not buffered, it seems that
> the localizing of $| is what makes the difference. The multi vs single
> still holds.
>
> But you don't modify $| unless you want to unbuffer, so the first test
> seems to be fair to me. What do you think?
>
> Do you think I should test it under Apache (thru ab) since it might behave
> differently under Apache? But I doubt I'd be able to measure this unless
> the text would be huge to get the real feel of the numbers. You saw that
> I'd to run 500_000 tests to get some real numbers...
>
> _
> Stas Bekman JAm_pH -- Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide http://perl.apache.org/guide
> mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC
> http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Apache::ASP in virtual hosts
How would one go about adding the Apache::ASP function to the virtual hosts? I have the defunct ASP setting in my httpd.conf file and it works fine for the default site, but nothing for any of the virtuals. Need more specifics? Any info is better than what I have, thanx.
DSO mod_perl and preloading
All these tips and benchmarks on optimising mod_perl by preloading used modules/DBD-drivers etc. are great. However, I have seen warnings about preloading modules if mod_perl is loaded as a DSO. (e.g for HTML::Embperl). Does this still apply? My setup is redhat6.2/perl-5.6/mod_perl-1.23. TIA Andrew
Re: Apache::Dispatch
> [new module] Apache::Dispatch > 5129 by: Geoffrey Young <[EMAIL PROTECTED]> > 5131 by: Stas Bekman <[EMAIL PROTECTED]> > 5132 by: Matt Sergeant <[EMAIL PROTECTED]> > 5133 by: Geoffrey Young <[EMAIL PROTECTED]> > 5134 by: Geoffrey Young <[EMAIL PROTECTED]> There's a real live working example if anybody wants it, called "Wing", available from your local friendly CPAN. The module is used as an IMAP interface but the main module handles everything except logins, the url is used to pass commands around, the one I'm looking at at the moment is http://server1.herald.ox.ac.uk/wing/cmd/ball/x/compose The "wing/cmd" tells the module that this is a call for the function called (in this case) "cmd_compose" with the parameters "ball" (a username) (x is a dummy used for other functions I think). Internally the module takes 'compose' and prefixes it with 'cmd_', evals the string as a soft reference to a function and returns an error code if the function doesn't exist, or runs the function if it does. It only lets a strict subset of functions run (it always appends a "cmd_" to the name) so internal functions are safe . It was created by Malcolm Beattie (i.e Not me). -- Christopher Lee. (I'm only on the Digest list btw). >hi all... > >I'm not sure if some you remember the idea Vivek and Matt had about creating >a handler that mapped, say, http://localhost/Foo/doit to Foo->doit() > >anyway, the relevant part of the thread, including some code, can be seen >here: >http://marc.theaimsgroup.com/?l=apache-modperl&m=95598609306936&w=2 > >I was thinking of officially implementing the idea and wanted to get some >design feedback first... > >My thoughts so far: > >* limit the response to content handling phase only (I'm not really >sure of what utility other phases would be anyway) > >* limit the top-level qualifier for the module that can be executed, >but give this control to the user. > perhaps using PerlAddVar to allow only Apache::, Foo::, etc >modules only is safe enough? > >* if possible, I'd like to see it make some intelligent decisions >about whether it should take over the request. > that is, perhaps move away from a restriction and try >to call Foo->doit() if the normal resoltion /Foo/doit results in a 404. >I'm not sure how this would interact with mod_dir, but I guess it would also >depend on how folks want to use it... > > * do we want to default to handler()? if so, what to try first: >Foo::doit->handler() or Foo->doit() > >anyway, that's all for now... feedback/thoughts welcome... --Geoff --
[performance/benchmark] $| and multiprint
Here is the benchmark that tests two things: buffered vs unbuffered code
and multi-statement print vs single statement print styles. Here are the
code and results:
use Symbol;
my $fh = gensym;
open $fh, ">/dev/null" or die;
use Benchmark;
sub multi_print{
print $fh "";
print $fh "";
print $fh "";
print $fh "Test page";
print $fh "";
print $fh "";
print $fh "";
print $fh "";
print $fh "Hello";
print $fh "";
print $fh "";
print $fh "foo";
print $fh "";
print $fh "";
print $fh "";
}
sub single_print{
print $fh qq{
Test page
Hello
foo
};
}
timethese
(500_000, {
multi_print_unbuffered => sub {local $| = 1; multi_print() ;},
multi_print_buffered=> sub { multi_print() ;},
single_print_unbuffered => sub {local $| = 1; single_print();},
single_print_buffered => sub { single_print();},
});
Benchmark: timing 50 iterations of multi_print_buffered,
multi_print_unbuffered, single_print_buffered, single_print_unbuffered...
multi_print_buffered: 13 wallclock secs (11.09 usr + 0.17 sys = 11.26
CPU)
multi_print_unbuffered: 18 wallclock secs (16.50 usr + 0.31 sys = 16.81
CPU)
single_print_buffered: 2 wallclock secs ( 2.83 usr + 0.06 sys = 2.89
CPU)
single_print_unbuffered: 8 wallclock secs ( 7.75 usr + 0.26 sys = 8.01
CPU)
But if I put:
timethese
(500_000, {
multi_print_unbuffered => sub {local $| = 1; multi_print() ;},
multi_print_buffered=> sub {local $| = 0; multi_print() ;},
single_print_unbuffered => sub {local $| = 1; single_print();},
single_print_buffered => sub {local $| = 0; single_print();},
});
Benchmark: timing 50 iterations of multi_print_buffered,
multi_print_unbuffered, single_print_buffered, single_print_unbuffered...
multi_print_buffered: 18 wallclock secs (15.79 usr + 0.65 sys = 16.44
CPU)
multi_print_unbuffered: 18 wallclock secs (16.57 usr + 0.37 sys = 16.94
CPU)
single_print_buffered: 7 wallclock secs ( 7.23 usr + 0.12 sys = 7.35
CPU)
single_print_unbuffered: 9 wallclock secs ( 7.57 usr + 0.32 sys = 7.89
CPU)
There is no difference between buffered and not buffered, it seems that
the localizing of $| is what makes the difference. The multi vs single
still holds.
But you don't modify $| unless you want to unbuffer, so the first test
seems to be fair to me. What do you think?
Do you think I should test it under Apache (thru ab) since it might behave
differently under Apache? But I doubt I'd be able to measure this unless
the text would be huge to get the real feel of the numbers. You saw that
I'd to run 500_000 tests to get some real numbers...
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
OT: Browsers (was: Re: Wierd user agent strings)
> Oh fyi, May's score was 80% MSIE, 18% NS.. Here (www.iagora.com, a general non-tech site) I get: MSIE-all: 64.73% Netscape-all: 34.04% Other: 1.23% within Netscape: Netscape-5: 0.09% Netscape-4: 92.34% Netscape-3: 7.38% Netscape-2: 0.19% within MSIE: MSIE-5: 69.59% MSIE-4: 28.12% MSIE-3: 1.82% MSIE-2: 0.30% -- Roger Espel Llima, [EMAIL PROTECTED] http://www.iagora.com/~espel/index.html
RE: [new module] Apache::Dispatch
> -Original Message- > From: Matt Sergeant [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 05, 2000 12:25 PM > To: Stas Bekman > Cc: Geoffrey Young; '[EMAIL PROTECTED]'; 'Vivek Khera' > Subject: Re: [new module] Apache::Dispatch > > > On Mon, 5 Jun 2000, Stas Bekman wrote: > > > On Mon, 5 Jun 2000, Geoffrey Young wrote: > > > > > hi all... > > > > > > I'm not sure if some you remember the idea Vivek and Matt > had about creating > > > a handler that mapped, say, http://localhost/Foo/doit to > Foo->doit() > > > > > > anyway, the relevant part of the thread, including some > code, can be seen > > > here: > > > > http://marc.theaimsgroup.com/?l=apache-modperl&m=95598609306936&w=2 > > > > > > I was thinking of officially implementing the idea and > wanted to get some > > > design feedback first... > > > > > > My thoughts so far: > > > > > > * limit the response to content handling phase only > (I'm not really > > > sure of what utility other phases would be anyway) > > > > > > * limit the top-level qualifier for the module that can > be executed, > > > but give this control to the user. > > > perhaps using PerlAddVar to allow only Apache::, Foo::, etc > > > modules only is safe enough? > > > > Geoff, > > I think you will open a Pandora box by releasing this > module. I don't see > > it'd give some real savings, but users will get hurt, badly. You > > shouldn't let the control into user hands! (I mean the > clients!) There > > will be alway a module that you will not know about, or a > function/method > > inside it you won't think about. > > It shouldn't be dangerous at all if you specify: > > PerlSetVar DispatchPrefix MyModule > > Then http://localhost/Foo/bar > > calls MyModule::Foo->bar() oh, I hadn't thought of using that combination. I guess that would also hide the full package names from the outside and would add an extra level of security... > > -- > > > Fastnet Software Ltd. High Performance Web Specialists > Providing mod_perl, XML, Sybase and Oracle solutions > Email for training and consultancy availability. > http://sergeant.org http://xml.sergeant.org >
RE: [new module] Apache::Dispatch
> -Original Message- > From: Stas Bekman [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 05, 2000 12:19 PM > To: Geoffrey Young > Cc: '[EMAIL PROTECTED]'; 'Vivek Khera'; 'Matt Sergeant' > Subject: Re: [new module] Apache::Dispatch > > > On Mon, 5 Jun 2000, Geoffrey Young wrote: > > > hi all... > > > > I'm not sure if some you remember the idea Vivek and Matt > had about creating > > a handler that mapped, say, http://localhost/Foo/doit to Foo->doit() > > > > anyway, the relevant part of the thread, including some > code, can be seen > > here: > > http://marc.theaimsgroup.com/?l=apache-modperl&m=95598609306936&w=2 > > > > I was thinking of officially implementing the idea and > wanted to get some > > design feedback first... > > > > My thoughts so far: > > > > * limit the response to content handling phase only > (I'm not really > > sure of what utility other phases would be anyway) > > > > * limit the top-level qualifier for the module that can > be executed, > > but give this control to the user. > > perhaps using PerlAddVar to allow only Apache::, Foo::, etc > > modules only is safe enough? > > Geoff, > I think you will open a Pandora box by releasing this module. > I don't see > it'd give some real savings, but users will get hurt, badly. well, it was the article in this month's LJ that made me think of it again... http://www2.linuxjournal.com/lj-issues/issue74/4002.html of course, while I don't share his views stated in the third and fourth paragraphs, I thought answersing those types of concerns would be a benefit... > You > shouldn't let the control into user hands! (I mean the clients!) There > will be alway a module that you will not know about, or a > function/method > inside it you won't think about. > > How Randal used to say: Dangerous, Willis? or was it Robinson :) Danger Will Robinson :) > > Personally I'm against this idea. Unless you allow only a list of > specified Module::method (s), but even then things will get > modified the > original intention forgotten, systems hacked and ruined. ok, I never claimed to be a security expert, and we certainly don't want to expose mod_perl or give it a bad name. However, if the client/user uses the module parameters to expose his system, does that mean that the module is a bad idea? but I don't see that by allowing only Apache:: modules adds a security risk (but I don't tear apart systems for a living :) --Geoff > > > * if possible, I'd like to see it make some intelligent > decisions > > about whether it should take over the request. > > that is, perhaps move away from a > restriction and try > > to call Foo->doit() if the normal resoltion /Foo/doit > results in a 404. > > I'm not sure how this would interact with mod_dir, but I > guess it would also > > depend on how folks want to use it... > > > > * do we want to default to handler()? if so, what to try first: > > Foo::doit->handler() or Foo->doit() > > > > anyway, that's all for now... feedback/thoughts welcome... > > > > --Geoff > > > > > > > > _ > Stas Bekman JAm_pH -- Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide http://perl.apache.org/guide > mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC > http://singlesheaven.com http://perlmonth.com http://sourcegarden.org >
Re: [new module] Apache::Dispatch
On Mon, 5 Jun 2000, Stas Bekman wrote: > On Mon, 5 Jun 2000, Geoffrey Young wrote: > > > hi all... > > > > I'm not sure if some you remember the idea Vivek and Matt had about creating > > a handler that mapped, say, http://localhost/Foo/doit to Foo->doit() > > > > anyway, the relevant part of the thread, including some code, can be seen > > here: > > http://marc.theaimsgroup.com/?l=apache-modperl&m=95598609306936&w=2 > > > > I was thinking of officially implementing the idea and wanted to get some > > design feedback first... > > > > My thoughts so far: > > > > * limit the response to content handling phase only (I'm not really > > sure of what utility other phases would be anyway) > > > > * limit the top-level qualifier for the module that can be executed, > > but give this control to the user. > > perhaps using PerlAddVar to allow only Apache::, Foo::, etc > > modules only is safe enough? > > Geoff, > I think you will open a Pandora box by releasing this module. I don't see > it'd give some real savings, but users will get hurt, badly. You > shouldn't let the control into user hands! (I mean the clients!) There > will be alway a module that you will not know about, or a function/method > inside it you won't think about. It shouldn't be dangerous at all if you specify: PerlSetVar DispatchPrefix MyModule Then http://localhost/Foo/bar calls MyModule::Foo->bar() -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: [new module] Apache::Dispatch
On Mon, 5 Jun 2000, Geoffrey Young wrote: > hi all... > > I'm not sure if some you remember the idea Vivek and Matt had about creating > a handler that mapped, say, http://localhost/Foo/doit to Foo->doit() > > anyway, the relevant part of the thread, including some code, can be seen > here: > http://marc.theaimsgroup.com/?l=apache-modperl&m=95598609306936&w=2 > > I was thinking of officially implementing the idea and wanted to get some > design feedback first... > > My thoughts so far: > > * limit the response to content handling phase only (I'm not really > sure of what utility other phases would be anyway) > > * limit the top-level qualifier for the module that can be executed, > but give this control to the user. > perhaps using PerlAddVar to allow only Apache::, Foo::, etc > modules only is safe enough? Geoff, I think you will open a Pandora box by releasing this module. I don't see it'd give some real savings, but users will get hurt, badly. You shouldn't let the control into user hands! (I mean the clients!) There will be alway a module that you will not know about, or a function/method inside it you won't think about. How Randal used to say: Dangerous, Willis? or was it Robinson :) Personally I'm against this idea. Unless you allow only a list of specified Module::method (s), but even then things will get modified the original intention forgotten, systems hacked and ruined. > * if possible, I'd like to see it make some intelligent decisions > about whether it should take over the request. > that is, perhaps move away from a restriction and try > to call Foo->doit() if the normal resoltion /Foo/doit results in a 404. > I'm not sure how this would interact with mod_dir, but I guess it would also > depend on how folks want to use it... > > * do we want to default to handler()? if so, what to try first: > Foo::doit->handler() or Foo->doit() > > anyway, that's all for now... feedback/thoughts welcome... > > --Geoff > > _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: [RFC: performance] Initializing DBI.pm
> > > I've not done much of either this last year, however, I'm hoping to get > > > a new beta DBI release out this week. Maybe... > > > > Tim I hope you plan to integrate Doug's patch which makes it possible to use > > DBI with Perl 5.6 -Dusethreads. Thanks! > > Of course. And I'll trust you'll all be doing my testing for me... :-) Sure thing, although I doubt many mod_perl users are using Perl 5.6 -Dusethreads in production environments. -- Eric
[new module] Apache::Dispatch
hi all... I'm not sure if some you remember the idea Vivek and Matt had about creating a handler that mapped, say, http://localhost/Foo/doit to Foo->doit() anyway, the relevant part of the thread, including some code, can be seen here: http://marc.theaimsgroup.com/?l=apache-modperl&m=95598609306936&w=2 I was thinking of officially implementing the idea and wanted to get some design feedback first... My thoughts so far: * limit the response to content handling phase only (I'm not really sure of what utility other phases would be anyway) * limit the top-level qualifier for the module that can be executed, but give this control to the user. perhaps using PerlAddVar to allow only Apache::, Foo::, etc modules only is safe enough? * if possible, I'd like to see it make some intelligent decisions about whether it should take over the request. that is, perhaps move away from a restriction and try to call Foo->doit() if the normal resoltion /Foo/doit results in a 404. I'm not sure how this would interact with mod_dir, but I guess it would also depend on how folks want to use it... * do we want to default to handler()? if so, what to try first: Foo::doit->handler() or Foo->doit() anyway, that's all for now... feedback/thoughts welcome... --Geoff
RE: non-DSO mod_perl, Embperl, and AIX not working (duplicate ?)
I haven't used Embperl on AIX (or any platform for that matter), but I am unfortunatly using AIX at work. :-( AIX's C compiler is as buggy as a Florida chineese resturaunt. I couldn't even get Apache to install right (it kept saying something to the effect of "Found , expected "...Sheesh!) Anyhoo, I went to IBMs site, downloaded the patches, and everything is happy again. I had to install somewhere near 45-50 patches to make it current. One of these days, I'm going to install GCC and be done with it. Anyway, you may want to see if it has something to do with AIX's cc or libraries. -man -Original Message- From: Greg Estep [mailto:[EMAIL PROTECTED]] Sent: Friday, June 02, 2000 6:35 PM To: [EMAIL PROTECTED] Subject: non-DSO mod_perl, Embperl, and AIX not working (duplicate ?) Sorry if this is a duplicate. I sent the message yesterday, but I haven't seen it posted back to me via the list. We have recently been having problems with our email services... --- I am using IBM's C complier (cc) under AIX 4.3.3 with Apache 1.3.12, mod_perl 1.24 (statically linked, not DSO), perl 5.00503, and Embperl 1.3b3. The "offline", "execute function", and "cgi mode" Embperl tests are all successful. In the "mod_perl" mode, even the simple "ascii" test fails. It fails with a seg. fault and a dbx stack trace that looks like this: ap_palloc() at 0xd1179d98 EMBPERL__malloc() at 0xd1178b98 EMBPERL_SetupFileData() at 0xd1177118 EMBPERL_SetupRequest() at 0xd1177764 XS_HTML__Embperl_SetupRequest() at 0xd116fcb8 .() at 0x1004a344 .() at 0x100536f0 .() at 0x1002ff98 perl_call_handler(??, ??, ??) at 0x10113f70 perl_run_stacked_handlers(??, ??, ??) at 0x10113160 perl_handler(??) at 0x10111d38 ap_invoke_handler(0x2011f1f0) at 0x100c42bc process_request_internal(0x2011f1f0) at 0x100f4d6c ap_process_request(0x2011f1f0) at 0x100f648c child_main(0x0) at 0x10002d24 make_child(0x200498e0, 0x0, 0x39363aa3) at 0x100025a0 startup_children(0x2) at 0x1000248c standalone_main(0x4, 0x2ff228c8) at 0x10001928 main(0x4, 0x2ff228c8) at 0x100014b0 To get Embperl.so to successfully build I added "-b erok" to LDDLFLAGS. I also tried '-G' with similar results. Without the modification to LDDLFLAGS I got several "unresolved symbol" errors. I also get similar results with Embperl 1.2b9, Apache 1.3.9, and mod_perl 1.23. BTW, I did not personally compile my perl executable, it is straight from a fileset on the AIX 4.3.3 CD. I have, however, upgraded several modules to their most recent CPAN version. My 'perl -V' output looks like this: Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=aix, osvers=4.3.3.0, archname=aix uname='aix funny 3 4 01716600 ' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='-O', gccversion= cppflags='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE - qmaxmem=16384' ccflags ='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE - qmaxmem=16384' stdchar='unsigned char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='ld', ldflags ='-s' libpth=/lib /usr/lib /usr/ccs/lib libs=-lnsl -ldbm -ldl -lld -lm -lc -lcrypt -lbsd -lPW -lC_r libc=/lib/libc.a, so=a, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_aix.xs, dlext=so, d_dlsymun=undef, ccdlflags='- bE:perl.exp' cccdlflags=' ', lddlflags='-bhalt:4 -bM:SRE - bI:$(PERL_INC)/perl.exp -bE:$(B ASEEXT).exp -b noentry -lc' Characteristics of this binary (from libperl): Built under aix Compiled at Aug 14 1999 08:59:55 @INC: /usr/opt/perl5/lib/5.00503/aix /usr/opt/perl5/lib/5.00503 /usr/opt/perl5/lib/site_perl/5.005/aix /usr/opt/perl5/lib/site_perl/5.005 . -- Greg Estep <[EMAIL PROTECTED]>
Re: Object persistence
I think the answer is yes if you are talking about a straight object data
structure. But no if you are talking about persistence of things like
socket or database connections that might be open resources that are
represented by your user object.
Apache::Session uses storable to serialize the objects into session's data
store.
Later,
Gunther
At 08:08 AM 6/5/00 -0700, Ian Mahuron wrote:
>Is there any way to implement object persistence with Apache::Session?
>
>I'd like to do something like this (though I'm not sure how):
>
># during some point in application (throwing object into session data)
>
>my $user = MyMods::User->new();
>$user->fetch_by_id(1234);
>$session{user} = $user;
>
>
># during some other request (pulling object out)
>
>my $user = $session{user};
>my $login = $user->login();
>print("$login\n");
>
>I'm sure it's more complicated then this. Any help would be appreciated.
>Thank you in advance.
>
>Ian
Object persistence
Is there any way to implement object persistence with Apache::Session?
I'd like to do something like this (though I'm not sure how):
# during some point in application (throwing object into session data)
my $user = MyMods::User->new();
$user->fetch_by_id(1234);
$session{user} = $user;
# during some other request (pulling object out)
my $user = $session{user};
my $login = $user->login();
print("$login\n");
I'm sure it's more complicated then this. Any help would be appreciated.
Thank you in advance.
Ian
Re: [RFC: performance] Preloading Perl Modules at Server Startup
On Mon, 5 Jun 2000, Vivek Khera wrote: > > "SB" == Stas Bekman <[EMAIL PROTECTED]> writes: > > SB> But an even better approach is to create a separate startup file > SB> (where you code in plain perl) and put there things like: > > SB> use DBI; > SB> use Carp; > > SB> Then you C this startup file in I with the > SB> C directive, placing it before the rest of the mod_perl > SB> configuration directives: > > SB> PerlRequire /path/to/start-up.pl > > > You should recommend > > use DBI (); > use Carp (); > > so that no symbols are imported into the name space of the start-up.pl > script as it is unlikely to be needed there. that's right. > Also, I'd recommend using libapreq's Apache::Request if you don't need > the content generating parts of CGI.pm... which leads to an > enhancement That's a topic of another section. > I'd like to see Doug add to libapreq's functionality: > > Currently, you need to do a call like this if you're using > Apache::Request inside a Registry script: > > my $ar = Apache::Request->new(Apache->request()) or die "Whoa Nelly!"; > > I'd like to see the Apache::Request->new() method automatically call > Apache->request() if no parameters are passed to it. Inside a > Apache->handler, it is easy since you already have a Apache->request > object passed to you, but in Registry, it is a lot of extra typing. As Geoff has mentioned it works already with shift() ... seems ok to me. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
RE: [RFC: performance] Preloading Perl Modules at Server Startup
> -Original Message- > From: Geoffrey Young [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 05, 2000 10:30 AM > To: 'Vivek Khera'; mod_perl list > Subject: RE: [RFC: performance] Preloading Perl Modules at Server > Startup > > > > [snip] > > > > > > Also, I'd recommend using libapreq's Apache::Request if you > > don't need > > > the content generating parts of CGI.pm... which leads to an > > > enhancement I'd like to see Doug add to libapreq's functionality: > > > > > > Currently, you need to do a call like this if you're using > > > Apache::Request inside a Registry script: > > > > > > my $ar = Apache::Request->new(Apache->request()) or die > > > "Whoa Nelly!"; > > > > my $apr = Apache::Request->new(shift); > > > did I really just say that? > > I guess that doesn't work for Registry scripts after all... > sorry for the > FUD :) ok, it does work... I'll stop posting now... > > --Geoff > > > > > > requires less typing and still has the desired effect in > > Regitry scripts or > > handlers... > > > > --Geoff > > > > > > > > I'd like to see the Apache::Request->new() method > automatically call > > > Apache->request() if no parameters are passed to it. Inside a > > > Apache->handler, it is easy since you already have a > Apache->request > > > object passed to you, but in Registry, it is a lot of > extra typing. > > > > > >
RE: [RFC: performance] Preloading Perl Modules at Server Startup
[snip] > > > > Also, I'd recommend using libapreq's Apache::Request if you > don't need > > the content generating parts of CGI.pm... which leads to an > > enhancement I'd like to see Doug add to libapreq's functionality: > > > > Currently, you need to do a call like this if you're using > > Apache::Request inside a Registry script: > > > > my $ar = Apache::Request->new(Apache->request()) or die > > "Whoa Nelly!"; > > my $apr = Apache::Request->new(shift); did I really just say that? I guess that doesn't work for Registry scripts after all... sorry for the FUD :) --Geoff > > requires less typing and still has the desired effect in > Regitry scripts or > handlers... > > --Geoff > > > > > I'd like to see the Apache::Request->new() method automatically call > > Apache->request() if no parameters are passed to it. Inside a > > Apache->handler, it is easy since you already have a Apache->request > > object passed to you, but in Registry, it is a lot of extra typing. > > >
Re: Mason/mod_perl failing with threaded perl
On Sun, 4 Jun 2000, John Chia wrote: > I've since upgraded to perl-5.6.0 and disabled threads. > It works now. Don't know anymore about it. Just thought > someone might like to know. same thing's happening to me, with perl 5.6 and threads. ill just go ahead and rebuild without threads. such heartache!
RE: [RFC: performance] Preloading Perl Modules at Server Startup
> -Original Message- > From: Vivek Khera [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 05, 2000 10:09 AM > To: mod_perl list > Subject: Re: [RFC: performance] Preloading Perl Modules at Server > Startup > > > > "SB" == Stas Bekman <[EMAIL PROTECTED]> writes: > > SB> But an even better approach is to create a separate startup file > SB> (where you code in plain perl) and put there things like: > > SB> use DBI; > SB> use Carp; > > SB> Then you C this startup file in I with the > SB> C directive, placing it before the rest of > the mod_perl > SB> configuration directives: > > SB> PerlRequire /path/to/start-up.pl > > > You should recommend > > use DBI (); > use Carp (); > > so that no symbols are imported into the name space of the start-up.pl > script as it is unlikely to be needed there. > > Also, I'd recommend using libapreq's Apache::Request if you don't need > the content generating parts of CGI.pm... which leads to an > enhancement I'd like to see Doug add to libapreq's functionality: > > Currently, you need to do a call like this if you're using > Apache::Request inside a Registry script: > > my $ar = Apache::Request->new(Apache->request()) or die > "Whoa Nelly!"; my $apr = Apache::Request->new(shift); requires less typing and still has the desired effect in Regitry scripts or handlers... --Geoff > > I'd like to see the Apache::Request->new() method automatically call > Apache->request() if no parameters are passed to it. Inside a > Apache->handler, it is easy since you already have a Apache->request > object passed to you, but in Registry, it is a lot of extra typing. >
Re: [benchmark] DBI/preload (was Re: [RFC] improving memory mapping thru code exercising)
On Mon, 5 Jun 2000, Vivek Khera wrote:
> > "PH" == Perrin Harkins <[EMAIL PROTECTED]> writes:
>
> PH> On Sat, 3 Jun 2000, Stas Bekman wrote:
> >> * install_driver (2):
> DBI-> install_driver("mysql");
>
> PH> I've never seen that before, and it isn't in the DBI perldoc. Is it safer
> PH> than "use DBD::mysql;"?
>
> "use DBD::mysql" doesn't really do anything, does it?
Only preloads (compiles) the module. See the benchmark.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: [RFC: performance] Preloading Perl Modules at Server Startup
> "SB" == Stas Bekman <[EMAIL PROTECTED]> writes: SB> But an even better approach is to create a separate startup file SB> (where you code in plain perl) and put there things like: SB> use DBI; SB> use Carp; SB> Then you C this startup file in I with the SB> C directive, placing it before the rest of the mod_perl SB> configuration directives: SB> PerlRequire /path/to/start-up.pl You should recommend use DBI (); use Carp (); so that no symbols are imported into the name space of the start-up.pl script as it is unlikely to be needed there. Also, I'd recommend using libapreq's Apache::Request if you don't need the content generating parts of CGI.pm... which leads to an enhancement I'd like to see Doug add to libapreq's functionality: Currently, you need to do a call like this if you're using Apache::Request inside a Registry script: my $ar = Apache::Request->new(Apache->request()) or die "Whoa Nelly!"; I'd like to see the Apache::Request->new() method automatically call Apache->request() if no parameters are passed to it. Inside a Apache->handler, it is easy since you already have a Apache->request object passed to you, but in Registry, it is a lot of extra typing.
Re: [benchmark] DBI/preload (was Re: [RFC] improving memory mappingthru code exercising)
> "PH" == Perrin Harkins <[EMAIL PROTECTED]> writes:
PH> On Sat, 3 Jun 2000, Stas Bekman wrote:
>> * install_driver (2):
DBI-> install_driver("mysql");
PH> I've never seen that before, and it isn't in the DBI perldoc. Is it safer
PH> than "use DBD::mysql;"?
"use DBD::mysql" doesn't really do anything, does it?
Mason/mod_perl failing with threaded perl
I'm getting an error (as follows) when I try to reload a mason page (any mason page) more than a dozen times. System error while serving host (blah blah) Can't upgrade that kind of scalar at /usr/lib/perl5/site_perl/5.005/HTML/Mason/ApacheHandler.pm line 498. The error disappears temporarily if I restart apache but reappears after another dozen or so refreshes. The line is a call to mod_perl's flist function... I've since upgraded to perl-5.6.0 and disabled threads. It works now. Don't know anymore about it. Just thought someone might like to know. -john
Location makes redirect and confuses CGI::url
Hello,
this (longer) post deals with DirectoryIndex expansion,
Apache::PerlRun (Registry gives the same) and CGI's url('-relative' => 1)
method. The versions are 1.24, 2.68, 1.3.11 and 5.6.0+patches upto the
end of May. In the end, there is a proposed patch for CGI.pm, but as I'm
not sure if the behaviour is a bug or feature of mod_perl, I'm sending it
to [EMAIL PROTECTED] as well, for comments.
This config
SetHandler perl-script
PerlSetVar PerlRunOnce On
PerlSendHeader On
PerlHandler Apache::PerlRun
and request for https://server/testing/ leads to redirect, where the
interesting values (printed via %ENV) are
PATH_INFO=/
PATH_TRANSLATED=/www/
REDIRECT_PATH_INFO=/
REDIRECT_PATH_TRANSLATED=/www/
REDIRECT_REQUEST_URI=/testing/
REDIRECT_SCRIPT_FILENAME=/www/testing
REDIRECT_SCRIPT_NAME=/testing
REDIRECT_URL=/testing/
REQUEST_URI=/testing/
SCRIPT_FILENAME=/www/testing/index.pl
SCRIPT_NAME=/testing/index.pl
This confuses CGI.pm, because $q->url('-relative' => 1) returns
'testing', not '' as would be expected.
If I change the config to be
SetHandler perl-script
PerlSetVar PerlRunOnce On
PerlSendHeader On
PerlHandler Apache::PerlRun
the redirect seems to be much less aggresive and the values are
REDIRECT_URL=/testing/
REQUEST_URI=/testing/
SCRIPT_FILENAME=/www/testing/index.pl
SCRIPT_NAME=/testing/index.pl
There is no PATH_INFO value here, as well. And the PATH_INFO being
set in the previous case is the cause of the trouble. I believe that
the following patch fixes the problem -- from '/testing/', even if
the path_info is '/', the relative address still needs to stay '',
not 'testing', otherwise '/testing/testing' is achieved in the link.
--- CGI.pm.orig Mon Jun 5 14:04:12 2000
+++ CGI.pm Mon Jun 5 14:04:48 2000
@@ -2183,6 +2183,7 @@
# and path
if (exists($ENV{PATH_INFO})) {
my $decoded_path = unescape($ENV{PATH_INFO});
+ $decoded_path =~ s!^/!!;
substr($script_name,$index) = '' if ($index =
rindex($script_name,$decoded_path)) >= 0;
}
} else {
Comments are gladly welcome.
--
Honza Pazdziora | [EMAIL PROTECTED] | http://www.fi.muni.cz/~adelton/
.project: Perl, DBI, Oracle, MySQL, auth. WWW servers, MTB, Spain.
Re: [RFC: performance] Initializing DBI.pm
On Mon, Jun 05, 2000 at 12:49:46AM +0200, Eric Cholet wrote: > On Sun, Jun 04, 2000 at 08:58:11PM +0100, Tim Bunce wrote: > > On Sun, Jun 04, 2000 at 10:57:57PM +0300, Stas Bekman wrote: > > > > > > This all won't be possible without you and other great folks writing and > > > maintaining this amaizing software... So the biggest thanks goes to you :) > > > > I've not done much of either this last year, however, I'm hoping to get > > a new beta DBI release out this week. Maybe... > > Tim I hope you plan to integrate Doug's patch which makes it possible to use > DBI with Perl 5.6 -Dusethreads. Thanks! Of course. And I'll trust you'll all be doing my testing for me... :-) Tim.
Re: Warning about guide exceptions docs...
On Sun, 4 Jun 2000, Stas Bekman wrote: > On Sat, 3 Jun 2000, Matt Sergeant wrote: > > > Just a "heads up" about the exceptions section of the guide. Don't try and > > create more than one generic exception handler on your server. As I've > > just discovered it really confuses things. Create one class and one class > > only for handling exceptions globally. > > Matt, will you please send me an update? I still didn't get a chance to > dig into your exceptions guide. OK - could you possibly email me the current perl.pod so that I don't have to go downloading the whole thing? Also, the die overloading needs a prototype to work like the real die(). > > Maybe I should put out a CPAN release: SimpleException.pm or something? > > Sounds good! Will you really do it? Well it would be trivial - I'll ask [EMAIL PROTECTED] -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
