Huffman encoding of litespeedtech server flawed?

#1
I had a problem decoding one of the header fields sent by litespeedtech.com on port 443
The header field was apparently etag: "204266-1742969072;br" , but we get the byte codes
- 254 68 6 132 227 139 5 214 132 251 143 129 209 125 253 253 255 63
from the litespeedtech server. Our own huffman decoder does not decode this to the above result, so I tried our encoder on the result and get
- 254 68 6 132 227 139 5 214 132 251 143 129 209 125 199 103 243
instead.
So I downloaded the benchmark code from github in litespeedtech/benchmarks and encoded and decoded the above header field, and I got exactly the byte array that our huffman encoder created, and the litespeed benchmark decoder properly decoded the byte array to the above header field.

Thus, it seems that at least the litespeed bechmark implementation of the huffman encoder creates a different result than the litespeedtech server (and the litespeed benchmark huffman decoder decodes the result properly):
May it be that the huffman encoder used on the litespeedtech website is flawed?

Regards, Magnus

I ran the tests on Windows11, Linux and MacOS (all 64bit); I compiled the benchmarks with VisualStudio 17.12.4.
I received the header fields by sending a http/3 request to the URL litespeedtech.com on port 443
 
#3
Thank you for your response.
I don't think that an influence of the ADC is likely: This is an Http/3 communication which always use QUIC (and not TCP/IP) for transport layer; the whole communication is TLS1.3 encrypted so it should not be possible for the ADC to analyze or change any data in the header frame of the communication.
 

abk

Administrator
Staff member
#4
Thank you for the details. I see you already opened a ticket on this, so we can continue the communication on this subject on the support ticket.
 
Top