Giters

Azure / azure-relay-dotnet

☁️ .NET Standard client library for Azure Relay Hybrid Connections

Home Page:https://docs.microsoft.com/en-us/azure/service-bus-relay/relay-what-is-it

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Proxy property on HybridConnectionListener ignored

MarkOtter opened this issue · comments

commented

Actual Behavior

When assigning the listener Proxy property with an instance of the WebProxy class, it is completely ignored when the same instance is used as WebRequest.DefaultProxy. It took us several hours of debugging and eventualy looking in the Azure Relay sources to figure this out.

It is not clear to us why this condition is present; isn't this a bug?
We believe this condition is the cause.

Expected Behavior

Setting any instance of IWebProxy as the Proxy to the Listener causes it to be used, regardless of uses elsewhere.

Versions

  • OS platform and version: Windows 10 Enterprise 1803 - 17134.345
  • .NET Version: Core 2.1
  • NuGet package version or commit ID: 2.0.0-preview1-20180523
commented

@Priya91 Is there any reason the code checking for whether to use a proxy includes the check to ignore the proxy if it's WebRequest.DefaultWebProxy?

commented

@MarkOtter, as a work-around have you tried setting HybridConnectionClient.UseBuiltInClientWebSocket and/or HybridConnectionListener.UseBuiltInClientWebSocket to true?

commented

@dlstucki, No we did not. Instead, we assigned a fresh new instance of WebProxy to the Proxy property. (This seemed to work with our local dev proxy, but not with the production proxy which is likely blocking the sb:// protocol, but that is another issue and we are looking into that)
[Update: apperently with the UseBuiltInClientWebSocket we are able to penetrate the production proxy?]

Is the UseBuiltInClientWebSocket a more preferabele solution? If so, why? Are there side effects to consider with either approach?

commented

@MarkOtter, regarding UseBuiltInClientWebSocket, it depends. When this library was first written there was no ClientWebSocket in any netstandard version (this library was netstandard1.3 I think at that time) so a custom ClientWebSocket was needed. With netstandard2.0 System.Net.WebSockets.ClientWebSocket was added part of the standard. However, there's still some functionality which our custom implementation has that the framework does not. No proxy authentication support outside of Windows is the biggest one that comes to mind.

For future proofing as well as when more improvements are made to System.Net.WebSockets.ClientWebSocket class we wanted a way for users to be able to pick that one instead.

commented

WebRequest.DefaultProxy throws PlatformNotSupportedException if attempted to be used in .NET Core 2.0. That's most likely why that check is there at the condition you pointed out.

This issue should be helped by the PR #108

commented

If using netcoreapp2.1 or greater I think UseBuiltInClientWebSocket = true is the best way to go. However, it won't use the system default proxy (IE/WinINET settings) until the next release of this library (whatever comes after 2.0.0 Release).