QPACK and the Static Table

[Mike Bishop <[e-mail]>]

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<https://github.com/quicwg/base-drafts/pull/1355> based 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="https://www.googleadservices.com/..."....
     *   Origin: https://www.facebook.com
     *   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?