Re: Clarification of dynamic table size change

Cory Benfield <> Mon, 19 October 2015 16:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ED95D1A8839 for <>; Mon, 19 Oct 2015 09:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tbPJFEY3kVeN for <>; Mon, 19 Oct 2015 09:16:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 971111A8788 for <>; Mon, 19 Oct 2015 09:16:06 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ZoD3s-0006mE-QH for; Mon, 19 Oct 2015 16:13:24 +0000
Resent-Date: Mon, 19 Oct 2015 16:13:24 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZoD3p-0006fm-02 for; Mon, 19 Oct 2015 16:13:21 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZoD3n-0005oc-Ps for; Mon, 19 Oct 2015 16:13:20 +0000
Received: by wicfx6 with SMTP id fx6so13238982wic.1 for <>; Mon, 19 Oct 2015 09:12:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=1M2+wcXy21GHt4urYH2JIy+EYUImEmcTZ5pmq1+vneY=; b=Gdhy3v7JJpIzRedGkndyPaQbm/fJYbqTxM1nIC/QHdBynbSSfd7S7jER2Nrerikf0q IktfiqeKVkk9ABIJN5pxWFJ+x117izNQ9hO4nKFHqzKCxw8m/2fJIoXR7u+2YqgVy3m0 2/RG+VOQYkwF2t8O70RVWqsIfOvXNB55N4c7LxxoTAtqQWKan9IH1q2k2Jx1JEgJYh34 FXmsWfa7R1WeHYMlJmHDJWC/wzZ6dfA8YBNO7OXDRk4tSH/B3rH9sVJiC+5v1p/8Q7po AePL6H0ulUAP2TT11UoM8DekYRNpCbNk37+PtwBEO063uu0SODPxH+IjhvM1TXOCpWKJ UCeg==
X-Gm-Message-State: ALoCoQkLQIsKeaMKUKw05SEscj+ps8YXcKkOWvWJFOaiRNh636GH5vqRDSW9IpruJ/FpISSZYhmF
X-Received: by with SMTP id v7mr13524234wiz.77.1445271173018; Mon, 19 Oct 2015 09:12:53 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id hs5sm15646701wib.6.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Oct 2015 09:12:52 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.4\))
Content-Type: multipart/signed; boundary="Apple-Mail=_06B6C9EE-49FF-4E0B-B3B1-F10D4E6FCF59"; protocol="application/pgp-signature"; micalg="pgp-sha256"
X-Pgp-Agent: GPGMail 2.6b2
From: Cory Benfield <>
In-Reply-To: <>
Date: Mon, 19 Oct 2015 17:12:50 +0100
Cc: "" <>
Message-Id: <>
References: <>
To: Tatsuhiro Tsujikawa <>
X-Mailer: Apple Mail (2.3096.4)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1ZoD3n-0005oc-Ps b4e236d5e74932bb16f9cdf7049bc51e
Subject: Re: Clarification of dynamic table size change
Archived-At: <>
X-Mailing-List: <> archive/latest/30381
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> On 19 Oct 2015, at 16:59, Tatsuhiro Tsujikawa <> wrote:
> I can read that dynamic table size update is always necessary as acknowledgement of SETTINGS_HEADER_TABLE_SIZE if it is present in SETTINGS.
> But someone can read in the other way.

Yeah, see, I read it the other way. My reading of section 4.2 of RFC 7541 emphasises this: “a *change* in the maximum size […] is signalled”. But you’re right that it’s ambiguous. In this case, I’d say that an implementation MAY emit a dynamic table size update if the size is unchanged (because it’s a no-op), but MUST do so if it has changed. For implementation simplicity, many implementations will chose to always emit that size update, but equally many implementations will not. If we’re counting, my own implementation does the same thing as Google’s: see here[0].

Specifically, I don’t think the HPACK layer should complain because a dynamic table size update was not received when the dynamic table size did not change. In this instance I believe nghttp2 is being overly strict about the relationship between the HTTP/2 layer and the HPACK layer.