- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 28 Dec 2017 07:19:01 +0100
- To: Kazuho Oku <kazuhooku@gmail.com>
- Cc: summerwind.jp@gmail.com, HTTP Working Group <ietf-http-wg@w3.org>
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