perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: httpd 2.3.01 and t/modules/proxy.t
Date Wed, 28 Sep 2005 08:24:22 GMT
On Fri, Sep 23, 2005 at 10:12:18AM -0400, Geoffrey Young wrote:
> 
> >This was discussed a while back.  I don't think it makes sense for 
> >mod_perl to set r->proxyreq to anything other than PROXYREQ_REVERSE; 
> >this fixes the failure, Geoff may disagree still though ;)
> 
> :)
> 
> ok, in all honesty I get the different types of proxies mixed up - by 
> name, by function, and all.  but this was my point before (I think :)
> 
> a common mod_perl technique since the mod_perl epoch has been to point 
> your browser proxy settings to a server where a PerlTransHandler decides 
> whether to let the request continue to mod_proxy or not.  in mp1-land 
> that involved

This seems reasonable.

>   $r->proxyreq(0);
> 
> >-        retval = r->proxyreq = 1;
> >+        retval = r->proxyreq = PROXYREQ_REVERSE;
> 
> as I said, I get my names mixed up all the time.  is a reverse proxy the 
> same as
> 
>   r->proxyreq = 1;
> 
> was in apache 1.3?  if not, then is this code actually accomplishing the 
> same thing at all?

It's strictly equivalent to 1.3's ->proxyreq = PROXY_PASS.  But either 
way: setting ->proxyreq = PROXYREQ_REVERSE is the only correct thing to 
do for the code in t/response/TestModules/proxy.pm - it enables a 
reverse proxy.

> >     if (val) {
> >-        r->proxyreq = SvIV(val);
> >+        r->proxyreq = SvIV(val) ? PROXYREQ_REVERSE : 0;
> 
> PROXYREQ_NONE here, yes?

s/0/PROXYREQ_NONE/ is more correct, yes.

> anyway, I guess I see two things here.  first, your original assertion 
> that we should only support PROXYREQ_REVERSE isn't entirely true - we 
> support PROXYREQ_NONE as well :)  which I guess speaks to my original 
> concern.  maybe.

It would be quite reasonable to just expose these three constants in the 
mod_perl API and punt on the issue.  I don't have round tuits to relearn 
enough XS to submit a patch for that though ;)

> the next is that while I'm not sure what the other PROXYREQ_* states 
> achieve, is it smart to just set to PROXYREQ_NONE silently when a user 
> attempts to set a different state?  assuming we agree to support just 
> NONE and REVERSE, what about something like
> 
>   if (val) {
>     if (val == PROXYREQ_NONE || val == PROXYREQ_REVERSE) {
>       r->proxyreq = val;
>     }
>     else {
>       warn "your request was ignored..."
>     }
>   }

That would be reasonable.

> finally, it looks like that code will undo the
> 
>   if (!val && !r->proxyreq... ) {
>     ...
>     retval = r->proxyreq = 1;
>   }
> 
> foo above, right?

Actually I'm not at all sure what that big if() statement is supposed to 
do.  It could be an attempt to automatically detect when the server is 
acting as *forward* proxy.  I don't know why that needs to be done in 
mod_perl.  This goes back to the assumption that mod_proxy will behave 
correctly as a forward proxy even when not configured using 
"ProxuRequests on" - which is no longer true in 2.2.

> in truth, this whole function looks wicked messy.  shouldn't all 
> request_rec accessor methods return the 
> current-before-you-messed-with-it value for the structure?  I'm not sure 
> that was ever explicitly spelled out in our mission statement (heh :) 
> but IIRC almost all the record accessors behave that way historically.

No idea about this sorry ;)

joe

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message