You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Jon Harper <jo...@gmail.com> on 2025/11/24 13:22:45 UTC
[DISCUSS] HTTPCLIENT-2381 use 'runtime' proxy activation by default
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"
Cheers,
Jon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [DISCUSS] HTTPCLIENT-2381 use 'runtime' proxy activation by default
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2025-12-11 at 20:31 +0100, Oleg Kalnichevski wrote:
> On Thu, 2025-12-11 at 13:55 +0100, Jon Harper wrote:
> > Hi Oleg,
> > it sounds like a good plan. Are you looking for more discussion
> > around
> > this or is the plan decided ?
>
Please see the proposed fix:
https://github.com/apache/httpcomponents-client/pull/773
As discussed the change-set deprecates existing factory methods and
encourages the users to migrate to the new APIs with a different
behavior with regards to system properties.
Please do note the existing builder classes will behave differently
going forward and have not been deprecated. This behavioral change will
be reflected in the release notes.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [DISCUSS] HTTPCLIENT-2381 use 'runtime' proxy activation by default
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2025-12-11 at 13:55 +0100, Jon Harper wrote:
> Hi Oleg,
> it sounds like a good plan. Are you looking for more discussion
> around
> this or is the plan decided ?
I see no point in having more discussions. We are not the European
Parliament.
I will propose a change-set, ask people to review and it will either
get approved or not.
Oleg
> To me, the most important part is that the API "nudges" developers
> towards writing and shipping code that will not be unusable by users
> behind mandatory corporate proxies, thus avoiding back and forth bug
> reports and fixes between the users and developers.
> So the naming and documentation in this new API is critical.
> Cheers,
> Jon
>
> On Wed, Dec 10, 2025 at 11:25 AM Oleg Kalnichevski <ol...@apache.org>
> wrote:
> >
> > On Mon, 2025-12-08 at 17:45 +0100, Jon Harper wrote:
> > > Hi,
> > > this would break existing applications only if
> > > * HttpClients.createDefault() is used
> > > * some proxy is actually selected at runtime (for example the
> > > target
> > > doesn't match nonProxyHost)
> > > * the mandatory behavior must be to ignore it (for example if the
> > > proxy refuses certain hosts, or the cost of using the proxy is
> > > important and must be avoided for certain hosts)
> > >
> > > In this case to restore the previous behavior, you would for
> > > example
> > > have to call a new method HttpClients.createIgnoringProxies()
> > >
> > > Another possibility would be to add a separate new runtime
> > > configuration to enable this behavior. Because it's new, it's
> > > guaranteed to not exist anywhere and won't change the behavior in
> > > any
> > > existing deployment.
> > > The downside is that in cases where using the proxy was simply
> > > the
> > > right thing to do, the user who has configured the proxy also has
> > > to
> > > set a dedicated configuration for httpcomponents. But at least
> > > the
> > > user would not be blocked.
> > >
> > > Cheers,
> > > Jon
> > >
> > >
> >
> > The plan is to deprecate the existing APIs, keep thir behavior
> > intact
> > and ask users to migrate to new APIs with a different behavior
> > going
> > forward.
> >
> > Oleg
> >
> >
> >
> > > On Mon, Nov 24, 2025 at 3:19 PM Gary Gregory
> > > <ga...@gmail.com>
> > > wrote:
> > > >
> > > > What does this mean for existing application stacks? Will they
> > > > break
> > > > because they try to use some default proxy?
> > > >
> > > > What exactly does this mean for existing call sites?
> > > >
> > > > Ty,
> > > > Gary
> > > >
> > > > On Mon, Nov 24, 2025, 08:23 Jon Harper <jo...@gmail.com>
> > > > 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"
> > > > >
> > > > > Cheers,
> > > > > Jon
> > > > >
> > > > > -------------------------------------------------------------
> > > > > ----
> > > > > ----
> > > > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > > > For additional commands, e-mail: dev-help@hc.apache.org
> > > > >
> > > > >
> > >
> > > -----------------------------------------------------------------
> > > ----
> > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: dev-help@hc.apache.org
> >
> > -------------------------------------------------------------------
> > --
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [DISCUSS] HTTPCLIENT-2381 use 'runtime' proxy activation by default
Posted by Jon Harper <jo...@gmail.com>.
Hi Oleg,
it sounds like a good plan. Are you looking for more discussion around
this or is the plan decided ?
To me, the most important part is that the API "nudges" developers
towards writing and shipping code that will not be unusable by users
behind mandatory corporate proxies, thus avoiding back and forth bug
reports and fixes between the users and developers.
So the naming and documentation in this new API is critical.
Cheers,
Jon
On Wed, Dec 10, 2025 at 11:25 AM Oleg Kalnichevski <ol...@apache.org> wrote:
>
> On Mon, 2025-12-08 at 17:45 +0100, Jon Harper wrote:
> > Hi,
> > this would break existing applications only if
> > * HttpClients.createDefault() is used
> > * some proxy is actually selected at runtime (for example the target
> > doesn't match nonProxyHost)
> > * the mandatory behavior must be to ignore it (for example if the
> > proxy refuses certain hosts, or the cost of using the proxy is
> > important and must be avoided for certain hosts)
> >
> > In this case to restore the previous behavior, you would for example
> > have to call a new method HttpClients.createIgnoringProxies()
> >
> > Another possibility would be to add a separate new runtime
> > configuration to enable this behavior. Because it's new, it's
> > guaranteed to not exist anywhere and won't change the behavior in any
> > existing deployment.
> > The downside is that in cases where using the proxy was simply the
> > right thing to do, the user who has configured the proxy also has to
> > set a dedicated configuration for httpcomponents. But at least the
> > user would not be blocked.
> >
> > Cheers,
> > Jon
> >
> >
>
> The plan is to deprecate the existing APIs, keep thir behavior intact
> and ask users to migrate to new APIs with a different behavior going
> forward.
>
> Oleg
>
>
>
> > On Mon, Nov 24, 2025 at 3:19 PM Gary Gregory <ga...@gmail.com>
> > wrote:
> > >
> > > What does this mean for existing application stacks? Will they
> > > break
> > > because they try to use some default proxy?
> > >
> > > What exactly does this mean for existing call sites?
> > >
> > > Ty,
> > > Gary
> > >
> > > On Mon, Nov 24, 2025, 08:23 Jon Harper <jo...@gmail.com>
> > > 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"
> > > >
> > > > Cheers,
> > > > Jon
> > > >
> > > > -----------------------------------------------------------------
> > > > ----
> > > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > > For additional commands, e-mail: dev-help@hc.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [DISCUSS] HTTPCLIENT-2381 use 'runtime' proxy activation by default
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2025-12-08 at 17:45 +0100, Jon Harper wrote:
> Hi,
> this would break existing applications only if
> * HttpClients.createDefault() is used
> * some proxy is actually selected at runtime (for example the target
> doesn't match nonProxyHost)
> * the mandatory behavior must be to ignore it (for example if the
> proxy refuses certain hosts, or the cost of using the proxy is
> important and must be avoided for certain hosts)
>
> In this case to restore the previous behavior, you would for example
> have to call a new method HttpClients.createIgnoringProxies()
>
> Another possibility would be to add a separate new runtime
> configuration to enable this behavior. Because it's new, it's
> guaranteed to not exist anywhere and won't change the behavior in any
> existing deployment.
> The downside is that in cases where using the proxy was simply the
> right thing to do, the user who has configured the proxy also has to
> set a dedicated configuration for httpcomponents. But at least the
> user would not be blocked.
>
> Cheers,
> Jon
>
>
The plan is to deprecate the existing APIs, keep thir behavior intact
and ask users to migrate to new APIs with a different behavior going
forward.
Oleg
> On Mon, Nov 24, 2025 at 3:19 PM Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > What does this mean for existing application stacks? Will they
> > break
> > because they try to use some default proxy?
> >
> > What exactly does this mean for existing call sites?
> >
> > Ty,
> > Gary
> >
> > On Mon, Nov 24, 2025, 08:23 Jon Harper <jo...@gmail.com>
> > 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"
> > >
> > > Cheers,
> > > Jon
> > >
> > > -----------------------------------------------------------------
> > > ----
> > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: dev-help@hc.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [DISCUSS] HTTPCLIENT-2381 use 'runtime' proxy activation by default
Posted by Jon Harper <jo...@gmail.com>.
Hi,
this would break existing applications only if
* HttpClients.createDefault() is used
* some proxy is actually selected at runtime (for example the target
doesn't match nonProxyHost)
* the mandatory behavior must be to ignore it (for example if the
proxy refuses certain hosts, or the cost of using the proxy is
important and must be avoided for certain hosts)
In this case to restore the previous behavior, you would for example
have to call a new method HttpClients.createIgnoringProxies()
Another possibility would be to add a separate new runtime
configuration to enable this behavior. Because it's new, it's
guaranteed to not exist anywhere and won't change the behavior in any
existing deployment.
The downside is that in cases where using the proxy was simply the
right thing to do, the user who has configured the proxy also has to
set a dedicated configuration for httpcomponents. But at least the
user would not be blocked.
Cheers,
Jon
On Mon, Nov 24, 2025 at 3:19 PM Gary Gregory <ga...@gmail.com> wrote:
>
> What does this mean for existing application stacks? Will they break
> because they try to use some default proxy?
>
> What exactly does this mean for existing call sites?
>
> Ty,
> Gary
>
> On Mon, Nov 24, 2025, 08:23 Jon Harper <jo...@gmail.com> 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"
> >
> > Cheers,
> > Jon
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [DISCUSS] HTTPCLIENT-2381 use 'runtime' proxy activation by default
Posted by Gary Gregory <ga...@gmail.com>.
What does this mean for existing application stacks? Will they break
because they try to use some default proxy?
What exactly does this mean for existing call sites?
Ty,
Gary
On Mon, Nov 24, 2025, 08:23 Jon Harper <jo...@gmail.com> 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"
>
> Cheers,
> Jon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: [DISCUSS] HTTPCLIENT-2381 read system properties by default
Posted by Arturo Bernal <ab...@apache.org>.
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 <ol...@apache.org> wrote:
> On Mon, 2025-11-24 at 12:36 -0500, Gary Gregory wrote:
> > On Mon, Nov 24, 2025, 12:02 Oleg Kalnichevski <ol...@apache.org>
> > 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: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: [DISCUSS] HTTPCLIENT-2381 read system properties by default
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2025-11-24 at 12:36 -0500, Gary Gregory wrote:
> On Mon, Nov 24, 2025, 12:02 Oleg Kalnichevski <ol...@apache.org>
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [DISCUSS] HTTPCLIENT-2381 read system properties by default
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Nov 24, 2025, 12:02 Oleg Kalnichevski <ol...@apache.org> 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
What gets more interesting is that in container environments (Docker), it's
common to set or override settings from environment variables. So we should
allow configuration from environment variables as well.
Gary
>
>
> Oleg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: [DISCUSS] HTTPCLIENT-2381 read system properties by default
Posted by Oleg Kalnichevski <ol...@apache.org>.
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.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org