httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 39673] mod_proxy opens connections that disturb NTLM
Date Thu, 26 Sep 2013 18:39:26 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=39673

--- Comment #16 from Yann Ylavic <ylavic.dev@gmail.com> ---
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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message