Subject: [quicwg/base-drafts] QPACK should require handling of integers up to of 62 bits long (#1727)

From: Kazuho Oku <[email-masked]>
Date: Fri, 07 Sep 2018 21:21:26 -0700

QPACK uses the integer encoding defined in [RFC 7541 section 5.1](https://httpwg.org/specs/rfc7541.html#integer.representation), which states:
> Integer encodings that exceed implementation limits — in value or octet length — MUST be treated as decoding errors. Different limits can be set for each of the different uses of integers, based on implementation constraints.

This was fine for HPACK because the maximum integer being transmitted was capped by the header table size.

OTOH, we use the encoding to transfer stream IDs. That means that QPACK implementations need to support decoding integers of up to 62 bits long.

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

---

From: Dmitri Tikhonov <[email-masked]>
Date: Sat, 08 Sep 2018 02:01:36 -0700

Yes, this makes sense.  Seems obvious, but should be in the document.

-- 
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/1727#issuecomment-419625206

---

From: Mike Bishop <[email-masked]>
Date: Fri, 14 Sep 2018 13:32:41 -0700

The prefixed-integer notation encodes in blocks of 7 bits.  So the largest possible QPACK value that would fit in a 64-bit unsigned integer is an 8-bit prefix plus nine bytes (with seven bits each) thereafter.  (That overflows a signed 64-bit integer's range, however.)  It might be friendlier to different languages to limit it to eight follow-on bytes, but we wouldn't be able to represent a 62-bit Stream ID then.

However, when do we ever do this?  Real needs for anything else are likely to be much more contained.  The length of a header is will not likely be more than three follow-on bytes.  Largest Reference can be arbitrarily large, but #1657 would fix that.  An very large table can be expressed in 4 bytes.  Do we have an actual use for more than 3-4 follow-on bytes?

An 8-bit prefix integer with 4 follow-on bytes fits comfortably in a 32-bit signed integer without overflowing to the sign bit.  That seems like a perfectly reasonable constraint for an implementation to put.  I don't know that we need to require the limit to be higher than that.

-- 
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/1727#issuecomment-421476452

---

From: afrind <[email-masked]>
Date: Tue, 18 Sep 2018 13:39:04 -0700

Closed #1727 via #1760.

-- 
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/1727#event-1853442290