perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: t/modules/proxy.t fails with httpd-2.1
Date Wed, 01 Dec 2004 15:15:35 GMT
Joe Orton wrote:
> On Wed, Dec 01, 2004 at 09:40:54AM -0500, Stas Bekman wrote:
>>Joe Orton wrote:
>>>On Fri, Nov 26, 2004 at 04:37:49PM -0500, Stas Bekman wrote:
>>>>I can't recall whether this was discussed before, but t/modules/proxy.t 
>>>>fails with httpd-2.1. Is anybody following the mod_proxy changes?
>>>I'll note that this may get fixed such that it only works for enabling a
>>>reverse-proxy "decision" by a module (i.e. r->proxyreq ==
>>>PROXYREQ_REVERSE), so the mod_proxy changes alone may not be sufficient
>>>to fix the mod_perl tests.
>>>We had a brief discussion on this previously: I still don't think it
>>>makes sense for a module to ever decide that a particular request has
>>>been "forward-proxied", that can only be a product of the configuration
>>>(both of client and server).  So if you disagree with this you'll have
>>>to argue that case...
>>What's wrong with a dynamic run-time decision?
> Well, convince me that it's useful decide it dynamically. If the client
> is not configured to use the server as a forward proxy, and the server
> is not configured up-front to act as a forward proxy, when does it make
> sense to treat a request as being "forward proxied"? 
> Whether or not the server acts as a *reverse proxy* is of course
> something the server can decide autonomously and hence dynamically at
> run-time.

I will let Geoff defend this one. Geoff is much better at this kind of 
debates than I am.

>>Isn't that a regression problem? I believe that's how it worked in apache 
> Change in behaviour, yes; regression, that's the debate...

Right, but if anybody was using this functionality moving from 2.0 to 2.2 
will break their code. So that change in behavior is not backwards 
compatible. The feature wasn't declared deprecated in 2.0 and therefore it 
can't be changed in 2.2. One needs to go through a deprecation cycle 
before any backwards compatibility in the same generation of the project 
can be dropped. If we don't follow that rule...

But I'm leaving this debate at this point and let others defend it if they 
are interested.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message