Subject: [quicwg/base-drafts] Header table size change (#1142)

From: Mike Bishop <[email-masked]>
Date: Tue, 27 Feb 2018 21:49:20 +0000 (UTC)

QCRAM doesn't afford the encoder the ability to specify the table size it is using, which is a takeback from HPACK.  In QCRAM, the encoder is using the maximum table size permitted by the decoder regardless.  Are we okay with that?

HPACK broke the "maximum you can use" and "size I am using" pieces apart because, although the encoder can choose to mostly-forget entries that are above the size it uses, the decoder is left tracking useless items.  (Also, it allows the encoder to play tricks like setting the table size to zero and then returning it to the previous size to flush the table on an idle connection.)

-- 
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/1142

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Feb 2018 01:06:46 +0000 (UTC)

There is no reason why an encoder can't use the table resize instruction in the current design.  Or, maybe a prune instruction that causes old entries past the cutoff to be flushed.  Either is easy to add or implement.

It messes with your nice proposal for 4 instructions, but other than that, it could easily work.  We could put an octet on the start of table update if you wanted to preserve the clean instruction separation.

-- 
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/1142#issuecomment-369084322

---

From: afrind <[email-masked]>
Date: Wed, 28 Feb 2018 21:11:18 +0000 (UTC)

The encoder needs to be able to have its own limit, since a malicious client can try to tell a server that it wants a really big table for decoding, which can lead to memory DoS.

-- 
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/1142#issuecomment-369384021