Re: Suspected errata on 7540 wrt stream states

Hi Kazuho,

On Thu, Dec 28, 2017 at 05:19:16AM +0900, Kazuho Oku wrote:
> Let me point out that section 6.1 also has a definition dealing with the
> case, which states:
> 
> 
>    If a DATA frame is received
>    whose stream is not in "open" or "half-closed (local)" state, the
>    recipient MUST respond with a stream error (Section 5.4.2
> <https://tools.ietf.org/html/rfc7540#section-5.4.2>) of type
>    STREAM_CLOSED.

Good point, and in fact it has always been a concern to me that rules
were dictated at different places (ie: in stream states and in frame
types). I think we made a mistake by proceeding like this because it's
almost impossible to maintain the exact same rules on the two sides,
we possibly ought to have used general guidelines in the states list
(i.e. "frames received in that state commonly lead to a stream error
and sometimes to a connection error" etc). Then for each frame type,
the exhaustive list of states should be enumerated.

> So I agree that there might be an issue here. My personal bet would be that
> this is an error in section 5.1 failing to nominate DATA frame as one of
> the frames that can end up in a stream-level error when received in closed
> state.

In fact it totally makes sense to me to abort DATA with a stream error
and that's what I used to do, that h2spec didn't catch as it focuses
on 5.1 expecting a connection error. However HEADERS or PUSH_PROMISE
should definitely end up in a connection error (as defined in 5.1.1
for stream ID reuse), regardless of whether the stream was recently
closed or not.

> FWIW, h2spec version 1 does not report an error if a stream-level error is
> returned in this case. So it might be a regression in h2spec version 2.

I wouldn't call that a regression, just a closer compliance with the
various rules in the spec, which is quite good. It's just that certain
areas in the spec do not totally agree :-)

Cheers,
Willy

Received on Thursday, 28 December 2017 06:19:28 UTC