httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: [users@httpd] Persistent proxied connections with Apache 2.4.x?
Date Tue, 27 Oct 2015 21:52:43 GMT
Hi Jim,

On Tue, Oct 27, 2015 at 1:57 AM, o haya <> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message