Subject: Ambiguity when handling DATA frames on closed streams

From: Alan Shreve <[email-masked]>
Date: Fri, 29 Nov 2013 16:48:14 +0000

Unless I'm reading this incorrectly, the spec requires conflicting behaviors on the receipt of DATA frames on streams in the "closed" or "half-closed (remote)" states. Section 5.1 requires that the implementation send a stream error of type STREAM_CLOSED whereas section 6.1 requires the implementation respond with a connection error of type PROTOCOL_ERROR.
Can someone clarify the expected behavior?
Relevant parts of the spec:
Section 5.1: Stream states, subsection "half-closed (remote)":
"If an endpoint receives additional frames for a stream that is in this state, other than CONTINUATION frames, it MUST respond with a stream error (Section 5.4.2) of type STREAM_CLOSED."
Section 5.1 Stream states, subsection "closed":
"An endpoint that receives any frame after receiving a RST_STREAM MUST treat that as a stream error (Section 5.4.2) of type STREAM_CLOSED. Similarly, an endpoint that receives any frame after receiving a DATA frame with the END_STREAM flag set, or any frame except a CONTINUATION frame after receiving a HEADERS frame with a END_STREAM flag set MUST treat that as a stream error (Section 5.4.2) of type STREAM_CLOSED."
However, Section 6.1 "DATA":
"If a DATA frame is received whose stream is not in "open" or "half closed (local)" state, the recipient MUST respond with a connection error (Section 5.4.1) of type PROTOCOL_ERROR ."
- alan

---

From: Martin Thomson <[email-masked]>
Date: Mon, 2 Dec 2013 10:57:27 -0800

On 29 November 2013 08:48, Alan Shreve <[email-masked]> wrote:
> "If a DATA frame is received whose stream is not in "open" or "half closed
> (local)" state, the recipient MUST respond with a connection error (Section
> 5.4.1) of type PROTOCOL_ERROR ."

Good catch.  I think that this is the part that is wrong.  Until and
unless I hear screams, I'll fix 6.1 to match the rest of the document.

https://github.com/http2/http2-spec/commit/b6345121badab90d93c336c11c1278f948d7390a

---

From: Jeff Pinner <[email-masked]>
Date: Mon, 2 Dec 2013 11:12:20 -0800

The reason it's not stream closed in section 6.1 is the stream may be in
the idle state when you receive the DATA frame.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 2 Dec 2013 11:20:10 -0800

On 2 December 2013 11:12, Jeff Pinner <[email-masked]> wrote:
> The reason it's not stream closed in section 6.1 is the stream may be in the
> idle state when you receive the DATA frame.

You know, I think that I'm OK with STREAM_CLOSED there too.  Though
treating that as a connection error (as opposed to a stream error) is
probably best.  But that's a discretionary thing.  But then, I think
that it's perfectly valid for an implementation to upgrade all their
stream errors to connection errors.