httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Woodworth" <>
Subject Issues with mod_proxy_http, keep-alive, and SSL
Date Wed, 09 Jan 2008 00:10:41 GMT

I have a couple issues with mod_proxy:

1) HTTP Keep-Alive on an SSL Connection:

In the source for Apache 2.2.6, around line 1704 of
modules/proxy/mod_proxy_http.c there is this code that causes HTTPS
connections to not use Keep-Alive's:

backend->is_ssl = is_ssl;
     * TODO: Currently we cannot handle persistent SSL backend connections,
     * because we recreate backend->connection for each request and thus
     * try to initialize an already existing SSL connection. This does
     * not work.
    if (is_ssl)
        backend->close_on_recycle = 1;

Looking in the same function in the latest Apache 2.0.x source, in
file modules/proxy/proxy_http.c around line 1081, the check for
setting close_on_recycle doesn't exist (there is no close_on_recycle
in the source).

I'm not intimately familiar with the differences between mod_proxy in
2.0.x and 2.2.x, but does this mean that the bug described (and
prevented) above in the 2.2.6 code (Keep-Alive persistent connections
with SSL in mod_proxy won't work with the current 2.2.6 design, and
are thus prevented) is still an issue (was never fixed) in 2.0.x?

2) Using Apache 2.2.6, mod_proxy opens a new connection for each
request being proxied:

This is the same exact problem that is described in this bug from 2006
(except our backend isn't JBoss, it's just another Apache web server):

To summarize, if a client (A) requests a keep-alive connection to our
Apache proxy (B) (running httpd 2.2.6), mod_proxy still opens a new
connection to the back-end (C) for each request coming from the
client, even though the client has keep-alive connections open.

Simple scenario:
I connect from A to B over a single connection (one socket) and use
HTTP/1.1 keep-alive requests to GET 4 URLs.  For each request that A
sends B over that single connection, B creates a new request to C.  I
would expect only one connection to be opened from B to C, to mirror
what A is requesting of B.

This problem, described in bug 38602, was solved for that individual
with the patch made at that time that is in the code for 2.2.6.  So
it's strange that I'm seeing the same issue now.

Anyone have any insight here?


View raw message