Hi,
A test against my project show's no real difference at all. I applied the
patch against Apache-Test-1.04 and I verified that my t/conf/modperl_inc.pl
contain the desired lines.
use lib '/tmp/ap_ex/blib/arch';
use lib '/tmp/ap_ex/blib/lib';
1;
my error message is the following:
...
Hi,
Am Dienstag, 21. Oktober 2003 09:00 schrieb Stas Bekman:
Boris Zentner wrote:
Hi,
A test against my project show's no real difference at all. I applied the
patch against Apache-Test-1.04 and I verified that my
t/conf/modperl_inc.pl contain the desired lines.
use lib
That was a very good hint. It allows me to keep the perl part into the apache
directives as desired. But my @INC path is still wrong.
hmm.
ok, how about you show us a few things, like all of modperl_inc.pl, then
what directories you would like included that are missing. and also show us
your
hi all
in preparation for the upcoming 1.05 release, I'm going to create a RELEASE
document in the Apache-Test directory. I've attached a preliminary version
here, which is essentially copied from the one for mod_perl (with a few
adjustments).
if I'm missing anything or something isn't right,
That leads to different
version of Apache:PageKit in the lib and blib/lib directories. With the
current version of Apache::Test the version in lib is tested. But 'make
install' installs the version from blib/lib. And depending from your perl
they are different.
so you want Apache-Test to test
Geoffrey Young wrote:
That leads to different version of Apache:PageKit in the lib and
blib/lib directories. With the current version of Apache::Test the
version in lib is tested. But 'make install' installs the version from
blib/lib. And depending from your perl they are different.
so you
Geoffrey Young wrote:
Stas Bekman wrote:
Boris Zentner wrote:
Hi,
A test against my project show's no real difference at all. I applied
the patch against Apache-Test-1.04 and I verified that my
t/conf/modperl_inc.pl contain the desired lines.
use lib '/tmp/ap_ex/blib/arch';
use lib
Geoffrey Young wrote:
hi all
in preparation for the upcoming 1.05 release, I'm going to create a
RELEASE document in the Apache-Test directory. I've attached a
preliminary version here, which is essentially copied from the one for
mod_perl (with a few adjustments).
if I'm missing anything or
4. Release the package and update links (e.g. mod_perl-1.99_11.tar.gz)
a. upload to www.apache.org:/www/perl.apache.org/dist/
b. remove releases older by 2 subversions (keep the last one)
we don't release Apache-Test on apache.org, but only CPAN. So you can
drop 4.
Geoffrey Young wrote:
4. Release the package and update links (e.g. mod_perl-1.99_11.tar.gz)
a. upload to www.apache.org:/www/perl.apache.org/dist/
b. remove releases older by 2 subversions (keep the last one)
we don't release Apache-Test on apache.org, but only CPAN. So you can
drop 4.
Hi,
Am Dienstag, 21. Oktober 2003 14:19 schrieb Geoffrey Young:
Stas Bekman wrote:
Boris Zentner wrote:
Hi,
A test against my project show's no real difference at all. I applied
the patch against Apache-Test-1.04 and I verified that my
t/conf/modperl_inc.pl contain the desired lines.
Hi Geoffrey,
Am Dienstag, 21. Oktober 2003 15:09 schrieb Geoffrey Young:
That was a very good hint. It allows me to keep the perl part into the
apache directives as desired. But my @INC path is still wrong.
hmm.
ok, how about you show us a few things, like all of modperl_inc.pl, then
Boris Zentner wrote:
[Finally the kind moderator let your messages through ;) Thank you!]
In short lib is searched before blib/lib. I had a workaround that overwrites
some routines in Apache::Test but it is really uggly and may not work taht
long. Im happy that Stas is now looking into the
Hi,
im subscribed!
All your hints and tips bring me a step forward, but I stuck on the @INC
again. Even with the patch.
The only thing that pass my brief tests is to change the order of the included
path inside TestConfig.pm
--- TestConfig.pm.orig 2003-10-21 20:49:53.0 +0200
+++
The new patch is the first step towards Flood handling 100 continue
responses. If such response is found in the first chunk read, and the
next response is also available there already, then we read past the 100
message and read in the next message's headers and body if available.
Please
Boris Zentner wrote:
Hi,
im subscribed!
And someone has let your previous posts through ;)
All your hints and tips bring me a step forward, but I stuck on the @INC
again. Even with the patch.
The only thing that pass my brief tests is to change the order of the included
path inside
Hi Stas,
It works fine. Thanks.
There were two more places where lib was unconditionally pushed. And
removing lib, affected mod_perl 2, so I had to fix that as well. I haven't
thoroughly tested this change yet, but please try this patch:
[...]
Stas Bekman wrote:
I
haven't thoroughly tested this change yet, but please try this patch:
tests fine for me on mp2 and my 3rd party apps.
nice work.
--Geoff
Geoffrey Young wrote:
Stas Bekman wrote:
I haven't thoroughly tested this change yet, but please try this patch:
tests fine for me on mp2 and my 3rd party apps.
nice work.
There are problems if you remove previously installed modperl. I'm looking
at it.
Stas Bekman wrote:
Geoffrey Young wrote:
tests fine for me on mp2 and my 3rd party apps.
Thanks Geoff.
There are problems if you remove previously installed modperl. I'm
looking at it.
Apparently mod_perl 2.0's distro must have 'lib' pushed onto @INC from t/TEST.
That was the problem. Now
Hi,
I am actually using apache as a reverse proxy, and i am trying to use a
handler with... and it doesn't work.
When i setup my SetHandler on a local virtualhost, it works well, but
when i setup it on a virtualhost doing reverse proxy, it's never called.
any ideas ?
Matthieu
Matthieu Estrade wrote:
I am actually using apache as a reverse proxy, and i am trying to use a
handler with... and it doesn't work.
When i setup my SetHandler on a local virtualhost, it works well, but
when i setup it on a virtualhost doing reverse proxy, it's never called.
any ideas ?
IMHO,
On Tue, 21 Oct 2003, Matthieu Estrade wrote:
I am actually using apache as a reverse proxy, and i am trying to use a
handler with... and it doesn't work.
When i setup my SetHandler on a local virtualhost, it works well, but
when i setup it on a virtualhost doing reverse proxy, it's never
I am using Apache 2.0 and what i want to do is a applicative
authentication using a form i wanted sent by the reverse proxy.
But i think i will do another way, looking into mod_mem_cache how it's
disable mod_proxy when it want to serve data directly from his cache...
Cliff Woolley wrote:
On
I have to look what this quick handler do exactly, but i work well and
seems to be able to act as normal handler.
ap_hook_quick_handler(cache_url_handler, NULL, NULL, APR_HOOK_FIRST);
Cliff Woolley wrote:
On Tue, 21 Oct 2003, Cliff Woolley wrote:
What exactly are you trying to do, and with
On Tue, 21 Oct 2003, Matthieu Estrade wrote:
I have to look what this quick handler do exactly, but i work well and
seems to be able to act as normal handler.
ap_hook_quick_handler(cache_url_handler, NULL, NULL, APR_HOOK_FIRST);
Be careful there... the quick handler bypasses a whole lot of
* Matthieu Estrade [EMAIL PROTECTED] wrote:
I could do with a filter but i need to place it before authentication
hook...
I have just finished what i wanted to do:
The quick handler is controlling if the user is already authenticated
(cookie based or session table)
Hmm. You could hook
-Original Message-
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
[...]
Do not attempt to
remove a filter once it's inserted, simple force it to be
inert. Serveral Apache filters already do this, although I
can't name one offhand (SSL might be, I think.)
Perhaps I am just
William A. Rowe, Jr. wrote:
On Mon, 20 Oct 2003, Jim Jagielski wrote:
* isn't ap_die() broken with recognizing recursive errors
Have you had a chance to run it through the perl-framework testsuite?
If so I'd give it +.5.
Does the perl test suite check error handling at all? (just curious)
William A. Rowe, Jr. wrote:
At 03:17 PM 10/20/2003, Aryeh Katz wrote:
I have an input filter that might need to reinvoke the handler that inserted this
input filter (this time with the filter removed).
Do not attempt to remove a filter once it's inserted, simple force it to be inert.
hmmm?
At 06:06 AM 10/21/2003, Tikka, Sami wrote:
-Original Message-
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
[...]
Do not attempt to
remove a filter once it's inserted, simple force it to be
inert. Serveral Apache filters already do this, although I
can't name one
At 09:51 AM 10/21/2003, [EMAIL PROTECTED] wrote:
William A. Rowe, Jr. wrote:
At 03:17 PM 10/20/2003, Aryeh Katz wrote:
I have an input filter that might need to reinvoke the handler that inserted this
input filter (this time with the filter removed).
Do not attempt to remove a filter once it's
At 12:45 PM 10/21/2003, André Malo wrote:
* William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Answer, the byterange filter removes itself. It *knows* there are no partially
processed buckets that it is holding on to. Nobody else is allowed to add
or remove a filter - but the filter may remove
Ahhh. Now look at the code below. WHO removes the byterange filter?
Answer, the byterange filter removes itself.
That's perfectly clear, and it's common practice. I (and evidently
others) read your previous post as disallowing that, causing a
raised eyebrow.
It *knows* there are
At 03:43 PM 10/21/2003, Nick Kew wrote:
Ahhh. Now look at the code below. WHO removes the byterange filter?
Answer, the byterange filter removes itself.
That's perfectly clear, and it's common practice. I (and evidently
others) read your previous post as disallowing that, causing a
raised
35 matches
Mail list logo
