You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@gmail.com> on 2004/08/14 17:38:42 UTC
proxy CONNECT and recent 2.1-dev proxy enhancements
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"
get back:
00000000: 48545450 2F312E30 20323030 20436F6E HTTP/1.0 200 Con
00000010: 6E656374 696F6E20 45737461 626C6973 nection Establis
00000020: 6865640D 0A50726F 78792D61 67656E74 hed..Proxy-agent
00000030: 3A204170 61636865 2F322E30 2E35302D : Apache/2.0.50-
00000040: 64657620 28556E69 78292044 41562F32 dev (Unix) DAV/2
00000050: 0D0A0D0A
send "GET / HTTP/1.1\r\nHost: foo\r\n\r\n"
get back normal response (here is start):
00000000: 48545450 2F312E31 20323030 204F4B0D HTTP/1.1 200 OK.
00000010: 0A446174 653A2053 61742C20 31342041 .Date: Sat, 14 A
00000020: 75672032 30303420 31353A32 333A3033 ug 2004 15:23:03
00000030: 20474D54 0D0A5365 72766572 3A204170 GMT..Server: Ap
00000040: 61636865 2F322E30 2E35302D 64657620 ache/2.0.50-dev
00000050: 28556E69 78292044 41562F32 0D0A4C61 (Unix) DAV/2..La
00000060: 73742D4D 6F646966 6965643A 20467269 st-Modified: Fri
00000070: 2C203034 204D6179 20323030 31203030 , 04 May 2001 00
00000080: 3A30313A 31382047 4D540D0A 45546167 :01:18 GMT..ETag
00000090: 3A202263 6336622D 3562302D 34303434 : "cc6b-5b0-4044
needs AllowConnect directive specifying whatever port you wish to CONNECT to
Re: proxy CONNECT and recent 2.1-dev proxy enhancements
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 10:56 AM 8/16/2004, jean-frederic clere wrote:
>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.
No, but I just realized that failover for a missing back-end server
could be a very good thing. Consider esp. an e-mail proxy where you
want to offer several arbitrary smtp back ends, all configured to
deliver email from an identical list of domains.
But it certainly isn't a high-priority issue, compared with getting
the entire modules/proxy/ tree stabilized.
Bill
Re: proxy CONNECT and recent 2.1-dev proxy enhancements
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Jeff Trawick wrote:
> On Mon, 16 Aug 2004 13:20:41 +0200, jean-frederic clere
> <jf...@fujitsu-siemens.com> wrote:
>
>>
>>Jeff Trawick wrote:
>>
>>>On Mon, 16 Aug 2004 12:16:02 +0200, jean-frederic clere
>>><jf...@fujitsu-siemens.com> 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.
Re: proxy CONNECT and recent 2.1-dev proxy enhancements
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, 16 Aug 2004 13:20:41 +0200, jean-frederic clere
<jf...@fujitsu-siemens.com> wrote:
>
>
> Jeff Trawick wrote:
> > On Mon, 16 Aug 2004 12:16:02 +0200, jean-frederic clere
> > <jf...@fujitsu-siemens.com> 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?
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?
Re: proxy CONNECT and recent 2.1-dev proxy enhancements
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Jeff Trawick wrote:
> On Mon, 16 Aug 2004 12:16:02 +0200, jean-frederic clere
> <jf...@fujitsu-siemens.com> 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.
Re: proxy CONNECT and recent 2.1-dev proxy enhancements
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, 16 Aug 2004 12:16:02 +0200, jean-frederic clere
<jf...@fujitsu-siemens.com> 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.
Re: proxy CONNECT and recent 2.1-dev proxy enhancements
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
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?
>
> get back:
>
> 00000000: 48545450 2F312E30 20323030 20436F6E HTTP/1.0 200 Con
> 00000010: 6E656374 696F6E20 45737461 626C6973 nection Establis
> 00000020: 6865640D 0A50726F 78792D61 67656E74 hed..Proxy-agent
> 00000030: 3A204170 61636865 2F322E30 2E35302D : Apache/2.0.50-
> 00000040: 64657620 28556E69 78292044 41562F32 dev (Unix) DAV/2
> 00000050: 0D0A0D0A
>
> send "GET / HTTP/1.1\r\nHost: foo\r\n\r\n"
>
> get back normal response (here is start):
>
> 00000000: 48545450 2F312E31 20323030 204F4B0D HTTP/1.1 200 OK.
> 00000010: 0A446174 653A2053 61742C20 31342041 .Date: Sat, 14 A
> 00000020: 75672032 30303420 31353A32 333A3033 ug 2004 15:23:03
> 00000030: 20474D54 0D0A5365 72766572 3A204170 GMT..Server: Ap
> 00000040: 61636865 2F322E30 2E35302D 64657620 ache/2.0.50-dev
> 00000050: 28556E69 78292044 41562F32 0D0A4C61 (Unix) DAV/2..La
> 00000060: 73742D4D 6F646966 6965643A 20467269 st-Modified: Fri
> 00000070: 2C203034 204D6179 20323030 31203030 , 04 May 2001 00
> 00000080: 3A30313A 31382047 4D540D0A 45546167 :01:18 GMT..ETag
> 00000090: 3A202263 6336622D 3562302D 34303434 : "cc6b-5b0-4044
>
> needs AllowConnect directive specifying whatever port you wish to CONNECT to
>
>