When "NIOHTTPRequestDecompressor" is configured with ".ratio(N)", the decompression limit is enforced using the "Content-Length" header value from the incoming request rather than the actual number of compressed bytes received. Since "Content-Length" is attacker-controlled, a malicious client can supply an inflated value that causes the ratio check to always pass, effectively disabling the configured decompression limit. This allows an attacker to send a small, highly-compressed payload (a "gzip bomb") with a falsified "Content-Length" header to bypass the ratio-based protection entirely. The server will decompress the payload without limit, consuming unbounded memory and potentially causing denial of service. For example, a gzip payload containing highly repetitive data can achieve amplification ratios of several hundred to one. Under ".ratio(10)" such a payload should be rejected, but if the attacker sets "Content-Length" to match the decompressed size, the check evaluates "decompressed > decompressed * 10" which is always false, and the payload is accepted without error. Across repeated requests, this allows sustained memory amplification far exceeding the configured limits with no error raised.