Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Deprecate the ClientBuilder.hostnameVerifier method #1161

Closed
jamezp opened this issue Jul 14, 2023 · 5 comments
Closed

Proposal: Deprecate the ClientBuilder.hostnameVerifier method #1161

jamezp opened this issue Jul 14, 2023 · 5 comments

Comments

@jamezp
Copy link
Contributor

jamezp commented Jul 14, 2023

I propose we should deprecate the ClientBuilder.hostnameVerifier(). The JDK HttpClient does not have a way to set this. It does allow this to be disabled, but it's a global setting which doesn't work well for the ClientBuilder. It could also be overridden with some custom HostnameVerifier, however that seems it could lead to security risks.

There is an open issue, DK-8213309, to enable this. However, there has been no word from the JDK team to indicate they will add this.

My assumption is this override was added for testing or internal use cases. It seems like something that could be worked around in different ways or a safer manner.

@jansupol
Copy link
Contributor

jansupol commented Jul 26, 2023

I am -1 on this one. First, even if this is not supported by the java.net.http.HttpClient, it does not mean it is not supported by other clients (HttpsUrlConnection, Apache, ...)

Jersey uses the HostNameVerifier with the HttpClient anyway, after the handshake. oops, wrong JDK client.

Jersey does not use it with HttpClient. But I am ok to update the Javadoc informing about the limited use.

@jamezp
Copy link
Contributor Author

jamezp commented Jul 27, 2023

I completely understand and respect the argument. There are ways around this for sure so it's not a huge deal, but just in case others wanted to start using the JDK's HttpClient, it just seemed worth at least putting it out there :)

@spericas
Copy link
Contributor

@jamezp Should we close this one then?

@jamezp
Copy link
Contributor Author

jamezp commented Aug 23, 2023

@spericas We can if no one else agrees they want it deprecated :)

@jamezp
Copy link
Contributor Author

jamezp commented Feb 21, 2024

Closing this as it's not agreed upon which is fine.

@jamezp jamezp closed this as completed Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants