[jira] [Created] (CAMEL-25656) camel-netty-http - available() of the request body stream cache (NettyChannelBufferStreamCache) always returns 0 although the whole body is in memory

["shashank (Jira)" <ji...@apache.org>]

shashank created CAMEL-25656:
--------------------------------

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


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)