When reseting a stream a library user could erroneously believe that they can disregard any frame from the stream. This reasoning is broken because we need to continue processing HEADERS, CONTINUATION, PUSH_PROMISE, and DATA frames which have a side-effect on the HTTP2 client state.
Current setup is roughly safe because there are two separate threads: one for "HPACK frames", one for DATA frames dedicated to perform state-changing operations. I'd like to keep this behavior for HPACK frames but let users have more control on the DATA frames because I want to expose more flow-control knobs. A prerequisite is to have a better mechanism to reset streams: send a RST and continue consuming DATA frames minimally for flow-control side-effects until a RST is received from the server. This function should not be too hard to implement from existing primitive.
When reseting a stream a library user could erroneously believe that they can disregard any frame from the stream. This reasoning is broken because we need to continue processing HEADERS, CONTINUATION, PUSH_PROMISE, and DATA frames which have a side-effect on the HTTP2 client state.
Current setup is roughly safe because there are two separate threads: one for "HPACK frames", one for DATA frames dedicated to perform state-changing operations. I'd like to keep this behavior for HPACK frames but let users have more control on the DATA frames because I want to expose more flow-control knobs. A prerequisite is to have a better mechanism to reset streams: send a RST and continue consuming DATA frames minimally for flow-control side-effects until a RST is received from the server. This function should not be too hard to implement from existing primitive.