ignore ping frame when connection is closed

[HoneyryderChuck]

while it's valid to process ping frames after sending/receiving goaway frames, preparing an AC frame may inadvertedly put bytes on the user buffer, thereby signaling that there's something to write back instead of terminating the connection,\

@igrigorik @mullermp would like to ask you guidance on this one. The RFC is not specific on what to do when receiving a PING frame after receiving a GOAWAY frame with stream id 0. I found at least one instance of a server which does exactly that, which led to some corruption on a long lived client connection, and while I can theoretically work around it on the client side in order to wipe out the buffer when processing a ping ack frame on a closed connection, that seems to be redundant and something the parser should do for me.

[mullermp]

I'm definitely not a subject matter expert in HTTP2 but taking a dive into the specification, I think this is wrong.

Receivers of a PING frame that does not include an ACK flag MUST send
a PING frame with the ACK flag set in response, with an identical
payload. PING responses SHOULD be given higher priority than any
other frame.

I read this as - you must respond back to PING regardless of the situation and it should be at highest priority (e.g. it supersedes the GOAWAY frame).

Is there a different or underlying fix that can be made to prevent those extra bytes or perhaps it is just the responsibility of the client to flush those? I think that after GOAWAY we can't just assume the connection is closed and done, we have to continue to do some house keeping until it's fully shut down.

[HoneyryderChuck]

thx @mullermp ! I also read that section, and where I'm a bit on the fence here is on what to do when the receiver sees the frames in that particular order:

1. client reads payload to buffer, parses and processes each frame in order
2. client receives GOAWAY frame from server, shuts down the socket
3. client receives PING frame (now what?)

While we definitely have that issue at the frame emission level (http-2 does not support prioritisation, i.e. it yields the frames per order), I'm just not sure what's the correct approach in the sequence of events above. should the parser somehow eager-parse, then reorder by priority, then yield to the caller?

[mullermp]

client receives GOAWAY frame from server, shuts down the socket

I think this is the fundamental problem. GOAWAY means to stop creating new streams. When the client receives GOAWAY, instead of shutting down the socket, the connection should be moved to a closing state. Then process the rest of the control frames (ping ack) then shut down the socket.

Reading GOAWAY:

The GOAWAY frame (type=0x7) is used to initiate shutdown of a
connection or to signal serious error conditions. GOAWAY allows an
endpoint to gracefully stop accepting new streams while still
finishing processing of previously established streams. This enables
administrative actions, like server maintenance.

phrases such as "initiate shutdown" and "gracefully stop" and "administrative actions" I think indicate that we should not be immediately terminating the connection on that frame.

[HoneyryderChuck]

(sorry for the late reply)

@mullermp I think that that type of language refers solely to the HTTP/2 connection, not the client resources (i.e. socket) management. I'd even interpret "administrative actions" as taking down the socket.

Nevertheless, I don't think that's the main issue at hand here, as at least, the way this surfaced in my case was that the issue was the ping ack frame being generated and buffered / ready to be sent back despite the goaway frame being received and the socket closed.

While I've built the workaround to check for socket state before buffering the ping ack frame, I find it error prone to expect the client to do this (because it is most likely being overlooked everywhere), which is why I believe that http-2 should do better here. I think we have two options:

1. ignore received PING frame after processing GOAWAY frame and moving connection to the closed state (what this PR is doing)
2. refactor frame processing code in order to decode all received frames in block THEN reorder before yielding, so that PING frames can be processed before the GOAWAY frame

Number 2 seems to be more correct as per what you linked from the RFC. I just pushed a commit implementing it, lmk what you think. It opens the door to stream prioritization, an area where http-2 has been lacking.