Eric, Sorry, but this time, I'm not quite sure what (which aspect of the discussion) you're referring to?
Jim -------------------------------------------- On Tue, 10/27/15, Eric Covener <cove...@gmail.com> wrote: Subject: Re: [users@httpd] Persistent proxied connections with Apache 2.4.x? To: users@httpd.apache.org Date: Tuesday, October 27, 2015, 7:02 PM Check the manuals discussion of how a "worker" is indirectly configured. On Tue, Oct 27, 2015, 6:55 PM o haya <oh...@yahoo.com.invalid> wrote: 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....@gmail.com> wrote: Subject: Re: [users@httpd] Persistent proxied connections with Apache 2.4.x? To: users@httpd.apache.org, "o haya" <oh...@yahoo.com> Date: Tuesday, October 27, 2015, 5:52 PM Hi Jim, On Tue, Oct 27, 2015 at 1:57 AM, o haya <oh...@yahoo.com.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-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
