httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: [PATCH] mod_proxy Keepalives
Date Sat, 31 Mar 2001 18:24:58 GMT wrote:

> It's hard to say whether this should be committed or not without
> seeing how it is used. Is this like 'prev' or 'next' request rec in a
> request rec?... or is it just used to 'copy' values back into the real
> req->conn_rec once a handler kicks in on a keepalive?

There is a separate conn_rec for the proxy -> downstream server
connection, apart from the conn_rec associated with the server -> client

Right now, after each request is completed, this second conn_rec is
discarded, and a new connection is set up with the second and subsequent
URLs fetched. The modification allows the downstream conn_rec to be
associated with the upstream conn_rec so that the next request need not
recreate a new connection.

The way proxy keepalives are done here is that a downstream proxy
keepalive will be only be possible if an upstream normal keepalive
exists, which in turn means that the whole keepalive transaction in both
directions is completed within the same process/thread.

There won't be a need to ever access c->proxy->proxy, because there will
only be one downstream proxy connection for each upstream normal

> Or are you doing this once a handler kicks in and 'restoring'
> the original conn_rec or something?...
> memcpy( req->conn_rec, req->conn_rec->proxy, sizeof( struct conn-rec ) );

This is pretty much what I am doing, however I've created the downstream
conn_rec using the same pool as the upstream conn_rec, so I have avoided
the memcpy.

> My concern would really be this...
> If mod_proxy is not updating req->conn_rec->proxy with connection
> related info then what happens to other modules in the chain that
> still expect critical things to be updated in the original req->conn_rec
> itself? Is req->conn_rec->proxy just a 'read only' placeholder?

The downstream proxy conn_rec is only used by the bare minimum CORE,
HTTP_IN, CORE_IN  and DECHUNK filters to suck data from the downstream
server. After being received the data is then passed into the normal
upstream conn_rec and filter chain like everything else, and is handled
like any normal request.

I posted the first revision of the full patch on friday for comment, but
I have since fixed a problem I was having with dechunking support - I'll
post the full revised patch again later tonight.

-----------------------------------------		"There's a moon
					over Bourbon Street

View raw message