HTTP/2: Ignore additional RST_STREAM frames sent to stream

[JamesNK]

Fixes #32442

[ahjohannessen]

@JamesNK Any chance this is backported into 5.0.x series as a bugfix?

[ghost]

Hi @ahjohannessen. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.

[JamesNK]

Is there a workaround for this issue in your app?

We judge whether to backport fixes based on a bunch of factors such as whether there is a workaround and how many people are encountering the problem.

I'd also like to figure out whether this is a bug in the Java gRPC client. I think the Java gRPC client is violating the HTTP/2 spec by double sending the RST_STREAM frame.

[ahjohannessen]

Is there a workaround for this issue in your app?

No, sadly not. I have tried various things, but when just as I thought I fixed it then it pops up under different setup. Also this is something that can happen frequently with EventStoreDB as it is common to read a series of streams and look for specific events and end the search mid-stream and issuing a cancel (which is what that led to this situation, i.e. RST_STREAM errorCode=8 then subsequent RST_STREAM errorCode=5)

We judge whether to backport fixes based on a bunch of factors such as whether there is a workaround and how many people are encountering the problem.

I would greatly appreciate it could find its way to 5.0.x as that would make it possible to get it into ESDB sooner than waiting for 6.0 to be released.

I'd also like to figure out whether this is a bug in the Java gRPC client. I think the Java gRPC client is violating the HTTP/2 spec by double sending the RST_STREAM frame.

It seems that it is not violating the spec according to 6.1:

If a DATA frame is received whose stream is not in "open" or "half-closed (local)" state, the recipient MUST respond with a stream error (Section 5.4.2) of type STREAM_CLOSED.

I think that is something @ejona86 is a better person to answer.

[ghost]

Hi @ahjohannessen. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.

[jageall]

there does not seem to be a reasonable workaround on the server for this either. Everything is internal and I am not seeing a sensible way to try and deal with it closer to the transport. The only possible option I can see is to fork aspnetcore and patch the .net5 version with this fix. I'd rather not be forced to do that unless I really have to. Are there any other alternatives I am missing?

[ghost]

Hi @jageall. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.