[EMAIL PROTECTED] wrote:
> If mod_proxy IS updating the new req->conn_rec->proxy conn_rec
> duplicate instead of the original then what happens to legacy
> modules that depend on first-level conn_rec to always hold the
> right info even across keep-alives?
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.
This downstream -> proxy connection already exists now, it just needs to
be kept across more than one upstream request, instead of being turfed
out like it is now.
> Any transport layer module such as mod_throttle absolutely
> depends on the original req->conn_rec holding accurate info
> across all requests being 'kept alive'.
mod_throttle would only be interested in throttling data over the server
-> client connection, and not the downstream -> proxy connection.
Of course it doesn't stop someone making mod_proxy aware of the
mod_throttle and using it to throttle connections between remote servers
and Apache, but this would require a modification to mod_proxy, not a
modification of mod_throttle.
> IBM has rewritten BUFF.C and they have made lots of changes
> to the original conn_rec itself. Things like the WIN32 handles
> have been eliminated and all the client->fd stuff changed to
> client->pfd. Is the addition of this duplicate conn_rec which is
> unaware of the IBM changes to conn_rec going to break IBMHTTPD
> right out of the box?
This patch is for 2.0 - I though buff.c was history? (The proxy no
longer uses buff.c).
> If it's just some kind of 'read-only' thing for mod_proxy I guess
> it's moot but is that what it really is? Just a memory bookmark?
Pretty much...
Regards,
Graham
--
-----------------------------------------
[EMAIL PROTECTED] "There's a moon
over Bourbon Street
tonight..."
