Re: Position of HPACK Dynamic Table Size Update

Cory Benfield <cory@lukasa.co.uk> Thu, 30 March 2017 08:43 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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69FD1294AC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 30 Mar 2017 01:43:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.401
X-Spam-Level:
X-Spam-Status: No, score=-6.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lukasa-co-uk.20150623.gappssmtp.com
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 u1HZWapyXO1Y for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 30 Mar 2017 01:43:34 -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 D7FF01293E9 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 30 Mar 2017 01:43:33 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ctVdP-0008Kq-IO for ietf-http-wg-dist@listhub.w3.org; Thu, 30 Mar 2017 08:40:47 +0000
Resent-Date: Thu, 30 Mar 2017 08:40:47 +0000
Resent-Message-Id: <E1ctVdP-0008Kq-IO@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <cory@lukasa.co.uk>) id 1ctVdJ-0008Hx-E9 for ietf-http-wg@listhub.w3.org; Thu, 30 Mar 2017 08:40:41 +0000
Received: from mail-wr0-f181.google.com ([209.85.128.181]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <cory@lukasa.co.uk>) id 1ctVdD-0007tZ-67 for ietf-http-wg@w3.org; Thu, 30 Mar 2017 08:40:36 +0000
Received: by mail-wr0-f181.google.com with SMTP id l43so50955768wre.1 for <ietf-http-wg@w3.org>; Thu, 30 Mar 2017 01:40:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lukasa-co-uk.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mUYWVGHqeAND34eRbdiIbqs1Nx03KvMFUtZ3K2k2cFs=; b=DQ1Z4KGHyMhyKARvu1HV8aBluruQ8hA4QLaz7iFj3MuIDkfciptwi4tFVGq+TNnD4A jbmvRqQzvGDzLSp/DAicLGrKW0pcXTS/0rxKHG/HhVaT27jZIjmpmVj+UTTLV9HHJWOX GnjZO3kJCCyKkDIZegkhRPIZkDj+r6i5ylml2mo9MR4RHMclf5HEO76Vcqms5nwz0JH3 3i6WfDleIpDi4sPpBQav9xPh70496s0DcSuR2InOp43SBEAWIeWzvocGRwonXm6mdAtp Dke8XlH31bFNrL2MeJlfCsi+XcsoNpgtWGL4ICV+b989HJP/Denjcqe6KTiFIQck7C65 M3QA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mUYWVGHqeAND34eRbdiIbqs1Nx03KvMFUtZ3K2k2cFs=; b=quUqR/Qh5AwhZllHO9WYZ431/P27JYcGuKOyjGCNKZbzgAhuBCrqxyGgPkKL+OcD8Q 5cPBmXK3Ze4FtwyPyb4tw+kiIguyFQNSw9ADY1MzDCUv1ZuLFICBItJorm45WGB6iApU OaKHRVEOqPvD6B0mswW5CHZkVf1ijr8+9W/wHlTGkn9QRTMdwxk/UbkPr766U0KviT8Y mY0/aBRTOE+JYFH4ym+bMhBATClBt6NmXxmLPWFPx27INuSYEzFtQ8aMjnHWSWxDcLHC sjUdhXzV/hVNB3YhfbKaVqp4gq85ae+RLp1fX7GgnQpgC1I0mDs+BFIJBd3vhGvC62Ya 8PxA==
X-Gm-Message-State: AFeK/H1oA9NW9MIfRe7ME3PUeY2imhmozgMVHLsBjlKFRTEfDwH+6bNkre32I06J0mH0xQ==
X-Received: by 10.28.166.133 with SMTP id p127mr2332615wme.62.1490863207917; Thu, 30 Mar 2017 01:40:07 -0700 (PDT)
Received: from [192.168.1.3] (78.17.75.194.dyn.plus.net. [194.75.17.78]) by smtp.gmail.com with ESMTPSA id h187sm11354771wma.32.2017.03.30.01.40.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 01:40:07 -0700 (PDT)
From: Cory Benfield <cory@lukasa.co.uk>
Message-Id: <A3B0997A-F8A6-4FDB-ACC3-834BCCCA303C@lukasa.co.uk>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BBD1E63A-2A51-4581-9D5C-6D60C4E013CC"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 30 Mar 2017 09:40:05 +0100
In-Reply-To: <CAPyZ6=JcDH42ayhLX6AN4EV4DtJv+W4aqLTZA1MhSnyugjf4FQ@mail.gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
References: <CAPyZ6=JcDH42ayhLX6AN4EV4DtJv+W4aqLTZA1MhSnyugjf4FQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Received-SPF: pass client-ip=209.85.128.181; envelope-from=cory@lukasa.co.uk; helo=mail-wr0-f181.google.com
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1ctVdD-0007tZ-67 f110cc47f904fe75e84332f57124a0ed
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Position of HPACK Dynamic Table Size Update
Archived-At: <http://www.w3.org/mid/A3B0997A-F8A6-4FDB-ACC3-834BCCCA303C@lukasa.co.uk>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33793
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 29 Mar 2017, at 14:32, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:
> 
> Hi,
> 
> I'd like to clarify the requirement of the position of HPACK Dynamic Table Size Update.
> Should it appear always at the beginning of the header block?  Or is it only required to do so only if it is the ack of SETTINGS?
> 
> Background: https://github.com/summerwind/h2spec/issues/78 <https://github.com/summerwind/h2spec/issues/78>
> 
> Best regards,
> Tatsuhiro Tsujikawa

Interesting. I’ve definitely read that section of the RFC as saying that dynamic table size updates must occur at the front of a block, but that you may have more than one in sequence. Put another way, a given header table size block may have 0 or more dynamic table size updates, followed by headers.

But of course, there is nothing in the text that actually requires this. It does seems somewhat simpler to say that header table size updates must come at the start of a header block.

Cory