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