Re: Is mod_perl for web app still active today?
On Sep 19, 2022, at 11:07 PM, Ken Peng wrote: > May I know if mod_perl is still active on web development today? I'm not sure what you're asking. Do some people still use it for web development? Yes, most definitely. However, I think it's safe to say it's declined in popularity compared to other Perl web development frameworks such as Plack and Mojolicious and obviously other non-Perl web frameworks, but it's still used by some web developers. Is mod_perl still maintained? Yes. The latest release (2.0.12) was released in late January 2022. Later, Ed
Re: Experience running mod_perl2 with mpm_event on Solaris 11
On Aug 26, 2022, at 1:16 PM, Joe Schaefer wrote: > AFAICT you guys are just too lazy to look. That came across as rude, Joe. Not all of us are experts at Perl internals or track the latest changes to Perl's ithread support and/or glibc, and it's generally been accepted in the mod_perl community for years that mod_perl only works reliably with mpm_prefork. To the best of my recollection, there haven't been any reports of mod_perl working under mpm_event prior to your messages about using it on Solaris a couple weeks ago. But thank you for sharing your knowledge and experiences. It does seem well worth exploring. Regards, Ed
Re: Config errors when building mod-perl-2.0.12
On Aug 20, 2022, at 8:54 AM, Mehul Sanghvi wrote:
> Since there seems to be activity on the mailing list, I’m re-posting the
> below query, in case it was missed earlier.
I looked at this when you posted it previously, but I couldn't find the cause
and neglected to subsequently follow up. (To be clear, I'm just an interested
mod_perl user, not an Apache committer.)
What operating system is this on? I don't think you ever said, but maybe I
missed it.
It looked like everything worked up until you issued the command:
> perl Makefile.PL MP_AP_PREFIX=${fakeroot_dir}${app_dir}
> MP_AP_DESTDIR=${DESTDIR} DESTDIR=${DESTDIR}
Is that right?
When I compiled mod_perl 2.0.11 from source, I used this command:
perl Makefile.PL MP_APXS=/my/path/to/bin/apxs
That worked for me, but I haven't tried to compile mod_perl 2.0.12, tbh.
(Haven't seen a reason to upgrade.) However, I reported a possibly related
problem with an Apache installation in a non-standard directory when I tested
the release candidate of Apache::Test 1.43. At the time I was told my issue
would be addressed later, but it hasn't been (yet). And mod_perl 2.0.12
includes Apache::Test 1.43, AFAIK, so I'm not very surprised. I had to hack the
source for Apache::Test to get it to work with my Apache httpd installation.
My first suggestion is to determine if your command works with the mod_perl
2.0.11 source. If so, I feel you definitely have found a regression from
2.0.11, and you should file a bug in the issue tracker, please.
Next, I would suggest dropping one or both of the "*DESTDIR" options from your
"perl Makefile.PL" command to see if that makes any difference and possibly
experiment with "MP_APXS=/path/to/your/bin/apxs" instead of "MP_AP_PREFIX=...".
Just some ideas
Hope this helps,
Ed
Re: Experience running mod_perl2 with mpm_event on Solaris 11
Very interesting, Joe! Thank you for sharing your insights into this and experience with it. Here’s hoping someone can solve/fix the problem with mod_perl threads on Linux. Regards, Ed On Aug 19, 2022, at 1:44 PM, j...@sunstarsys.com wrote: > The problem is really confined to embedded uses of ithreads, because Perl > itself will mutex-wrap the malloc calls. In httpd, so do all apr_pool_t > calls to malloc. It's when the two memory management techniques are > interacting that there is no application-level way to guard against thread > contention in libc's malloc. > > Mod_perl+ithreads are awesome, when used intelligently. You gain intelligence > from experience trying to use it in a lot of ways that suck, until you hit > one the path that yields success.
Re: :Sealed subs for typed lexicals
On Aug 16, 2022, at 11:12 AM, j...@sunstarsys.com wrote: > Here’s some more fun I’ve been grinding out for the mod_perl community. > Unfortunately I haven’t resolved all the issues with using this stuff in a > mod_perl+ithread runtime, but if you figure out the right incantation please > let me know: > > https://sunstarsys.com/essays/perl7-sealed-lexicals This looks great, Joe! Could be a real game-changer for mod_perl. I shall follow your development with interest. Thanks, Ed
Re: Experience running mod_perl2 with mpm_event on Solaris 11
On Aug 16, 2022, at 12:27 PM, j...@sunstarsys.com wrote: > To the best of my knowledge, the underlying problem with mod_perl+ithread is > that it requires a reentrant malloc in libc. That's it? This is the first I'm learning this. Is there an option to compile Perl and mod_perl with a reentrant malloc on Linux? Thanks, Ed
Re: PerlAccessHandler for POST access
On Aug 4, 2022, at 5:09 AM, pengyh wrote:
>> LoadModule apreq_module modules/mod_apreq2.so
>> in your httpd.conf?
>
> yes. as you see:
> lrwxrwxrwx 1 root root 27 Aug 4 14:00 perl.load ->
> ../mods-available/perl.load
> lrwxrwxrwx 1 root root 29 Aug 4 14:01 apreq2.load ->
> ../mods-available/apreq2.load
>
>
>> Have you tried it with mpm_prefork?
>
> the development environment is mpm_prefork.
>
>> What version of Apache and mod_perl are you using exactly?
>
> Apache/2.4.41 (Ubuntu) mod_apreq2-20101207/2.8.0 mod_perl/2.0.11 Perl/v5.30.0
> configured
>
>
> ubuntu 20.04 x64 OS.
I presume you installed these things using apt-get? Is Apache2::Request version
2.16?
I apologize in advance if the following suggestions are obvious things you've
already tried:
Could you try changing the handler to log or display the values of $ts and
$key? What do they contain if anything?
I'd log or display $r->as_string as well.
Also, try putting an eval { } block around the code inside your handler and
then log or display the value of $@.
Something like this:
package MyApacheAccessHandler;
use strict;
use Apache2::RequestRec ();
use Apache2::RequestIO ();
use Apache2::Connection ();
use APR::Table ();
use Apache2::Const -compile => qw(OK FORBIDDEN);
use Apache2::ServerUtil ();
use Apache2::Log ();
use Apache2::Request;
use Digest::MD5 qw(md5_hex);
sub handler {
my $r = shift;
my $s = Apache2::ServerUtil->server;
eval {
$s->log_error("r = ", $r->as_string);
my $req = Apache2::Request->new($r);
my $ts = $req->param("timestamp");
my $key = $req->param("authkey");
my $digest = md5_hex($ts);
$s->log_error("ts = ", $ts);
$s->log_error("key = ", $key);
$s->log_error("digest = ", $digest);
};
if ($@) {
$s->log_error("exception: ", $@);
}
return $key eq $digest ? Apache2::Const::OK : Apache2::Const::FORBIDDEN;
}
After testing the above, what's does the error_log file show?
Later,
Ed
Re: PerlAccessHandler for POST access
> On Aug 4, 2022, at 3:29 AM, pengyh wrote: > OK as you can test this GET works: > > http://fb.cloudcache.net/?timestamp=12345=906434463477769dba188a4b670ef425 > > but this POST doesn't work: > > curl -X POST -d 'timestamp=12345' \ >-d 'authkey=906434463477769dba188a4b670ef425' \ >http://fb.cloudcache.net/ > > The server responds with: > > Forbidden > You don't have permission to access this resource. > > So how to fix it? Hmmm Do you have LoadModule apreq_module modules/mod_apreq2.so in your httpd.conf? Have you tried it with mpm_prefork? What version of Apache and mod_perl are you using exactly? Later, Ed
Add Contributing file? (was Re: unwanted setlocale() interaction between mod_php and mod_perl2)
On Nov 23, 2021, at 3:34 AM, Steve Hay wrote: > The mod_perl bug tracker is > https://rt.cpan.org/Dist/Display.html?Name=mod_perl, which can be > accessed from the "Issues" link in the left-hand menu at the > metacpan.org page, https://metacpan.org/pod/mod_perl2. (I think you > need to log in to an account on rt.cpan.org to actually report bugs > there.) This probably ought to be documented better somewhere. I will > add a note to the README file at least. While you are modifying the README, could you add a CONTRIBUTING or CONTRIBUTING.md or Contributing.pod file as well? This would make it so that the "How to Contribute" link in the left sidebar on the metacpan.org page would display something useful. Personally, this is always the first link I check when I want to submit a patch or issue on something Perl-related. Compare https://metacpan.org/dist/mod_perl/contribute to https://metacpan.org/dist/DBD-Pg/contribute, e.g. This file should document how to check out the source code repository, how and where to submit patches, where to file issues, etc. I think it would be extremely useful, and it doesn't need to be anything elaborate. You could just copy https://raw.githubusercontent.com/bucardo/dbdpg/master/CONTRIBUTING.md and make some edits to that. Thanks, Ed
Re: Problem compiling mod_perl on AIX
On Jul 6, 2021, at 2:49 AM, Rainer Tammer wrote: > I do have a problem compiling mod_perl 2.0.8, 2.0.10 or 2.0.11 on AIX 7.1/7.2. > I did not have this problem in the past (older AIX and older AIX system Perl > v5.10.1). > The current system Perl version on AIX is 5.28.1. [...] > make: 1254-002 Cannot find a rule to create target static from dependencies. Well, I googled that error message, and I saw that another person reported the exact same "make" error when compiling mod_perl 2.0.2 on AIX 5.2 on 07 Feb 2006. There was no follow-up with a solution. Another person also reported the same "make" error with AIX 6.1 when compiling mod_perl 2.0.10 with Perl 5.26.1 on 15 Nov 2017. No reply then either. Do a Google search for details. You might try emailing the person who posted in 2017 and see if they were ever able to get it to compile. https://www.perzl.org/aix/index.php?n=Main.ModPerl has a mod_perl 2.0.7 package for AIX 5.1. So, yeah, it looks to be a long-standing problem. :-( Make sure you've read through https://perldoc.perl.org/perlaix to see if any of that applies. I see a suggestion there that says to compile Perl with gcc. It might be worth trying that and then compiling mod_perl with gcc too. Good luck. If you find a solution, please come back and post it for future AIX users. Regards, Ed
Re: Prototype Mismatch in ModPerl::PerlRun
Hi, Daniel. This error can happen even under regular Perl in some circumstances when a package redefines a core function ((like what importing Time::HiRes does here with time). I would change "use Time::HiRes qw(time);" to "use Time::HiRes ();" and then change "time()" on line 13 to "Time::HiRes::time()." Does that make the message go away? Even better would be to move or add "use Time::HiRes ();" to your startup.pl. I think it's generally a good idea (I want to say "best practice" even) to not import any functions or variables in your startup.pl, so I always add " ()" to my "use" statements there. You can then *usually* import specific functions with "use Whatever qw(func);" in your scripts. The problem here though is that the import is redefining the core function, and I think that can just be problematic. I think the moral here is that ModPerl::PerlRun* is not a perfect drop-in replacement for a Perl CGI. With mod_perl, there's usually something you need to tweak (like how global variables and things like that) slightly in order to get it working as intended, but the changes are usually minor and make sense once you wrap your head around how mod_perl works. Hope this helps! Regards, Ed On May 14, 2021, at 9:36 AM, Daniel Ragle wrote: > I'm investigating short term solutions for site performance (long term is a > full rewrite of the app) and I'm working for the first time with > ModPerl::PerlRun (and ModPerl::PerlRunPrefork, both seem to exhibit the same > behavior) and feel like I'm missing something obvious. > > I have this reduction (as test2.pl): > > > #!/usr/bin/perl > > use strict; > use warnings; > > use Time::HiRes qw(time); > > use CGI; > my $cgi = CGI->new(); > > print $cgi->header(); > print "Hello World\n"; > print "HiRes time is: ", time(), "\n"; > # > > The script runs properly as far as I can see, but I'm getting Prototype > Mismatch warnings in the log with each hit after the first one: > > Prototype mismatch: sub > ModPerl::ROOT::ModPerl::PerlRunPrefork::var_www_test_test2_2epl::time: none > vs () at /var/www/test/test2.pl line 6.
Re: [DISCUSS] The future of mod_perl
On Mar 17, 2021, at 3:40 PM, Sander Striker wrote: > If you are interested in seeing mod_perl remain an active project, and are > able to help maintain and provide oversight, please respond in this thread > indicating that you are interested in performing the duties of a PMC > member[2]. I am, but I'm not currently a committer, fwiw. https://github.com/esabol Regards, Ed
Re: [ANNOUNCE] libapreq2-2.15 Released
Thanks, Joe, for your efforts with this release! Should there be a v2_15 tag in http://svn.apache.org/viewvc/httpd/apreq/tags/ ? FWIW, I successfully compiled and tested it with Apache httpd 2.4.41 and mod_perl 2.0.11 on CentOS 6.10. My httpd and mod_perl are 32-bit/i686 for silly legacy reasons I won't get into. Previous build systems detected this and added "-m32" automatically where appropriate, but, when building libapreq2-2.15, I had to explicitly specify CFLAGS=-m32 to get it to build and test properly. No big deal. I realize compiling for 32-bits on a 64-bit system is very much an edge case, and the workaround is simple enough. I was wondering about the following test results: t/cgi.t .. skipped: cannot find one of cgi.c or cgid.c and t/apreq/cgi.t skipped: cannot find one of cgi.c or cgid.c I went back and checked my build of libapreq2-2.13 and it does the same thing, so I guess that's fine? Can anyone explain why the cgi.c isn't included though? Thanks! Regards, Ed
Re: Apache2::Cookie and SameSite
On Sep 7, 2020, at 11:28 AM, Andrew Green wrote:
> I’d like to be able to set SameSite=Strict on a cookie generated using
> Apache2::Cookie, but if I simply try to set that parameter, I get the
> following error:
>
> Can't locate object method "SameSite" via package "Apache2::Cookie”
>
> Is it possible?
Try the following:
$cookie->set_attr('SameSite' => 'strict');
Let me know if that works for you.
Regards,
Ed
Re: Apache2:AuthCookie With httpd 2.4
On May 11, 2020, at 8:58 AM, Scott Alexander wrote: > I've included using > https://manpages.debian.org/unstable/libapache2-authcookie-perl/Apache2_4::AuthCookie.3pm.en.html > as an example > > # In httpd.conf or .htaccess: > PerlModule Sample::Apache2::AuthCookieHandler > PerlSetVar WhatEverPath / . > > to my ssl.conf file > > No changes made to httpd.conf or ssl.conf. Those two statements seem to be conflicting? I keep my authentication/authorization information in httpd.conf, personally. > When trying to access the page I get the errors above. That sample configuration from the POD assumes that you are subclassing Apache2::AuthCookie and that the name of your subclass is Sample::Apache2::AuthCookieHandler. It's meant to be illustrative. I'm guessing you don't actually have such a subclass. Try just removing the "Sample::" part. You can probably also find working examples in the tests in the "t" subdirectory. > I've read this > https://metacpan.org/pod/distribution/Apache-AuthCookie/README.apache-2.4.pod > which unfortunately doesn't make sense to me. That POD is meant for people developing (or porting from Apache 2.2.x) their own Perl modules for doing authentication and authorization under Apache 2.4.x. AuthCookie already handles all of this for you, assuming you only need or use AuthCookie. It might apply if you are subclassing from AuthCookie and you get into the gritty details, such as implementing your own AuthzProvider. Check out Apache2_4::AuthCookieDBI for an example of that. https://metacpan.org/pod/Apache2_4::AuthCookieDBI Regards, Ed
Re: installing mod_perl on Windows 10
On Jan 8, 2020, at 10:17 AM, André Warnier (tomcat/perl) wrote: > Please provide a full path to 'apxs' executable > (press Enter if you don't have it installed): > > > Configure mod_perl with C:\Apache24? [y] y It seems to me you didn’t provide the *full* path to the apxs executable. I would think that the full path should end with “\bin\apxs”. Hope this helps, Ed
Re: AuthCookieDBI and Apache 2.4
On Oct 20, 2019, at 7:35 PM, Edward J. Sabol wrote:
> I've successfully ported Apache2::AuthCookieDBI's group
> authorization to work with Apache 2.4.x. It works on my system, and I am
> now looking at submitting a pull request on GitHub for this issue.
In case anyone is interested:
https://github.com/matisse/Apache-AuthCookieDBI/pull/6
https://github.com/esabol/Apache-AuthCookieDBI/blob/apache-2.4.x-support/lib/Apache2_4/AuthCookieDBI.pm
I could still use answers to the following questions:
> [...] what's the best way to determine the Apache version in
> non-testsuite code? Should I use Apache::Test's have_min_apache_version()
> regardless?
>
> Apache2::AuthCookieDBI stashes the valid/authorized group in
> $r->subprocess_env('AUTH_COOKIE_DBI_GROUP') so that higher-level interface
> code can reference it. To eliminate multiple database queries for the same
> request (at one point, I was seeing 4+ requests per request since the URL
> was a directory and Apache was authz'ing the directory and then the
> index.html in that directory), I was wondering if checking for the presence
> of $r->subprocess_env('AUTH_COOKIE_DBI_GROUP') and using that instead of
> querying the database again was secure? It all seems to work in my testing
> and it drastically cuts down on repeated database queries, but I'm worried I
> might be doing something insecure.
Thanks,
Ed
Re: AuthCookieDBI and Apache 2.4
On Feb 12, 2019, at 2:25 PM, Edward J. Sabol wrote:
> Hello! I have a project that has successfully used Apache2::AuthCookieDBI
> with mod_perl on Apache 2.2 and Apache 2.0 before that for many years. For
> various reasons, we are looking at moving this project to a new system that
> uses Apache 2.4 exclusively, and the custodians of this new system are
> disinclined to use Apache 2.2 even in a dual lightweight/heavyweight server
> configuration.
>
> I know AuthCookie has been updated by the magnificient Michael Schout to
> support Apache 2.4, but AuthCookieDBI hasn't seen a release in many years.
> On Feb 21, 2019, at 3:52 PM, Edward J. Sabol wrote:
> On Feb 21, 2019, at 5:22 AM, Vegard Vesterheim
> wrote:
>> I registered a ticket against Apache2-AuthCookieDBI regarding this issue
>> a long time ago:
>>
>> https://rt.cpan.org/Public/Bug/Display.html?id=106663
>>
>> We do not use this any longer. But, given that the ticket is still open,
>> I wonder if this ticket could be closed, or at least commented upon.
>
> I don't think it should be closed until the issue is resolved. I've
> personally also filed an issue on the author's GitHub for this:
>
> https://github.com/matisse/Apache-AuthCookieDBI/issues/2
>
> The author did respond recently to that issue, but doesn't seem to be
> terribly interested in fixing it. If anyone wants to help collaborate on a
> pull request, however, maybe we can actually help resolve this.
Eight months later (really it only took one day of coding--most of the
time/effort was getting our dev system upgraded to use Apache 2.4.41 and
mod_perl 2.0.11), I've successfully ported Apache2::AuthCookieDBI's group
authorization to work with Apache 2.4.x. It works on my system, and I am
now looking at submitting a pull request on GitHub for this issue. I
submitted a couple of PRs to
https://github.com/matisse/Apache-AuthCookieDBI over the summer, and the
maintainer released a new version. So I'm hopeful we can get a new release
out with Apache 2.4.x support baked in.
Before (or after) submitting the PR, would anyone be interested in
reviewing my code for correctness?
I also had a several questions:
Currently, the group authz code is in a separate Apache2_4::AuthCookieDBI
module which inherits from Apache2::AuthCookieDBI. I was wondering if the
code could be moved to Apache2::AuthCookieDBI and the separate file could
be eliminated. Any suggestions or tips on doing that? The AUTHZ_*
Apache2::Const's needed for Apache 2.4.x authz are a problem, I think? Do
they exist on Apache versions less than 2.4.0?
Along those lines, what's the best way to determine the Apache version in
non-testsuite code? Should I use Apache::Test's have_min_apache_version()
regardless?
Apache2::AuthCookieDBI stashes the valid/authorized group in
$r->subprocess_env('AUTH_COOKIE_DBI_GROUP') so that higher-level interface
code can reference it. To eliminate multiple database queries for the same
request (at one point, I was seeing 4+ requests per request since the URL
was a directory and Apache was authz'ing the directory and then the
index.html in that directory), I was wondering if checking for the presence
of $r->subprocess_env('AUTH_COOKIE_DBI_GROUP') and using that instead of
querying the database again was secure? It all seems to work in my testing
and it drastically cuts down on repeated database queries, but I'm worried I
might be doing something insecure.
Thanks,
Ed
Re: [ANNOUNCE] mod_perl-2.0.11
On Oct 12, 2019, at 4:09 AM, Wesley Peng wrote: > Edward J. Sabol wrote: >> Except we're actually upgrading from Apache 2.2.34 to 2.4.41, and all the >> tests pass with 2.2.34 (I just ran them again and verified this), so this >> is kind of a new issue for us, but I'm happy to trust in the experiences of >> other folks who have running using mod_perl with Apache 2.4.x. > > We also run mp2 with httpd 2.2. should we upgrade to httpd 2.4 for better > performance? I have no idea. We're upgrading to httpd 2.4.x for security reasons, not performance reasons. Regards, Ed
Re: [ANNOUNCE] mod_perl-2.0.11
On Oct 11, 2019, at 3:59 PM, Steve Hay wrote: >> Is the consensus that these test failures are innocuous and >> it's OK to upgrade anyway? > > I believe so, especially since the same failures existed in 2.0.9 and > 2.0.10, so at least aren't a new issue if that's what you're upgrading > from. Except we're actually upgrading from Apache 2.2.34 to 2.4.41, and all the tests pass with 2.2.34 (I just ran them again and verified this), so this is kind of a new issue for us, but I'm happy to trust in the experiences of other folks who have running using mod_perl with Apache 2.4.x. Thanks, Ed
Re: [ANNOUNCE] mod_perl-2.0.11
Hello. I'm seeing the same failures in t/filter/in_bbs_inject_header.t (Wstat: 0 Tests: 36 Failed: 3) Failed tests: 22, 26, 30 that others reported with the release candidates. Those are the only failures. This is when building with Apache 2.4.41 on RHEL. All tests pass if I build with Apache 2.2.34 instead. Is the consensus that these test failures are innocuous and it's OK to upgrade anyway? Thanks, Ed
Re: AuthCookieDBI and Apache 2.4
On Feb 21, 2019, at 5:22 AM, Vegard Vesterheim wrote: > I registered a ticket against Apache2-AuthCookieDBI regarding this issue > a long time ago: > > https://rt.cpan.org/Public/Bug/Display.html?id=106663 > > We do not use this any longer. But, given that the ticket is still open, > I wonder if this ticket could be closed, or at least commented upon. I don't think it should be closed until the issue is resolved. I've personally also filed an issue on the author's GitHub for this: https://github.com/matisse/Apache-AuthCookieDBI/issues/2 The author did respond recently to that issue, but doesn't seem to be terribly interested in fixing it. If anyone wants to help collaborate on a pull request, however, maybe we can actually help resolve this. Regards, Ed
Re: AuthCookieDBI and Apache 2.4
On Feb 20, 2019, at 11:28 AM, Michael Schout wrote:
> As for AuthCookieDBI, you may not even need to change it to use
> Apache2_4::AuthCookie base, as eventually I managed to get all of the
> changes needed to work togehter in Apache2::AuthCookie. I left
> Apache2_4::AuthCookie for historical reasons, and in case further issues
> came up that would require more changes that were 2.4 exclusive.
Impressive! And good to know.
> If you aren't doing anything fancy with `require` directives, you likely
> don't need to worry about creating an Authz provider, which is where
> most of the issues are when moving to 2.4. Looking at AuthCookieDBI, it
> does implement support for `require group`, so if you need that, you
> will need to create an Authz provider that implements it. But if not,
> you can probably not worry about it.
Well, I definitely have to worry about it, unfortunately. We use group-based
authorization ('require group foo') extensively.
Looking at your
https://metacpan.org/pod/distribution/Apache-AuthCookie/README.apache-2.4.pod
document, we need a
PerlAddAuthzProvider group My::AuthCookieHandler->authz_group
Any pointers to a working AuthzProvider written in Perl (like for the "species"
one) in your examples? It's not perfectly clear to me how to go about that.
Many thanks,
Ed
AuthCookieDBI and Apache 2.4
Hello! I have a project that has successfully used Apache2::AuthCookieDBI with mod_perl on Apache 2.2 and Apache 2.0 before that for many years. For various reasons, we are looking at moving this project to a new system that uses Apache 2.4 exclusively, and the custodians of this new system are disinclined to use Apache 2.2 even in a dual lightweight/heavyweight server configuration. I know AuthCookie has been updated by the magnificient Michael Schout to support Apache 2.4, but AuthCookieDBI hasn't seen a release in many years. Has anyone tried using AuthCookieDBI with Apache 2.4 or porting AuthCookieDBI to 2.4? I presume it's more involved than just installing the latest version of AuthCookie and changing "use base qw( Apache2::AuthCookie );" to "use base qw( Apache2_4::AuthCookie );" in Apache2::AuthCookieDBI? I've looked over Michael Schout's Apache 2.4 authentication API porting guide here: http://search.cpan.org/~mschout/Apache-AuthCookie/README.apache-2.4.pod Any assistance or experience with AuthCookieDBI on Apache 2.4 would be welcome. Thanks, Ed
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC2
I think we're ready from some +/-1s :) Although it doesn't affect me since I don't develop on Mac OS X, I'd still like to see you include the simple CFLAGS fix for make test for Mac OS X, for what it's worth. Can you be more specific as to what you are talking about ? Jonathan Vanasco [EMAIL PROTECTED] mentioned it on the mailing list three days ago. Here's a URL to refresh your memory, as well as two URLs to the original thread from March in which the fix was noted: http://mail-archives.apache.org/mod_mbox/httpd-apreq-dev/200605.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/httpd-apreq-dev/200603.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/httpd-apreq-dev/200603.mbox/[EMAIL PROTECTED]
