Re: Questions about stream state transitions
Shigeki Ohtsu <ohtsu@iij.ad.jp> Thu, 18 July 2013 06:41 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA34621E8093 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Jul 2013 23:41:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMjf6XnESmv9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Jul 2013 23:41:23 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 42E1B21E8086 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 17 Jul 2013 23:41:22 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Uzhs6-0002Jk-RE for ietf-http-wg-dist@listhub.w3.org; Thu, 18 Jul 2013 06:39:26 +0000
Resent-Date: Thu, 18 Jul 2013 06:39:26 +0000
Resent-Message-Id: <E1Uzhs6-0002Jk-RE@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <ohtsu@iij.ad.jp>) id 1Uzhrw-0002IE-Um for ietf-http-wg@listhub.w3.org; Thu, 18 Jul 2013 06:39:16 +0000
Received: from mo30.iij.ad.jp ([202.232.30.71] helo=omgo.iij.ad.jp) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <ohtsu@iij.ad.jp>) id 1Uzhru-0004I2-RN for ietf-http-wg@w3.org; Thu, 18 Jul 2013 06:39:16 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iij.ad.jp; h=Message-ID: Date:From:MIME-Version:To:Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding; i=ohtsu@iij.ad.jp; s=omgo1; t=1374129531; x= 1375339131; bh=cqrk1ecYieP4xo4VKcbQJLtD71ED/juJgPEBF+h6+6k=; b=Yt0LreDIStrbBRSQ I9WKHOzJD+n3ghrI4ceGN31EQlOS56ItF4A5SxUYhZwmLLT45M2gCYoSyNn9eSCrcRGx0KNLXfmgJ MvyFY3dvPceKDAEZol/cK3C1xm7TBW8n040dVAmlLRmFg+VzhHzYcq5oQ9RIQEKJTbqDHf/csO1HV 4=;
Received: by omgo.iij.ad.jp (mo30) id r6I6cpTb029281; Thu, 18 Jul 2013 15:38:51 +0900
Message-ID: <51E78D77.7060000@iij.ad.jp>
Date: Thu, 18 Jul 2013 15:38:47 +0900
From: Shigeki Ohtsu <ohtsu@iij.ad.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: ietf-http-wg@w3.org
References: <51E6908F.2010602@iij.ad.jp> <CABkgnnVRuSRwr+3RQd=5+nMcz5Mhy3mavSXc15wi_0ZFd5yo8g@mail.gmail.com>
In-Reply-To: <CABkgnnVRuSRwr+3RQd=5+nMcz5Mhy3mavSXc15wi_0ZFd5yo8g@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=202.232.30.71; envelope-from=ohtsu@iij.ad.jp; helo=omgo.iij.ad.jp
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: lisa.w3.org 1Uzhru-0004I2-RN 49613bf60ede5c08752af30229cbabec
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Questions about stream state transitions
Archived-At: <http://www.w3.org/mid/51E78D77.7060000@iij.ad.jp>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18838
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Thanks for answers, they are very helpful for me. Following comments, I've update the table in http://html5.ohtsu.org/HTTP2_Stream_State.pdf Please review this if it is correct and I've also submitted a new PR of https://github.com/http2/http2-spec/pull/179 which is related in receiving PUSH_PROMISE shown in the table as marked (*2) Please review it too. Regards, (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: > https://github.com/http2/http2-spec/issues/175 > > 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 <ohtsu@iij.ad.jp> 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 >> >> http://html5.ohtsu.org/HTTP2_Stream_State.pdf > > 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. > -> https://github.com/http2/http2-spec/issues/176 > >> (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. > -> https://github.com/http2/http2-spec/issues/177 > >> 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. >
- Questions about stream state transitions Shigeki Ohtsu
- Re: Questions about stream state transitions Martin Thomson
- Re: Questions about stream state transitions Shigeki Ohtsu
- Re: Questions about stream state transitions Ilari Liusvaara
- Re: Questions about stream state transitions Shigeki Ohtsu
- Re: Questions about stream state transitions Martin Thomson
- Re: Questions about stream state transitions Martin Thomson
- Re: Questions about stream state transitions Shigeki Ohtsu