[
https://issues.apache.org/jira/browse/CAMEL-26247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-26247.
---------------------------------
Resolution: Fixed
Fixed by https://github.com/apache/camel/pull/28955, merged to main as
f6e08d43062a1ff241f7e8710db21f9020b2a8bb.
_Claude Code on behalf of davsclaus_
> camel-azure-functions - invokeFunction sends a stream body as its toString
> and a File as its path, and an HTTP 500 does not fail the exchange
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26247
> URL: https://issues.apache.org/jira/browse/CAMEL-26247
> Project: Camel
> Issue Type: Bug
> Components: camel-azure
> Reporter: Claus Ibsen
> Assignee: Andrea Cosentino
> Priority: Minor
> Fix For: 4.24.0
>
>
> Found while adding the catalog body types of azure-functions (CAMEL-24961, PR
> #28403).
> h4. 1. A stream body is sent as its toString, a File as its path
> {{FunctionsInvocationClient.convertBodyToString}} (main 2a465aa4814c, line
> 124) handles String and byte[] only (byte[] is decoded as UTF-8) and uses
> {{toString()}} for anything else, so an {{InputStream}} is sent as
> {{java.io.ByteArrayInputStream@...}} and a File as its path. Checked on
> 4.24.0-SNAPSHOT with a JDK {{HttpServer}} fake.
> Proposed: convert the body with the type converter (to byte[]), and send
> bytes with {{BodyPublishers.ofByteArray}}.
> h4. 2. The default Content-Type is only added when the headers map is set
> {{FunctionsInvocationClient.invoke}} (line 84) adds {{Content-Type:
> application/json}} only when {{headers != null}}, so without the
> {{CamelAzureFunctionsHttpHeaders}} header a body is sent with no
> Content-Type. Checked on 4.24.0-SNAPSHOT with the fake.
> Proposed: add the default when no Content-Type is set, whether the headers
> map is there or not.
> h4. 3. An error status does not fail the exchange
> {{FunctionsProducer.invokeFunction}} (lines 167-172) sets the response text
> as the body and the status in a header for any status, so a 500 from the
> function continues the route as a success. Checked on 4.24.0-SNAPSHOT with
> the fake.
> Proposed: throw an exception for a 4xx/5xx status (as the http component
> does), with an option to keep the current behaviour.
> _Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
