You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Geoffrey Young <ge...@modperlcookbook.org> on 2004/10/07 22:04:16 UTC
t/modules/proxy.t failure with 2.1
hi all...
just FYI, 2.1 is failing t/modules/proxy.t with a 404. I've spent some time
this afternoon trying to see what (of importance) has changed in between 2.0
and HEAD but I can't see where it is at the moment.
so, if anyone has been following proxy development of late and knows what
the issue is, feel free to jump in. otherwise, just know that I'm working
on it.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/modules/proxy.t failure with 2.1
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Joe Orton wrote:
> On Mon, Oct 11, 2004 at 09:26:37AM -0400, Geoffrey Young wrote:
>
>>Joe Orton wrote:
>>
>>>as far as the fact that mod_proxy in HEAD refuses to
>>>act as a forward proxy unless "ProxyRequests On" has been configured.
>>>So adding "ProxyRequests On" as below fixes the test but whether this
>>>should actually be considered a mod_proxy bug or not, I'm not sure.
>>
>>well it's certainly an important change in behavior. and it kinda feels odd
>>- I know that mod_perl has been doing this kind of proxy thing forever but
>>we're always doing unusual stuff :)
>
>
> I think it's a bit odd for mod_perl to be asking the server to act as a
> forward proxy for a particular request; I'm not sure that really makes
> sense.
actually, putting mod_perl in control of dispatching a forward proxy is
pretty powerful (and interesting). however, I think there is a valid point
here - while mod_perl ought to be able to handle some of the proxy foo for
mod_proxy, it might not make sense to be able to do it dynamically. that
is, requiring ProxyRequests On might make sense from a security standpoint
here since mod_perl is not _entirely_ in control, but rather dispatches a
large part of the work over to mod_proxy and, thus, it should respect its
rules. oddly enough, the cookbook mentions requiring ProxyRequests On,
while the eagle book does not. go figure ;)
> It does make sense for a module to want the server to act as a
> *reverse* proxy on a per-request basis (an important mod_rewrite feature
> if nothing else), and it looks like that must be broken too.
gak, that would be bad.
> So I'll verify that and then continue this on dev@httpd as necessary...
> but probably mod_perl should be setting ->proxyreq = PROXYREQ_REVERSE
> anyway in this case.
yes, I noticed that we were using the wrong hard-coded value in the test
case as well. once we get everything here figured out we'll move to a named
constant, maybe even the right one :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/modules/proxy.t failure with 2.1
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Oct 11, 2004 at 09:26:37AM -0400, Geoffrey Young wrote:
> Joe Orton wrote:
> > as far as the fact that mod_proxy in HEAD refuses to
> > act as a forward proxy unless "ProxyRequests On" has been configured.
> > So adding "ProxyRequests On" as below fixes the test but whether this
> > should actually be considered a mod_proxy bug or not, I'm not sure.
>
> well it's certainly an important change in behavior. and it kinda feels odd
> - I know that mod_perl has been doing this kind of proxy thing forever but
> we're always doing unusual stuff :)
I think it's a bit odd for mod_perl to be asking the server to act as a
forward proxy for a particular request; I'm not sure that really makes
sense. It does make sense for a module to want the server to act as a
*reverse* proxy on a per-request basis (an important mod_rewrite feature
if nothing else), and it looks like that must be broken too.
So I'll verify that and then continue this on dev@httpd as necessary...
but probably mod_perl should be setting ->proxyreq = PROXYREQ_REVERSE
anyway in this case.
> I guess it warrants discussion over on httpd-dev.
>
> --Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/modules/proxy.t failure with 2.1
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Joe Orton wrote:
> On Thu, Oct 07, 2004 at 04:04:16PM -0400, Geoffrey Young wrote:
>
>>hi all...
>>
>>just FYI, 2.1 is failing t/modules/proxy.t with a 404. I've spent some time
>>this afternoon trying to see what (of importance) has changed in between 2.0
>>and HEAD but I can't see where it is at the moment.
>
>
> I tracked this down
wow. thanks joe!
> as far as the fact that mod_proxy in HEAD refuses to
> act as a forward proxy unless "ProxyRequests On" has been configured.
> So adding "ProxyRequests On" as below fixes the test but whether this
> should actually be considered a mod_proxy bug or not, I'm not sure.
well it's certainly an important change in behavior. and it kinda feels odd
- I know that mod_perl has been doing this kind of proxy thing forever but
we're always doing unusual stuff :)
I guess it warrants discussion over on httpd-dev.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/modules/proxy.t failure with 2.1
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Oct 07, 2004 at 04:04:16PM -0400, Geoffrey Young wrote:
> hi all...
>
> just FYI, 2.1 is failing t/modules/proxy.t with a 404. I've spent some time
> this afternoon trying to see what (of importance) has changed in between 2.0
> and HEAD but I can't see where it is at the moment.
I tracked this down as far as the fact that mod_proxy in HEAD refuses to
act as a forward proxy unless "ProxyRequests On" has been configured.
So adding "ProxyRequests On" as below fixes the test but whether this
should actually be considered a mod_proxy bug or not, I'm not sure.
Index: t/response/TestModules/proxy.pm
===================================================================
RCS file: /misc/pepper/cvs/root/modperl-2.0/t/response/TestModules/proxy.pm,v
retrieving revision 1.6
diff -u -r1.6 proxy.pm
--- t/response/TestModules/proxy.pm 23 Sep 2004 01:44:11 -0000 1.6
+++ t/response/TestModules/proxy.pm 11 Oct 2004 10:10:50 -0000
@@ -53,6 +53,7 @@
</IfModule>
</Proxy>
+ ProxyRequests On
PerlModule TestModules::proxy
PerlTransHandler TestModules::proxy::proxy
<Location /TestModules__proxy_real>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/modules/proxy.t failure with 2.1
Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
> On Fri, Oct 08, 2004 at 10:27:23AM -0400, Stas Bekman wrote:
>
>>Joe Orton wrote:
>>
>>>On Fri, Oct 08, 2004 at 10:08:21AM -0400, Stas Bekman wrote:
>>>
>>>
>>>>And it'd be nice for the failing test to run t/REPORT and include it in
>>>>the output. W/o it we know almost nothing about what perl and apache
>>>>builds were used.
>>>
>>>
>>>I guessed you'd say that... I've changed the script to append ./t/REPORT
>>>and tail -100 t/logs/error_log if the tests fail.
>>
>>There is a better way, instead of 'make test' run t/SMOKE -bug and it'll
>>show the failing STDOUT and STDERR only for those tests that have failed
>>(it seeks through both streams after each test is run). It also scans for
>>core files (which makes it quite slower than plain t/TEST, but it tells
>>you exactly which test has caused the segfault). The only problem is that
>>it's not an equivalent of make test (yet). perhaps we should make a new
>>target for it. For now you need to run:
>
>
> I don't have IPC::Run3 installed on many of my test machines (we don't
> ship it in the distro) so it's a bit of hassle to get t/SMOKE running
> unfortunately.
sorry about that, the reason we had to utilise IPC::Run3 is because
t/SMOKE didn't work on windows :(
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/modules/proxy.t failure with 2.1
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Oct 08, 2004 at 10:27:23AM -0400, Stas Bekman wrote:
> Joe Orton wrote:
> >On Fri, Oct 08, 2004 at 10:08:21AM -0400, Stas Bekman wrote:
> >
> >>And it'd be nice for the failing test to run t/REPORT and include it in
> >>the output. W/o it we know almost nothing about what perl and apache
> >>builds were used.
> >
> >
> >I guessed you'd say that... I've changed the script to append ./t/REPORT
> >and tail -100 t/logs/error_log if the tests fail.
>
> There is a better way, instead of 'make test' run t/SMOKE -bug and it'll
> show the failing STDOUT and STDERR only for those tests that have failed
> (it seeks through both streams after each test is run). It also scans for
> core files (which makes it quite slower than plain t/TEST, but it tells
> you exactly which test has caused the segfault). The only problem is that
> it's not an equivalent of make test (yet). perhaps we should make a new
> target for it. For now you need to run:
I don't have IPC::Run3 installed on many of my test machines (we don't
ship it in the distro) so it's a bit of hassle to get t/SMOKE running
unfortunately.
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/modules/proxy.t failure with 2.1
Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
> On Fri, Oct 08, 2004 at 10:08:21AM -0400, Stas Bekman wrote:
>
>>And it'd be nice for the failing test to run t/REPORT and include it in
>>the output. W/o it we know almost nothing about what perl and apache
>>builds were used.
>
>
> I guessed you'd say that... I've changed the script to append ./t/REPORT
> and tail -100 t/logs/error_log if the tests fail.
There is a better way, instead of 'make test' run t/SMOKE -bug and it'll
show the failing STDOUT and STDERR only for those tests that have failed
(it seeks through both streams after each test is run). It also scans for
core files (which makes it quite slower than plain t/TEST, but it tells
you exactly which test has caused the segfault). The only problem is that
it's not an equivalent of make test (yet). perhaps we should make a new
target for it. For now you need to run:
t/TEST -conf
t/SMOKE -bug
cd ModPerl-Registry
t/TEST -conf
t/SMOKE -bug
and then you only need to add the output of t/REPORT
>>Also this fails to build:
>>http://www.apache.org/~jorton/regress/2004-10-05/cocoa/mod_perl-on-2.0-make.log
>
> ^^^^^^^^^^
>>but you aren't using the current cvs, where it was fixed :)
>>so other reports are probably failing for the same reason.
>
>
> You missed the time axis at the top :)
But I also didn't remember when it was fixed :)
I just went to see if I can fix the problems :)
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/modules/proxy.t failure with 2.1
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Oct 08, 2004 at 10:08:21AM -0400, Stas Bekman wrote:
> And it'd be nice for the failing test to run t/REPORT and include it in
> the output. W/o it we know almost nothing about what perl and apache
> builds were used.
I guessed you'd say that... I've changed the script to append ./t/REPORT
and tail -100 t/logs/error_log if the tests fail.
> Also this fails to build:
> http://www.apache.org/~jorton/regress/2004-10-05/cocoa/mod_perl-on-2.0-make.log
^^^^^^^^^^
> but you aren't using the current cvs, where it was fixed :)
> so other reports are probably failing for the same reason.
You missed the time axis at the top :)
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/modules/proxy.t failure with 2.1
Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
> On Thu, Oct 07, 2004 at 04:04:16PM -0400, Geoffrey Young wrote:
>
>>hi all...
>>
>>just FYI, 2.1 is failing t/modules/proxy.t with a 404. I've spent some time
>>this afternoon trying to see what (of importance) has changed in between 2.0
>>and HEAD but I can't see where it is at the moment.
>
>
> I don't know who else is running nightly regression tests here. I have
I run a lot of them, but not all the time as it makes my notebook smoke. I
do only 2.0 and test against all perl versions 5.6.1 - 5.9.1, each perl
built in 4 different ways, plus one apache worker and one apache prefork.
> just synched the results from the builds I started running with
> httpd+mod_perl-from-CVS on a few machines here:
>
> http://www.apache.org/~jorton/regress/mod_perl.html
>
> I know these are not entirely useful without access to the machines to
> debug etc but it does at least give status tracking.
And it'd be nice for the failing test to run t/REPORT and include it in
the output. W/o it we know almost nothing about what perl and apache
builds were used.
Also this fails to build:
http://www.apache.org/~jorton/regress/2004-10-05/cocoa/mod_perl-on-2.0-make.log
but you aren't using the current cvs, where it was fixed :)
so other reports are probably failing for the same reason.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/modules/proxy.t failure with 2.1
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> I don't know who else is running nightly regression tests here. I have
> just synched the results from the builds I started running with
> httpd+mod_perl-from-CVS on a few machines here:
>
> http://www.apache.org/~jorton/regress/mod_perl.html
very cool. what are you using to generate that?
for the curious, here's what I have been running nightly. current mod_perl
CVS against:
2.0.47-worker-perl-5.8.5
2.0.52-worker-perl-5.8.5
2.1-worker-perl-5.8.5
2.1-prefork-perl-5.8.5
2.1-prefork-perl-5.8.5-nothreads
2.0-worker-perl-5.8.0
2.0-worker-perl-5.8.5
2.0-prefork-perl-5.8.0
2.0-prefork-perl-5.8.5
2.0-prefork-perl-5.8.5-nothreads
> I know these are not entirely useful without access to the machines to
> debug etc but it does at least give status tracking.
yup. and if each of us done it a little bit different we'll be catching
different stuff. for instance, all my builds use MP_COMPAT_1X=0, which is
not the default and has caught a few little things. and, until you reported
it, I think I was the only one testing 2.1 nightly - thanks for the help :)
>>so, if anyone has been following proxy development of late and knows what
>>the issue is, feel free to jump in. otherwise, just know that I'm working
>>on it.
>
>
> I presumed this was because of all the recent proxy/balancer type
> changes...
yeah, I saw those :) but I can't really see where it's different that it
matters. but today is a new day, so maybe I'll see it now :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/modules/proxy.t failure with 2.1
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Oct 07, 2004 at 04:04:16PM -0400, Geoffrey Young wrote:
> hi all...
>
> just FYI, 2.1 is failing t/modules/proxy.t with a 404. I've spent some time
> this afternoon trying to see what (of importance) has changed in between 2.0
> and HEAD but I can't see where it is at the moment.
I don't know who else is running nightly regression tests here. I have
just synched the results from the builds I started running with
httpd+mod_perl-from-CVS on a few machines here:
http://www.apache.org/~jorton/regress/mod_perl.html
I know these are not entirely useful without access to the machines to
debug etc but it does at least give status tracking.
> so, if anyone has been following proxy development of late and knows what
> the issue is, feel free to jump in. otherwise, just know that I'm working
> on it.
I presumed this was because of all the recent proxy/balancer type
changes...
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org