Camel CXF may propagate wrong Content-Length headers

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.