On Tue, 2023-09-12 at 15:06 +0000, Michael Osipov wrote: > On 2023/09/12 14:53:52 Torsten Krah wrote: > > Am Dienstag, dem 12.09.2023 um 14:39 +0000 schrieb Michael Osipov: > > > How, did you expect us to write an custom JSSE provider? > > > > The old pre 4.x http components had their own http classes and did > > not > > use the JSSE base ones - if I remember rightÂ
You do not. > > - for their > > implementation, so it seemed not that unlikely, that there would be > > some custom code here, which may have that enabled (without knowing > > what would be needed to accomplish that, if I would have known, I > > guess > > I could have answered the question myself) - that's why I did ask > > the > > user mailing list, I had no time to read and understand the whole > > code > > base before ;-). > > Well, I joined the project at 4.x times. Your statement is very > likely true. It is not. > > > > That is not correct. It would be unsupported if the underlying > > > API > > > would support it, but we would not expose it. Here, it is simply > > > impossible. > > > > From a user perspective - the end result is the same, just the > > reason > > is different - it is still unsupported (because it is not possible > > with > > the current JSSE implementation HttpComponents does use) - so just > > a > > nitpick in naming it, in the end: > > > > Q: Does it work (can it be enabled) with the current code / > > implementation? > > A: no ;) > > Point taken. There is nothing stopping anyone from building their own connection socket factory (for classic i/o) or their own TLS strategy (for the async i/o) and add whatever custom TLS behavior their heart desires. One can easily plug-in custom JSSE implementations by the way if the default one shipped with the JRE is not good enough. We support Conscrypt JSSE based TLS strategies out of the box sicne 5.0. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
