Re: Questions about stream state transitions

Martin Thomson <> Wed, 17 July 2013 16:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 483C021F99C2 for <>; Wed, 17 Jul 2013 09:25:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.588
X-Spam-Status: No, score=-10.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mEDVNTIZMrze for <>; Wed, 17 Jul 2013 09:25:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6928021F99F1 for <>; Wed, 17 Jul 2013 09:25:53 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UzUX8-0006b1-Uq for; Wed, 17 Jul 2013 16:24:55 +0000
Resent-Date: Wed, 17 Jul 2013 16:24:54 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UzUX0-0006Zi-Kt for; Wed, 17 Jul 2013 16:24:46 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UzUWv-0003IH-SZ for; Wed, 17 Jul 2013 16:24:46 +0000
Received: by with SMTP id n11so2023443wgh.9 for <>; Wed, 17 Jul 2013 09:24:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZyCvjdFVVpMnYgB1+gcmKYMOIRVChOp7FpUBHso6Wis=; b=AbNcvgR4yq6WCV+cjxfX9YRdUxZzyU5lmRhPQYGgGCXtoreLSyqUClT7X9CsuiYrxf /oeeT7SPAf0Trs9R5JcmE3FbMpC5D0EmRf88KMErpp6c+vNT32ULdbJfDFOSKa0W9vnB Tz8HH3c2Dyqzg6LdP6Pkr2DeSIeJJcyi/J3p5TV0jNN9ha59dU7sMb2JjoXXiMLZrP3r NZNUCZCmAGIJObKcMg0yZKgY1TIFGDgk46UGkuL/seji8SbjqZ+xITqQ1SrhXC9nLrA7 kH45DgKja42SEac1cjMSIbwJhU/kCB5uyOny1MimHz2JT7adSoPxgq1h/XgNLLaI8MXc HO6w==
MIME-Version: 1.0
X-Received: by with SMTP id a14mr5514807wjx.84.1374078255577; Wed, 17 Jul 2013 09:24:15 -0700 (PDT)
Received: by with HTTP; Wed, 17 Jul 2013 09:24:15 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 17 Jul 2013 09:24:15 -0700
Message-ID: <>
From: Martin Thomson <>
To: Shigeki Ohtsu <>
Cc: HTTP Working Group <>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.670, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UzUWv-0003IH-SZ 9fe43bbd0d9e75a8459c79244f6887dd
Subject: Re: Questions about stream state transitions
Archived-At: <>
X-Mailing-List: <> archive/latest/18826
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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

> 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

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

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.