Questions about stream state transitions

Shigeki Ohtsu <> Wed, 17 July 2013 12:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97A3B21F9F50 for <>; Wed, 17 Jul 2013 05:41:13 -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 e2wWGUU0k18B for <>; Wed, 17 Jul 2013 05:41:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B428821F9EF5 for <>; Wed, 17 Jul 2013 05:41:08 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UzR20-0006QX-Py for; Wed, 17 Jul 2013 12:40:32 +0000
Resent-Date: Wed, 17 Jul 2013 12:40:32 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UzR1k-0006PQ-A3 for; Wed, 17 Jul 2013 12:40:16 +0000
Received: from ([] by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1UzR1e-0001am-OL for; Wed, 17 Jul 2013 12:40:16 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h=Message-ID: Date:From:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; i=; s=omgo1; t=1374064786; x=1375274386; bh=2rFn/7DXOny8yMH7H86nxUVa PYwj9VyzoV016eaxZfg=; b=unCcxGCCqRvPgomnZujuwt/tpjOXCHUFgH7TiymR4jMFmA9GBwT0Mq Md/ZxunNSMKq1hLfte/KIKOv7m/maHrvNJtnPT/RV2PmPQvm80o+oc+dAhmJNcdCZuu/6ZW894OaS WAiQtj0eKi3nwD+fzQFaCgaMxzKnNpZ9MYIHsYco=;
Received: by (mo00) id r6HCdkF0002173; Wed, 17 Jul 2013 21:39:46 +0900
Message-ID: <>
Date: Wed, 17 Jul 2013 21:39:43 +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
To: HTTP Working Group <>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.7
X-W3C-Hub-Spam-Report: AWL=-3.252, 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: 1UzR1e-0001am-OL 7069447a40c2948c83d6da6df70ae567
Subject: Questions about stream state transitions
Archived-At: <>
X-Mailing-List: <> archive/latest/18823
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>


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

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?

(2) Receivng PRIRORITY and WINDOW_UPDATE in "half closed(local)"
They are not necessary. So is it to be an error or ignored?

(3) Sending PRIORITY in "half closed(remote)"
No description about this case is in the draft. Is it prohibited?

(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?

(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?

If any missings or mistakes are found in the table, I'm very glad to have feedbacks.