Re: Questions about stream state transitions

Shigeki Ohtsu <> Thu, 18 July 2013 06:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA34621E8093 for <>; Wed, 17 Jul 2013 23:41:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QMjf6XnESmv9 for <>; Wed, 17 Jul 2013 23:41:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 42E1B21E8086 for <>; Wed, 17 Jul 2013 23:41:22 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1Uzhs6-0002Jk-RE for; Thu, 18 Jul 2013 06:39:26 +0000
Resent-Date: Thu, 18 Jul 2013 06:39:26 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Uzhrw-0002IE-Um for; Thu, 18 Jul 2013 06:39:16 +0000
Received: from ([] by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1Uzhru-0004I2-RN for; Thu, 18 Jul 2013 06:39:16 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h=Message-ID: Date:From:MIME-Version:To:Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding;; s=omgo1; t=1374129531; x= 1375339131; bh=cqrk1ecYieP4xo4VKcbQJLtD71ED/juJgPEBF+h6+6k=; b=Yt0LreDIStrbBRSQ I9WKHOzJD+n3ghrI4ceGN31EQlOS56ItF4A5SxUYhZwmLLT45M2gCYoSyNn9eSCrcRGx0KNLXfmgJ MvyFY3dvPceKDAEZol/cK3C1xm7TBW8n040dVAmlLRmFg+VzhHzYcq5oQ9RIQEKJTbqDHf/csO1HV 4=;
Received: by (mo30) id r6I6cpTb029281; Thu, 18 Jul 2013 15:38:51 +0900
Message-ID: <>
Date: Thu, 18 Jul 2013 15:38:47 +0900
From: Shigeki Ohtsu <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.981, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.394, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1Uzhru-0004I2-RN 49613bf60ede5c08752af30229cbabec
Subject: Re: Questions about stream state transitions
Archived-At: <>
X-Mailing-List: <> archive/latest/18838
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Thanks for answers, they are very helpful for me.

Following comments, I've update the table in

Please review this if it is correct and I've also submitted a new PR of

which is related in receiving PUSH_PROMISE shown in the table as marked (*2)

Please review it too.


(2013/07/18 1:24), Martin Thomson wrote:
> This is really valuable work.
> I'm going to create a ticket to cover addressing these points:
> That one, I'll mark as editorial, but I'll also create a couple of
> extra issues (below).
> On 17 July 2013 05:39, Shigeki Ohtsu <> wrote:
>> Hi,
>> The stream state is newly introduced in the draft-04. For my understandings,
>> I've just wrote a table diagram for the stream states transition to cover
>>   all scenarios in the case of sending and receiving frames.
>> The table is listed in
> Note that, in general, you will see a great deal of symmetry between
> the two tables.  If it is a PROTOCOL_ERROR to receive, then it will be
> a MUST NOT for send, aside from the boundary cases where races can
> occur.
>> In writing this, I have the folowing five questions which are painted gray in
>> the table field.
>> (1) Receiving RST_STREAM in "idle"
>> Is it a stream error with PROTOCOL_ERROR or falled into "closed" state?
> I believe that the right approach is to treat this as a *connection*
> error of type PROTOCOL_ERROR.  Otherwise, an endpoint can be required
> to maintain too much extra state.
> ->
>> (2) Receivng PRIRORITY and WINDOW_UPDATE in "half closed(local)"
>> They are not necessary. So is it to be an error or ignored?
> Both can be received in this state.  If you just sent END_STREAM, then
> it would not be unexpected to receive either frame shortly thereafter.
>   Ignoring them seems safe (providing that you apply the usual DoS
> heuristics).
>> (3) Sending PRIORITY in "half closed(remote)"
>> No description about this case is in the draft. Is it prohibited?
> No need to send it, but it's impossible to force compliance (see above answer).
>> (4) Receiving RST_STREAM in "closed"
>> The draft says that " An endpoint that sends a RST_STREAM frame MUST ignore
>> frames that it receives on closed streams after it has sent a RST_STREAM frame."
>> Is this ignored always in the closed state or only in the case
>> after RST_STREAM sent?
> If you send RST_STREAM, then receiving RST_STREAM should be OK.  In my
> opinion, an implementation could choose to use RST_STREAM as a signal
> that they can stop ignoring frames on that streams (and transition to
> a  hard connection-level PROTOCOL_ERROR for any other frames that
> appear).
> If a stream is closed, either because both peers sent END_STREAM, or
> you *received* RST_STREAM, receiving RST_STREAM is a PROTOCOL_ERROR.
> That, we should clarify.
>> (5) Receiving PUSH_PROMISE in "closed"
>> The draft says that 'An endpoint might receive a PUSH_PROMISE frame after
>> it sends RST_STREAM. PUSH_PROMISE causes a stream to become "reserved".'
>> The same question above.
>> Is PUSH_PROMISE always leads the associted stream to be reserved(remote)
>> in the closed state? Or is it limited in the case after RST_STREAM was sent?
> This is only valid if you send RST_STREAM.  If you reach "closed" in
> any other way, the remote peer is aware of the close and should not be
> sending junk.  In this case, perhaps we need to escalate the error to
> a connection one, so that we can avoid the need to worry about the
> promised stream.
> That might be a general principle that can be applied to invalid
> PUSH_PROMISE frames, lest we end up with streams that are sort-of
> promised, but not promised in any valid way.
> ->
>> If any missings or mistakes are found in the table, I'm very glad to have feedbacks.
> I think that you have the PUSH_PROMISE a little wrong, depending on
> which stream that you are talking about.
> The stream that you are using here is the *promised* stream.  But the
> frame header for PUSH_PROMISE includes the *associated* stream.
> Perhaps you need to add another column for the effect that
> PUSH_PROMISE has on the associated stream.