HPACK edge cases

Following are a few edge cases in HPACK I noticed:

1) EOS being decoded:

The draft says:

>   Given that only between 0-7 bits of the
>   EOS symbol is included in any Huffman-encoded string, and given that
>   the EOS symbol is at least 8 bits long, it is expected that it should
>   never be successfully decoded.

What if it IS decoded?
- Error?
- Treat the same as 0 (i.e. break header)?
- Skip the symbol?

If one intermediary/server in chain skips it and another treats it as header
break, bad things can happen.

Or if some client/intermediary/server crashes or behaves unpredictably if one
is received.


Idea: Eliminate EOS. Ensure that table has at least 8-bit all-zeroes symbol.


2) Padding not all ones.

The draft says:

>   When padding for Huffman encoding, the bits from the EOS (end-of-
>   string) entry in the Huffman table are used, starting with the MSB
>   (most significant bit).

What if this is violated and padding is not all ones (that's the current
prefix of EOS)?
- Error?
- Ignore?


3) Handling of large headers

How does endpoint know how large header can be sent?
- If huffman-compressed, is the limit in compressed or uncompressed size?
- Is there difference if the header is to be added to header table or not?

Note that if there is header too large (but not so large that length
overflows), the global effects on connection state can be computed
with already committed resources, but the header can't be decoded.

Also, headers spanning multiple HEADER/CONTINUATION frames might cause
crashes or unpredictable behaviour in badly coded endpoints/
intermediarities...


Idea: Disallow headers spanning frames (this would limit header size
to about 16kB-32kB).



4) Handling of large header sets

Endpoints can process large header sets in streaming manner, but are
not required to. How can sender know how large header set can be
sent?

Intermediaries have worse problem: If there are multiplexed connections,
any request being sent monopolizes the connection, and thus overly
large header sets are a DOS vector (the endpoint can just sink the
header set, no matter how large).


-Ilari

Received on Friday, 7 March 2014 08:00:10 UTC