On Mar 12, 2004, at 5:12 PM, Stas Bekman wrote:
John D.Lima wrote:*snip*
For clarity (?): my PerlPreConnectionHandler works great on browser requests
coming into the proxy, but it runs again when the server response to the proxied
request returns _to the proxy_. In this server response case I want to do
something slightly different based on the _server's_ IP. But I don't know how to
easily determine if this (server response) connection is actually due to the
proxy's own subrequest, and not another client browser connecting.
I don't think that qualifies as an Apache sub-request. Are you talking about "sub-request" to a remote server? If it's a local subrequest, it won't use a new connection, and therefore won't invoke PerlPreConnectionHandler.
yep, my mistake for calling it a subrequest...
If that's a remote request (like LWP'ing), why do you say that the response from the remote server creates a new connection?
Yes, this is (mostly) the case. The remote server response to the proxy is apparently
due to mod_proxy's action just after the fixup phase of the original request into the
proxy. I'm saying the remote server response appears to make another connection to the
proxy because the same PerlPreConnectionHandler runs a second time. Here's what I see:
CLIENT: sends request through proxy.
PROXY:
1 my PerlPreConnectionHandler runs
* debug shows CLIENT IP
* I set a connection note for later
2 various HTTP phases run...
3 my PerlFixupHandler runs
* I see my connection note from earlier CLIENT connect
4 <mod_proxy proxies>
5 my PerlPreConnectionHandler runs *again*
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* debug shows REMOTE SERVER IP
* there is NO connection note
* I set a (different) connection note
6 my RequestOutputFilter runs
* I see my connection note from ealier CLIENT connectIn the above PROXY (4), it appears that mod_proxy dutifully proxies the CLIENT request to the REMOTE SERVER;
In PROXY (5), the PROXY receives the REMOTE SERVER response -- where it definitely runs my PerlPreConnectionHandler. I believe this is a different connection than that seen in the earlier run of my PerlPreConnectionHandler.
In PROXY (6), just as the proxy is going to send the response to the client, I see that indeed, the connection note is from the first run of my PerlPreConnectionHandler from the original CLIENT connect.
In any case, I don't think you can gain anything useful besides IP during the preconnection phase.
I want to do something -- based on client IP -- at client connections _to the proxy_,
and I want to do something *else* -- based on the (remote) server's IP -- with the
server response to the proxied request back through the proxy. Both these actions
are from the proxy perspective.
My workaround for now is to run my IP-based stuff from the PerlPostReadRequestHandler.
But while allowing the proxy to do something based on the client IP early on, this
precludes the possibility of also doing something IP-based with the remote server
response traveling back through the proxy.
It would seem the PerlPreConnectionHandler catches both. BUT how would I distinguish
between the two, aside from IP?
Cheers, -jd.
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
