Mark Hedges schrieb:
On Wed, 7 Jan 2009, Michael Ludwig wrote:
In 2.0, is there a way to access the current request object using one
of the classes in the following fashion?
my $r = Apache2::RequestRec->current(); # INVALID!
From `man Apache2::RequestUtil`:
# get the global request obje
Trying to locate APR::Request::Apache2 on my system, I noticed it is
part of libapreq2.
libapreq 2-2.07 | ModPerl | ModPerl
http://www.gossamer-threads.com/lists/modperl/modperl/87199
| libapreq2 is an APR-based shared library used for parsing HTTP
| cookies, query-strings and POST data.
Doing
Michael Ludwig wrote:
> I'd like to reach an understanding of what these ranges of modules and
> interfaces are intended for. When would I want to use which interface?
> Or is it all a matter of style and taste?
Possibly. You will need the standard modperl2 library to even get
modperl up and runn
Foo JH schrieb:
Michael Ludwig wrote:
I'd like to reach an understanding of what these ranges of modules
and interfaces are intended for. When would I want to use which
interface? Or is it all a matter of style and taste?
Possibly. You will need the standard modperl2 library to even get
modper
Michael Ludwig wrote:
It is said in the thread referred to above that "the splitting of the
APIs [...] is strange and confusing", and coming from mod_perl 1.0, I
agree. But it probably has advantages as well.
i think that comment about splitting the api was with respect to
RequestRec, Request
Adam Prime wrote:
Personally, i think libapreq should be part of core httpd (or at least a
'normal' module, and libapreq2's perl bindings should be part of stock
mod_perl.
Oh, but we started work for this in 2.4 of httpd for libapreq.so and
mod_apreq.so for http core.
after httpd 2.6/3.0 we m
Adam Prime schrieb:
Michael Ludwig wrote:
It is said in the thread referred to above that "the splitting of the
APIs [...] is strange and confusing", and coming from mod_perl 1.0, I
agree. But it probably has advantages as well.
i think that comment about splitting the api was with respect
to
Philip M. Gollucci wrote:
Oh, but we started work for this in 2.4 of httpd for libapreq.so and
mod_apreq.so for http core.
cool
after httpd 2.6/3.0 we might be able to swing the perl bindings peices.
So where does that leave the perl binding between 2.4 and 3.0? Or will
we all be running
Adam Prime wrote:
Philip M. Gollucci wrote:
Oh, but we started work for this in 2.4 of httpd for libapreq.so and
mod_apreq.so for http core.
cool
after httpd 2.6/3.0 we might be able to swing the perl bindings peices.
So where does that leave the perl binding between 2.4 and 3.0? Or will
On Thu, 8 Jan 2009, Adam Prime wrote:
> Personally, i think libapreq should be part of core httpd
> (or at least a 'normal' module, and libapreq2's perl
> bindings should be part of stock mod_perl.
Yeah I've run into systems multiple times where the boss was
too afraid of change to allow building
Mark Hedges wrote:
So where does that leave the perl binding between 2.4 and
3.0? Or will we all be running mod_parrot/mod_perl6 by
then (which looks like it's made great progress since
YAPC)
Great, all code where '.' was the concatenator operator
breaks, hurray. (?)
You don't have to switch
On Wed, 7 Jan 2009, Odysseas Pentakalos, Ph.D. wrote:
>
> sub handler {
> my($r) = @_;
>
> my $log = $r->log;
>
> return FORBIDDEN unless $r->is_main;
>
> my $subr = $r->lookup_uri($r->uri);
> my $dn = $subr->subprocess_env('SSL_CLIENT_S_DN');
>
> $r->log_reason("In CertAu
Mark,
Thanks so much for your help. That was not the problem but it helped me see
the problem. I was not importing the Constants at the top so regardless of
whether I was returning FORBIDDEN or DECLINED, or HTTP_UNAUTHORIZED the
value was invalid. I spent hours tracking down this oversight.
Thank
On Thu, 8 Jan 2009, Odysseas Pentakalos, Ph.D. wrote:
> Thanks so much for your help. That was not the problem but
> it helped me see the problem. I was not importing the
> Constants at the top so regardless of whether I was
> returning FORBIDDEN or DECLINED, or HTTP_UNAUTHORIZED the
> value was
14 matches
Mail list logo