Hello All,
Took me a day, but I think I've finally been able to move my
scripts from plain cgi perl to mod_perl2. The extensive documention
on perl.apache.org was invaluable, though I have some comments below.
One question: Prior to using mod_perl I was able to have
unsuffixed scripts and .html
Perrin Harkins wrote:
You should be able to do the SetHandler inside a Files directive just
like you did with ForceType. Have you tried that?
Thanks Perrin, that worked. I didn't think SetHandler directives
were allowed in Files sections, because it's not listed in the SetHandler
docs
Stas Bekman wrote:
Mark James wrote:
1. In http://perl.apache.org/docs/1.0/guide/getwet.html , use of x.x.x
for both the Apache and mod_perl version numbers made me think that
the version numbers had to be matched. Maybe y.y.y should be used
for one.
Please get used to x.x.x meaning
Some of my scripts break when running under mp2 (cvs) because the UID
is set as root rather than the Apache user (which for me is web).
The problem manifests with RCS file locking. Is there some switch
to set so that I can run scripts as web?
Stas Bekman wrote:
Mark James wrote:
Some of my scripts break when running under mp2 (cvs) because the UID
is set as root rather than the Apache user (which for me is web).
The problem manifests with RCS file locking. Is there some switch
to set so that I can run scripts as web?
Eh? Are you
Hello All,
Took me a day, but I think I've finally been able to move my
scripts from plain cgi perl to mod_perl. The extensive documention
on perl.apache.org was invaluable, though I have some comments below.
One question: Prior to using mod_perl I was able to have
unsuffixed scripts and .html
I'm having CGI redirect problems mp2 (cvs).
Instead of being redirected to the proper web page, I'm sometimes
getting a 302 Moved page containing a link to the correct URL.
Seems to be related to the following code in modperl_cgi.c:
if (location (location[0] == '/') (r-status == 200)) {
Stas Bekman wrote:
...
Well, actually this is not the case. It behaves exactly the same as in
modperl 1.0. You can use Env::C module (available from CPAN) to easily
debug this:
...
In any case you probably want to rely on getpwuid($), rather than
$ENV{USER} if applicable.
Unfortunately ci
Devi .M wrote:
Hello All,
I have a perl script that would be running infinitely and updating
an array by processing some data. Now I would like to read the array
values that should not disturb this perl script.
I thought to use the concept of shared variable and write a method
in perl module
Stas Bekman wrote:
Mark James wrote:
I'm having CGI redirect problems mp2 (cvs).
as the comment just above this line says, that code was copy-n-pasted
from mod_cgi. Can you reproduce the same problem while running a cgi
script?
No, them problem only manifests under mod_perl (2, haven't used 1
Mark James wrote:
303 See Other is the correct post-POST redirect response:
http://rfc.net/rfc2616.html#s10.3.4
which your first link suggests works in all browsers.
Well, taking a closer look, 303 doesn't work in Netscape 3 or 4.
CGI.pm always returns a 302, though, if necessary, I can
Stas Bekman wrote:
Can you send a short script (removing all the irrelevant bits) that we
can reproduce the problem with?
Made a script that generated the same POST request and same
redirect as the problem code. The problem was not reproduced!
The only difference I can see between working POSTs
Mark James wrote:
I'm having CGI redirect problems mp2 (cvs).
Instead of being redirected to the proper web page, I'm sometimes
getting a 302 Moved page containing a link to the correct URL.
Damn this was a hard bug to track down.
The cause of the problem was my perl code calling flush.pl
Stas Bekman wrote:
Mark James wrote:
The cause of the problem was my perl code calling flush.pl and
flushing STDOUT at a point prior to it printing the response headers.
Hmm, why do you flush?
STDOUT is flushed prior to a fork to exec an external binary (rcs).
The child is closing STDOUT
Stas Bekman wrote:
Mark James wrote:
STDOUT is flushed prior to a fork to exec an external binary (rcs).
I understand the cause. But I hope that you agree with me that this is
an application's problem. If you haven't sent anything to STDOUT yet,
don't flush. And if this is not under your control
Stas Bekman wrote:
Since the mod_perl's internal STDOUT buffer isn't mangled if you re-tie
it later, and it'll be always flushed at the end of the request, there
is no *need* to flush on CLOSE. However in order to be consistent with
perl fh close behavior, it probably needs to be changed to
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)
Rosane Novello wrote:
When I try to build I receive the error above. Someone can help me?
C:\mod_perl-1.99_08perl Makefile.PL MP_AP_PREFIX=C:\Apache Group\Apache2
Use of uninitialized value in concatenation (.) or string at
lib/ModPerl/BuildOptions.pm line 89, DATA line 18.
A comment in
18 matches
Mail list logo
