Weird interaction when compressed (binary) data accidentally contains LFLF

[frkay]

When using fork I ran into this problem in some of my outputs two 0x0A bytes appear and are interpreted as an empty line this desynchronises the transmissions.

Apparently you have added a binary mode to fork with self.delimit_binary, I'll try to figure out how it works. Is the previous version of sample_exec_codec.py supposed to work in 'bin' mode? https://github.com/http2/compression-test/blob/0290da0c28c454e5b58f7a47495bff4cf49e55f1/sample_exec_codec.py

Otherwise could it be possible to add an hexadecimal mode? Where each byte of the compressed data would be represented by two printable chars representing its hexadecimal value. For instance value 75 would become "4B" and 10 (LF) "0A", the transmission could end as usual by an empty line, and to get the real size of the compressed data just divide the hexadecimal representation size by 2, this avoids to know the final size in advance.

[grmocg]

The previous version expected the compressor to emit a size (32 bits), followed by that many bytes.