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]
