Re: Design Issue: Life-cycle of a Stream

William Chan (陈智昌) <willchan@chromium.org> Wed, 01 May 2013 17:37 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 AD8D121F9A33 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 1 May 2013 10:37:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.676
X-Spam-Level:
X-Spam-Status: No, score=-9.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 SCSs2DuKB6pG for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 1 May 2013 10:37:47 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2563B21F99B3 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 1 May 2013 10:37:46 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UXaxl-0005ZX-Lj for ietf-http-wg-dist@listhub.w3.org; Wed, 01 May 2013 17:37:05 +0000
Resent-Date: Wed, 01 May 2013 17:37:05 +0000
Resent-Message-Id: <E1UXaxl-0005ZX-Lj@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <willchan@google.com>) id 1UXaxb-0005X9-EG for ietf-http-wg@listhub.w3.org; Wed, 01 May 2013 17:36:55 +0000
Received: from mail-qc0-f171.google.com ([209.85.216.171]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UXaxa-0007I8-DW for ietf-http-wg@w3.org; Wed, 01 May 2013 17:36:55 +0000
Received: by mail-qc0-f171.google.com with SMTP id q2so790923qch.2 for <ietf-http-wg@w3.org>; Wed, 01 May 2013 10:36:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tDpOnmODoepbYxv8L27GYBMFTI8bM9sUQ6DLgjkRkk4=; b=hY6qyxCBDZTqB/M5rBG3CzCCFrC6z5TRiCdooVIkelaFqAJL/cVKsEQfAgPlXQut5Z rRHv5eFUkMpSymWLYLoLeMnl4XxDo3OlOce+rr+v+ppxzb47oRZCli7rGkbVDuyFCEl/ TazL97+RFvXh/CqCeKi5DxOCWP6h6cpVbASFCNVQ893NZvLUhk/eM+5FokQSDURKViRu G3N60WrOzSdsusONjlmwETEk5W87Xa34wLzcXhnCuOxcVblQmYp+ODTpck86HEdmsgWR eyYmwECiaN4IX/XtgNU31ikd6CFrUzjFvq3Ah0aetM1aaKNE9G3VlOF1j4++e4bD0wYs imew==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tDpOnmODoepbYxv8L27GYBMFTI8bM9sUQ6DLgjkRkk4=; b=FY3JrTjP2g3A3mNSeLaVZ0fMbAHma1bDiyydhNxLXSLCX6LchX1ESUHFldYV4W8uHV xq3AB2As4d7x2VA8zjUP8c/XghOqSgKPrlP4ri7l1mkkSxtoaDfBKAUeqXfK6IDJfWCi o8xZcKAhhPiRd8iD5V9hZj/6ymRWOJPk716mc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=tDpOnmODoepbYxv8L27GYBMFTI8bM9sUQ6DLgjkRkk4=; b=fsHAHHcvivzxUUiT02xIgM3ws7bEz/j/NcUSVN2bFqdyasJ16Mk67l0ItYAITvSRDs xuFrn47kz27bmX/pf7UgjZA2jKEhqQDFtG1MskgBps8bEZnw042jGOoQyEMHLDP/vUAF tcw8jDbtwlsJpnfN6bMa3Twi/imAuRAQZgVh1ptkxj5Dor1UKo6w58EbeMIlzKtXAaK9 Iij3HkBg0dmuZJeaV2wBCAMRkJbILLAJByJI0jU/A8YjrsR3ga62gbRbpErpRoUY6YX3 iB/EOCfcwOf7xmcVPfBIamtn/BXPVVV2QRzOVOqYyc02LcpXmLMWUaTOlImdZsKxtCzn bCpA==
MIME-Version: 1.0
X-Received: by 10.229.131.85 with SMTP id w21mr1414380qcs.71.1367429788581; Wed, 01 May 2013 10:36:28 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.180.4 with HTTP; Wed, 1 May 2013 10:36:28 -0700 (PDT)
In-Reply-To: <CABP7Rbd08=A6FGA_Huydcx59MWjd7GgBsZ-hcQfAB4mt3d72yQ@mail.gmail.com>
References: <CABP7Rbd08=A6FGA_Huydcx59MWjd7GgBsZ-hcQfAB4mt3d72yQ@mail.gmail.com>
Date: Wed, 1 May 2013 14:36:28 -0300
X-Google-Sender-Auth: 89wZHLjtJh833lscOWUN84AY5Qc
Message-ID: <CAA4WUYiDLsc8VLiwfLbBAFk+Gc3MsZhxfYJ2qJUHZ06UwtM8Fw@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: James M Snell <jasnell@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=001517576d14cdfd1c04dbab8e50
X-Gm-Message-State: ALoCoQlklt8fHGE7skE/Pe5w8uSxdcuvf+BnF3cPAnrh4KZz4TVunKVnzMldlNdmcsxkbbfdTxtka4Vf84kooBcmDdrEoaSOoU2WAUigz49LeiSoqrqeozsFFgvn2D0ymjFk8vDuTRwWGT2LPMtOOWhZweTpAgE833FdGTqfnKKHHglKXKZ2Os6DzMVqGFwO4QuzWkJjat3x
Received-SPF: pass client-ip=209.85.216.171; envelope-from=willchan@google.com; helo=mail-qc0-f171.google.com
X-W3C-Hub-Spam-Status: No, score=-4.8
X-W3C-Hub-Spam-Report: AWL=-1.413, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.57, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UXaxa-0007I8-DW 1ef332993163df90b965d44cb99a31f6
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design Issue: Life-cycle of a Stream
Archived-At: <http://www.w3.org/mid/CAA4WUYiDLsc8VLiwfLbBAFk+Gc3MsZhxfYJ2qJUHZ06UwtM8Fw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17765
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 sending this email. This is great. I'll chime in with my
personal interpretations.

On Wed, May 1, 2013 at 2:03 PM, James M Snell <jasnell@gmail.com>; wrote:

> The current spec is rather vague on the complete life-cycle of a
> stream within a session. Aside from discussing how the Mommy Endpoint
> and the Daddy Endpoint get together, we ought to take just a bit of
> time to make sure we're all on the same page...
>
> In a separate thread, several of us discussed stream creation...
> specifically, how is a stream initiated. Let's see if we can formalize
> the process and the language. I've written the following out as
> statements, if you disagree with the statement or see it a different
> way, lemme know! Some of this is obvious and well established, I'm
> documenting it here just to make sure we have the complete picture
> captured. I've marked the items that appear to me to be the most
> controversial with an asterisk.
>
> 1. Streams are initialized or opened by sending a HEADERS or
> HEADERS+PRIORITY frame that uses a previously unused stream
> identifier.
>
> 2. Only HEADERS and HEADERS+PRIORITY frames are used to open a stream.
>
> 3. PUSH_PROMISE frames reserve a stream identifier but do not open the
> stream.
>
> 4. Promised streams are only opened by sending a subsequent HEADERS or
> HEADERS+PRIORITY frame that uses the reserved stream identifier.
>
> 5. All streams are either fully open, half-closed by the client,
> half-closed by the server, or fully closed.
>
> 6. All promised streams are associated with an originating "parent" stream.
>

For HTTP/2 I think this totally makes sense and this is the right
interpretation. Again, if we assume the framing layer is separate from
HTTP/2 usage, then this might not be good to require.


> 7. A stream is half-closed by sending a frame with the FINAL bit set.
>
> 8. A stream becomes fully-closed when either: a) both endpoints send
> frames with the FINAL bit set or b) either endpoint sends an RST_FRAME
> with that streams identifier.
>
> 9*. Promised streams are automatically half-closed for the recipient.
> That is, when the server sends a PUSH_PROMISE to a client, that
> streams becomes automatically half-closed for the client. The only
> frame the client can send back to the server for that stream are
> RST_STREAM frames.
>

I think we agreed on this interpretation in the last email thread you
raised on PUSH_PROMISE.


>
>   -- or --
>
> 9*. Promised streams are handled just like regular streams. The server
> opens the stream and half-closes. The stream does not fully close
> until either the client half-closes it or a RST_STREAM frame is sent
> for that stream.
>
> 10*. Sending an RST_FRAME for a parent stream fully closes that stream
> as well as all associated promised streams.


>   -- or --
>
> 10*. Sending an RST_FRAME for a parent stream only closes that stream
> and has no affect on associated promised streams.
>

I forget if we settled this issue or not. But I'm inclined to prefer your
second interpretation here. I'd rather explicitly reset streams.


>
> 11*. Fully closing a parent stream using symmetric half-closes will
> fully close all associated promised streams.
>
>   -- or --
>
> 11*. Fully closing a parent stream using symmetric half-closes has no
> affect on associated promised streams.
>

The latter. I believe the spec only says we have to promise the streams
before the parent stream closes. We don't have to even open the streams
yet. This is probably ideal since the parent stream is likely the main
document, and the main document is likely to contain the most important
data. One might say just send all the data and delay the sending of a
0-byte DATA frame with the FINAL flag set, but I see no reason to require
that. Speaking as an implementer, it's easier for the browser to receive
the FINAL flag ASAP (there are some implementation complications with
multiple readers and single writer, where multiple "readers" are requesting
a resource at the same URL, and are sharing the same response...we stream
the response to a single reader and only when we know it to be complete do
we stream to all other readers. don't ask me why, it's complicated and
relates to our cache implementation).


>
> 12. Half or fully closing a promised stream has no impact on the
> parent stream or any associated sibling promised streams.


> Ok, so that covers the lifecycle.. let's talk about processing.. this
> is largely a reiteration of my previous note on this but I want to
> make sure I've hit all the major points in how this is categorized.
>

I don't really want to start calling this Tier Number. I call things by the
relevant layer. Everyone else at the in person meetings has done the same.
I know jpinner@ has organized his code accordingly to his view of the
layers. I'd like us to standardize terminology on that.


>
> Tier 1: Includes the following...
>
> A. Reception and basic parsing of frames. "Basic parsing" here means
> looking at the header bytes to determine the frame type, making note
> of the flags, frame size and stream identifier, and performing any
> necessary header block decompression and state management.
>
> B. Handling of all session frames (stream id #0). This means that
> upgrade negotiation, SETTINGS, PING, flow control and session level
> error handling are all Tier 1 processes.
>
> C. Basic lifecycle handling of stream frames. This includes
> determination of whether a stream is open or closed, whether or not
> additional frames are allowed for a stream, validation of proper
> stream id use, reservation of stream id's with push_promise, and
> handling of the FINAL flag.
>
> Tier 2: Includes the following...
>
> A. Frame-type specific processing. Validation and handling of frame
> payloads and frame-specific flags, not including header block
> processing (which is tier 1)
>
> B. Additional stream-level error handling not related to stream-lifecycle
>
> Tier 3: Includes all application-level handling (HTTP Semantics)
>
> So, when we say things like "an endpoint must be prepared to continue
> receiving frames on a closed stream", we mean to say that "an endpoint
> must be prepared to do tier 1 processing on all frames, even those
> sent for closed streams."
>
> Please weigh in on whatever items y'all feel are controversial. I'll
> work up proposed spec edits based on whatever feedback is received.
>
> - James
>
>