[
https://issues.apache.org/jira/browse/HTTPCLIENT-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18055239#comment-18055239
]
ASF subversion and git services commented on HTTPCLIENT-2381:
-------------------------------------------------------------
Commit ab404c46af3bb68349ad8eca364f3e4e57727b6b in httpcomponents-client's
branch refs/heads/master from Ryan Schmitt
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=ab404c46a ]
[HTTPCLIENT-2381] Respect system properties by default
The practical effect of this change is that default JVM configuration
for key stores (for mutual TLS) and proxy selection will be respected by
default. This change has two goals.
First, applications and libraries built on the client will work with
proxies much more reliably, since their authors no longer need to opt in
to a non-default setting in order for things like proxies to be
configurable in the usual manner (i.e. without code changes).
Second, this change, along with the change in 5.6 to make `BUILTIN` the
default `HostnameVerificationPolicy`, makes the client's configuration
philosophy fully consistent across all supported features. To wit:
1. HttpComponents _itself_ is always configured programmatically and
does not directly read system properties to obtain config values.
2. For a given feature, the default behavior is to delegate to the JDK
implementation. This implementation may support out-of-band
configuration via system properties, static methods, the
`java.security` file, system-wide OS configuration, etc.
3. This delegation behavior can be overridden by a programmatic config
option, either to directly customize the JDK-supplied implementation
or to supply an alternate implementation.
This table shows what this philosophy looks like concretely across
various features:
| Feature | Default JDK behavior |
Example JDK config property | Override strategy
|
| --------------------- | ---------------------------------------------- |
--------------------------- |
-------------------------------------------------------------------------------
|
| Trust store | Load from OS |
`javax.net.ssl.trustStore` | Set a `TrustManager[]`
|
| Key store | Load nothing |
`javax.net.ssl.keyStore` | Set a `KeyManager[]`
|
| Hostname verification | Run `HostnameChecker` from `sun.security.util` | None
| Set a `HostnameVerifier` and
`HostnameVerificationPolicy` |
| Proxy config | Use system properties or load from OS |
`java.net.useSystemProxies` | Set a `ProxySelector` or `HttpRoutePlanner`
|
| Client cipher suites | Send all supported cipher suites |
`java.security.properties` | Set an `SSLContext`
|
| IP family selection | Prefer IPv6 |
`java.net.preferIPv4Stack` | Set a `DetachedSocketFactory` or `DnsResolver`,
call `setUnixDomainSocket`, etc |
| DNS resolution | Use built-in resolver |
`networkaddress.cache.ttl` | Set a `DnsResolver`
|
See also the previous discussion at:
https://github.com/apache/httpcomponents-client/pull/773
> Allow environment proxy settings by default or strongly document this decision
> ------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-2381
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2381
> Project: HttpComponents HttpClient
> Issue Type: Wish
> Reporter: Jon Harper
> Priority: Minor
> Labels: volunteers-wanted
> Fix For: Stuck
>
> Time Spent: 8h 20m
> Remaining Estimate: 0h
>
> Hi,
> projects keep getting burned by the fact that is it impossible to set runtime
> environment variables to use http proxies. My personal latest frustration is
> with central-publishing-maven-plugin which is unusable in many companies
> where using a corporate proxy is mandatory (no direct internet access). This
> has happened times and times again, for example.
> https://github.com/spring-cloud/spring-cloud-vault/issues/75
> https://github.com/spring-projects/spring-boot/issues/35815
> It seems like every time this happen, people then just add the required code
> to be able to set an environment variable or a system property, after the
> initial pain of beeing blocked by this problem.
> Should this project be changed so that by default without code you can use
> system properties to configure the proxy ? That is have systemProperties=true
> everywhere and replace useSystemProperties() by disableSystemProperties().
> Using the same system properties as the jdk clients is the simplest, but if
> needed it would still provide benefit if it were entirely new system
> properties (so no backwards compatibilty as these properties would never have
> been set), at least people would be to use proxies without changing some code
> or worse changing some third party library.
> An alternative would be to add a prominent note in the docs to warn that
> unless specific code is added, using a proxy is impossible and makes the
> client unusable in many corporate contexts. Maybe also document why this
> design decision was made, what are the advantages of doing this so that users
> at least understand what they gain in exchange for their suffering.
> Thanks in advance,
> Jon
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
