Hi Jim,
sorry for the late, I'm not much online these days.
On Sun, Oct 25, 2015 at 9:54 PM, o haya <ohaya@xxxxxxxxx.invalid> wrote:
>
> - With respect to proxying NTLM authentication, does the "aside connections"
> functionality that was mentioned earlier accomplish the same thing as using
> the "Proxy keepalive=On and SetEnv proxy-initial-not-pooled"?
Shortly, no.
"ProxySet keepalive=On" is about TCP keepalive (system probes to
prevent long living TCP connections from being dropped by gateways,
i.e. the socket's SO_KEEPALIVE option), and has nothing to do with
HTTP keepalive (multiple HTTP requests sent on the same connection).
Actually, HTTP keepalive is the default for mod_proxy_http, provided
the backend is "declared" with either a ProxyPass line or a <Proxy>
block (as opposed to eg. a RewriteRule [P]), so you don't need to
configure anything special to get it (whereas on the contrary
"ProxySet disablereuse=on" can be used to disable HTTP keeplive on the
backend side).
"SetEnv proxy-initial-not-pooled" is unfortunately not fully helpful for NTLM.
It allows to always create a new connection to the backend for any new
connection from the client, or said differently, it prevents an
established backend connection (kept alive) from being reused in this
case (see [*] below for the real goal of proxy-initial-not-pooled).
But this gives no garanty on subsequent requests on the same
connection, or worse, subsequent requests on another connection...
Those may reuse any established connection in the pool, or a new
connection, depending on the first one available at the time of each
incoming request.
In other words, mod_proxy_http handles a pool of connections for each
"declared" backend independently/regardless of client-side connections
or requests (basically it's a n client connections multiplexor over m
backend connections), because the HTTP protocol *is* stateless.
And that breaks NTLM because this protocol really authenticates
connections, not requests, assuming there is one single user per
connection (sigh)...
>
> - If not, what are the differences?
So for a proxy to "work" with NTLM, it must associate a single client
connection with a single one on the/each backend side, and pray for
any gateway before it to do the same (yes, proxying NTLM may be
hazardous, one single multiplexor on the route and things get messed
up)!
That's what the "aside connections" patch does, it can create
connections aside from the backend pool (based on the "proxy-aside-c"
environment variable, settable with SetEnv[If] or a RewriteRule, eg.
when "RewriteCond %{HTTP:Authorization} ^NTLM"), and maintain them by
client connection so that all the requests on this connection (setting
the env var) will be routed to their associated backend connection.
However I don't recall all the details of the patch proposed in 2014,
I think I have a simpler/more-to-the-point one now (the previous one
was meant to be generic enough to be accepted in httpd, which did not
happen), so let me have a look when back home and attach it here.
Regards,
Yann.
[*] The goal of proxy-initial-not-pooled is to help recover from a
race-condition error where the proxy sends its request to the backend
while the latter is in the process of closing the connection
(keepalive timeout or whatever). This results in an error (502) being
returned to the client, but while the client "expects" this error on
kept alive connections (because of the same possible race condition on
its side) and can then resend the same request, it will not do this
for newly established connections, and hence proxy-initial-not-pooled
prevents this error from being fatal for the "user experience" by
avoiding the race on the backend side when the user-agent does not
expect it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|