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

Mike Bishop <> Mon, 04 May 2020 21:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 746AF3A1074 for <>; Mon, 4 May 2020 14:03:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Status: No, score=-3.1 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_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, 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 BiWfaumpCD0i for <>; Mon, 4 May 2020 14:03:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D47F23A107D for <>; Mon, 4 May 2020 14:02:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ED7F4282CC9 for <>; Mon, 4 May 2020 14:02:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1588626177; bh=jnztmIuClL24Ac4pC7Fbrf6O7zNj3hYjPeIh8FuXSeo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=qcdFrF+XoaYBffrdidB8vPotVVaNi50t+rEGVJrvY8a373Klj50M+yBOy4XYsPLdw EjxgXIMI3m0rSAb/bX5yfgOB7e7l60QQdIAKxoF5I/4oIpTW5wXdQUEC4pOG9PdLx2 o49km2D5f2GzKZt8W9BZXa8WarspjczhZ0wsXo4o=
Date: Mon, 04 May 2020 14:02:57 -0700
From: Mike Bishop <>
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_5eb08301ddb7e_3ab83fbe1cccd96c3665ba"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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: Mon, 04 May 2020 21:03:06 -0000

The way we've designed SETTINGS is that you assume the minimal required capabilities from the peer until you learn that it supports more capabilities.  #3086 was an alternative design the working group did not consider acceptable given the current capabilities of TLS; any discussion of "when we fix" that issue depends on a hypothetical future version of HTTP that uses a hypothetical future version of QUIC that depends on ECHO or kin.  That may not particularly concern @vasilvv, but it concerns me.

If we reduced the minimum capability for QPACK, then the client is even further down the road of needing to either wait for the SETTINGS frame to learn capabilities or not compressing the headers.  I agree that there's some code size; there's also benefit as to size of the outgoing requests.  Based on that compression benefit, I would strongly oppose changing the default stance of the protocol.

There's actually no need for QPACK at all without these features.  There was a push in the HTTP/2 era to define a second ALPN token with more constrained defaults so that you never needed to drop back further from the defaults.  A new ALPN token that uses a simple encoding for HEADERS frames might be a better solution here.  I don't think that needs to be in the core spec; it would be a simple document to write if you think there's application demand for it.

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