[
https://issues.apache.org/jira/browse/CAMEL-25656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-25656 started by shashank.
----------------------------------------
> camel-netty-http - available() of the request body stream cache
> (NettyChannelBufferStreamCache) always returns 0 although the whole body is
> in memory
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25656
> URL: https://issues.apache.org/jira/browse/CAMEL-25656
> Project: Camel
> Issue Type: Improvement
> Components: camel-netty-http
> Reporter: shashank
> Assignee: shashank
> Priority: Minor
>
> Follow-up requested in the review of the merged PR
> [#27757|https://github.com/apache/camel/pull/27757] (CAMEL-25573).
> {{NettyChannelBufferStreamCache}} holds the whole request body in a Netty
> {{ByteBuf}} and is an {{InputStream}}, but it does not override
> {{available()}}, so it falls back to the {{InputStream}} default and returns
> 0 (main 1de5ec5135f8: no {{available()}} in the class; {{length()}} at line
> 118 already returns {{buffer.readableBytes()}}). Returning 0 is allowed by
> the contract, but readers that use {{available()}} get less than they could:
> {{IOHelper.copy}} sizes its buffer from it, and
> {{java.util.zip.GZIPInputStream}} has used it to decide whether another gzip
> member follows (the reviewer's example; in the sources of JDK 21.0.11
> {{GZIPInputStream}} does not call it, JDK 17 not checked).
> h3. Proposed change
> {{available()}} returns {{buffer.readableBytes()}}: the bytes left to read
> without blocking, 0 at the end, the full length again after {{reset()}}.
> h3. Test
> New test {{availableIsTheNumberOfBytesLeft}} in
> {{NettyChannelBufferStreamCacheTest}}: a 5-byte body in a buffer of capacity
> 16, {{available()}} after each read and after {{reset()}}. Without the
> change: {{expected: <5> but was: <0>}}. camel-netty-http with the change: 313
> tests, 0 failures, 8 skipped.
> Camel's own copies of this stream are not affected: the two-argument
> {{IOHelper.copy}} (used by {{writeTo}} and the type converters) goes through
> {{transferTo}} and does not call {{available()}}; only the overloads that
> take a buffer size read it, and their only core caller
> ({{CachedOutputStream}}) passes its own cache.
> Affected: main, camel-4.23.x, camel-4.22.x and camel-4.18.x (no
> {{available()}} in the class on any of them): read, not run. Not a
> user-visible failure; an improvement of the stream contract.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
