Re: Implicit close of idle streams

So after reading through the state machine text a few times again, I
realised that the last part handles implicitly closed streams with saying
that anything that is not explicitly allowed should be declined with a
connection error... But in this case, my push stream related scenario would
also result in connection error, but that's not related to this issue, so
opened a new one here: https://github.com/http2/http2-spec/issues/236


2013/8/20 Gábor Molnár <gabor.molnar@sch.bme.hu>

> '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.
>> >>
>> >
>>
>>
>