Am 2021-11-27 um 11:01 schrieb Oleg Kalnichevski:
On Fri, 2021-11-26 at 18:39 +0100, Michael Osipov wrote:
Am 2021-11-23 um 20:14 schrieb Oleg Kalnichevski:
Folks
Here's my proposal
HttpClient 5.2:
* Announce the plan to deprecate and eventually remove NTLM support
and experimental SPNEGO / Kerberos support
* Ask downstream projects to get in touch with us. Invite
interested
parties to participate in Kerberos support improvements
OK for me.
HttpClient 5.3:
* Make NTLM / SPNEGO / Kerberos disabled by default requiring an
explicit opt-in from the user. Mark respective implementations
deprecated.
Also OK for me also. I have explicitly disabled SPNEGO for Wagon
some
time ago. It simply did not make any sense.
* Remove stateful connection support
^^^^^^^^^^^^^^^^^^^^^^
This contradicts the option still to explicitly enable to
providers.
Did you mistype?
Hi Michael
What I propose is that the support for connection state tracking be
removed in 5.3. It is an extra security mechanism presently used by
NTLM only. It adds a lot of otherwise unnecessary complexity to the
connection pooling logic and the APIs. I would like to get rid of it
sooner.
I see, I am completely unaware of this code, frankly. But when this is
removed, how is the NTLM scheme going to work at all? It requires
connection tracking for sure. Sorry for playing stupid, but you code
knodledge is magnitudes apart from me.
I hope that the curent NTLM module is explicitly excluded from HTTP/2
because it is not compatible with concurrent streams on one TCP
connection. See
https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10/http2-on-iis#when-is-http2-not-supported
Will you prepare a PR for this somehwere next year?
* Invite interested parties to participate in Kerberos support
improvements
HttpClient 6.0:
* Remove NTLM support
* Remove SPNEGO / Kerberos support if still broken
Can you answer my previous request?
What is important to know for you when you want to remove code: The
security context loop is always client initiated and required to be
completed by a token sent from the server with the response unless
it
is 401/407. So the HttpClient needs to store the context somewhere
until it receives the response, completes security context and
frees
the security context. This is on a per-request basis. If the
context
is not completed with the response then the authentication should
not
be trusted, either an exception should be through or a
warning/error
must be logged.
Will this still be possible for SPNEGO to be implemented properly
after
the remove of stateful connection support?
Of course. There will be no changes to the Auth APIs. It will always be
possible to add NTLM and Kerberos as extra authentication schemes if
desired.
Great, that is what I wanted to know whether we are still able to make
things right in the future.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
