perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: httpd 2.3.01 and t/modules/proxy.t
Date Fri, 23 Sep 2005 14:12:18 GMT

> 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


> -        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?

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

PROXYREQ_NONE here, 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.

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..."

finally, it looks like that code will undo the

   if (!val && !r->proxyreq... ) {
     retval = r->proxyreq = 1;

foo above, right?

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.


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

View raw message