Re: Clarification of dynamic table size change

Cory Benfield <cory@lukasa.co.uk> Mon, 19 October 2015 17:19 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 EBC701ACEA6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 19 Oct 2015 10:19:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 pjawxLrHN_oD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 19 Oct 2015 10:19:18 -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 CE83D1ACE9B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 19 Oct 2015 10:19:18 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ZoE2X-0003k1-Tm for ietf-http-wg-dist@listhub.w3.org; Mon, 19 Oct 2015 17:16:05 +0000
Resent-Date: Mon, 19 Oct 2015 17:16:05 +0000
Resent-Message-Id: <E1ZoE2X-0003k1-Tm@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) 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 1ZoE2U-0003jG-2y for ietf-http-wg@listhub.w3.org; Mon, 19 Oct 2015 17:16:02 +0000
Received: from mail-wi0-f171.google.com ([209.85.212.171]) by maggie.w3.org with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <cory@lukasa.co.uk>) id 1ZoE2R-0007jD-5e for ietf-http-wg@w3.org; Mon, 19 Oct 2015 17:16:00 +0000
Received: by wicfx6 with SMTP id fx6so15861572wic.1 for <ietf-http-wg@w3.org>; Mon, 19 Oct 2015 10:15:32 -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=qhyHdF9k3sn9og+jeMDLC1zhUhkLNFdB7Y2oQjVgRWU=; b=jwwvKvYa18YU9Up9VUAGPM043hcxkVFOFgc0iWXhoXGrwhFMljBxJBrmoYFU2OBN3x M4tUjFg1Ot7OFugr3ftLvcXGcfZaLM/5wFZId3bRMoqZCQUHdAwc12VR0Kth8Nw6/GC+ fuG+GCldEfDLYusq8MugKnUa0Bjnf5KlHaBIiNf+hRF4a9zOcs5k1aqgYF1xD6ATI0xH yeBSduQGavsO7fYGUTCn1zB/0X6k7eD0l+e5WTj5varAwU/uYEXsqsLW7P9jd/WQbvXa mHMJOj8etMNqTN3TSgAbN/5z0CvQtNLfddx6lZ903OYJacui86w6i0L2WLXWyFDylXEA OJQg==
X-Gm-Message-State: ALoCoQkzAMU4xgE5PVFy09nl7ggzfyzdW+CiBcgRPLKdRV3ybyEhilNLjuvWMUOvTh5hr5B9F+nS
X-Received: by 10.194.243.102 with SMTP id wx6mr35289397wjc.68.1445274932053; Mon, 19 Oct 2015 10:15:32 -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 q1sm41349400wjy.31.2015.10.19.10.15.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Oct 2015 10:15:30 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.4\))
Content-Type: multipart/signed; boundary="Apple-Mail=_831620A8-9044-4612-847C-82FDA6748A88"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.6b2
From: Cory Benfield <cory@lukasa.co.uk>
In-Reply-To: <CAPyZ6=JVZnn-bwkXpRfPJxMVsTOxLsqhMFLsLZX3s9ojR6C8tA@mail.gmail.com>
Date: Mon, 19 Oct 2015 18:15:28 +0100
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <3EE9A02C-794A-4147-A108-914AB19F2800@lukasa.co.uk>
References: <CAPyZ6=+wnoJ4o3g4eS3B2Om3Yqk+wD1_9L6HKWqT8-A4cztnBQ@mail.gmail.com> <EC984486-0010-4B7D-953E-3D1F183C547D@lukasa.co.uk> <CAPyZ6=JVZnn-bwkXpRfPJxMVsTOxLsqhMFLsLZX3s9ojR6C8tA@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.171; envelope-from=cory@lukasa.co.uk; helo=mail-wi0-f171.google.com
X-W3C-Hub-Spam-Status: No, score=-4.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1ZoE2R-0007jD-5e a3b3a293553852ba1f6f630dd3f7bc83
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Clarification of dynamic table size change
Archived-At: <http://www.w3.org/mid/3EE9A02C-794A-4147-A108-914AB19F2800@lukasa.co.uk>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30383
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 17:26, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:
> ​Could be.  But I don't think we mixed HTTP/2 layer and HPACK layer.  More specifically, we input the max header table size to HPACK, and see what it react to it in this case.  It is specific to HPACK implementation behaviour.
> 
> In general, we choose simpler path in HTTP/2​, I mean single execution path rather than "do this if we have x otherwise do that".  For example, we require client preface even if we negotiated HTTP/2 over ALPN.
> We send HTTP2-Settings in HTTP Upgrade request, but still we need to send SETTINGS frame in client preface.
> Taking into account of this split, it is more natural to always send header table size update as acknowledgement for SETTINGS_HEADER_TABLE_SIZE.  We can do more strict validation about the peer; it might forget to implement it anyway.

I don’t know that I buy that. The acknowledgement for SETTINGS_HEADER_TABLE_SIZE is a SETTINGS frame with the ACK flag set. Why is further acknowledgement required? As far as I can see it, there are two (slightly different) values here:

- SETTINGS_HEADER_TABLE_SIZE is the *maximum* value the encoder may use.
- Whatever is sent by the HPACK encoder in a dynamic table size update is the *actual* value being used.

You may be able to change the first without affecting the second (e.g. if you raise or leave unchanged the value of SETTINGS_HEADER_TABLE_SIZE). In the case that the second is not affected, it seems like unnecessary noise for the encoder to be forced to emit a dynamic table size update that has no change.

I don’t strongly object to adding an erratum to RFC 7541 that requires that a dynamic table update be emitted for any change to SETTINGS_HEADER_TABLE_SIZE, even if that change does not actually affect the size of the table the encoder will use, but my current reading of the specification does not require that such an update be emitted.

Cory