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
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
