Allow for SignalR Clients to Handle Unregistered Handlers
- Dominant language
- C#
- Stars
- 38.4k
- Forks
- 10.9k
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 276
Description
## Summary
While consuming a SignalR Hub, we have no way of handling "unknown" invocations using the current API.
The idea of the proposal is to allow for a "fallback" handler to either handle the invocation, basically turning an unknow invocation into a handled one, or pass it back to the engine for logging/treatment.
## Motivation and goals
I want ot be able to trace every message received by my client, it being a deliberate part of my implementation or not.
A fallback method would allow me to monitor server changes, track missing features/bugs and improve security by knowing "exaclty" what I am receiving.
## In scope
A method registration for fallback handling or a middleware like approach were I can centrilize monitoring logic and handle "unknown" invocations.
## Out of scope
I expect no changes in current behavior, so it being register or not, the client should behave the same.
## Risks / unknowns
I think the risk here depends on how we implement it. If we delegate "too much" power to the fallback or middleware, we may break the protocol when the server is expecting a response.
## Examples
I'll limit the examples using C#.
```csharp
// For registering a fallback approach
connection.OnUnregisteredInvocation += async (InvocationMessage invocation) => /*...*/;
// or
connection.OnUnregistered(async (InvocationMessage invocation) => /*...*/);
// For registering a middleware, we could use the builder
connectionBuilder.WithMiddleware();
// or
connectionBuilder.WithMiddleware(new MyMiddleware());
```
Maybe instead of "Middleware" we can use "Filter":
```csharp
connectionBuilder.WithFilter();
// or
connectionBuilder.WithFilter(new MyFilter());
```
Contributor guide
Assessment
This issue has not been assessed yet.