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 <[email protected]> > 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 <[email protected]> > > 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: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
