[quicwg/base-drafts] Static table negotiation (#1343)

[Mike Bishop <[e-mail]>]

During the discussion on #904, it was proposed that a means of using different static tables might be worthwhile.  We've already found that the web has moved on a bit from the headers in RFC 7541, and the same is likely to be true of whatever we put in HQ1.  It might be nice not to need a protocol rev to update the table every few years.

Another reason to support multiple tables:  Both the HPACK and the draft QPACK static table are based on browser web traffic.  Browsers and web aren't the whole of HTTP usage, and other users of HTTP might well define a static table better suited to their needs.  If such a mechanism is available, it might also make sense to define separate client and server tables.

A few models have been suggested, none of them ideal:

1. **An instruction to switch to a new static table.**  Probably difficult to actually work out, because of reordering of request streams with the control stream, but has the advantage that you can start by assuming the default table and switch to another later if the peer supports it.
2. **Crossed SETTINGS values.**  Each side declares its supported tables in preferred order.  Each side encodes using its most preferred table that was also in the peer's list; decode using the first entry in the peer's list that was also in your list.  Requires consuming the server's SETTINGS frame before sending any requests, which clients don't currently have to do, but the requirement to remember settings for 0-RTT plus the server's ability to send in 0.5-RTT makes this less onerous than it would have been in H2.  (Note that this option could also be implemented as an HTTP/2 extension.)
3. **Crossed transport parameter.**  As previous, but carried in a transport parameter.  There are currently no application-level settings exchanged in transport parameters, both due to separation of concerns and because the transport doesn't know in its initial flight what application protocol will be selected (in the general case), so it would need to carry the settings of all application protocols that ALPN is proposing.

I feel like this is interesting, but I'm undecided about whether it's unnecessary feature creep or useful future-proofing.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1343