[jira] [Commented] (CAMEL-24612) camel-langchain4j-agent: content converter charset and content-type handling issues

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

    [ https://issues.apache.org/jira/browse/CAMEL-24612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18111166#comment-18111166 ] 

Andrea Cosentino commented on CAMEL-24612:
------------------------------------------

Fixed in https://github.com/apache/camel/pull/26079 (merged to main, 4.23.0).

_Claude Code on behalf of oscerd_

> camel-langchain4j-agent: content converter charset and content-type handling issues
> -----------------------------------------------------------------------------------
>
>                 Key: CAMEL-24612
>                 URL: https://issues.apache.org/jira/browse/CAMEL-24612
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-langchain4j-agent
>            Reporter: Andrea Cosentino
>            Assignee: Andrea Cosentino
>            Priority: Major
>             Fix For: 4.23.0
>
>
> Three low-severity issues in LangChain4jAgentConverter:
> 1. Text content is decoded with the platform default charset: TextContent.from(new String(data)) uses new String(byte[]) with the JVM default charset. Combined with normalizeContentType() stripping the charset= parameter, any declared charset is discarded and non-ASCII text is mis-decoded on a non-UTF-8 locale. Fix: decode with StandardCharsets.UTF_8 (or the charset parsed from the content type).
> 2. detectMimeType (the WrappedFile path) returns the raw header value without normalization, unlike its byte[]/InputStream sibling detectMimeTypeFromHeaders which wraps every return in normalizeContentType(...). A WrappedFile whose content-type header carries parameters (e.g. application/pdf; charset=...) fails the exact-match branch in createContent and is rejected as 'Unsupported MIME type'; for image/* the charset leaks into Image.mimeType. Fix: normalize the WrappedFile-path header values too.
> 3. The InputStream converter calls inputStream.readAllBytes() and never closes the stream (a handle can leak for a source stream backing a file/spooled stream cache). Fix: wrap in try-with-resources.
> _Reported by an automated functional audit._



--
This message was sent by Atlassian Jira
(v8.20.10#820010)