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