I think we should honor JVM system properties by default. IMO, when HttpClient-based tools are deployed behind corporate proxies, users expect to solve connectivity via JVM/container configuration rather than changing library code, with explicit builder configuration still taking precedence
Arturo On Mon, Nov 24, 2025 at 6:46 PM Oleg Kalnichevski <[email protected]> wrote: > On Mon, 2025-11-24 at 12:36 -0500, Gary Gregory wrote: > > On Mon, Nov 24, 2025, 12:02 Oleg Kalnichevski <[email protected]> > > wrote: > > > > > On Mon, 2025-11-24 at 14:22 +0100, Jon Harper wrote: > > > > Hi, > > > > in > > > > > > > > https://issues.apache.org/jira/projects/HTTPCLIENT/issues/HTTPCLIENT-2381 > > > > I was suggested to "Let’s have the original reporter kick off a > > > > [DISCUSS] on dev@" > > > > > > > > In summary, I think the current API ( HttpClients.createDefault() > > > > ) > > > > invites developers to write code that can't work for users in > > > > filtered > > > > corporate networks with mandatory http proxies to access > > > > external. > > > > Said developers test their code in unrestricted network and > > > > release > > > > their software or libraries. Later a user tries to use the > > > > software > > > > or > > > > library and is just in a dead end. > > > > > > > > What do you think of flipping this around, make the simple code > > > > that > > > > most developers actually write work with proxies by default, and > > > > have > > > > developers go the extra mile to prevent their users from > > > > activating > > > > proxies if that's the requirement ? > > > > > > > > There are more details and discussions in the jira issue: > > > > - should this runtime proxy activation come from java system > > > > properties (-DproxyHost and friends) > > > > - should this runtime proxy activation come from environment > > > > variables ($http_proxy and friends) > > > > - is it always safe to read this runtime configuration "This > > > > could > > > > literally get [the process] killed" > > > > > > > > > For those you do not have the time to read the ticket, TLDR: > > > > > > The decision to not read system properties (initially it was "at > > > all" > > > and later it became "by default") was taken literally 20 year ago. > > > The > > > rationale, which was quite sound at that time, is no longer > > > applicable > > > or valid in the present. > > > > > > I asked Jon to start this discussion and based on its outcome I > > > would like to start a lazy vote to have this policy reversed for > > > all > > > system properties, not just proxy settings. > > > > > > I think we need to define something like (for specific features): > > > > - the default behavior is whatever default builders and constructors > > do > > today > > - the above can be overriden by using different builder inputs or > > non-default constructors, or > > - the above can be overridden from system properties > > > > I am not sure how this differs from the initial proposal. > > > > What gets more interesting is that in container environments > > (Docker), it's > > common to set or override settings from environment variables. > > Absolutely true. The use of environment variables for passing > configuration parameters to JRE processes become more and more common. > Unfortunately, as far as I know, none of those environment variables > have been standardized / defined by Oracle. > > > > So we should > > allow configuration from environment variables as well. > > > > We do not disallow it, do we? Again, i am not sure what you are > proposing. > > Oleg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
