You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The framework could provide a "default" proxy handler on all outbound connections, so that upstream proxies only need to be configured in one place for simple pipelines. This would also enable framework services such as #5 to retrieve certificate chains, even when a proxy is required to reach the destination.
Alternatively, pipelines may configure their own branch-specific proxy configurations, and the framework should detect this and get out of the way. This gets a little more complicated when considering the SubChannel, as finding instances of a ProxyHandler handler on a different pipeline means you have to look up that pipeline first.
If the framework proxy configuration is flexible enough, e.g. network/mask -> proxy mapping, you should be able to avoid pipeline-specific proxies, I guess.
The text was updated successfully, but these errors were encountered:
The framework could provide a "default" proxy handler on all outbound connections, so that upstream proxies only need to be configured in one place for simple pipelines. This would also enable framework services such as #5 to retrieve certificate chains, even when a proxy is required to reach the destination.
Alternatively, pipelines may configure their own branch-specific proxy configurations, and the framework should detect this and get out of the way. This gets a little more complicated when considering the SubChannel, as finding instances of a ProxyHandler handler on a different pipeline means you have to look up that pipeline first.
If the framework proxy configuration is flexible enough, e.g. network/mask -> proxy mapping, you should be able to avoid pipeline-specific proxies, I guess.
The text was updated successfully, but these errors were encountered: