The uploaded file
Apache-AuthCookie-3.02.tar.gz
has entered CPAN as
file: $CPAN/authors/id/M/MS/MSCHOUT/Apache-AuthCookie-3.02.tar.gz
size: 29015 bytes
md5: 107408d13a43cfbe2d2eccce40adffbe
Changes:
---
Version: 3.0
On Thu, 13 Jun 2002, Brian Reichert wrote:
> Apache::AuthTicket says:
>
>Finally, by using the Secure mode of Apache::AuthCookie, the
>ticket is not passed over unencrypted connections.
>
> Passed in what direction?
Client -> server.
rfc2109 says:
Secure
Optional. The Secure
On Thu, 2 May 2002, Per Einar Ellefsen wrote:
> At 21:25 02.05.2002, Peter Rothermel wrote:
> >greetings,
> >
> >Has anybody had any luck getting Apache-AuthCookie going
> >on an Apache 2.0 / mod_perl 1.99 setup? The first thing that
> >I hit was $r->connection->user is deprecated. I've changed t
The uploaded file
Apache-AuthCookie-3.00.tar.gz
has entered CPAN as
file: $CPAN/authors/id/M/MS/MSCHOUT/Apache-AuthCookie-3.00.tar.gz
size: 25399 bytes
md5: 5c94e0ced442653f229b39f4f1fcfe8c
Changes since v2.011:
- New maintiner: Michael Schout <[EMAIL PROTECTED]>
- changed to
I can verify for you that this is a problem.
You wouldnt happen to be using Apache::Filter would you?
I've posted this problem at least once over the past year, and I have seen it
posted by others. I had this porblem trying to oepn3() a pipe to gnupg and
encrypt some data. I later switched to t
The uploaded file
Apache-AuthTicket-0.31.tar.gz
has entered CPAN as
file: $CPAN/authors/id/M/MS/MSCHOUT/Apache-AuthTicket-0.31.tar.gz
size: 11958 bytes
md5: b5224689b7823eb54b6e4f8190a20d69
No action is required on your part
Request entered by: MSCHOUT (Michael Schout)
Request ente
I have isolated a problem in section processing that I have been
encountering. Basically there are situations where one particular entry in
%Location or %LocationMatch causes the *NEXT* entry to fail to configure
properly.
I have a standard httpd configuration, and then the following mod_perl
c
I've been scratching my head on this for quite a while and I cant seem to
figure it out. I have a very stripped down configuration, which only contains
the following section:
use Apache::Status;
$Location{"^/perl-status-1\$"} = {
SetHandler => 'perl-script',
PerlHandler => 'Apache::Statu
Hi.
I'm using HTML::Template v2.0, IPC::SharedCache 1.3, IPC::ShareLite 0.08,
Storable 1.0.6. I've discovered that if I turn on the "global_vars" option in
HTML::Template, then Storable cant serialize the template so that it can be
placed in the cache.
e.g.:
my $tmpl = HTML::Template->new_fil
About a month or 2 ago, I had posted a problem where I tried to upgrade from:
Redhat Linux 6.2,
perl 5.6.0
Apache 1.3.12
mod_perl 1.24
mod_ssl 2.6.6
to
Redhat Linux 6.2
perl 5.6.0
Apache 1.3.14
mod_perl 1.24_01
mod_ssl 2.7.1
And reported that after doing this, my httpds would spin on startup.
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
I have had an application working under apache 1.3.12/mod_perl 1.24 for several
months now with no problems.
I am currently trying to make the jump to apache 1.3.14/mod_perl 1.24_01 (since
mod_perl 1.24 will not easily build agains 1.3.14). When I do this, and then
try to start apache, it goes i
On Tue, 10 Oct 2000, Matt Sergeant wrote:
> On Mon, 9 Oct 2000, Herrington, Jack wrote:
>
> > This allows for XML parsing with no change to the Perl code. I'm just not
> > sure what I am losing in Apache (which is where I make the change). What
> > does losing EXPAT do to Apache?
>
> You lo
On Wed, 16 Aug 2000, Matt Sergeant wrote:
> On Tue, 15 Aug 2000, Mark D. Anderson wrote:
>
> > The problem was the symbol conflict between XML::Parser and apache when
> > built with expat. This has been apparently known for over a year, but has
> > still not been fixed last i checked, presumably
Ok.
Turns out that what the real problem here was that CGI::Application uses
CGI::Carp, and I needed a newer version of CGI::Carp.
So I seem to have sovled this :)
Mike
On Wed, 19 Jul 2000, Michael J Schout wrote:
> I have been trying to get CGI::Application to work under mod_perl today.
I have been trying to get CGI::Application to work under mod_perl today. So
far with no success.
Finally I removed everything except CGI::Application from the config files, and
the server dumps core on startup.
I have a very stripped odwn httpd.conf that basically loads the bare minimum
apache
On Tue, 18 Jul 2000, davidu wrote:
>
> Hi,
>
> Our company, like.com, has been looking for some experianced mod_perl
> coders. We have checked most of the major job sites, including guru.com
> and have not come across any that have real skills. Where do all the
> mod_perl coders hang out?
T
I guess I will chime in on this since we have dealt with this very same issue.
The problem that we have is that there are a handful of production boxes, a
handful of staging boxes (testing release candidates etc), and a handful of
developer boxes.
Our goal was to make it as easy as possible to g
The uploaded file
Apache-AuthTicket-0.20.tar.gz
has entered CPAN as
file: $CPAN/authors/id/M/MS/MSCHOUT/Apache-AuthTicket-0.20.tar.gz
size: 11591 bytes
md5: e2f84546aa18b7afb1c8aead5ea3365f
Release 0.20
o Renamed module from Apache::TicketAccess to Apache::AuthTicket.
o Adapt
Ok I think I might have figured this one out.
If I treat the keys of %Location as regexps I sseem to get the desired results
:).
e.g.: '^/foo$', '^/bar/foo$'
Maybe this shold be documented in the guide better?
Mike
I'm having some issues with sections. Basically what I have is a setup
like this:
httpd.conf:
my %handlers = (
'/foo' => { HANDLER => 'GKG::Foo', FILTER => 1 },
'/bar/foo' => { HANDLER => 'GKG::FooBar' }
);
for my $i (keys %handlers) {
my %conf = %{$handlers
Hi.
I would like to use a CHECK { } block under mod_perl, but have so far not had
any luck. It seems like mod_perl does not know how to deal with CHECK { }
blocks. Is this true? If so, can it be remedied? I cant use a BEGIN block
for what I am doing because it must happen after compilation i
On Mon, 19 Jun 2000, Matt Sergeant wrote:
> On Sun, 18 Jun 2000, Michael J Schout wrote:
>
> > On Tue, 13 Jun 2000, Erich L. Markert wrote:
> >
> > > I'm trying to figure out the best way to make apps (un)available without
> > > having to edit
On Tue, 13 Jun 2000, Erich L. Markert wrote:
> I'm trying to figure out the best way to make apps (un)available without
> having to edit the apache config files.
We did something like this by making a handler like this:
package Foo::PerlHandler;
use Class::MethodMaker
new_with_init =>
On Fri, 16 Jun 2000 [EMAIL PROTECTED] wrote:
> Hi,
>
> my open2 script failes to work under mod_perl with perl v5.6.0. Works correctly
> outside of the 5.6.0-mod_perl environment but works with mod_perl-5.005_03.
...
I have the exact same problem using IPC::Open3 under perl 5.6.0/mod_perl 1.24
Apache-TicketAccess-0.10.tar.gz
has entered CPAN as
file: $CPAN/authors/id/M/MS/MSCHOUT/Apache-TicketAccess-0.10.tar.gz
size: 9388 bytes
md5: 42a00ba96205ead6a0d03cb25903bae6
This is the inital version of Apache::TicketAccess. This version does not yet
subclass Apache::AuthCookie, b
Sorry if this is slightly off topic.
I seem to have run into problems using IPC::Open3 under mod_perl 1.22 and perl
5.6.0. This probelm only seems to have cropped up after I upgraded form perl
5.005 to perl 5.6.0. What happens is I have an exception handler that opens
gpg and uses gpg to encryp
Hi.
I seem to have run into some issues since I upgraded to perl 5.6.0. Since
doing this, I recompiled all of my modules (I removed /usr/lib/perl5 and
started fromscratch). I also recompiled apache/mod_perl so everything was
linked against the properl libperl.
Im using:
apache 1.3.12
mod_perl
28 matches
Mail list logo