[jira] [Updated] (HTTPCLIENT-2315) Inconsistent observance of system properties when using HttpClients.createSystem

2024-01-05 Thread Oleg Kalnichevski (Jira)


 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-2315:
--
Fix Version/s: 5.3.1

[~vitorcd] I will take a look.

Oleg

> 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
> Fix For: 5.3.1
>
>
> 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



[jira] [Updated] (HTTPCLIENT-2315) Inconsistent observance of system properties when using HttpClients.createSystem

2024-01-05 Thread Vitor Dantas (Jira)


 [ 
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: