Re: QPACK and the Static Table

Martin Thomson <> Thu, 24 May 2018 00:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDAF812D87D for <>; Wed, 23 May 2018 17:38:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bEq-FBu2O3hZ for <>; Wed, 23 May 2018 17:38:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ADF9412D87A for <>; Wed, 23 May 2018 17:38:34 -0700 (PDT)
Received: by with SMTP id l13-v6so27394766otk.9 for <>; Wed, 23 May 2018 17:38:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=f8L69NNbipk5awztxQV9rZ7rTPhukIAlg+GJq/LUu4k=; b=I6b/nS2kweYaS3aPL9fgEKK21ccNAYGOsG0e5eQBqi7koVIwyy0Ef6HL3huv+H44PC ylnaqzoO5FbdqCyMKpus7/OXdNrlH1dzH682A970lcW7+mn3tZFEINV68Ao8BG9p7256 TVOBITd3Y5SVKf9jOjtoiTpDI0k3WUZ4f2OIOFVFZTU0wjsWshUugaS11y7+gvx9X9Sf hvFb+Yc1yGWyncaLp11X/VcBkPbQEjfPXZm+kRMgqSbGIqtcwYgi55krvOd1bjZxF4UR i8FNIHaBXiRD9UMDx5xnwM/9OEVszFXYGY4xmtaHIcEbzOJzvaupbiNcv9uzmMkN1vZv 6DVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=f8L69NNbipk5awztxQV9rZ7rTPhukIAlg+GJq/LUu4k=; b=hJnnBlq3bgGSxg6IOLDb4W+sIo0w9gOV6+zzCvy9hzFAKKdyPd97lzodkI7FrGzoxB +LnFU4ZL7n2FZ4PQbFcI3bhkyRwh4GBm/oa0BdgA9Zv192WGF90glRQbrOlfIXcoCddD 8zsNDPbPF8ISCjEqRZrLD7KqPDsFxqBqZ6TGr69LTIbecGPLKw1MYlh85Yw+xCfEMluK 1PvZNAh77na0ke6EyeKznyR+kL5498g3BgiAspjqteSWvhKWL0JA/Xnb15h0rZVD2lyX 0bfSn6zC0pfhvGd+B0o6uXPZO6EUpyZ+XmZCZNJ7sPKQ6euSqy72L1bXrahhinXADnd1 FdOg==
X-Gm-Message-State: ALKqPwf3L203L8xj6kDKnlyogxZLB31qW3FxfsO/7+RPHNWT/+5pTUc8 bZO8/gx0NJj6ZgG4Xfqe2+R5mZE6yuVHiPdT0sE=
X-Google-Smtp-Source: AB8JxZrPJItBFVNNplwhbdXGHvU4oZNSHqGGVP853R4c2vbMY4WLfde+W47VGiFnun3JXynF2U/U8FPGTg8NzFwGWnc=
X-Received: by 2002:a9d:3a65:: with SMTP id j92-v6mr3491399otc.352.1527122314033; Wed, 23 May 2018 17:38:34 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Martin Thomson <>
Date: Thu, 24 May 2018 10:38:24 +1000
Message-ID: <>
Subject: Re: QPACK and the Static Table
To: Mike Bishop <>
Cc: HTTP Working Group <>, QUIC WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Thu, 24 May 2018 00:38:37 -0000

It might be worth skimming our current drafts and recent RFCs for header
fields that might be useful.  Early-Data seems like a real option, value
and all.
On Thu, May 24, 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 table based on queries against HTTPArchive

> 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?