Jeff Trawick wrote:
On Mon, 16 Aug 2004 13:20:41 +0200, jean-frederic clere
<[EMAIL PROTECTED]> wrote:


Jeff Trawick wrote:

On Mon, 16 Aug 2004 12:16:02 +0200, jean-frederic clere
<[EMAIL PROTECTED]> wrote:


Jeff Trawick wrote:


probably obvious to those doing the load balancing work, but just in case...

url in this case is ip:port, which ap_proxy_get_balancer() doesn't handle

simple working testcase in case this helps testing

connect and send "CONNECT 0.0.0.0:8080\r\n"

Do we need balancer for CONNECT?


I would think not.  My understanding is that CONNECT is just a pipe,
with no ability to keep connections open (e.g., in keepalive state) or
re-use connections already opened.



Ok, the patch is quite easy in this case.

BTW: proxy_connect.c loops when the client closes the connection, I am preparing
a patch for this problem.


good; I had a patch in my tree and went to test it this weekend but
didn't get past the balancer ;)


Index: mod_proxy.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/modules/proxy/mod_proxy.c,v
retrieving revision 1.130
diff -u -r1.130 mod_proxy.c
--- mod_proxy.c 13 Aug 2004 12:09:13 -0000      1.130
+++ mod_proxy.c 16 Aug 2004 11:13:35 -0000
@@ -611,8 +611,14 @@

    /* Try to obtain the most suitable worker */
    access_status = ap_proxy_pre_request(&worker, &balancer, r, conf, &url);
-    if (access_status != OK)
+    if (access_status != OK && r->method_number != M_CONNECT) {


could connect provide a pre-request hook that does the right thing?

There are different things:
We could be serving to another proxy in this case my patch is just a work-around and proxy_balancer.c should handle the CONNECT uri and we could have something like:


<Proxy 0.0.0.0:8080>
   BalancerMember localhost:8080
   BalancerMember pgtr0327.mch.fsc.net:8080
</Proxy>
(That means also to support this syntax).

Or to a normal proxy in this case we don't need the new logic.

if this code has to hard-code a check for M_CONNECT, why not simply
avoid the call to ap_proxy_pre_request() in the first place?



We don't want load balancing for CONNECT.

Reply via email to