With #5125 support for Snappy content compression was added, using the Accept-encoding: x-snappy-framed header. The choice for x-snappy-framed while correct from the spec does not really match up with how some modern frameworks such as Netty treat this, as most see the frame format as already implied and just return snappy. Netty specifically is flexible with the accept-encoding as long as it contains "snappy" (HttpContentCompressor), but returns the explicit Content-encoding: snappy. The current implementation in StreamDecoderFactories is however explicitly checking for x-snappy-framed being returned. This results in Armeria receiving a Snappy encoded stream, but seeing it as unencoded, leading to parsing issues down the line. I've created a small working example demonstrating this behavior
I think it makes sense to distinguish what Armeria passes as the accept-encoding header versus what it accepts in the content-encoding, being more lenient for both snappy and x-snappy-framed.
With #5125 support for Snappy content compression was added, using the
Accept-encoding: x-snappy-framedheader. The choice forx-snappy-framedwhile correct from the spec does not really match up with how some modern frameworks such as Netty treat this, as most see the frame format as already implied and just returnsnappy. Netty specifically is flexible with theaccept-encodingas long as it contains"snappy" (HttpContentCompressor), but returns the explicitContent-encoding: snappy. The current implementation inStreamDecoderFactoriesis however explicitly checking forx-snappy-framedbeing returned. This results in Armeria receiving a Snappy encoded stream, but seeing it as unencoded, leading to parsing issues down the line. I've created a small working example demonstrating this behaviorI think it makes sense to distinguish what Armeria passes as the
accept-encodingheader versus what it accepts in thecontent-encoding, being more lenient for bothsnappyandx-snappy-framed.