Re: Clarification of dynamic table size change

Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> Mon, 19 October 2015 16:29 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 9DDBD1A89A2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 19 Oct 2015 09:29:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiT1AD743XVA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 19 Oct 2015 09:29:57 -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 D47841A8853 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 19 Oct 2015 09:29:57 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ZoDH8-0000pA-U8 for ietf-http-wg-dist@listhub.w3.org; Mon, 19 Oct 2015 16:27:06 +0000
Resent-Date: Mon, 19 Oct 2015 16:27:06 +0000
Resent-Message-Id: <E1ZoDH8-0000pA-U8@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 <tatsuhiro.t@gmail.com>) id 1ZoDH5-0000oN-Ep for ietf-http-wg@listhub.w3.org; Mon, 19 Oct 2015 16:27:03 +0000
Received: from mail-oi0-f52.google.com ([209.85.218.52]) by lisa.w3.org with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <tatsuhiro.t@gmail.com>) id 1ZoDH3-0006U5-UK for ietf-http-wg@w3.org; Mon, 19 Oct 2015 16:27:03 +0000
Received: by oies66 with SMTP id s66so61718596oie.1 for <ietf-http-wg@w3.org>; Mon, 19 Oct 2015 09:26:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cvRrxgDPSPCuCS+SZh68gGyfyWGfV7uLgt0cOE6wmfU=; b=iDJFMSGgACdzyZmPivjplKgVeXs3iRNDnWF8XlAmYnWTMFfOLwZtcOU3HMy/H50wIj 4lxCp9DWgk12RKdijNNdSZNLLYn4WcKMnwPnkv0RaZ1cZeQ3O0rT9GrH8ICzioURbB+h qz37eZ6+sw5SEpPELztIai8RyNPSxtumusNSo9UuIk66pV4MvQQC5aiARBZw1R/IdhkT ZPw6L+PZkXkFWCu9xVBhs0BGJuvIb1c2p8b0MoOhdjfauOKDxLHBlm5rkYlHaY4Wt3aM vw/toHTx/GHIR02DR/63bimPikJjA69uon5s2i8mBgbPOo31G8cGsdNr3JX2a+oSyp9S FEDA==
X-Received: by 10.202.168.129 with SMTP id r123mr11285971oie.44.1445271995871; Mon, 19 Oct 2015 09:26:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.114.103 with HTTP; Mon, 19 Oct 2015 09:26:16 -0700 (PDT)
In-Reply-To: <EC984486-0010-4B7D-953E-3D1F183C547D@lukasa.co.uk>
References: <CAPyZ6=+wnoJ4o3g4eS3B2Om3Yqk+wD1_9L6HKWqT8-A4cztnBQ@mail.gmail.com> <EC984486-0010-4B7D-953E-3D1F183C547D@lukasa.co.uk>
From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Tue, 20 Oct 2015 01:26:16 +0900
Message-ID: <CAPyZ6=JVZnn-bwkXpRfPJxMVsTOxLsqhMFLsLZX3s9ojR6C8tA@mail.gmail.com>
To: Cory Benfield <cory@lukasa.co.uk>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=001a113ccffceaf6150522779b20
Received-SPF: pass client-ip=209.85.218.52; envelope-from=tatsuhiro.t@gmail.com; helo=mail-oi0-f52.google.com
X-W3C-Hub-Spam-Status: No, score=-5.5
X-W3C-Hub-Spam-Report: AWL=-0.770, 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: lisa.w3.org 1ZoDH3-0006U5-UK c623fc8ba275aa809e668292a62a8c80
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Clarification of dynamic table size change
Archived-At: <http://www.w3.org/mid/CAPyZ6=JVZnn-bwkXpRfPJxMVsTOxLsqhMFLsLZX3s9ojR6C8tA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30382
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>

Hi,

On Tue, Oct 20, 2015 at 1:12 AM, Cory Benfield <cory@lukasa.co.uk> wrote:

>
> > 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.
>
>
​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.

Best regards,
Tatsuhiro Tsujikawa




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