Is more than 7bits EOS padding or full EOS sequence in huffman byte string subject to compression error?

Current HPACK draft says that huffman EOS is solely used for padding bits
if huffman encoded byte strings does not end in byte boundary.

'''

The EOS symbol is represented with value 256, and is used solely to signal
the end of the Huffman-encoded key data or the end of the Huffman-encoded
value data. 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.
'''

The question is if the receiver gets more than 7bits EOS prefix or full EOS
sequence, should the receiver treat it as compression error? The draft does
not explicit in this point.

There are several such cases:
* The encoded byte string ends in the byte boundary but the compressor
appends 8bits EOS prefix in the next byte
* The encoder appends full EOS bit sequence and possibly append another EOS
prefix as padding.

I prefer they are subject to compression error, because checking the
padding is easy and unambiguous. And we have done in a strict way in this
kind of thing.

Best regards,

Tatsuhiro Tsujikawa