allthingssecurity opened a new pull request, #28070: URL: https://github.com/apache/camel/pull/28070
# Description [CAMEL-25743](https://issues.apache.org/jira/browse/CAMEL-25743) The aws2-s3 producer used the `CamelAwsS3ContentLength` header as the content length whenever it was set, also for a body whose length is known (`byte[]`, `String`, file, `Path`, cached stream), and the SDK sends exactly that many bytes. The aws2-s3 consumer and `getObject` set this header to the length of the object read, and it stays on the message when the route changes the body. So a route that reads an object, changes it (transform, enrich, marshal) and writes it to another bucket stored the longer body cut to the old length, and the exchange completed normally. A shorter body failed in the SDK. The header is there for a stream whose length is not known (CAMEL-4126, CAMEL-13433), and that case is unchanged. CAMEL-25167 kept the existing precedence of the length headers as it was; this change narrows it to bodies whose length is not known. SDK behaviour: `MakeHttpRequestStage` wraps the content in `LengthAwareInputStream` (SDK 2.55.15), which ends the stream after `contentLength` bytes and fails a shorter one. Checked with the real `S3Client` against a local HTTP server (a probe, not part of the PR): with the header 10, a 31-byte String body arrives as 10 bytes on main and as 31 bytes with the change. Change (in `AWS2S3Producer`, single and multi-part upload): when the length of the body is known without reading it (`PayloadHelper.getLength` of the body or of its input stream), it is used; otherwise the header, as before; otherwise the stream is cached to measure it, as before. What users can notice: an object is stored with the length of its body even when a stale `CamelAwsS3ContentLength` header is on the message. Upgrade guide (4.24): a note under its own `camel-aws2-s3` heading. Cost: none (the length check reads no data). Tests (in `AWS2S3ProducerPayloadLengthTest`, mocked `S3Client`): - `bodyLongerThanAStaleContentLengthHeaderIsStoredWhole`, `bodyShorterThanAStaleContentLengthHeaderIsStoredWithItsLength` and `multiPartUploadOfABodyLongerThanAStaleContentLengthHeader` fail without the change (`expected: <31> but was: <10>`, `expected: <5> but was: <1000>`, `expected: <1048576> but was: <10>`, 3 of 3 runs). - `streamOfUnknownLengthUsesTheContentLengthHeader` passes with and without the change. It guards the case the header is for, which the change could break. - With the change the camel-aws2-s3 tests pass: 108 run, 0 failures, 0 errors, 0 skipped. What is not changed: a stale header on a stream whose length is not known is still used. Possible follow-ups: camel-minio, camel-ibm-cos and camel-google-storage give their own content-length header the same precedence. What was not run: the full root build; no test against S3. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it): [CAMEL-25743](https://issues.apache.org/jira/browse/CAMEL-25743). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built and tested camel-aws2-s3, including the formatter and import-sort plugins. No option or generated file changed. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
