allthingssecurity opened a new pull request, #27675: URL: https://github.com/apache/camel/pull/27675
# Description [CAMEL-25524](https://issues.apache.org/jira/browse/CAMEL-25524) `MinaSftpOperations.doStoreFile` wrote the body as `getMandatoryBody(InputStream.class)`. It did not use the `charset` option of the endpoint, so a String body was written in the charset of the exchange (UTF-8 by default), and a null body failed with `InvalidPayloadException` although `allowNullBody=true`. The existing `SftpProducerWithCharsetIT` passed only because it sends with a `ProducerTemplate` straight to the endpoint, whose `createExchange` sets the endpoint charset on the exchange; in a route such as `from("file:in").to("mina-sftp:...?charset=iso-8859-1")` every non-ASCII character was written in UTF-8. Now `doStoreFile` gets the input stream as camel-sftp, camel-ftp and camel-smb do: an empty file for a null body with `allowNullBody=true` (and the camel-sftp "Cannot write null body to file" failure when it is false), `GenericFileHelper.toInputStream(exchange, charset)` (the streaming conversion of CAMEL-25167) when the `charset` option is set, and the body as before otherwise. A 4.23 upgrade guide note describes the two changes. Tests: - New `SftpProducerWithCharsetIT.testProducerWithCharsetInRoute`: the existing payload sent through `direct:start` to the endpoint with `charset=iso-8859-1`. - New `SftpProducerAllowNullBodyIT`, as `FtpProducerAllowNullBodyIT` in camel-ftp (`allowNullBody=true` writes an empty file; `allowNullBody=false` fails and writes nothing, which the new null check now decides). - Without the change: `The file must be written in the charset of the endpoint ==> expected: <æøå ©> but was: <æøå ©>`, and `testAllowNullBodyTrue` fails with `InvalidPayloadException`. - With the change: camel-mina-sftp 26 unit tests (1 skipped) and 270 integration tests with the embedded SFTP server (7 skipped), 0 failures; one `SftpBulkRequestsIT` test timed out once waiting for the embedded server to start and passed on the rerun (7 of 7). Not changed here: camel-azure-files also ignores `charset` in `FilesOperations.storeFile`; it computes the length of the upload, so it is better handled on its own. Found with a Lean 4 model of the store: "the file is the body in the endpoint charset, and an empty file for a null body with allowNullBody" (what camel-sftp does) fails for "æ" and for a null body, and the fix is proved to equal camel-sftp's behaviour for every body and configuration, and to write the same bytes as before when no `charset` is set or it is the exchange charset. I then reproduced it with the producer. # 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). # 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-mina-sftp, including the formatter and import-sort plugins. 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]
