Re: [quicwg/base-drafts] Make using static table and Huffman encoding in QPACK opt-in (#3622)

Lucas Pardue <> Fri, 01 May 2020 12:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1B1D3A114F for <>; Fri, 1 May 2020 05:25:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.302
X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bGvFn6IfI_bv for <>; Fri, 1 May 2020 05:24:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B41323A0772 for <>; Fri, 1 May 2020 05:24:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E3FF26A0021 for <>; Fri, 1 May 2020 05:24:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1588335896; bh=aikMlRiKqV4GoPetuFU/cVzROac0ntJ8Y4EdynJOv4o=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=0gfvrE13j6Yh4dPzcBnxr9aoQ3mjHGJpidZQmlFFlvf9WPl7OeYP8mrf9g7aW3MwJ t/nc2aGVZoWBKEIgqQTk3NBeFpwMkY80T7TighYgLqh4C/hB+A0qEIl2y1xYX/7X84 xORniH5RIkZgCCdK3o1mkjGsBBYo95hQMoCdWkA8=
Date: Fri, 01 May 2020 05:24:56 -0700
From: Lucas Pardue <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3622/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Make using static table and Huffman encoding in QPACK opt-in (#3622)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5eac1518d27e1_41a23fb1b2acd96c984c6"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: LPardue
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 May 2020 12:25:01 -0000

I understand the attractiveness of the idea but I think we're too late in the process to seriously consider changing this, independent of the specific details of proposals.

How should a server that has no intention of enabling this setting respond to HEADERS that include other instructions? If the answer is to blow up the connection then the (unintended?) side effect will encourage clients to start connections by sending all requests as "Literal Header Field Without Name Reference" until they receive the setting. But that stage of a HTTP/3 connection is the exact place where static and huffman have the most value; we groomed the static table to suit best the first flights of client requests.

My concern is that by trying to accommodate some smaller segment of HTTP clients, we cause a serious regression compared to HTTP/2.

This sort of thing seems better suited to a version that is "profile of HTTP/3" that disables some things and mandates others.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: