[
https://issues.apache.org/jira/browse/THRIFT-6129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmytro Shteflyuk resolved THRIFT-6129.
--------------------------------------
Fix Version/s: 0.25.0
Resolution: Fixed
> Enforce Ruby HeaderTransport ZLIB limit before buffering
> --------------------------------------------------------
>
> Key: THRIFT-6129
> URL: https://issues.apache.org/jira/browse/THRIFT-6129
> Project: Thrift
> Issue Type: Bug
> Components: Ruby - Library
> Reporter: Dmytro Shteflyuk
> Assignee: Dmytro Shteflyuk
> Priority: Major
> Fix For: 0.25.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> h3. Problem
> Ruby HeaderTransport checks its configured ZLIB decompression limit only
> after appending the result returned by Zlib::Inflate. A compressed Header
> frame can therefore produce a large temporary output even when the configured
> limit is much smaller.
> h3. Client impact
> Applications that set a small max_decompressed_size do not receive the
> intended bounded buffering behavior for highly compressible HeaderTransport
> payloads.
> h3. Reproduction
> Create a HeaderTransport frame containing 8,000,000 repeated bytes with the
> ZLIB transform, then read it using a HeaderTransport whose
> max_decompressed_size is 100. The frame is 7,806 bytes in the validated
> environment. The read raises SIZE_LIMIT, but the prior implementation first
> appended an 8,000,000-byte inflate result.
> h3. Expected behavior
> HeaderTransport should process ZLIB output incrementally and raise SIZE_LIMIT
> before appending a chunk that would exceed max_decompressed_size. Frames
> within the configured limit must continue to decode normally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
