stas and I were having an offline discussion about the logic behind the
no-args logic in $r->proxyreq(), specifically this part (from
Apache__RequestRec.h)
if (!val && !r->proxyreq &&
r->parsed_uri.scheme &&
!(r->parsed_uri.hostname &&
strEQ(r->parsed_uri.scheme, ap_http_method(r)) &&
ap_matches_request_vhost(r, r->parsed_uri.hostname,
r->parsed_uri.port_str ?
r->parsed_uri.port :
ap_default_port(r))))
{
retval = r->proxyreq = 1;
r->uri = r->unparsed_uri;
/* else mod_proxy will segfault */
r->filename = apr_pstrcat(r->pool, "modperl-proxy:", r->uri, NULL);
}
after giving it lots of thought and analysis I think this ought to be
removed entirely. here's my reasoning:
- this code duplicates mod_proxy's proxy_request() routine
- proxy_request() runs in a post-read-request handler, meaning that if
mod_proxy is installed and activated the code can't help but run, even if
you add the logic yourself from mod_perl.
- if you don't have mod_proxy installed or activated, this code doesn't
help you, since there is no content handler around to serve the proxy
(unless you write one).
basically, all this code provides is a duplication of the mod_proxy logic
that is useful only if you go through the trouble of writing a proxying
content handler as well - essentially this offers a shortcut to only one
aspect of a much larger task.
it looks as though this code always runs in mp1. here's the history:
http://marc.theaimsgroup.com/?l=apache-modperl&m=90221051626217&w=2
for mp2 I think the underlying assertion is wrong - mod_perl should not be
detecting proxies on its own. apparently somebody (doug?) agreed and the
logic was moved from 'always run' in mp1 to 'run on demand' in mp2.
I see no reason to keep the 'run on demand' logic in $r->proxyreq() at all.
if you want to go through the pain of writing your own proxy from scratch
(instead of using mod_proxy) then you have all the API bits available via
the mp2 API to get the job done yourself - there is no reason mod_perl needs
to support a simplified version of proxy_detect() that I can see.
so, unless someone can convince me differently, I'm going to strip away this
logic and shift $r->proxyreq() back into an autogenerated accessor/mutator,
probably toward the end of the week.
so, speak up :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
