[
https://issues.apache.org/jira/browse/HTTPCLIENT-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitor Dantas updated HTTPCLIENT-2315:
-------------------------------------
Description:
During the startup of my application, I configure an SSLContext with additional
certificates and set it as a global default using SSLContext.setDefault.
Subsequently, all requests created without explicit configuration can
successfully connect to servers requiring these certificates. This setup
functions seamlessly with various APIs I currently utilize:
* java.net.URLConnection (e.g., URLConnection conn = url.openConnection())
* java.net.http.HttpClient (e.g., HttpClient client =
HttpClient.newHttpClient())
* org.springframework.ws.client.core.WebServiceTemplate (e.g.,
WebServiceTemplate webServiceTemplate = new WebServiceTemplate())
Previously, this approach worked flawlessly with
org.apache.httpcomponents:httpclient:4.5.14, where clients were created using:
HttpClient httpclient = org.apache.http.impl.client.HttpClients.createSystem();
However, issues arise (due to missing certificates) after upgrading to
org.apache.httpcomponents.client5:httpclient5:5.3 and creating clients with:
HttpClient httpclient =
org.apache.hc.client5.http.impl.classic.HttpClients.createSystem();
When creating a client with
HttpClientBuilder.create().useSystemProperties().build() or more succinctly
with HttpClients.createSystem(), the expectation is that system properties are
observed throughout.
However, upon inspecting the code, it becomes evident that the connection
manager underneath is created using
PoolingHttpClientConnectionManagerBuilder.create().build(), and not
PoolingHttpClientConnectionManagerBuilder.create().useSystemProperties().build()
as one might anticipate.
Consequently, an internal condition registers the HTTPS socketFactory using
SSLConnectionSocketFactory.getSocketFactory() instead of
SSLConnectionSocketFactory.getSystemSocketFactory(). This, in turn, results in
the creation of a new SSLContext.getInstance(SSLContextBuilder.TLS) instead of
leveraging the default one through SSLSocketFactory.getDefault().
Why is this the case? Is it possible to change this behavior so that the
configuration is simplified when one aims to use the default socket factory?
Specifically, without the need for explicit configuration of the connection
manager in such a common scenario.
was:
During the startup of my application, I configure an SSLContext with additional
certificates and set it as a global default using SSLContext.setDefault.
Subsequently, all requests created without explicit configuration can
successfully connect to servers requiring these certificates. This setup
functions seamlessly with various APIs I currently utilize:
* java.net.URLConnection (e.g., URLConnection conn = url.openConnection())
* java.net.http.HttpClient (e.g., HttpClient client =
HttpClient.newHttpClient())
* org.springframework.ws.client.core.WebServiceTemplate (e.g.,
WebServiceTemplate webServiceTemplate = new WebServiceTemplate())
Previously, this approach worked flawlessly with
org.apache.httpcomponents:httpclient:4.5.14, where clients were created using:
HttpClient httpclient = org.apache.http.impl.client.HttpClients.createSystem();
However, issues arise (due to missing certificates) after upgrading to
org.apache.httpcomponents.client5:httpclient5:5.3 and creating clients with:
HttpClient httpclient =
org.apache.hc.client5.http.impl.classic.HttpClients.createSystem();
When creating a client with
HttpClientBuilder.create().useSystemProperties().build() or more succinctly
with HttpClients.createSystem(), the expectation is that system properties are
observed throughout.
However, upon inspecting the code, it becomes evident that the connection
manager underneath is created using
PoolingHttpClientConnectionManagerBuilder.create().build(), and not
PoolingHttpClientConnectionManagerBuilder.create().useSystemProperties().build()
as one might anticipate.
Consequently, an internal condition registers the HTTPS socketFactory using
SSLConnectionSocketFactory.getSocketFactory() instead of
SSLConnectionSocketFactory.getSystemSocketFactory(). This, in turn, results in
the creation of a new SSLContext.getInstance(SSLContextBuilder.TLS) instead of
leveraging the default one through SSLSocketFactory.getDefault().
Why is this the case? Is it possible to change this behavior so that the
configuration is simplified when one aims to use the default socket factory
configured through system properties? Specifically, without the need for
explicit configuration of the connection manager in such a common scenario.
> Inconsistent observance of system properties when using
> HttpClients.createSystem
> --------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-2315
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2315
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 5.3
> Reporter: Vitor Dantas
> Priority: Minor
>
> During the startup of my application, I configure an SSLContext with
> additional certificates and set it as a global default using
> SSLContext.setDefault. Subsequently, all requests created without explicit
> configuration can successfully connect to servers requiring these
> certificates. This setup functions seamlessly with various APIs I currently
> utilize:
> * java.net.URLConnection (e.g., URLConnection conn = url.openConnection())
> * java.net.http.HttpClient (e.g., HttpClient client =
> HttpClient.newHttpClient())
> * org.springframework.ws.client.core.WebServiceTemplate (e.g.,
> WebServiceTemplate webServiceTemplate = new WebServiceTemplate())
> Previously, this approach worked flawlessly with
> org.apache.httpcomponents:httpclient:4.5.14, where clients were created using:
> HttpClient httpclient =
> org.apache.http.impl.client.HttpClients.createSystem();
> However, issues arise (due to missing certificates) after upgrading to
> org.apache.httpcomponents.client5:httpclient5:5.3 and creating clients with:
> HttpClient httpclient =
> org.apache.hc.client5.http.impl.classic.HttpClients.createSystem();
> When creating a client with
> HttpClientBuilder.create().useSystemProperties().build() or more succinctly
> with HttpClients.createSystem(), the expectation is that system properties
> are observed throughout.
> However, upon inspecting the code, it becomes evident that the connection
> manager underneath is created using
> PoolingHttpClientConnectionManagerBuilder.create().build(), and not
> PoolingHttpClientConnectionManagerBuilder.create().useSystemProperties().build()
> as one might anticipate.
> Consequently, an internal condition registers the HTTPS socketFactory using
> SSLConnectionSocketFactory.getSocketFactory() instead of
> SSLConnectionSocketFactory.getSystemSocketFactory(). This, in turn, results
> in the creation of a new SSLContext.getInstance(SSLContextBuilder.TLS)
> instead of leveraging the default one through SSLSocketFactory.getDefault().
> Why is this the case? Is it possible to change this behavior so that the
> configuration is simplified when one aims to use the default socket factory?
> Specifically, without the need for explicit configuration of the connection
> manager in such a common scenario.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
