On Tue, 26 Sep 2000, Salvador Ortiz Garcia wrote:
> IMHO the real problem relies in allow Perl{Module|Require} directives in
> .htaccess files, The cls->PermModule and cls->PerlRequire arrays are both
> in the per server part of mod_perl config, so allow to modify them (in
> this case append to) when apache is parsing a .htaccess (a per request
> operation to create a per directory config) simply don't make sense.
right, i realize that, and thought about also setting:
cls->PerlRequire = cls->PerlModule = NULL;
after they are processed at startup, but decided to think about it more
later.
> First, both arrays are procesed only inside perl_startup for the case that
> the real require was delayed, and when apache starts servicing requests
> and parsing .htaccess files, the perl startup was done.
Perl{Require,Module} happen inline if Perl is already running.
> Second, Loading a perl module at per request time that will be remain in
> core for the rest of the live of the running child and can not be shared
> among other children in general isn't a good idea so is better don't
> promote that practice.
right, but that's already the case with most people using Apache::Registry
who don't pre-load everything. letting everything work in .htaccess is
just more rope. for example, not everybody has write access to the main
httpd.conf, or simply prefer .htaccess for whatever reason. even though
we know it's best to disable .htaccess and pre-load everything in
httpd.conf, that's not required for everybody.
> Worse, allow that can create false expectations to the user, because if
> the PerlRequire is used for its side effects, ie out of subs code that
> code will be run only the first time a child sees the .htaccess and any
> other request served by that child will be silent, so from the point of
> view of the module programer that code runs at random times. [see note1]
i'm not too worried about that. i doubt many people are using
Perl{Module,Require} in .htaccess, but there were at least 2 who tried and
got a core dump, so i wanted to at least provide a bandaid.
> The corrent fix IMHO is simply don't allow that directives in
> per directory containers:
>
> { "PerlRequire", (crft) perl_cmd_require,
> NULL,
> - OR_ALL, ITERATE, "A Perl script name, pulled in via require" },
> + RSRC_CONF, ITERATE, "A Perl script name, pulled in via require" },
> { "PerlModule", (crft) perl_cmd_module,
> NULL,
> - OR_ALL, ITERATE, "List of Perl modules" },
> + RSRC_CONF, ITERATE, "List of Perl modules" },
>
> Right now its don't works, so nothing is broken.
but it does work now and people are using it in .htaccess, the only part
that was broken was the merge routine, which only matters to those using
VirtualHosts.
> [note1]
>
> A "fix" for that behavior is a simple 'delete $INC{$module_name}' at the
> end, but ussing that as common practice is a bad thing. Much better is a
> simple
>
> <Perl>
> MyModule::parsing_htaccess('foo','bar')
> </Perl>
>
> inside the .htaccess file.
oh, you're saying what doesn't work is PerlRequire running the code for
every request? i didn't see that expectation with the 2 posts w/ segv's,
they were both using PerlModule. but a good point.
> BTW, I have a _very_ small and well tested patch for a new directive
> 'PerlDo', that acts exactly like a
>
> <Perl>
> {On line of perl code}
> </Perl>
>
> as
>
> PerlDo {On line of perl code}
thanks salvador, that looks useful. but, shouldn't it be called PerlEval?
i would expect PerlDo to run 'do $arg'. which might be a solution for
people who expect something like PerlRequire in .htaccess to run the code
in that file on every request.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
