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