Hi Claus & others,
I investigated this JIRA issue and found out that there are actually 2
different HeaderFilterStrategy implementations being used in the
HttpProducer class.
1. The strategy set on the endpoint which is configurable and defaults
to org.apache.camel.http.common.HttpHeaderFilterStrategy. This filters
Camel headers in both directions and filters 12 typical HTTP headers in
the OUT direction. It is used in HttpProducer both when building the
HTTP request from the Camel message and when populating the Camel
response message from the HTTP response.
2. The strategy
org.apache.camel.http.common.HttpProtocolHeaderFilterStrategy which is
instantiated in the HttpProducer as final. This is the class mentioned
in the JIRA which includes the long list of HTTP headers which are set
as IN filters. This strategy is only used when copying the Exchange.in
headers to the Exchange.out headers if the "copyHeaders" property is true.
I'm wondering if this is really what was intended.
The comment in the code says:
// to avoid overriding existing headers with old values just
// filter the http protocol headers
It seems unlikely that most of the headers in
HttpProtocolHeaderFilterStrategy would be set on the Exchange.in
message. But suppose they are, and that the HttpResponse also contained
these headers which have already been copied to the "out" message.
Wouldn't it be easier to check if the header is present before copying
it from the IN message?
Thanks for your input,
Karen Lease
