Re: Clarification of dynamic table size change

Cory Benfield <cory@lukasa.co.uk> Mon, 19 October 2015 16:16 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED95D1A8839 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 19 Oct 2015 09:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbPJFEY3kVeN for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 19 Oct 2015 09:16:06 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 971111A8788 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 19 Oct 2015 09:16:06 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ZoD3s-0006mE-QH for ietf-http-wg-dist@listhub.w3.org; Mon, 19 Oct 2015 16:13:24 +0000
Resent-Date: Mon, 19 Oct 2015 16:13:24 +0000
Resent-Message-Id: <E1ZoD3s-0006mE-QH@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <cory@lukasa.co.uk>) id 1ZoD3p-0006fm-02 for ietf-http-wg@listhub.w3.org; Mon, 19 Oct 2015 16:13:21 +0000
Received: from mail-wi0-f182.google.com ([209.85.212.182]) by lisa.w3.org with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <cory@lukasa.co.uk>) id 1ZoD3n-0005oc-Ps for ietf-http-wg@w3.org; Mon, 19 Oct 2015 16:13:20 +0000
Received: by wicfx6 with SMTP id fx6so13238982wic.1 for <ietf-http-wg@w3.org>; Mon, 19 Oct 2015 09:12:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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 10.180.87.71 with SMTP id v7mr13524234wiz.77.1445271173018; Mon, 19 Oct 2015 09:12:53 -0700 (PDT)
Received: from [192.168.1.3] (29.97.45.217.dyn.plus.net. [217.45.97.29]) by smtp.gmail.com with ESMTPSA id hs5sm15646701wib.6.2015.10.19.09.12.51 (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 <cory@lukasa.co.uk>
In-Reply-To: <CAPyZ6=+wnoJ4o3g4eS3B2Om3Yqk+wD1_9L6HKWqT8-A4cztnBQ@mail.gmail.com>
Date: Mon, 19 Oct 2015 17:12:50 +0100
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <EC984486-0010-4B7D-953E-3D1F183C547D@lukasa.co.uk>
References: <CAPyZ6=+wnoJ4o3g4eS3B2Om3Yqk+wD1_9L6HKWqT8-A4cztnBQ@mail.gmail.com>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
X-Mailer: Apple Mail (2.3096.4)
Received-SPF: pass client-ip=209.85.212.182; envelope-from=cory@lukasa.co.uk; helo=mail-wi0-f182.google.com
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: lisa.w3.org 1ZoD3n-0005oc-Ps b4e236d5e74932bb16f9cdf7049bc51e
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Clarification of dynamic table size change
Archived-At: <http://www.w3.org/mid/EC984486-0010-4B7D-953E-3D1F183C547D@lukasa.co.uk>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30381
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>

> On 19 Oct 2015, at 16:59, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> 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.

Cory

[0]: https://github.com/python-hyper/hpack/blob/master/hpack/table.py#L188