For those interested, I've been doing a general clean up of the code
( shrinking the code size down mainly ), prior to starting further
work on it.
Code available on request.
My intentions is to keep it as light as possible. While Apache::Fake
seems to be able to do a very large amount of things
Hello all,
I have a machine acting as a proxy using mod_perl-1.99_09 with apache
2.0.46. This proxy is supposed to filter all html content. So far I
have achieved most of my project's goals. But there is one issue I
can't get straight, this is when the proxy gets a page that is
encoded (like in
On Fri, Sep 05, 2003 at 10:13:36, Geoffrey Young said...
> actually, the return value is entirely ignored in Registry scripts - that's
> why we need the $r->status hack, which is not needed (or desired) in
> handlers. if you returned SERVER_ERROR it would still work, so long as you
> set $r->s
I had version CGI 3.00 installed.
Downgraded it to CGI 2.93, put I still have the same result.
The problem as I see it that I have a form with character — in it.
But it is returned as character — from the Widows-1252 characterset.
Does everybody agree that it should be returned as — (the utf-8
rep
Stas wrote:
>Bart, can you test whether you have the same problem when a run the same
code
>under mod_cgi in Apache2 (with perl5.8 ofcourse)? If not, that will point
the
>blaming finger towards mod_perl 2.0.
Well I did that and guess what? mod_cgi fails as well.
So it is not a mod_perl problem
Bu
So these are the versions required to run properly with mod_perl 2.0?
Here is an updated table:
Module Name Required Dist Package
-
Apache::AuthExpire Apache-AuthExpire-0.38
Apache::AuthNetLDAPApache-AuthNetL
Stas Bekman wrote:
speeves wrote:
Stas Bekman wrote:
Thanks that did it.
Great.
It would be nice though if the minimum rev level of the CGI.pm
could be
mentioned in the doc.
Or maybe it is there somewhere and I skimmed over it.
It's a a CGI.pm problem, really. We can't go and support a
