[ 
https://issues.apache.org/jira/browse/CAMEL-8810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Franz Forsthofer resolved CAMEL-8810.
-------------------------------------
    Resolution: Fixed

> Camel CXF may propagate wrong Content-Length headers
> ----------------------------------------------------
>
>                 Key: CAMEL-8810
>                 URL: https://issues.apache.org/jira/browse/CAMEL-8810
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-cxf
>    Affects Versions: 2.14.2, 2.15.2, 2.16.0
>            Reporter: Stephan Siano
>            Assignee: Franz Forsthofer
>            Priority: Minor
>             Fix For: 2.16.0, 2.15.3, 2.14.4
>
>         Attachments: 
> 0001-CAMEL-8810-Camel-CXF-may-propagate-wrong-Content-Len.patch
>
>
> In some rare cases camel-cxf may propagate wrong Content-Length HTTP headers 
> in routing scenarios.
> The scenario in question is a simple camel-cxf to camel-cxf scenario with a 
> request-reply pattern. If the called server does respond with a 
> Content-Length (not chunked) and the server does not send any HTTP protocol 
> header that is not filtered (like Content-Length or Content-Type) the headers 
> from the original server response are forwarded.
> If the payload returned by Camel is longer than the payload returned by the 
> called server (which provided the Content-Length) e.g. because the proxy is 
> working in PAYLOAD mode and the server uses shorter namespace prefixes for 
> the SOAP envelope, the Content-Length will be too short and the calling 
> client may cut off the message.
> See the attached unit test for details.
> The reason for that is that the original headers get set when copying the 
> invocation context from the camel exchange. Normally the protocol header map 
> will be overwritten with the map of filtered headers, so this is not an 
> issue, however of the map of filtered headers is completely empty this will 
> not happen. The fix is to remove the copied protocol headers in that case.
> The situation will rarely occur in real life because the Server header is 
> there most of the time, so the list of filtered protocol headers is not 
> empty. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to