-
-
Notifications
You must be signed in to change notification settings - Fork 275
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
Don't discard pending data frames on errors #536
Comments
Actually the RFC makes it clear that any premature end of stream is definitely a protocol error, my bad:
So I'll just fix the hanging, once I understand how it happens. |
I'm curious though as to how a proxy making a h1 request to some origin on behalf of a h2 request it received from the client should handle the case of a response with a body shorter than the content-length. |
In the case where such proxy is aware that the h1 response is not chunked and it has content length, if it sees the response end (the TCP connection close) before all the content has arrived, then it can reset the stream to the client. |
It turns out that the hanging is probably due to the proxy or the client, so closing this. |
Repurposed the issue. |
I wonder if we should also expose the frames too large for the stream's window size, and those that overflow content-length. |
@seanmonstar Do you have any opinion on how to implement this? My initial thought was to add a new The current code really doesn't expect a user to see a frame after a stream error so it's quite difficult to implement this change. |
Maybe an |
That's what I tried at first, but then that would mean resetting the stream |
When a server sends a data frame with the EOS flag set and there are still bytes that were supposed to be received before content-length reaches 0, h2 just discards the entire frame and its payload, not letting the user access its bytes at all. Instead, it should queue the error about the malformed message and yield it next time the user polls the stream.
h2/src/proto/streams/recv.rs
Lines 601 to 611 in a6b4144
The text was updated successfully, but these errors were encountered: