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
