Re: QPACK and the Static Table

Mark Nottingham <> Wed, 23 May 2018 23:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 21306127077 for <>; Wed, 23 May 2018 16:47:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=I0FqwY4y; dkim=pass (2048-bit key) header.b=D26Ev6cF
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fUYLN7M3_zZe for <>; Wed, 23 May 2018 16:47:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ACF4D1273B1 for <>; Wed, 23 May 2018 16:47:50 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 2850221F1A; Wed, 23 May 2018 19:47:50 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute3.internal (MEProxy); Wed, 23 May 2018 19:47:50 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=4VTKw4WLQ6Pw3fI2MeqgvwNaNRq54 uGw/evx9JBnREg=; b=I0FqwY4ywyHO/Yitq5iAz0RxMb80qSeyBhy32NLSa2DWF RwnQ3yMsWX1bYC2plJp4lkCj4DZwXPnV0d/9zOQWfsdwnNpRLwPnV1kqAFcXu3pO ree30X2nnqugtZFgG5JjoCXvw80RB2KrEXWroaqiUVLcFCPAn75iua0B9qwwEqvq AymaSG0h52v8wseKqNdCJuxHUrANeochpR/hraWuzsahHTLP9msfDFgBbzNddf26 McPuv8Hdz+XpsmBscAfPXjP/rwNX2eYuMS/LuA0Et5x+NgzaxVryDwJKQQ5U5i54 UlyzrS2khEqoDoH99MKVXatVhgiEmpo2BXtv59F3w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=4VTKw4 WLQ6Pw3fI2MeqgvwNaNRq54uGw/evx9JBnREg=; b=D26Ev6cFMgn0N1NnIkalwv FHAl5uxL6J6KPV/qDnHKldXD12pkC4cNnvbdjSIzx9J84U67fGrEi+ahT1qeOtFZ CQ71cvu2cgDXVoknqa63zEF8yCkccNzRr5Q/Rf6dvPAE4SfZrMpbIsMmAUMdGC9H uQZHcJi9yMqo0Pvz3haoUqMtteH34tK5JJR9rSuMTyOeWGGtpEOnA7QfnCjbwc4n MgvMcK2ZL+aDUFW2O16Z9gWUl+viMFJUG5nAfk21mBmyqxMqq4EaR0tqtqQI6BvE smGhyrrX4qZYpVHYlHqKFz5PQh8UgdVfqCfljO7ztytxKnP6XXylVrZPmEY5Mzvg ==
X-ME-Proxy: <xmx:pf0FW9FvFzjO4aSKqaKl1d--WMLahQ3U36nQM_VsyhKOJ2P9Ju0pMQ>
X-ME-Proxy: <xmx:pf0FWySjfUL6GNKtamF9FZ7UD60j4FOM8FyaLgfkTlsWMMcGHd4IIQ>
X-ME-Proxy: <xmx:pf0FW6vsQd1C8rZBSS9BOU-ObWFqH7k8KH5oeYE31fe-Zl38X1HPeQ>
X-ME-Proxy: <xmx:pf0FW4C7H0Tle97HPZ8Dn4HsOgPrCrRu1nPhItot_IohMx5oDFF_2Q>
X-ME-Proxy: <xmx:pf0FW8158fp_iQkvilUxpsZGGfwOIpWF_NgIVz9L9M88z31eE58bBw>
X-ME-Proxy: <xmx:pv0FW0b2gNZWCoP4SrE4NW8BL2UFpw4a8OpY4rQcO_-L0AOaz2Jn8g>
X-ME-Sender: <xms:pf0FW0kDP2U4TKcyviNw_mhJ-4QBlKgNpakpjt7GZn2jOSqgyZ6dDA>
Received: from [] (unknown []) by (Postfix) with ESMTPA id 6616CE4437; Wed, 23 May 2018 19:47:48 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Re: QPACK and the Static Table
From: Mark Nottingham <>
In-Reply-To: <>
Date: Thu, 24 May 2018 09:47:45 +1000
Cc: HTTP Working Group <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Mike Bishop <>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 May 2018 23:47:55 -0000

Hey Mike,

My .02 (I also left some notes in the PR) -

The static table is most useful on request headers, so that's what we should be focusing on. If it were me, I'd drop all of the response header fields except the most common ones (say 10 or so), and focus on request headers.

In fact, I'd look at paring down the number of entries in total for *just* the initial requests on a connection -- putting too many things in the static table might influence how implementations emit other headers, and that's not the intent here.

The HTTP Archive is a bit problematic; not only is it focused on "big" sites (albeit a lot of them), but it's also AIUI pretty homogenous on the client side, so it's not going to be very representative for request headers.

I think it would be better to get a sample of request headers seen by a couple of sites, a CDN or two, and at least one "HTTP API" type deployment, and see where that leads -- if we can find someone willing to do the work.


> On 24 May 2018, at 9:16 am, Mike Bishop <> wrote:
> Wanted to get a sense of the affected working groups on two issues in QPACK (header compression for HTTP/QUIC).
> Rather than indexing the tables together and having the static table at 1-61, QPACK uses a bit to indicate static vs. dynamic.  Since the field is seven bits long, the performance is comparable for the dynamic table (you can access 63 entries in one byte, 190 in two), but you can increase the size of the static table without hurting the dynamic table.  As a result, we’re building a fresh static tablebased on queries against HTTPArchive data.
> The key question that has come up in a couple venues:  What real-world headers do we want to artificially remove from what the data shows, and what headers not seen by HTTP Archive do we want to force in anyway?
> So far, we’ve:
> 	• forced in pseudo-headers because the Archive doesn’t capture them and they would otherwise be absent
> 		• :path, :authority, :method
> 	• deleted values presumed biased by the test configuration:
> 		• Server: (various vendors)
> 		• User-Agent
> 		• Accept-Language: en-us, en;q=0.9
> 		• Content-Length: 531
> 			• I still wonder exactly why that’s so common….
> 		• P3p: policyref=””….
> 		• Origin:
> 		• Alt-Svc for various versions of gQUIC
> 		• …the list goes on
> 	• deleted headers prohibited by HTTP/QUIC and HTTP/2
> 		• Transfer-Encoding: chunked
> 	• Reordered to put headers you’re likely to name-reference at the front, especially if you’re unlikely to add them to the dynamic table
> The question is whether we should also backfill headers which HTTP Archive wouldn’t see, delete headers we wish people wouldn’t use, and/or insert the ones we hope they eventually will.  Some candidates:
> 	• Add Alt-Svc entry for HTTP/QUIC with QUIC v1
> 	• Add X-Forwarded-For
> 	• Don’t add X-Forwarded-For, but do add Forwarded
> 	• Remove Expires to incent the use of Cache-Control
> 	• Collapse the “Content-Type: <thingey>” and “Content-Type: <thingey>; charset=utf-8” entries together
> 		• …but which one to keep?
> 	• Add Content-Encoding and/or Accept-Encoding entries for zstd
> There’s an endless parade of bikesheds here.  As Martin has pointed out, this will never be perfect, so the goal is “good enough and keep going.”  Any strong feelings about any of these before we merge it?
> Also, there’s been some discussion of a mechanism for selecting one of several static tables at the start of a connection.  In that case, the spec would probably define three tables (client headers, server headers [for servers that don’t push], combined [for servers that push]) and enable future RFCs to define others for targeted scenarios (proxies, video playback, IoT, etc.).  How much does that interest folks?

Mark Nottingham