camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully" <>
Subject Re: Where is it best to remove a message transport header that breaks a response?
Date Thu, 14 Feb 2008 13:12:05 GMT
On 13/02/2008, Roman Kalukiewicz <> wrote:
> 2008/2/13, Tully, Gary <>:
>  > Currently, the unmarshaller copies the input message to the output
>  > message and augments it. The copy brings with it all of the http
>  > headers.
>  > The result is that Content-Length from the request ends in the reply.
>  > This breaks the http response[1].
>  I don't think it is caused by unmarshaller really. Basically it is the
>  behaviour of pipeline to copy the result of the pipeline (either in or
>  out message) into out message of original exchange. I write it without
>  looking at the code, so it could be wrong ;)
the pipeline copies from out to in or from in to in if there is no
out. But it does no create an out message. So in this case

            	.process(new Processor() {
           	 public void process(Exchange e) {
the out is created by the processor and no headers are copied and it
works just fine.
With the unmarshaller, it makes a copy from in to out and then resets
the body with the contents of the unmarshall. My first attempt to
reproduce without an unmarshaller failed because of this :-)

>  > One solution is to add a .removeHeader("Content-Length") to the route
>  > but should that be necessary?
>  > the header really belongs with the in message.
>  >
>  > I am thinking that it never makes sense to copy a Content-Length header
>  > from a HttpMessage but it would be wrong to remove it.
>  I don't think we want to remove any header by default. If I don't see
>  a header I assume that there was no such header. If there is
>  Content-Length, then it should be in the message.
I am not sure, after a transformation, say a deserialisation, the
Content-Length is meaningless. I am thinking that it is only relevant
to the consumer of the HTTPMessage.
It has no business in the out message the results from a transformation.

I like the idea that a particular message type can control how its
headers are replicated. Producers of messages then just send on what
they get, incompatible headers, or headers that are related only to
the initial receipt of the messages are stripped out at source. As in
the existing JMS producer case, the set of headers to strip could be

This does beg the question about access to the original
message/exchange for the case that a downstream processor does want to
see the original Content-Length, but I can't imagine why!

>  I would vote for the solution implemented in JMS case James mentioned
>  about. BTW it is consistent with the same solution we have implemented
>  for CAMEL-254 (notice my comment on the issue).
There is a lot of value in consistency. The simplest solution is to
add a remove to the http binding before we produce a response.
My only problem with this is that if a processor intentionally added
the Content-Length to an out message we would ignore it.

View raw message