[
https://issues.apache.org/jira/browse/CAMEL-23286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Carletti resolved CAMEL-23286.
------------------------------------
Resolution: Not A Problem
thanks [~davsclaus] to confirm this
> camel-platform-http: platform-http propagates request Content-Length header
> to response when a custom HeaderFilterStrategy is used
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-23286
> URL: https://issues.apache.org/jira/browse/CAMEL-23286
> Project: Camel
> Issue Type: Bug
> Components: camel-platform-http
> Affects Versions: 4.18.1
> Reporter: Marco Carletti
> Priority: Minor
> Attachments: SpringBootPlatformHttpContentLengthTest.java
>
>
> When a custom HeaderFilterStrategy based on DefaultHeaderFilterStrategy
> (rather than HttpHeaderFilterStrategy) is set on the PlatformHttpComponent,
> the request's Content-Length header leaks into the HTTP response. This causes
> a FixedLengthOverflowException on the server side when the response body is
> larger than the request body — for example, a POST with an empty body
> (Content-Length: 0) that produces a non-empty response.
> The root cause is in DefaultHttpBinding.doWriteResponse(): it iterates over
> all Camel message headers and writes them to the response via
> response.addHeader() before doWriteDirectResponse() computes and sets the
> correct Content-Length.
> Since DefaultHeaderFilterStrategy does not include content-length in its
> out-filter (unlike HttpHeaderFilterStrategy), the request's value passes
> through and the servlet container enforces it, closing the connection before
> the full response body is written.
> This is a legitimate use case — users may set a custom
> DefaultHeaderFilterStrategy to allow specific headers (e.g., CamelMetrics*)
> through, without expecting transport-level headers like Content-Length to
> break request/response handling.
> This problem is verified using Spring Boot runtime, it has a correct behavior
> when using Quarkus runtime.
> The test to reproduce the scenario is attached
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
