Skip to content
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

WINDOW_UPDATE must be ignored on closed connection as stated by RFC 7540 #64

Open
pemarko opened this issue Apr 4, 2023 · 0 comments
Open

Comments

@pemarko
Copy link

pemarko commented Apr 4, 2023

I see a GO_AWAY with CLOSED_STREAM error sent to client when WINDOS_UPDATE is received right after server sent END_STREAM and closed stream locally. This is seen when using fasthttp2 client which sends WINDOW_UPDATE despite it should already know that server closed stream locally - client has local half-closed stream and just received frame with END_STREAM flag.

RFC says:
Endpoints MUST ignore [WINDOW_UPDATE] or [RST_STREAM] frames received in this state, though endpoints MAY choose to treat frames that arrive a significant time after sending END_STREAM as a connection error ([Section 5.4.1] of type [PROTOCOL_ERROR]

Easy fix is to add FrameWindowUpdate type as allowed frames as in below patch. Ideally, timestamp of close event might be tracked to make decision based on age of closed stream.

diff --git a/serverConn.go b/serverConn.go
index cd0e2ea..3df2c5f 100644
--- a/serverConn.go
+++ b/serverConn.go
@@ -374,7 +374,7 @@ loop:
                                }
 
                                if _, ok := closedStrms[fr.Stream()]; ok {
-                                       if fr.Type() != FramePriority {
+                                       if fr.Type() != FramePriority && fr.Type() != FrameWindowUpdate {
                                                sc.writeGoAway(fr.Stream(), StreamClosedError, "frame on closed stream")
                                        }

Thx,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant