On Sun, 2022-09-11 at 19:35 +0200, Michael Osipov wrote: > Am 2022-09-11 um 19:24 schrieb Oleg Kalnichevski: > > Folks > > > > There has been surprisingly very few bug reports for the 5.2 > > series, > > which can be either a bad thing or a good thing depending on how > > one > > looks at it. Anyway, I see no reason to delay 5.2 GA any longer. I > > would like to get HC 5.2 GA released by October unless someone > > objects. > > Agree! > > > While I am at it here is my personal development plan for the 5.3 > > series > > > > 1. Deprecate and disable NTLM by default. Make it opt-int at your > > risk > > feature with no support. > > > > 2. Deprecate and disable Kerberos by default. Make it opt-int at > > your > > risk feature with no support. > > > > 3. Remove connection state tracking by the connection pool > > implementations primarily required for NTLM and Kerberos. Both > > schemes > > actually violate the general HTTP protocol philosophy of being > > state- > > less. This would greatly simply the connection management logic and > > make it possible for us to use third-party connection pool > > implementations such as Commons Pool. > > If you remove this, how is the above (1, 2) supposed to work when > enabled? > > I am able in the future to properly implement SPNEGO? Which is one > token > from the client and one token back from the server to complete the > security context? I other word, then the GSS context is created and > the > request is sent, the context needs to be stored and retrieved with > the > response to complete it and then dispose it. See also [1] >
Of course, one can still still implement state-full authentication schemes. Nothing is going to change in the protocol handling layer. However connection pools would no longer track connection state. Proper user context separation will become the responsibility of the caller, not of HttpClient. In other works the caller will have to make sure different users have different connection pools. Oleg > > PS: Travis CI sucks. I am almost prepared to remove any use of > > their > > services altogether. > > You should have dropped this much much sooner. > > M > > [1] https://www.rfc-editor.org/rfc/rfc7546#page-6 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
