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

Regarding websocket URI format constraints.

ayadavumass opened this issue · comments

commented

It looks like that websocket URIs should have a specific format like
"wss://contoso.servicebus.windows.net:443/$hc/endpoint1?sb-hc-action=connect&sb-hc-id=E2E_TRACKING_ID"

This makes it hard to integrate existing software with the service bus relay, like a browser opening a websocket won't add $hc or sb-hc-action=connect , which are needed for websocket connections through the service bus relay. Is there any way to specify this information in http header rather than the URI, which is usually easier to update in existing software? Most existing software just take wss://contoso.servicebus.windows.net:443/endpoint1 as input and then they make their own URIs, so it is hard to change such URIs to work with the service bus relay.

Actual Behavior

Expected Behavior

Versions

  • OS platform and version:
  • .NET Version:
  • NuGet package version or commit ID:
commented

Action = connect is the default if none is given. The $hc is still an issue at the moment.

commented

Okay, thanks for quick response :)

commented

I sent the last message from my phone just before going to sleep. I'll expound a bit more.
connect is the default if sb-hc-action is not present in the query string for a WebSocket connection to /$hc/{HYBRID_CONNECTION}. sb-hc-id is optional and simply for flowing a user supplied Guid that Azure Relay will then use internally for tracing purposes (so you can ask us "What happened to the connection with ID XXXX?"). If Azure Relay generates a Guid instead we return that in the HTTP Response headers in the "TrackingId" header. There is already support for flowing the auth token in an HTTP header.

The /$hc is trickier. It exists because {YOUR_NAMESPACE}.servicebus.windows.net:443 is shared across a lot of different services using an API predating WebSocket. The current implementation only allows WebSockets by listening on a different HTTP url prefix registration. In order to remove this prefix requirement the entire HTTP/S stack for WcfRelay, HybridConnections, ServiceBus Queues/Topics, and EventHubs will need to be rewritten/intercepted in such a way that the same HTTP prefix can route properly between WebSockets and all those existing services. It's not impossible, we'd like if it were this way, but it isn't going to happen within the next 6 months based on any planning discussions I've heard.

commented

I don't know if this helps but here's an example which shows using a websocket in a browser and even implementing the listener side of the HybridConnection protocol (sb-hc-action=listen and so on). It shows how to generate tokens, include $hc in the path, and put action=listen&token= in the query string.

Test.htm.txt

commented

Thanks for the explaining the use of $hc and the example code. I am basically trying to run jupyter notebook behind the service bus relay, https://jupyter.org/
. The jupyter notebook is python and java script open source code, so I have been able to make changes to add "$hc" in websockets path. I will also see if there are any other simplifications I can make based on your inputs.