The Problem
When you create a Radius Gateway resource with a route that uses WebSocket as its protocol, the connection to this route terminates after a certain period. You need to refresh the connection to establish another stable connection between the browser and the server.
The issue that made us aware of this limitation: radius-project/radius#7590.
What is a WebSocket?
WebSocket is a protocol that provides a way to exchange date between browser and server via a persistent connection. The data can be passed in both directions as “packets”, without breaking the connection and the need of additional HTTP-requests.
Possible Solutions
Please see this property of contour that will be used whether we choose the first solution or the second: https://github.com/projectcontour/contour/blob/main/apis/projectcontour/v1/httpproxy.go#L547.
-
Add enableWebsockets property during Gateway rendering and set it to true all the time. The main downside of this solution is that it is going to enable websocket support for all routes created by Radius Gateway. Some users may not want this since it could have performance problems down the line.
-
Adding a property to the Radius Gateway Route object called enableWebsockets. Users can set this to true and don't need to set it to false because by default it is going to be false. Here is the initial PR for this solution: https://github.com/radius-project/radius/pull/7643/files#diff-03d1aeb3a197a506b55a913705eb62271ddf651581877939a2d49ab51e835c8eR78.
Pros of Solution 1
- Flexibility and readiness for future WebSocket needs.
- Minimal immediate performance overhead.
- Consistent and simplified configuration management.
Cons of Solution 1
- Potential resource management issues if WebSocket connections are not properly controlled.
- Increased security risks requiring additional protective measures.
- Added complexity in debugging and risk of misconfigurations.
- Possible additional compliance and auditing requirements.
References
is the recommendation to go with Solution 2?