Re: [quicwg/base-drafts] HTTP SETTINGS: define setting content encoding (#1556)

Mike Bishop <> Fri, 27 July 2018 19:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82147130DF5 for <>; Fri, 27 Jul 2018 12:52:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Status: No, score=-8.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 JzU3qxzvngUr for <>; Fri, 27 Jul 2018 12:52:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7931B130DD1 for <>; Fri, 27 Jul 2018 12:52:28 -0700 (PDT)
Date: Fri, 27 Jul 2018 12:52:27 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1532721147; bh=nEWPxU3aIkVMvARBeOW++Uv5iP3FJ5BeJbPK4oC0egg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=hnAZWAGuVVa2VfTapxJtfzA82xtlgHCmOHdXXtLXcGKhBmg1D7aNWcp5/+ewfWlpf fCuMkJOQKubgtcuzhg8JrMLjt+6xcCv97+8oowBUY7MPtcoMjyfDQm3wk58a70buAT rv6Hc6/zsI8PkIcSJEOE1lOVGpA0GDuatBXz7yXc=
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/1556/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] HTTP SETTINGS: define setting content encoding (#1556)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b5b77fb65397_77d63f9eaa4be6181097cd"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.27
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: Fri, 27 Jul 2018 19:52:31 -0000

@afrind, that's an interesting point.  Could you split that out into a separate issue?

The current boolean encoding is intended to save bytes in the case of turning something on/off and not needing to convey any other data (e.g. "I support extension Foo").  If you don't send anything, the default case, it's false; it takes the minimum possible length to send true.  Because HQ doesn't allow modifying settings after the initial setup, we don't need an affordance for turning something that was true back to false.  In HTTP/2, you got 32 bytes regardless of how much or little you needed to convey, so settings of this sort use 0/1 and make other value invalid, or they use 0/non-zero.  However, most extensions to HTTP/2 so far have defined non-critical frames that didn't need a setting.

I'm not opposed to saying the payload of the integer settings isn't a varint, but it seems like that introduces additional complexity to deal with oddly-sized integers.  Is that a noticeably different level of complexity from having to check that the varint is the size claimed by the setting?

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