- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 27 Dec 2017 09:57:53 +0100
- To: ietf-http-wg@w3.org
Hi all, while taking a closer look at some of the issues reported by h2spec on haproxy's h2 implementation, I found that it reported something that I thought I had properly handled, namely the receipt of frames after the ES flag. Taking a closer look, I implemented what is indicated in 5.1 : open: (...) an endpoint receiving an END_STREAM flag causes the stream state to become "half-closed (remote)". half-closed (remote): (...) If an endpoint receives additional frames, other than WINDOW_UPDATE, PRIORITY, or RST_STREAM, for a stream that is in this state, it MUST respond with a stream error (Section 5.4.2) of type STREAM_CLOSED. And indeed, when haproxy sees, say, a DATA frame after ES, it sends an RST_STREAM with error type STREAM_CLOSED. But h2spec expects to see a connection error here, which surprized me a bit. So I continued to read and found what rule it relies on : closed: (...) Similarly, an endpoint that receives any frames after receiving a frame with the END_STREAM flag set MUST treat that as a connection error (Section 5.4.1) of type STREAM_CLOSED, unless the frame is permitted as described below. So in fact here I suspect that this last paragraph has nothing to do with the closed state but is in fact related to the half-closed(remote) one, and it contradicts the rule dictated in the half-closed(remote) description. Am I overlooking anything ? Should I implement a connection error to be more conservative ? Should I file an errata given that we're seeing two conflicting MUST ? Thanks, Willy
Received on Wednesday, 27 December 2017 08:58:19 UTC