Hi Yann,
Thank you for responding (with lots of info!).
First of all, I have to apologize for top-posting. I am using Yahoo mail, and it doesn't seem to allow quoted responses, which makes things kind of difficult (i.e., very difficult to intersperse comments since they don't mark the quoted email).
First of all, as a kind of an aside remark (sorry for the "pun" :)), from my testing, it appears that if I have "ProxySet keepalive=On" inside a <Proxy>....</Proxy>, then the requests to the backend all have "Connection: Keep-Alive" in the requests headers going to the backend server (a SharePoint server). Conversely if "ProxySet keepalive=Off" is inside the <Proxy>...</Proxy>, the HTTP requests to the backend have HTTP request header "Connection: closed". In other words, the "ProxySet keepalive=On/Off" appears to be able to control whether a "Connection: keep-alive" vs. "Connection: closed" gets sent in a HTP request header to the backend.
I am NOT trying to dispute what you said about the "ProxySet" being only about "TCP keepalive", but just letting you know what I was seeing during testing and also maybe I'm misunderstanding what you meant when you were saying "TCP keepalive" vs. "HTTP keepalive"?
Next: I think I kind of understood about the proxy-initial-not-pooled setting ==> a new connection from the client always connected to the backend via a new Apache-to-backend connection, but I didn't realize that NTLM meant that all the requests SUBSEQUENT to the NTLM authentication had to ALSO go to the backend via the SAME connection.
Is my interpretation of what you said correct?
I have only been testing one client test at-a-time so far, so probably that was why my testing so far with proxy-initial-not-pooled and NTLM worked, i.e., if there had been multiple clients all authenticating and going to the same SharePoint server, and if I'm understanding what you were saying about the requests going over the same connection that was used for the NTLM authentication, my testing would probably have failed.
Is that correct?
Now, I am really glad I asked about this (and that Eric referred me to your "aside connection" discussion). I will have to raise this with my colleagues, as it appears that the "proxy-initial-not-pooled" setting will not work for any kind of production type situation?
Thanks!
Jim
----- Original Message -----
From: Yann Ylavic <ylavic.dev@xxxxxxxxx>
To: users@xxxxxxxxxxxxxxxx; o haya <ohaya@xxxxxxxxx>
Cc:
Sent: Monday, October 26, 2015 6:48 PM
Subject: Re: Persistent proxied connections with Apache 2.4.x?
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|