Clarification of dynamic table size change

Tatsuhiro Tsujikawa <> Mon, 19 October 2015 16:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EC2161A872F for <>; Mon, 19 Oct 2015 09:03:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Status: No, score=-7.011 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, 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 BKedoxoo9d3x for <>; Mon, 19 Oct 2015 09:03:46 -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 39C411A8729 for <>; Mon, 19 Oct 2015 09:03:45 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ZoCrE-0001sr-LX for; Mon, 19 Oct 2015 16:00:20 +0000
Resent-Date: Mon, 19 Oct 2015 16:00:20 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZoCrA-0001T3-Jh for; Mon, 19 Oct 2015 16:00:16 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZoCr6-00058W-8c for; Mon, 19 Oct 2015 16:00:14 +0000
Received: by iow1 with SMTP id 1so197142293iow.1 for <>; Mon, 19 Oct 2015 08:59:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=HzzzG/hondHdZpP1HACoh50Dj4p65B+I7loRs+XPP4I=; b=m+bTDnvtVhUUQRvhX508mjSrqA4oe4ZpmNuZmv2vMHzXcCD3CJTSu/5E33B8PmKRxi XEY5MQHA6Vjmhn0NVRo7ij3YkDyuTHCNqYRxbrp2EdDuxhHJQkTHxIlpk5lgsCXEud1d oWfiaLs0T3wXv/ffexWiQbbJNOdetaq06IvoPWO4+wzJ8OOf8pbL1925T4cToRf+TFLe Rfd/AioM+Kndjt2ZsaZ97kMM0Wf0MNP/nPDvJ01ciCIitZGYRtRV45iqUKh3zRkSkman VeKk+8YVZY2NS1rZgDaqreOEU83+7ObyqFF1dzhKsqKUoY7YwdWSl5qU06j68wmczgIY eGmQ==
X-Received: by with SMTP id k63mr36746174ioi.103.1445270386124; Mon, 19 Oct 2015 08:59:46 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 19 Oct 2015 08:59:26 -0700 (PDT)
From: Tatsuhiro Tsujikawa <>
Date: Tue, 20 Oct 2015 00:59:26 +0900
Message-ID: <>
To: "" <>
Content-Type: multipart/alternative; boundary="001a113fbb5af82db60522773baa"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.5
X-W3C-Hub-Spam-Report: AWL=-0.775, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1ZoCr6-00058W-8c 68d588b0d534041a06a6c5172f17cb24
Subject: Clarification of dynamic table size change
Archived-At: <>
X-Mailing-List: <> archive/latest/30380
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>


I got the bug report from nghttp2 user:

When nghttp client sends SETTINGS_HEADER_TABLE_SIZE=4096 in the first
SETTINGS, it looks like google server does not send back dynamic table size
update.  This is probably because they think that it is not necessary
because table size is not changed.

I'd like to clarify this is a valid behavior.  Specification is not clear
enough in this special case.
So the question is whether we are required to send dynamic table size
update as acknowledgement for SETTINGS_HEADER_TABLE_SIZE if it is included

  SETTINGS_HEADER_TABLE_SIZE (0x1):  Allows the sender to inform the
      remote endpoint of the maximum size of the header compression
      table used to decode header blocks, in octets.  The encoder can
      select any size equal to or less than this value by using
      signaling specific to the header compression format inside a
      header block (see [COMPRESSION]).  The initial value is 4,096
   A change in the maximum size of the dynamic table is signaled via a
   dynamic table size update (see Section 6.3).  This dynamic table size
   update MUST occur at the beginning of the first header block
   following the change to the dynamic table size.  In HTTP/2, this
   follows a settings acknowledgment (see Section 6.5.3 of [HTTP2]).

   The new maximum size MUST be lower than or equal to the limit
   determined by the protocol using HPACK.  A value that exceeds this
   limit MUST be treated as a decoding error.  In HTTP/2, this limit is
   the last value of the SETTINGS_HEADER_TABLE_SIZE parameter (see
   Section 6.5.2 of [HTTP2]) received from the decoder and acknowledged
   by the encoder (see Section 6.5.3 of [HTTP2]).

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.

Best regards,
Tatsuhiro Tsujikawa