IETF Logo Mail Archive

RE: Position of HPACK Dynamic Table Size Update

Mike Bishop <Michael.Bishop@microsoft.com> Wed, 29 March 2017 14:34 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 F242C127599 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 29 Mar 2017 07:34:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 ho4NcYrLE5ns for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 29 Mar 2017 07:34:26 -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 8E4C6127449 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 29 Mar 2017 07:34:21 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ctEdA-0001GB-L0 for ietf-http-wg-dist@listhub.w3.org; Wed, 29 Mar 2017 14:31:24 +0000
Resent-Date: Wed, 29 Mar 2017 14:31:24 +0000
Resent-Message-Id: <E1ctEdA-0001GB-L0@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 <Michael.Bishop@microsoft.com>) id 1ctEd2-0001FM-VU for ietf-http-wg@listhub.w3.org; Wed, 29 Mar 2017 14:31:17 +0000
Received: from mail-sn1nam01on0124.outbound.protection.outlook.com ([104.47.32.124] helo=NAM01-SN1-obe.outbound.protection.outlook.com) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from <Michael.Bishop@microsoft.com>) id 1ctEcw-0007dD-GK for ietf-http-wg@w3.org; Wed, 29 Mar 2017 14:31:11 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Wvfr1icwjSV4Hu6iJYy4JA6ZpCKn9+zxlnaUwIH9gH8=; b=oYVNvu2EBdgazC7qm2XsWQSfXO3L805kiqAALWmPT+fvx1fvhNxp8MdPMvrG+CQ6bHTqPZ0YsNsspMv5qcMnMoL/l/uR1sd3GNhJET3HxM0eYOJCEp1CrTKDNfyAVBBal5SKE5iP8RBKl7PCuzJl488yTckreJPNhftOU5MFUAk=
Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2706.namprd03.prod.outlook.com (10.173.144.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Wed, 29 Mar 2017 14:30:41 +0000
Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0991.021; Wed, 29 Mar 2017 14:30:41 +0000
From: Mike Bishop <Michael.Bishop@microsoft.com>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Thread-Topic: Position of HPACK Dynamic Table Size Update
Thread-Index: AQHSqJGDarpRF+nbnUOR08RyGAcPOaGr36ng
Date: Wed, 29 Mar 2017 14:30:41 +0000
Message-ID: <BN6PR03MB27086A615C00A1EB6B5513F187350@BN6PR03MB2708.namprd03.prod.outlook.com>
References: <CAPyZ6=JcDH42ayhLX6AN4EV4DtJv+W4aqLTZA1MhSnyugjf4FQ@mail.gmail.com>
In-Reply-To: <CAPyZ6=JcDH42ayhLX6AN4EV4DtJv+W4aqLTZA1MhSnyugjf4FQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [31.133.134.0]
x-microsoft-exchange-diagnostics: 1; BN6PR03MB2706; 7:svMoZX1VAXZdp5BJwf7oyAOile9/4YTR0GkSOg1qHnPvlA/2b1dhfiJJ85D8PxMxQtI3kr0Ysj7uohjaeR6Q2aNUIu+APXpYg7C8xlnk+I662VLBFpLN0HMB255GOzffnFMTMa6YPNlFiJiGLbmoOIrwGd5QkrWLenV4Fpqy7nIOjDBiXuaZX69G/peKg53rybfQR986O5zdZqUYx7gDRHHBctJx0ua7hE7I4EavQWYINsTBSoENOyczsdBqZOwerfVYQawUVggDgIBZqugGaF3tUWHOIMvLzkNmiR1VYhWKlq3phX4YgVdEaQHENp6hnFDzXZkXPyrjVoeVtMJ3z0MuZ2N3XmzH3qSfUOw+oF0=
x-ms-office365-filtering-correlation-id: 94ad2b12-5960-4700-1e30-08d476b02d7d
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN6PR03MB2706;
x-microsoft-antispam-prvs: <BN6PR03MB2706AD6AE65C0937A20CC91F87350@BN6PR03MB2706.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406075)(20161123558025)(20161123555025)(20161123562025)(6072148); SRVR:BN6PR03MB2706; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2706;
x-forefront-prvs: 0261CCEEDF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39400400002)(39860400002)(39450400003)(39840400002)(39410400002)(377454003)(3660700001)(8676002)(236005)(3846002)(6116002)(2950100002)(102836003)(54356999)(50986999)(76176999)(790700001)(189998001)(6246003)(7110500001)(86612001)(55016002)(99286003)(81166006)(9686003)(8936002)(122556002)(6436002)(77096006)(7696004)(54896002)(38730400002)(6506006)(606005)(3280700002)(6306002)(5660300001)(25786009)(39060400002)(2900100001)(86362001)(53546009)(2501003)(74316002)(7906003)(66066001)(53936002)(19609705001)(7736002)(2420400007)(15650500001)(10710500007)(229853002)(10290500002)(8990500004)(10090500001)(5005710100001)(2906002)(33656002)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2706; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR03MB27086A615C00A1EB6B5513F187350BN6PR03MB2708namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 14:30:41.2566 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2706
Received-SPF: pass client-ip=104.47.32.124; envelope-from=Michael.Bishop@microsoft.com; helo=NAM01-SN1-obe.outbound.protection.outlook.com
X-W3C-Hub-Spam-Status: No, score=-1.8
X-W3C-Hub-Spam-Report: AWL=-0.239, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_NW=0.5
X-W3C-Scan-Sig: mimas.w3.org 1ctEcw-0007dD-GK 2f420fe64b3c64f6b1da9ea2aed9f194
X-Original-To: ietf-http-wg@w3.org
Subject: RE: Position of HPACK Dynamic Table Size Update
Archived-At: <http://www.w3.org/mid/BN6PR03MB27086A615C00A1EB6B5513F187350@BN6PR03MB2708.namprd03.prod.outlook.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33789
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>

I can’t speak to everyone’s implementation, but I don’t believe there’s a restriction on where in the packet an encoder can choose to change the table size.  We discussed, for example, the ability to clear the table by issuing back-to-back changes to zero and back to non-zero.

I would restate the highlighted text in the table as “if the SETTINGS_MAX_TABLE_SIZE changes such that the current size is no longer valid, the encoder MUST emit a table size change instruction prior to emitting any new compressed header blocks.”

From: Tatsuhiro Tsujikawa [mailto:tatsuhiro.t@gmail.com]
Sent: Wednesday, March 29, 2017 8:33 AM
To: ietf-http-wg@w3.org
Subject: Position of HPACK Dynamic Table Size Update

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
Best regards,
Tatsuhiro Tsujikawa

v2.39.1 | Report a Bug | By Email | System Status