Re: Implicit close of idle streams

'Implicit closing' is not handled very well in the stream state machine.
Closely reading the section about 'closed' state reveals that there's
currently no restriction about receiving frames on an implicitly closed
stream. It says:

      An endpoint MUST NOT send frames on a closed stream.  An endpoint
      that receives a frame after receiving a RST_STREAM or a frame
      containing a END_STREAM flag on that stream MUST treat that as a
      stream error (Section 5.4.2) of type STREAM_CLOSED.


And then goes on with ignoring specific frame types. So it's an error if
the peer sends something after sending RST_STREAM or END_STREAM, but it's
not an error if it sends something on an implicitly closed stream.

Promised streams are also implicitly half-closed, so this paragraph does
not apply to those either, but I don't know if it's intentional or not
because this has a specific use case (1. an endpoint promises a push stream
2. puts the whole push stream into the output buffer including the last
data frame 3. from its perspective, the stream is now in 'fully closed'
state 4. but then it receives an RST_STREAM(CANCEL) from the peer 5. it is
not an error because it did not receive an RST_STREAM or END_STREAM from
the peer before, so everyone is happy)

I think that one of the clean solutions would be to introduce a new
'unused' (or similar) stream state which raises a connection error if it
receives anything. Or staying with the original wording without mentioning
implicit closing. The seconds sounds simpler and I think that the original
wording was accurate enough.


2013/8/14 James M Snell <jasnell@gmail.com>

> Yes, with a bit of refinement that is better. I struggled to come up
> with a good alternative also...
>
> On Wed, Aug 14, 2013 at 10:02 AM, William Chan (陈智昌)
> <willchan@chromium.org> wrote:
> > Sorry Martin, I think I'm with everyone else in thinking this is
> confusing.
> > You're being very precise with your language, and it's technically
> correct,
> > but I believe that's because you've internalized the state diagram. The
> > simplest, yet perhaps imprecise, way of describing this is to say that
> > stream ids are monotonically increasing, so you once you use a new stream
> > identifier X, you cannot newly use a stream identifier < X. I'm terrible
> at
> > this editorial stuff and don't know if my new proposed wording is any
> > better. I suspect it's very possibly worse :P
> >
> >
> > On Wed, Aug 14, 2013 at 6:51 PM, Martin Thomson <
> martin.thomson@gmail.com>
> > wrote:
> >>
> >> On 14 August 2013 16:15, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
> >> wrote:
> >> > I'm non-native English readers and if you ask me it is confusing then
> >> > I'll
> >> > answers yes.
> >> > My understanding is that that explains the monotonically increasing
> >> > stream
> >> > identifier scheme
> >> > in formal way. I think it would be less confusing to convey that
> notion.
> >>
> >> I'm having trouble with this confusion because every time I read the
> >> section in its entirety, it's perfectly clear to me.  Even after doing
> >> what I can do compensate for the usual I-wrote-this blindness.
> >>
> >> I'll add an example, which I hope clarifies this, but in the absence
> >> of specific suggestion, I don't know how I can address these comments.
> >>
> >
>
>