Fred Moyer wrote:
Try with the 2.0.4 stable version of mod_perl. Also I would suggest
building mod_perl as a shared object (dynamically, not statically), so
would say remove the MP_USE_STATIC=1. I've seen people get it to work
but almost everyone I know builds mod_perl as a loadable module in
> Under mod_perl, packages/scripts remain in memory across requests, for the
> duration of the Apache child.
> The second issue is that, due to the stateless nature of HTTP, requests are
> dispatched to Apache/mod_perl children at random. You can't store
> information about a particular user or
Mr. Foertsch, that was a wonderful reply. Just what the doctor ordered.
Thanks.
> If you are using the prefork MPM (as you probably do) you can still
> manipulate the environment without affecting other requests. But you
> have to use the C-level functions. There is a module called Env::C on
Using mod_perl2, is there a way of mapping a URI to a filename or
directory.
I can get the root directory for the server and I can append the URI to
it but this doesn't taking to account aliases, UserDir directives etc..
Any suggestions?
Anthony.
On Sat 16 Aug 2008, Berg, Eric wrote:
> > Now, the environment is a process global resource. So, if
> > those values are changed all threads are affected. This is surely
> > no what you want.
>
> When you say that the environment is a global process, global to
> what? Each forked process has its o
I've taken a few minutes to regurgitate this into something that I can submit
to the documentation project. Mind taking a look and giving me some feedback
(anyone) before I do?
>>
=head1 Issues with Environment Variables
There are several thread-safety issues with setting environme
