On Tue, 20 Feb 2024 06:24:49 GMT, Jaikiran Pai <[email protected]> wrote:
> Can I please get a review for this change which proposes to fix > https://bugs.openjdk.org/browse/JDK-8326233? > > As noted in the issue, when the `java.net.HttpClient.Builder` is configured > with a `SSLParameters` instance whose `needClientAuth` is set to true, then > it is expected that the `HttpClient` that's built from such a build will have > its `SSLParameters` with `needClientAuth` as `true` and `wantClientAuth` as > `false`. But due to a bug in the internal implementation of a the > `HttpClient`, the value for `needClientAuth` was getting reset to `false`. > The commit in this PR fixes that issue and introduces a jtreg tests which > reproduces the issue and verifies the fix. Hello Valentin, > I reported the bug. This looks good so far. Thank you for reporting that bug. I'm surprised it wasn't noticed so far. I guess not many applications use TLS client authentication when using the HttpClient. > The solution I thought about was a copy constructor for SSLParameters, that > just copies every internal field. Introducing a copy constructor in the `javax.net.ssl.SSLParameters` would be a much bigger change. Since `javax.net.ssl.SSLParameters` is part of a public API it would also mean that such a change would require a specification change (a CSR request). Specification changes are allowed but such changes have a much higher barrier to what kind of APIs (in this case the constructor) are considered useful and worthwhile. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17923#issuecomment-1953735644
