Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.3-rc2
-
Fix Version/s: 2.0.0
-
Component/s: Transport: HTTP(S) / Jetty
-
Labels:None
-
Environment:
JDK 1.4.2
-
Similar Issues:None
Description
We are using Mule 1.3 rc2 as an ESB in our architecture. We are using 2 endpoints in our case. First one is an http endpoint via an inbound router and the other one is also an http endpoint,which is created dynamicly, via an outbound router. When the message comes to the http endpoint the http protocol specific headers like Content-Length are supplied via the UMOMessage object. after gathering the message in the http enpoint we create a new message to be sent to the target http endpoint. On that point the message properties are copied from the received message to the one we created new(I mean the MuleMessage). Because the http specific headers(Content-Length) is in the source message it is also being copied to the new message and httpclientdispatcher uses this property(Content-Length) as an http header. As a result of this the Content-Length header of the target http message is not correct. So the target system can not parse the http message correctly. I suppose that we should not override the protocol specific headers especially the ones like Content-Length. Is this a bug or improvement I do not know or may be I should remove the protocol specific properties from the message?
Note: This problems occurs not only in Content-Lngth bu also in Transfer-encoding....
There is the same problem with Mule 1.3.3.
How can one use several http endpoints in the same Mule project ?