httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From o haya <>
Subject Re: [users@httpd] Persistent proxied connections with Apache 2.4.x?
Date Tue, 27 Oct 2015 05:25:17 GMT

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


On Mon, 10/26/15, o haya <> wrote:

 Subject: Re: [users@httpd] Persistent proxied connections with Apache 2.4.x?
 To: "" <>
 Cc: "O. Haya" <>
 Date: Monday, October 26, 2015, 8:57 PM
 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
 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
 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
 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
 Is that
 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
 Original Message -----
 From: Yann Ylavic
 o haya <>
 Sent: Monday, October 26,
 2015 6:48 PM
 Subject: Re: [users@httpd] Persistent
 proxied connections with Apache 2.4.x?
 Hi Jim,
 for the late, I'm not much online these days.
 On Sun, Oct 25, 2015 at 9:54
 PM, o haya <>
 > - 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.
 keepalive=On" is about TCP keepalive (system probes
 prevent long living TCP connections from
 being dropped by gateways,
 i.e. the
 socket's SO_KEEPALIVE option), and has nothing to do
 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>
 (as opposed to eg. a RewriteRule [P]), so you don't need
 configure anything special to get it
 (whereas on the contrary
 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.
 allows to always create a new connection to the backend for
 any new
 connection from the client, or said
 differently, it prevents an
 backend connection (kept alive) from being reused in this
 case (see [*] below for the real goal of
 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
 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
 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
 gateway before it to do the same (yes, proxying NTLM may
 hazardous, one single multiplexor on the
 route and things get messed
 That's what the "aside
 connections" patch does, it can create
 connections aside from the backend pool (based
 on the "proxy-aside-c"
 variable, settable with SetEnv[If] or a RewriteRule, eg.
 when "RewriteCond %{HTTP:Authorization}
 ^NTLM"), and maintain them by
 connection so that all the requests on this connection
 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.
 [*] 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
 its side) and can then resend the same
 request, it will not do this
 for newly
 established connections, and hence
 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:
 For additional commands, e-mail:
 To unsubscribe, e-mail:
 For additional commands, e-mail:

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

View raw message