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

[Mike Bishop <[e-mail]>]

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:
https://github.com/quicwg/base-drafts/issues/3622#issuecomment-623704092