[HTTP/2] Throw meaningful exception if we get GOAWAY while reading response body

[liveans]

Fixes #97128

Not sure if this is the correct way to fix this.

[liveans]

/azp run runtime-libraries-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[MihaZupan]

Glad to see this was a simple enough change to get into 9.0.
Thanks

[ManickaP]

Is the original issue an issue at all?
We call OnReset for all streams with id > than indicated in GO_AWAY.

Based on JNK logs:

ProcessIncomingFramesAsync,Frame 15: StreamId=0; Type=GoAway; Flags=None; PayloadLength=22.
ReadGoAwayFrame,lastStreamId=1, errorCode=EnhanceYourCalm

He complains that server didn't let the client finish stream Id 1, while sending GO_AWAY with id 1. What does the RFC says? I'd expect server is supposed to let us finish those requests.

[liveans]

What does the RFC says? I'd expect server is supposed to let us finish those requests.

RFC9113 - HTTP/2 says:

Activity on streams numbered lower than or equal to the last stream identifier might still complete successfully. The sender of a GOAWAY frame might gracefully shut down a connection by sending a GOAWAY frame, maintaining the connection in an "open" state until all in-progress streams complete.

If I'm interpreting this correctly, this can go either way.

[antonfirsov]

Not sure if this is the correct way to fix this.

I think @JamesNK should be able to test private binaries to confirm.

[liveans]

Not sure if this is the correct way to fix this.

I think @JamesNK should be able to test private binaries to confirm.

That would be nice, but the test is written as he described in the reproduction steps. So, I think this kind of confirms that it's behaving as expected.

[JamesNK]

He complains that server didn't let the client finish stream Id 1, while sending GO_AWAY with id 1. What does the RFC says? I'd expect server is supposed to let us finish those requests.

What do you mean by "let us finish those requests"? Are you expecting reading from the response stream so say there is no more data without throwing an error?

Because of the GO_AWAY the server is never going to send a final stream frame with END_STREAM on it. The stream ended ungracefully. I expect an error when trying to read more of the stream body. What I want improved is the exception's message to say why the response ended.

[JamesNK]

Something that occurred to me, can responseStream.ReadAsync throw HttpProtocolException in other scenarios? If reading from the stream only throws IOException and friends, should the error by wrapped in HttpIOException?

[liveans]

Something that occurred to me, can responseStream.ReadAsync throw HttpProtocolException in other scenarios? If reading from the stream only throws IOException and friends, should the error by wrapped in HttpIOException?

That's a great question, so you're saying that this can be breaking change. I'll leave the answer to the HTTP experts.

[JamesNK]

ReadAsync throws a protocol error in some situations so it's not a new error. That is what I was worried about.

Is it breaking change? Maybe. I don't know the semantics of when to throw an IOException vs HttpProtocolException.

[ManickaP]

HttpProtocolException derives from HttpIOException which derives from IOException.