-
Notifications
You must be signed in to change notification settings - Fork 834
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide option to configure HttpClient settings per Route, but not only per cluster. #2609
Comments
Instead of maintaining separate configurations for WS requests, have you considered using the request timeouts feature? |
Thank you, @MihaZupan ! |
Note that modifying existing clusters/routes is easier than creating new ones. builder.Services.AddReverseProxy()
.LoadFromConfig(builder.Configuration.GetSection("ReverseProxy"))
.AddConfigFilter<TimeoutsConfigFilter>();
internal sealed class TimeoutsConfigFilter : IProxyConfigFilter
{
public ValueTask<ClusterConfig> ConfigureClusterAsync(ClusterConfig cluster, CancellationToken cancel) =>
new(cluster);
public ValueTask<RouteConfig> ConfigureRouteAsync(RouteConfig route, ClusterConfig cluster, CancellationToken cancel) =>
new(route with { Timeout = TimeSpan.FromSeconds(10) });
} |
What should we add or change to make your life better?
We are using YARP in order to proxy REST and WebSocket (WS) request to the backend.
And one and the same service (server, container, cluster) exposes both REST and WS APIs (for one and the same domain and data).
Something like following structure (simplified):
WebSocket routes however have different requirements for the HttpClient compared to the REST ones. Manly in terms of "ActivityTimeout", as the default one (100 seconds) is too less for a WebSocket channel. Because sometimes we have idle periods with no messages.
Why is this important to you?
In order to achieve difference in the idle timeout, we need to define different clusters (situation right now).
Which makes configuration looking more complex, harder to read and redundant (actually having 2 cluster definitions for one and the same background service - for every background service).
Some thoughts about the restrictions.
Someone could argue that we need to separate implementations of REST and WS channels to different service anyway. But actually those are APIs on one and the same data and domain. You could imagine them like REST version for data pulling and WS for data push (evening). And we have both for historical reasons. The are all public and some of the integrators prefer one and some the other.
As per the idle timeout - most of the WS APIs do have ping-pong logic (client sending "I'm alive"). But time interval for sending those is configurable (server side). And all this is deployed on customer side (mainly on-prem). Some customers want to decrease the (empty) chatting for those APIs. Thus we have the setting and it could be extended more that the 100 seconds default timeout.
The text was updated successfully, but these errors were encountered: