https://issues.apache.org/bugzilla/show_bug.cgi?id=39673
--- Comment #16 from Yann Ylavic <[email protected]> --- Created attachment 30887 --> https://issues.apache.org/bugzilla/attachment.cgi?id=30887&action=edit mod_proxy_http one for one connection This patch (2.4.x) associates the backend's connection with the client's one, when the env variable "proxy-1for1-connection" is defined. One can use a SetEnv or a RewriteRule like the following to get the expected result : RewriteCond %{HTTP:Authorization} ^NTLM RewriteRule ^ - [E=proxy-1for1-connection] Note: be sure to only set the env variable in a relevant Location or one can use an Authorization header to force mod_proxy in this mode, which is less efficient... Regarding the patch, the rationale is that mod_proxy can't use a backend connection from the reslist for the whole lifetime of a client connection, or the other clients would miss that backend connection during the client's Keep-Alive times. Hence the new APR_OPTIONAL_FN(ap_proxy_conn_create), used by mod_proxy_http to get an "aside" (off the reslist) connection and bind it to the client's connection (using c->conn_config and built on c->pool, once). The connection will be reused for the next requests, until the client closes (both are destroyed then). Since I don't know what is really feasible in terms of API/ABI changes in 2.4.x, ap_proxy_conn_create is private (APR_DECLAREd_OPTIONAL in proxy_util.h, which AFAICT is not public). Maybe the ap_proxy_conn_destroy/clear/close functions and the the "1for1" handling in mod_proxy_http could also be usefull for other mod_proxy_* modules, I guess this is off topic here... To preserve the API still, this patch circumvents the proxy_conn_rec's flag 'inreslist', which used to be a guard not to put back the same connection twice in the reslist, and now indicates whether the connection comes from the reslist or not. Ideally the patch should create another flag (with an API change), but anyhow this guard seems useless should the connection be released twice (the damage is done), there is still the possibility that another thread gets this connection before the second release. Finally, I would add that it is not only a NTLM compatibility problem, some devices (BigIp LTM's with some configuration IIRC), will simply refuse multiple clients (sessions) in the same TCP connection. Although this can surely be disabled on the device (and is indeed a questionable feature), some like it, and even some want mod_proxy in front of it... If the 1for1 feature worth being in mod_proxy (that way), I can provide a trunk patch too. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
