keepalive in 2.0.39 reverse proxy

["Dr. Ernst-Udo Wallenborn" <eu...@mail.deuba.com>]

Hi,

i'm new to this list so please forgive me if i'm asking a FAQ (i
browsed the archive and there were a few related questions but
not exactly this one).

My problem is: i am upgrading a 1.3.x SSL reverse proxy to 2.0.39
and all is fine and dandy except one thing: keepalives.

When the client is a new browser (mozilla 1.0 and IE from 5.0 upwards)
it issues a HTTP/1.1 request. This is handled by the reverse proxy as
a persistent connection both to the client and to the backend web
server. Consequently, in a tcpdump i see only about a half dozen
connections in either direction. Fine, that's just what i want.

But there is the occasional Netscape 4.7 out there, and it issues a
HTTP/1.0 request with Connection:Keep-Alive. The reverse proxy treats
it as a non-persistent connection and answers with a Connection:close.
As a result, each gif on my test page produces a new connection. In our
current 1.3.x reverse proxy we use the ap_proxy_ka.diff patch to keep
the connectio alive, being fully aware that this patch is quite a hack.

Now i can see the rationale for not treating the connection as
persistent in this case. After all, the client specifically asks for
1.0 and should not receive a response that uses 1.1-specific
features. But i would still like to have persistent connections for
old browsers, too. Is there a way to do this with apache-2.0.39?
mod_proxy would have to do two things differently: 1) answer a
1.0-Connection:Keep-Alive with a Connection:Keep-Alive and 2) not
close the connection to the client after delivering the response.

Is there a way to do this?

udo.

Re: keepalive in 2.0.39 reverse proxy

["Dr. Ernst-Udo Wallenborn" <eu...@mail.deuba.com>]

On Thu, 18 Jul 2002, Graham Leggett wrote:

>Dr. Ernst-Udo Wallenborn wrote:
>
>> Load is not the problem. Client side latency is. We could tell the
>> users to upgrade, though. Since IE has been HTTP/1.1 from 5.0 on it
>> would effectively be relevant for Netscape 4.x users only.
>
>How bad is the client side latency?


For old clients it's the difference between displaying the page after a
second or so and having to wait around 10 seconds. So it's really not critical.
I talked to a few people and it seems we will just recommend an upgrade. It's
only affecting old netscapes after all...

Re: keepalive in 2.0.39 reverse proxy

[Graham Leggett <mi...@sharp.fm>]

Dr. Ernst-Udo Wallenborn wrote:

> Load is not the problem. Client side latency is. We could tell the
> users to upgrade, though. Since IE has been HTTP/1.1 from 5.0 on it
> would effectively be relevant for Netscape 4.x users only.

How bad is the client side latency?

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm 
	"There's a moon
					over Bourbon Street
						tonight..."

Re: keepalive in 2.0.39 reverse proxy

["Dr. Ernst-Udo Wallenborn" <eu...@mail.deuba.com>]

On Mon, 15 Jul 2002, Graham Leggett wrote:
>Supporting HTTP/1.0 Keepalives was hard to do, and if my rusty memory
>serves there were issues in HTTP/1.1 with HTTP/1.0 keepalives - thus I
>didn't worry about keepalives in the HTTP/1.0 case.
>Is the resultant non-keepalive load significantly high to cause a problem?

Load is not the problem. Client side latency is. We could tell the
users to upgrade, though. Since IE has been HTTP/1.1 from 5.0 on it
would effectively be relevant for Netscape 4.x users only.

Re: keepalive in 2.0.39 reverse proxy

[Graham Leggett <mi...@sharp.fm>]

Dr. Ernst-Udo Wallenborn wrote:

> But there is the occasional Netscape 4.7 out there, and it issues a
> HTTP/1.0 request with Connection:Keep-Alive. The reverse proxy treats
> it as a non-persistent connection and answers with a Connection:close.
> As a result, each gif on my test page produces a new connection. In our
> current 1.3.x reverse proxy we use the ap_proxy_ka.diff patch to keep
> the connectio alive, being fully aware that this patch is quite a hack.

Supporting HTTP/1.0 Keepalives was hard to do, and if my rusty memory 
serves there were issues in HTTP/1.1 with HTTP/1.0 keepalives - thus I 
didn't worry about keepalives in the HTTP/1.0 case.

Is the resultant non-keepalive load significantly high to cause a problem?

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm 
	"There's a moon
					over Bourbon Street
						tonight..."