Check the manuals discussion of how a "worker" is indirectly configured.
Hi Yann,
A CORRECTION.re. what I said about "ProxySet keepalive=On/Off".
I tested again, because I couldn't exactly remember if, when I tested previously, I had commented out the ProxySet directive completely, OR if I had just changed "ProxySet keepalive=On" to "ProxySet keepalive=Off".
So the correction is that:
- If ProxySet is commented out completely, then Apache sends "Connection: close" to the backend (Sharepoint) server
- If "ProxySet keepalive=On", then Apache sends "Connection: keep-alive" to the backend server
- If "ProxySet keepalive=Off", then Apache sends "Connection: keep-alive" to the backend server
In other words regardless of whatever ProxySet keepalive was set to "On" or "Off", Apache sent "Connection: keep-alive" to the back end server.
On the other hand, if the "ProxySet" was commented out completely, then Apache sent "Connection: close" to the backend server.
Re. the last part of your message, are you saying if the httpd was compiled with MPM: prefork, that then the "proxy-initial-not-pooled" would let the Apache proxy work for NTLM and no need for the "aside" connections functionality?
FYI, I wanted to let you know that I checked, and our httpd was built with MPM: prefork.
Thanks!
Jim
--------------------------------------------
On Tue, 10/27/15, Yann Ylavic <ylavic.dev@xxxxxxxxx> wrote:
Subject: Re: Persistent proxied connections with Apache 2.4.x?
To: users@xxxxxxxxxxxxxxxx, "o haya" <ohaya@xxxxxxxxx>
Date: Tuesday, October 27, 2015, 5:52 PM
Hi Jim,
On Tue, Oct 27, 2015 at 1:57
AM, o haya <ohaya@xxxxxxxxx.invalid>
wrote:
>
> 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.
That's really weird, I can't see
anything in the code that can provoke this.
"ProxySet keepalive=On" really only
issues a setsockopt(SO_KEEPALIVE,
on) for
the backend socket, whereas HTTP keepalive (Connection:
keep-alive/close") is rather controlled by
"ProxySet disablereuse=On"
or
SetEnv's like force-proxy-request-1.0 and
proxy-nokeepalive.
Will test this because it
would be an unexpected behaviour (given that
keepalive=off is the default)...
>
>
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?
Yes, each request on the same connection should
contain the same
"Authorization: NTLM
<authenticator>" header finally negotiated for
that connection, otherwise the NTLM server will
respond with a status
401 (IIRC) to
renegotiate a new authenticator.
They may be
NTLM implementations that require the authenticator for
the first request only (actually until the
third one due to the
client's three-step
handshake), but this is even worse because from
there it becomes quite likely that any
multiplexer on the route may
not only break
NTLM (make it renegotiate again and again) but possibly
mixup sessions since subsequent requests could
"steal" the session
(authenticator) of the first/previous user
authenticated...
>
>
> 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?
I'm afraid yes, but with
MPM prefork! (see below)
>
> I must be doing a lot
of "praying", because so far I am not able to
cause a problem, at least trying to run 3 different
clients. I don't think that I can actually get the
NTLM authentications to occur simultaneously, but I'm
pretty sure the sessions are simulataneous, at least part of
the time, but even then, the pages seem for all 3 browsers
seem to be appearing correctly :(...
This may be due to the small number of
connections reaching different
processes,
rather than different threads in the same process, or are
you using the prefork MPM?
I should have think about "prefork"
before, sorry for that (you
mentioned 2.4.x
which made me sadly forget about prefork), but I
indeed realize now that it is very likely to
work for NTLM when
proxy-initial-not-pooled
is used: no chance that an established
backend connection gets reused underneath the
current client
connection (i.e. the session
for NTLM).
But with any
other threaded MPM (event, worker, windows, ...), if you
try to forcibly make httpd run with a single
process (either with
"StartServers
1"+"ServerLimit 1", or simply by using the
-DONE_PROCESS
or -X arguments on the command
line), you may reach the concurrency
issue
quite rapidly with few client connections.
So if the prefork MPM is an
option for you (and it works as I assume
it
should), I would definitely recommend using it for NTLM,
otherwise
I'm afraid you are stuck with
the kind of patch I proposed.
Regards,
Yann.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|