[core] allow programmatic configuration of no proxy list

One problem with current approach is that we load the noProxyList from NO_PROXY env var and cache it in first proxyPolicy() call, therefore

• it is not possible to change the list when creating new pipelines.
• it is not easy to configure noProxyList programmatically. For example, storage explorer allow users to configure proxy settings from the UI instead of using the NO_PROXY environment variable.

To address 1) we should remove the caching and load the list every time proxyPolicy() is called.

For 2) maybe add a parameter for noProxyList?

export function proxyPolicy(proxySettings?: ProxySettings, customNoProxyList?: string[]): RequestPolicyFactory {
  if (!proxySettings) {
    proxySettings = getDefaultProxySettings();
  }
  noProxyList = customNoProxyList ?? loadNoProxy();

  return {
    create: (nextPolicy: RequestPolicy, options: RequestPolicyOptions) => {
      return new ProxyPolicy(nextPolicy, options, proxySettings!);
    }
  };
}

Another question is do we want to make noProxyList per ProxyPolicy, similar to proxySettings? There might be case where two clients from different SDK libraries want to use different set of proxy configurations. This will then make the noProxyList and the byPassedList cache per ProxyPolicy

@bterlson @chradek @xirzec

[craxal]

Storage Explorer is currently in the process of adding direct support for NO_PROXY.

Storage Explorer allows users to specify proxy settings using either system proxy settings, custom app proxy settings, or environment variables. Users can change these settings at any time, which means we need to be able to support changing proxy information used by the various networking modules we use (request, Azure SDK, etc.). This is further complicated by the fact that Storage Explorer is spread out across several processes. Relying on environment variables for proxy settings is not sufficient without a full app restart.

Here’s how we intend to handle environment variables in 1.21.0:

1. At startup, copy the environment variables to an internal object. If the user wishes to use proxy settings from environment variables, this object becomes the source for this information.
2. Delete the environment variables before any networking modules have a chance to load and read them.
3. When the user changes any proxy settings, we broadcast the change to any process that uses network communications.
4. How each process applies the settings depends on the network module in use in that process. Where possible, proxy settings are applied on a per-request basis.

Because different modules treat environment variables differently, we avoid setting process environment variables and rely on things like proxy policies or options. The read-once caching behavior for NO_PROXY is a good example. In order to work around that behavior, we have to implement the NO_PROXY behavior ourselves. If the URL matches one of the patterns in NO_PROXY, we skip applying a proxy policy to that request.

If the SDK supported a “no proxy” list when creating a proxy policy, that would remove the need for us to do the no-proxy check ourselves.

Here’s our work item: microsoft/AzureStorageExplorer#2685

[craxal]

@xirzec We’re already doing that, actually. We create a new client for every operation that is performed. Then we discard it when the operation completes and returns.

Historically, we never relied on environment variables. But users were reporting issues when their environments had these variables set. Since the underlying networking modules already used these variables, we thought at first just using them would be the way to go, and it seemed to work with HTTPS_PROXY and HTTP_PROXY.

Since environment variables are essentially language/platform-independent versions of global variables…well, we learned that wasn’t a good idea.