Subject: HPACK, length of a particular string

From: "简单一点" <[email-masked]>
Date: Fri, 29 Sep 2017 09:04:39 +0000

Hi.
Assuming a sender sent a frame contains the string "What you \0 gonna do to it?" using Huffman encoding or not  to a receiver. 
I know most compilers would drop the characters after "\0". Let's just say the sender had its way sent all of these octets on purpose. String length was also set to the number of these octets (26 if not using Huffman encoding).
Let's say it's also an incremental indexing entry. Therefore the length of the string will affect the dynamic table.
So, it's important to use the correct length for calculating entry size. 
What is it, 26 or 9?
Or just treat it as a COMPRESSION_ERROR?
In other case, if the sender replace \0 to 0x8 (backspace) or 0x1 (some invisible character).
Is the length for calculating entry size still the same?

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 29 Sep 2017 13:19:06 +0300

> Is the length for calculating entry size still the same?

That string is valid in HPACK (HPACK is 8-bit clean) and has length of
26 for space counting purposes. It is not a decompression error.

The strings in HPACK do not have end-of-string marker, so explicit
length needs to be kept.

However, once forwarded to HTTP level, such haders are treated
malformed, causing one of three effects:

- HTTP 400 error (requests)
- HTTP 502 error (response forwarded by gateway)
- Treat the response as malformed (client).

If dumping such stream, use RST_STREAM[CANCEL]. However, any HTTP error
sent needs to be cleanly half-closed first.

The exact same thing would happen with any ASCII characters 0-31 in
the HTTP header.

-Ilari