Should be a pretty simple question, looking for an option in header_out
to target a frame.
For example...
.
$r->err_header_out("Pragma", "no-cache");
$r->header_out('Location' => 'http://www.somesite.com/login_expired.html');
$r->status(REDIRECT);
$r->send_http_header;
Was hoping I could
Cory Omand wrote:
On Tue, 2004-11-02 at 16:19, Stas Bekman wrote:
Does your global httpd.conf has an AcceptMutex entry which specifies a
location which is only root accessible? So A-T should probably detect that
and rewrite the path to something local (e.g. t/logs/acceptmutex)?
The global httpd.
> Did you try #include'ing mod_ssl.h to pick up the optional function
> declarations rather than copy'n'pasting them? It should work OK with
> recent 2.0 releases.
just putting in
# include "mod_ssl.h"
gives
cc -c -I/apache/2.0.52/ssl/perl-5.8.5/include -D_REENTRANT -D_GNU_SOURCE
-DTHREADS_HA
On Tue, 2004-11-02 at 16:19, Stas Bekman wrote:
> Does your global httpd.conf has an AcceptMutex entry which specifies a
> location which is only root accessible? So A-T should probably detect that
> and rewrite the path to something local (e.g. t/logs/acceptmutex)?
The global httpd.conf file, w
Jean-Paul COGNET wrote:
I have tried using Env::C (from CPAN), without using a startup.pl script.
And it is the same behaviour.
Any idea ?
Thank you very much.
I've never used Oracle, so I can't really tell what the problem is. If you
could figure out how to reproduce it with something else I'd be
CALDWELL, JERAMIE W (SWBT) wrote:
Okay Stas, I appreciate the prompt response, here's the information you
asked for. First the output of t/REPORT, then the result of t/TEST
-no-httpd -v apr-ext/base64.t, & t/TEST -no-httpd -v apr/constants.t.
[...]
so both groups of failures fail for the same reas
Cory Omand wrote:
[... explanation snipped ...]
Does the above clarify where I'm coming from?
Yes, thanks for the explanation, Cory. Now I more or less understand what
is the problem.
Does your global httpd.conf has an AcceptMutex entry which specifies a
location which is only root accessible? S
On Tue, 2004-11-02 at 15:35, Stas Bekman wrote:
> Cory Omand wrote:
>
> [First of all, don't forget to reply-all, when following up on list's
> threads. Thanks.]
Sorry -- force of habit.
> >>It has nothing to do with either A-T or mod_perl, A-T just per-uses the
> >>globally installed httpd.co
Stas Bekman wrote:
[please don't forget to CC/reply-all the list]
sorry, i've hit the Send too quickly...
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.a
[don't forget to CC the list! Thanks]
Steven Mocking wrote:
> On Monday 01 November 2004 23:28, Stas Bekman wrote:
>
>>Steven wrote:
>>
>>>*** Makefile.PL options:
>>> MP_APR_LIB => aprext
>>> MP_COMPAT_1X => 1
>>> MP_GENERATE_XS => 1
>>> MP_LIBNAME => mod_perl
>>> MP_USE_DSO =>
[please don't forget to CC/reply-all the list]
Steven wrote:
On Sunday 31 October 2004 22:18, Stas Bekman wrote:
Steven, can you please tell me where did you see the suggestion to post
here the script t/REPORT and not the output of its execution? If it wasn't
clear in the help document, please sugg
Cory Omand wrote:
[First of all, don't forget to reply-all, when following up on list's
threads. Thanks.]
On Tue, 2004-11-02 at 14:44, Stas Bekman wrote:
Cory Omand wrote:
-8<-- Start Bug Report 8<--
1. Problem Description:
When running 'make test' as a non
Joe Orton wrote:
> On Tue, Nov 02, 2004 at 04:49:55PM -0500, Geoffrey Young wrote:
>
>>I've been meaning to take care of this since you mentioned it.
>>
>>http://www.modperlcookbook.org/~geoff/modules/Apache-SSLLookup-2.00_01.tar.gz
>>
>>I'll probably move it to cpan in the next day or so.
>
>
Cory Omand wrote:
-8<-- Start Bug Report 8<--
1. Problem Description:
When running 'make test' as a non-root user, apache fails to create the
default AcceptMutex. All tests fail, and the following is output to the
error_log:
[Tue Nov 02 17:16:22 2004] [emerg
-8<-- Start Bug Report 8<--
1. Problem Description:
When running 'make test' as a non-root user, apache fails to create the
default AcceptMutex. All tests fail, and the following is output to the
error_log:
[Tue Nov 02 17:16:22 2004] [emerg] (13)Permission
On Tue, Nov 02, 2004 at 04:49:55PM -0500, Geoffrey Young wrote:
> I've been meaning to take care of this since you mentioned it.
>
> http://www.modperlcookbook.org/~geoff/modules/Apache-SSLLookup-2.00_01.tar.gz
>
> I'll probably move it to cpan in the next day or so.
Very nice! Now can I just bo
On Mon, Nov 01, 2004 at 12:45:11PM -0600, David Nicol wrote:
> "proscribed?" are you sure?
>
> m-w.com says that word means
> 2 : to condemn or forbid as harmful or unlawful : PROHIBIT
Whoopsie, typo. :) I meant 'prescribe'. :) Thanks for the correction...
> > You don't use the database's auth
> The best thing to do is to use the ssl_var_lookup hook which the C
> interface to mod_ssl exports, or better yet, if using 2.0.51 or later,
> the ssl_is_https hook. This means you don't have to use "SSLOptions
> +StdEnvVars" to get SSL variables via subprocess_env, which adds a lot
> of overhea
Make sure you read:
http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems
and submit a proper bug report to help us solve your problem.
Stuart Scharf wrote:
I am trying to compile mod_perl on SuSE 9.0
with:
apache_1.3.33
mod_perl-1.29
mod_ssl-2.8.22-1.3.33
php-4.3.9
It all works
On Tue, 02 Nov 2004 18:51:20 +0100
Tom Schindl <[EMAIL PROTECTED]> wrote:
> Of course he is have you read the since tag in the docs? :-)
hehehe actually I hadn't, boy do I feel silly now...
-
Frank Wiles <[EMAIL PROTECTED]>
http://www.wiles.org
Frank Wiles wrote:
On Tue, 2 Nov 2004 11:24:40 -0500
Jason Dixon <[EMAIL PROTECTED]> wrote:
On Nov 2, 2004, at 11:15 AM, Frank Wiles wrote:
I'm thinking Apache::compat might be confusing it. Can you try
running without it?
Commented out Apache::compat, same error. :(
Unfortunately, I think
Having Just re-read your reply, (don't ask, waiting
for a machine sync to finish, bored...!) I noticed
that you said you didn't get an apache Object at all.
This is behaviour I've seen myself, and I never got a
decent understanding of why it happens?
So does anybody know under what circumstances
On Tue, 2 Nov 2004, Frank Wiles wrote:
> On Tue, 2 Nov 2004 10:44:41 -0500
> Jason Dixon <[EMAIL PROTECTED]> wrote:
>
> > On Nov 2, 2004, at 10:37 AM, Frank Wiles wrote:
> >
> > > I believe this is caused by a documentation bug I've yet to fix in
> > > Apache::DProf. Try preloading Apache2 in
On Tue, 2 Nov 2004 11:24:40 -0500
Jason Dixon <[EMAIL PROTECTED]> wrote:
> On Nov 2, 2004, at 11:15 AM, Frank Wiles wrote:
>
> > I'm thinking Apache::compat might be confusing it. Can you try
> > running without it?
>
> Commented out Apache::compat, same error. :(
Unfortunately, I think
On Nov 2, 2004, at 11:15 AM, Frank Wiles wrote:
I'm thinking Apache::compat might be confusing it. Can you try
running without it?
Commented out Apache::compat, same error. :(
Thanks,
--
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net
--
Report problems: http://perl.apache.org/bu
On Tue, 2 Nov 2004 11:03:11 -0500
Jason Dixon <[EMAIL PROTECTED]> wrote:
> On Nov 2, 2004, at 10:59 AM, Frank Wiles wrote:
>
> > H... ok try adding Apache::ServerUtil in your startup.pl, I
> > may have written down Apache2 as the fix, but it might really be
> > Apache::ServerUtil.
>
>
Okay Stas, I appreciate the prompt response, here's the information you
asked for. First the output of t/REPORT, then the result of t/TEST
-no-httpd -v apr-ext/base64.t, & t/TEST -no-httpd -v apr/constants.t.
-8<-- Start Bug Report 8<--
1. Problem Descript
On Nov 2, 2004, at 10:59 AM, Frank Wiles wrote:
H... ok try adding Apache::ServerUtil in your startup.pl, I
may have written down Apache2 as the fix, but it might really be
Apache::ServerUtil.
Unfortunately, that didn't work either. Here's my startup.pl:
[EMAIL PROTECTED] root]# cat /var
On Tue, 2 Nov 2004 10:44:41 -0500
Jason Dixon <[EMAIL PROTECTED]> wrote:
> On Nov 2, 2004, at 10:37 AM, Frank Wiles wrote:
>
> > I believe this is caused by a documentation bug I've yet to fix in
> > Apache::DProf. Try preloading Apache2 in your startup.pl and it
> > should work for you.
>
On Tue, 2004-11-02 at 10:45, Jason Dixon wrote:
> Unfortunately not. The client has mandated that we stick with the RHEL
> package for "supportability".
That's precisely the reason you shouldn't stick with the RHEL package.
The version of mod_perl they ship is ancient and hard for the mod_perl
On Nov 2, 2004, at 10:35 AM, Perrin Harkins wrote:
On Tue, 2004-11-02 at 10:30, Jason Dixon wrote:
My server runs Apache 2.0.46 with
mod_perl 1.99 and Apache::DProf 0.09.
Can you re-try with the latest? The current apache release is 2.0.52
and the current mod_perl release is 1.99_17.
Unfortunately
On Nov 2, 2004, at 10:37 AM, Frank Wiles wrote:
I believe this is caused by a documentation bug I've yet to fix in
Apache::DProf. Try preloading Apache2 in your startup.pl and it
should work for you.
Hi Frank-
I'm still getting the error:
Starting httpd: [Tue Nov 02 10:42:26 2004] [error] Ca
On Tue, 2 Nov 2004 10:30:32 -0500
Jason Dixon <[EMAIL PROTECTED]> wrote:
> Note: Folks on perlmonks might recognize this post from last night.
> There have been no responses, so I'm posting it to the mod_perl list.
>
> I'm trying to profile some perl CGI someone else wrote, but I can't
> seem
On Tue, 2004-11-02 at 10:30, Jason Dixon wrote:
> My server runs Apache 2.0.46 with
> mod_perl 1.99 and Apache::DProf 0.09.
Can you re-try with the latest? The current apache release is 2.0.52
and the current mod_perl release is 1.99_17.
- Perrin
--
Report problems: http://perl.apache.org/bu
Note: Folks on perlmonks might recognize this post from last night.
There have been no responses, so I'm posting it to the mod_perl list.
I'm trying to profile some perl CGI someone else wrote, but I can't
seem to get Apache::DProf working. My server runs Apache 2.0.46 with
mod_perl 1.99 and
Hello and many thanks to Martin and Geoffrey,
Martin was right - using "Dump" revealed that only "Our::Auth" was passed as
an input variable (and the request was not passed at all). After I changed
"PerlAuthenHandler Our::Auth->authen_handler" to "PerlAuthenHandler
Our::Auth::authen_handler", the
> This code works OK in RedHat but cannot find "get_basic_auth_pw" in SGI.
> Still, my feeling is that that something simple but imporant is omitted
> in the code.
no, the code looks fine. the issue isn't that get_basic_auth_pw() can't
generally be found, but that $r isn't an Apache object, so y
Hi Marina,
Can you post a bit of your http.conf which declares
your AuthHandler's usage?
Are you saying:-
PerlAuthHandler Our::Auth->authen_handler
or
PerlAuthHandler Our::Authen::authenhandler
I ran some code across SuSe and Redhat and noticed
different behviours for using "->".
If you use "-
Hello Geoffrey,
Thank you for your answer; but I have to ask you for more help
as I neither use a pre-build version nor work with subclassing.
The handler code is very simple:
package Our::Auth;
use strict;
use Apache;
use Apache::Constants qw(:common);
use mod_perl ();
sub authen_handle
I have tried using Env::C (from CPAN), without using a startup.pl script.
And it is the same behaviour.
Any idea ?
Thank you very much.
The script is now :
use DBI;
use DBD::Oracle;
use CGI;
use Env::C;
Env::C::setenv('NLS_LANG', 'french_fr
I'm trying to migrate from plain file authentication (AuthType Basic) to
a DBM type (AuthDBMType).
In our system, the only DBM authentication we had was SDBM, but we
discovered that we can't use it because in our application a user may
belong a quite a lot groups at the same time and it seems t
41 matches
Mail list logo
