Peter Hartzler wrote:
Hello,
We're looking into using your Apache::AuthenSmb module to allow us to
migrate our intranet to GNU/Linux/Apache. One issue we have is that we
have two NT domains. I have a couple of different ideas for how to modify
the code to allow this scenario, and am wondering
Hi,
1 - You must be aware, by now, that your machine is infected. Please
install and run a recented/updated antivirus. The fact that your question
contained a virus is a good reason why nobody answered it.
2 - This list is for mod_perl questions; asking about a particular
module is OT
The only thing that puzzles me about this thread is that it seems to be
leaning towards the position that says;
If the developer just does straight out weird stuff and messes with
$r-status in a cgi-script and expects it to work with Apache::Registry
(which as far as I understand is a cgi
OK, so we are not done with it.
The first thing I'd like to see is to have Apache::Registry and
Apache::PerlRun agree on how they handle return codes, because they
aren't the same. Once this happens, the Cooker will do the same.
As you have mentioned we have a problem with relying on return
Geoffrey Young wrote:
OK, so we are not done with it.
The first thing I'd like to see is to have Apache::Registry and
Apache::PerlRun agree on how they handle return codes, because they
aren't the same. Once this happens, the Cooker will do the same.
As you have mentioned we have a problem
The logic here is simpler:
1. store the new status code (just in case the script has changed it)
2. reset the status code to the one before the script execution
3. if the script has attempted to change the status by itself and the
execution status is Apache::OK return that new status.
Geoffrey Young wrote:
The logic here is simpler:
1. store the new status code (just in case the script has changed it)
2. reset the status code to the one before the script execution
3. if the script has attempted to change the status by itself and the
execution status is Apache::OK return
Stas Bekman wrote:
Geoffrey Young wrote:
The logic here is simpler:
1. store the new status code (just in case the script has changed it)
2. reset the status code to the one before the script execution
3. if the script has attempted to change the status by itself and
the execution status
David Dick wrote:
[...]
The only thing that messed me up was when running a script with mod_cgi,
you can return your own status codes and apache will happily go along
with it. However, when you run the same script under mod_perl's
Apache::Registry, you suddenly get Apache::Registry second
alrightly, back again. The problem is that Apache::Registry will return
a 206, which will trigger the error message. In case there is anyone
out there as daft as me :), the crude delegation-type module below can
solve this problem. Maniacs who see a need to return 204's, etc can
probably
David Dick wrote:
alrightly, back again. The problem is that Apache::Registry will return
a 206, which will trigger the error message. In case there is anyone
out there as daft as me :), the crude delegation-type module below can
solve this problem. Maniacs who see a need to return 204's,
If I'm correct both Apache::PerlRun and Apache::Registry will have
problems in certain situations if we agree that ModPerl::Registry has
the correct logic for handling the execution status. If you can tell
otherwise please give me a test script that doesn't work under
ModPerl::Registry.
But in
Hi there,
On Sun, 2 Feb 2003, David Dick wrote:
Got a bit of a weird set of behaviour with a mod_perl Apache::Registry
type script.
[snip]
More information about this error may be available
in the server error log.P
[snip]
Anyone got any ideas?
What does it say in the error_log?
73,
Ged.
Good Point. Forgot to mention that the error log is completely empty. :)
Ged Haywood wrote:
Hi there,
On Sun, 2 Feb 2003, David Dick wrote:
Got a bit of a weird set of behaviour with a mod_perl Apache::Registry
type script.
[snip]
More information about this error may be
Hi there,
On Sun, 2 Feb 2003, David Dick wrote:
Forgot to mention that the error log is completely empty. :)
Are you getting core dumps?
73,
Ged.
not even getting a broken connection. So somehow mod_perl doesn't
_really_ think it's an error.
Ged Haywood wrote:
Hi there,
On Sun, 2 Feb 2003, David Dick wrote:
Forgot to mention that the error log is completely empty. :)
Are you getting core dumps?
73,
Ged.
Hi again,
On Mon, 3 Feb 2003, David Dick wrote:
not even getting a broken connection. So somehow mod_perl doesn't
_really_ think it's an error.
Check out DEBUGGING in 'perldoc Apache::Registry'.
Apache::Registry won't always return what you'd think it should.
This has snookered more than
Tom Hibbert wrote:
Hi,
I downloaded the mod-perl 2.0 tarball today from:
http://perl.apache.org/dist/mod_perl-2.0-current.tar.gz
When I untar'd it:
bash-2.03$ tar xf mod_perl-2.0-current.tar
It extracted to the following directory:
drwxr-x--- 13 software software 512 Jun
From: mike808 [mailto:[EMAIL PROTECTED]]
Sent: 24 July 2002 05:54
To: Lincoln Stein; Cope, Greg; [EMAIL PROTECTED]
Subject: Re: possible buget in CGI.pm
Lincoln, Greg, mod_perl list:
The problem appears to be that the -no_xhtml option is only
processed in
_setup_symbols
Hi,
* [EMAIL PROTECTED] [EMAIL PROTECTED] [2002-07-23 11:26]:
We are implementing mod_perl here for internal intranet use. We have
discovered a possible buglet in CGI.pm.
We do not want CGI.pm to return XHTML as it upsets Verity indexing
(long story).
So sorry to hear about that.
So in
-Original Message-
From: darren chamberlain [mailto:[EMAIL PROTECTED]]
Can someone confirm this?
Yes:
Good I'm not mad :-)
From CGI.pm, version 2.81:
35 # Here are some globals that you might want to
adjust
36 sub initialize_globals {
37 # Set
I'm aware of the problem, but I haven't been able to track it down. Any help
is welcome.
Lincoln
On Tuesday 23 July 2002 08:27 am, [EMAIL PROTECTED] wrote:
Hi All,
We are implementing mod_perl here for internal intranet use. We have
discovered a possible buglet in CGI.pm.
We do not
On Tuesday 23 July 2002 08:27 am, [EMAIL PROTECTED] wrote:
We do not want CGI.pm to return XHTML ...
So in Apache::Registry executed scripts we use:
use CGI qw( -no_xhtml );
But on the first invocation it returns normal HTML. On second invocation
it ignores this directive and
mod_perl. If you're using mod_perl
regardless, then it really comes down to what tools you feel happiest
with.
Andrew
On 11 Jun 2002, simran wrote:
Date: 11 Jun 2002 14:02:59 +1000
From: simran [EMAIL PROTECTED]
To: Marc Slagle [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Possible
On Fri, 6 Jul 2001, Stef Telford wrote:
Hello,
I hope this is the right place to put this. I have some code that takes data
from a database and encrypts it via Blowfish and CBC. Not a problem so far,
the problems comes with sending it to the client.
...
Now, if i look at the
If you build modperl with 'perl Makefile.PL EVERYTHING=1' (or, at least
with 'PERL_SSI=1', then your server side includes will have an additional
option that looks like this:
!--#perl sub="DoSomething"--
This will invoke routine 'DoSomething' when this page is expanded.
You'll need to
Here's another way around it. You could use HTML::Template in place of SSI.
Jamie
-Original Message-
From: Surat Singh Bhati [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 25, 2001 7:28 AM
To: [EMAIL PROTECTED]
Subject: possible solution for "exec cgi SSI" in mod_perl
Hi,
I am
-Original Message-
From: Michael J Schout [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 18, 2000 2:54 PM
To: [EMAIL PROTECTED]
Subject: Re: possible bug in mod_perl 1.24_01
I should also have mentioned:
I am using perl 5.6.0, Linux 2.2.x
I have the same config
I should also have mentioned:
I am using perl 5.6.0, Linux 2.2.x
I used the same perl / os for both apache1.3.12/mod_perl 1.24, and apache
1.3.14/mod_perl 1.24_01.
Mike
On Thu, 28 Sep 2000, Adi wrote:
As it turns out, the second call to My::ProxyAccessOnly is an internal
redirect
...
Is there a logical reason why PerlAccessHandler should be called twice, the
because internal_redirects are implemented with subrequests and
subrequests run all phases (except
Vincent Bruijnes wrote:
Dear mod_perl users.
Is it possible to have an apache with --enable-shared=max and mod_perl
statically linked?
If yes please tell me how to do, i need mod_perl statically cause otherwise
my Apache::ASP won't work.
Sincerely Vincent Bruijnes
[EMAIL PROTECTED]
Yes, I do it
Support for strings represented as a vector of ordinals
Literals of the form Cv1.2.3.4 are now parsed as a string composed
of characters with the specified ordinals. This is an alternative, more
readable way to construct (possibly unicode) strings instead of
interpolating characters, as in
On Tue, 28 Mar 2000, Dave Seidel wrote:
and now everything is working correctly. What I don't undetrstand is that
the original code was identical in mod_perl 1.21, but I didn't have this
problem. Could this be due to some internal change in Perl 5.6?
probably, thanks for the fix!
[EMAIL PROTECTED] (Robert Locke) wrote:
Below is a proposed patch to AuthCookie.pm that I believe solves this
problem. Basically, I replaced each occurrence of the above with:
$r-err_headers_out-add("Set-Cookie" = ...
I think you've got the patch backwards.
PS. Who's the current maintainer
34 matches
Mail list logo
