Re: [quicwg/base-drafts] Consider making SETTINGS part of the control stream header (#2783)

Kazuho Oku <> Wed, 12 June 2019 01:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8ABCE120089 for <>; Tue, 11 Jun 2019 18:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.008
X-Spam-Status: No, score=-8.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QxzXxCkAsFZD for <>; Tue, 11 Jun 2019 18:35:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6470D12002F for <>; Tue, 11 Jun 2019 18:35:47 -0700 (PDT)
Date: Tue, 11 Jun 2019 18:35:46 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1560303346; bh=LmucBCQw29Ar7XvQdtwm3ZJGlh3ye5enM0O6QCNqYK8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=PeKVcEcWv1sqahdHLrI9mfJuDOGqAAnTjuVUQNzlcqulcVWAPscd8VaOMJR5cK+BI hyScBS4cPqvNKLwon/n+GDeven9PKdEPs2Oel5q5jCTFrwepK90Fdx5Wi0jLurS4Iu yfoBCFyBQxVY3uFODpUNUJHrrisstDWo7zMkXfPc=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2783/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Consider making SETTINGS part of the control stream header (#2783)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d0056f22a0f5_21223fc4a3ecd9641041db"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Jun 2019 01:35:50 -0000

While the proposal is interesting, I think my preference goes to retaining the current design.

I agree that HTTP_MISSING_SETTINGS is unnecessary, it is my view that it should be merged to HTTP_UNEXPECTED_FRAME.

But once it gets done, it would be my view that the complexity is indifferent; there is no difference in the encoding-side (just sending different series of octets). On the decoding-side, it either having a state that receives series of special octets or a state that receives a particular frame.

That said, the reason I prefer using a frame for carrying the settings is because it makes the design consistent. Having a layer that is used for "frame"-ing all the information being exchanged is a good thing.

IMO the use of HTTP_UNEXPECTED_FRAME or HTTP_WRONG_STREAM in relation to SETTINGS frame is fine, because use of these errors are the design pattern we use for other frames too. For example, HTTP_UNEXPECTED_FRAME is used to indicate error when the peer sends a DATA frame before a HEADERS frame. Or transmission of a HEADERS frame on the control stream triggers the HTTP_WRONG_STREAM error.

I prefer using that same design pattern for everything, rather than creating different rules for the way things are being sent in each state.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: