[
https://issues.apache.org/jira/browse/CAMEL-23320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Federico Mariani updated CAMEL-23320:
-------------------------------------
Description:
The Spring Boot platform-http consumer corrupts binary request bodies (PDFs,
images, protobuf, etc.) by default since CAMEL-20097 introduced the line:
_this.binding.setUseReaderForPayload(!endpoint.isUseStreaming());_
Since useStreaming defaults to false, useReaderForPayload is true, causing
_DefaultHttpBinding.parseBody()_ to return _request.getReader()_, a character
stream that applies charset encoding to the raw bytes.
On Camel Spring Boot, it results in a StreamCacheException (CoyoteReader stream
closed) and a 500 error due to the async CompletableFuture.runAsync execution
model.
The original CAMEL-19177 implementation did NOT set useReaderForPayload. Since
the field defaults to false, it always used request.getInputStream(), and
binary data worked fine.
CAMEL-20097 attempted to map the useStreaming option to Spring Boot by toggling
useReaderForPayload, but this was semantically wrong, it conflated "streaming
vs buffered" with "Reader vs InputStream". In Vert.x, useStreaming=true uses
CachedOutputStream for disk-spoolable handling; the Spring Boot default path
already uses CachedOutputStream (via
HttpHelper.cacheResponseBodyFromInputStream), so the behavior is already
aligned.
was:
The Spring Boot platform-http consumer corrupts binary request bodies (PDFs,
images, protobuf, etc.) by default since CAMEL-20097 introduced the line:
_this.binding.setUseReaderForPayload(!endpoint.isUseStreaming());_
Since useStreaming defaults to false, useReaderForPayload is true, causing
_DefaultHttpBinding.parseBody()_ to return _request.getReader()_, a character
stream that applies charset encoding to the raw bytes.
On Camel Spring Boot, it results in a StreamCacheException (CoyoteReader stream
closed) and a 500 error due to the async CompletableFuture.runAsync execution
model.
The original CAMEL-19177 implementation did NOT set useReaderForPayload. Since
the field defaults to false, it always used request.getInputStream(), and
binary data worked fine.
CAMEL-20097 attempted to map the useStreaming option to Spring Boot by toggling
useReaderForPayload, but this was semantically wrong, it conflated "streaming
vs buffered" with "Reader vs InputStream". In Vert.x, useStreaming=true uses
CachedOutputStream for disk-spoolable handling; the Spring Boot default path
already uses CachedOutputStream (via
HttpHelper.cacheResponseBodyFromInputStream), so the behavior is already
aligned.
> camel-platform-http-starter - Fix binary data corruption
> --------------------------------------------------------
>
> Key: CAMEL-23320
> URL: https://issues.apache.org/jira/browse/CAMEL-23320
> Project: Camel
> Issue Type: Improvement
> Components: camel-platform-http, camel-spring-boot
> Reporter: Federico Mariani
> Assignee: Federico Mariani
> Priority: Major
>
> The Spring Boot platform-http consumer corrupts binary request bodies (PDFs,
> images, protobuf, etc.) by default since CAMEL-20097 introduced the line:
> _this.binding.setUseReaderForPayload(!endpoint.isUseStreaming());_
> Since useStreaming defaults to false, useReaderForPayload is true, causing
> _DefaultHttpBinding.parseBody()_ to return _request.getReader()_, a character
> stream that applies charset encoding to the raw bytes.
> On Camel Spring Boot, it results in a StreamCacheException (CoyoteReader
> stream closed) and a 500 error due to the async CompletableFuture.runAsync
> execution model.
> The original CAMEL-19177 implementation did NOT set useReaderForPayload.
> Since the field defaults to false, it always used request.getInputStream(),
> and binary data worked fine.
> CAMEL-20097 attempted to map the useStreaming option to Spring Boot by
> toggling useReaderForPayload, but this was semantically wrong, it conflated
> "streaming vs buffered" with "Reader vs InputStream". In Vert.x,
> useStreaming=true uses CachedOutputStream for disk-spoolable handling; the
> Spring Boot default path already uses CachedOutputStream (via
> HttpHelper.cacheResponseBodyFromInputStream), so the behavior is already
> aligned.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
