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