[
https://issues.apache.org/jira/browse/HTTPCLIENT-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18015147#comment-18015147
]
Jon Harper commented on HTTPCLIENT-2381:
----------------------------------------
Hi Arturo,
thanks for working on this. I looked at and tried
https://github.com/arturobernalg/httpcomponents-client/tree/HTTPCLIENT-2381
from https://github.com/apache/httpcomponents-client/pull/680/files
Unfortunately, I don't think it works for me. In your proposed approach the new
behavior of looking up the environment variables is only active in
SystemDefaultRoutePlanner so HttpClients.createDefault()`does not benefit from
it and most software ends up being impossible to use behind a mandatory proxy
because library and tool authors don't think about proxies and use
HttpClients.createDefault() instead of HttpClients.createSystem() .
Essentially I would like the http proxy to be an opt-out behavior. And if not
opted-out by the code (library or tool developper), then the user should always
be able to enable it without recompiling anything (by setting either java
system properties on the command line, or environment variables). So what I
want most is not a new source of runtime configuration for proxies like in your
changes, it's that runtime configuration is only disabled when the code
explicitly says so.
For what it's worth, your proposed changes are interesting. Although using the
environment variables is rare for java software, it is not totally unheard of
(the example I know that uses environment variables for proxy is the amazon s3
sdk) and I think it's a good thing so I would like to see more software use
these environment variables.
Cheers,
Jon
> 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: 1h 50m
> 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: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
