Kestrel: callbacks for HTTP2 events(stream open, stream close, stream error, etc)

[cyberfirst-developer]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

I am using Kestrel with YARP in place of nginx, i did implemented some basic ban with ipset for bad requests.
Trying to analyze some behaviour i found that i can't capture HTTP2 events without log tracing. I would have prefered to have inapp callbacks to handle that data.
such inside callbacks can be usefull in advanced usages of Kestrel.(especially with YARP)

Describe the solution you'd like

i see two possible options, one is via ListenOptions, second via DI.

ListenOptions.UseHttp2Callbacks(c=>{
    c.OnStreamOpened = async (connectionContext, StreamContext, StreamId) => {...};
    c.OnStreamClosed = async (connectionContext, StreamId, error) => {...}
});

something like that.

Additional context

No response

[amcasey]

@cyberfirst-developer Thanks for the suggestion! Can you elaborate a little more on what you're trying to achieve? What sort of code would you put in those callbacks?

And, to confirm, it sounds like you're not interested in having more logging (or having logging at a different verbosity level), is that right?

[amcasey]

@benjaminpetit May have thoughts about how YARP could use this.

[cyberfirst-developer]

Can you elaborate a little more on what you're trying to achieve? What sort of code would you put in those callbacks?

After some data collection(it can be done now with logging), i want to find suspicious behaviour of clients, and block them.(requests per stream for example). callbacks mostly cuz i want to examine contexts(i store some data here) and may be even replace transport pipe to be able precisely calculate traffic inside. Also i want to be able to block fast if needed(this is why i have some analytics inside proxy app).

while YARP not build for this, i am building some DDoS mitigation with it.

[amcasey]

I think your best bet is probably some combination of logging and connection middleware.

[amcasey]

I think I'm going to close this one in favor of #53377. They're slightly different, but I think making sure that appropriate data is exposed for decision making is more widely applicable (not to mention easier to maintain and evolve) than hooks/callbacks.

[cyberfirst-developer]

I think I'm going to close this one in favor of #53377. They're slightly different, but I think making sure that appropriate data is exposed for decision making is more widely applicable (not to mention easier to maintain and evolve) than hooks/callbacks.

Issue with logger capture is that logger don't have access to context.
But as you wish.