- 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