W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2017

Re: Suspected errata on 7540 wrt stream states

From: Ilari Liusvaara <ilariliusvaara@welho.com>
Date: Wed, 27 Dec 2017 15:19:51 +0200
To: Willy Tarreau <w@1wt.eu>
Cc: ietf-http-wg@w3.org
Message-ID: <20171227131951.GA16671@LK-Perkele-VII>
On Wed, Dec 27, 2017 at 09:57:53AM +0100, Willy Tarreau wrote:
> 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 ?

One of the rules is about half-open state and the other is about closed

So if RST_STREAM is not involved, it depends on if you have sent

1) If no, it is stream error.
2) If yes, it is connection error.

(Not that this makes very much sense, but at least the spec does not
seem to conflict with itself).

Then there is more whacky case if RST_STREAM is involved:

If you have sent RST_STREAM and then receive END_STREAM and then DATA
(all in "short" succession), that is no error.

Received on Wednesday, 27 December 2017 13:20:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 27 December 2017 13:20:32 UTC