httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TOKI...@aol.com
Subject Re: [PATCH] mod_proxy Keepalives
Date Sat, 31 Mar 2001 15:05:32 GMT

In a message dated 01-03-31 13:39:30 EST, Graham writes...

> The req->connection->proxy isn't a duplicate, but a completely
>  independent connection. This connection is only ever touched by the
>  filters CORE, HTTP_IN, CORE_IN and DECHUNK, so other third party filters
>  need not be aware of or care about the mod_proxy.

Roger that.

Like I said... not enough coffee earlier this AM.

Thanks for taking the time for the explanation. I had not
seen the Friday patch and I just wasn't sure if the new
conn_rec pointer was for upstream or downstream.

A conn_rec simply named 'proxy' doesn't really invoke any 
immediate understanding of what it might be for.

proxy_target might be a better name since that's what it
really is used for.

Suggestion?

Adding a new 'other side of the conversation' conn_rec
to existing conn_rec is the way to get persistence for
doubly-connected requests since conn_rec can be
preserved while request rec evaporates, but would it not
be better to name this new structure element something
a little more generic and true to what it really is such
as 'tconn' for 'target connection' or 'oconn' for 'other connection?

>From the Server's perspective r->conn is always the CLIENT
side and r->tconn would always mean 'the TARGET that the
CLIENT is doubly connected to. Might be used by mod_proxy,
might not.

The reason I make the suggestion is that conn_rec has probably
always needed this 'target connection' secondary tracking
pointer and it can have uses for things other than mod_proxy.

Heck... as long as it's on the table... I could even feature this...

#define MAX_CLIENT_TARGET_CONNECTION 10
struct conn_rec {
 ...
 int tconn_total; /* Total number of Client to target connections */
 conn_rec *tconn[ MAX_CLIENT_TO_TARGET_CONNECTIONS ];
 ...
};

That way someone could use mod_proxy AND have the ability
to have modules make alternate upstream target connections
at the same time. All you have to do is check 'tconn_total' and
grab the next 'conn_rec *tconn' so you don't interfere with
other target connection records already 'in use'.

One more suggestion?

Isn't the actual proxy target tied to config or Virtual Host dirs?
Why not add a conn_rec to the actual config info which is
also persistent across connections? I like the idea of adding
'target' connection info to client conn_rec but if mod_proxy
can just refer to it's config info for target connection stuff
then is the new item in conn_rec really needed?

Regarding BUFF and IBMHTTPD...

I have not seen the source for IBMHTTPD for Apache 2.0.
if BUFF.C is gone then they must have already re-written
the re-write to do something else since IBMHTTPD was
using an altered version of conn_rec and BUFF.C.

There are other changes/additions to conn_rec in IBMHTTPD
that were not part of the 'BUFF client' thing such as discarding
the Win32 handles from the record and the like. If conn->proxy
is just a dupe rec for the 'other' connection then this shouldn't
really break anything even in the IBMHTTPD rewrite.

Again... thanks for the explanation.

Yours...
Kevin Kiley



Mime
View raw message