allthingssecurity opened a new pull request, #28384: URL: https://github.com/apache/camel/pull/28384
# Description [CAMEL-25867](https://issues.apache.org/jira/browse/CAMEL-25867) With `headersInline=true`, `MimeMultipartDataFormat` unmarshals by giving the body stream to `new MimeBodyPart(stream)`. Jakarta Mail uses a `ByteArrayInputStream` as it is (other streams get a `BufferedInputStream`), and the header parser of Angus Mail (`LineInputStream.readLine`) calls `mark(2)` on it after every CR of the MIME headers. With stream caching (the default), an `InputStream` body such as an HTTP request body below the spool threshold becomes an `InputStreamCache`, which extends `ByteArrayInputStream`, and its `reset()` goes back to the last mark. So after the unmarshal, reading the body again started at the last CR of the MIME headers: - a body that is not multipart, which the data format leaves alone, came back without its first lines (`"first line\r\nsecond line\r\n\r\nthird line\r\n"` became `"\nthird line\r\n"`), without an error; - for a multipart body the unmarshal result is right, but the original body lost its MIME headers: a dead letter channel with `useOriginalMessage()`, or the stream cache kept in a property before the unmarshal, got the body from the CR LF before the first boundary. This is the mechanism of CAMEL-25574 (the gzip reader of camel-zip-deflater marked the stream-cached body), found in another reader. Change (one line in `unmarshalWithInlineHeaders`): the parser gets `new BufferedInputStream(stream)`, which it marks on its own, as the gzip data format does since CAMEL-25574. The `headersInline=false` path copies the body into a byte array first and is not affected. No option changed, so no upgrade guide entry. Tests: - New `MimeMultipartInlineHeadersStreamCacheTest` (3 tests; route with stream caching, the body an `InputStream` that is not a `ByteArrayInputStream`, as an HTTP request body is): - `bodyThatIsNotMultipartIsKeptWhole`: without the change `expected: <first line ... third line> but was: <\nthird line>`; - `originalMessageOfAFailedExchangeHasTheWholeBody` (dead letter channel with `useOriginalMessage`) and `streamCacheKeptInAPropertyCanBeReadAgain`: without the change `expected: <Content-Type: multipart/mixed; ...> but was: <\n--XYZ ...>`. - With the change the camel-mail unit tests pass: 248 run, 0 failures, 0 errors, 4 skipped. How it was found: variant analysis of CAMEL-25574, looking for other readers that get the stream-cached body itself and mark it in the middle. What was not run: the full root build; an HTTP consumer end to end (the test uses the same in-memory stream cache that stream caching makes of a request body). # 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-25867](https://issues.apache.org/jira/browse/CAMEL-25867). # 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-mail, 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]
