Datapower changes Content-Type in HTTP header

Hi, There:

I am having this issue with IBM WebSphere Datapower routing function, which I still haven’t solved it yet after a week or so. I suspect this is a bug in the Datapower for WS proxy. Anyway, the issue is as following.

I am trying to do some incoming URL based routing using XSLT, pretty straightforward like this core line in the stylesheet.

<dp:set-variable name=”‘var://service/routing-url'” value=”‘http://newhost:7001/newURL'&#8221; />

This routing itself actually works correctly as expected. However, when the incoming SOAP WS call is a multipart request such as in MTOM/XOP, the Datapower will strip off the Content-Type in the HTTP header (I could not prove this until I used Wireshark to capture the network packets).

The original HTTP Content-Type going into the WS proxy was:

multipart/related; boundary=”uuid:d50f031f-5eda-46cd-aee3-29d1d0e3f026″; start-info=”application/soap+xml”; type=”application/xop+xml”; start=”<rootpart*>”; action=””

And after Datapower XSLT routing action, it becomes simply this:


This caused a SOAP fault on my Web Service server side with this error: Couldn’t create SOAP message due to exception: XML reader error: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character ‘-‘ (code 45) in prolog; expected ‘<‘ at [row,col {unknown-source}]: [3,1] at at at at at


The error simply means that the server ignores the multipart (due to the new Content-Type) and attempts to parse the whole HTTP body as a single SOAP envelope. Naturally it would fail because it expects the first char from the SOAP XML as ‘<‘ instead of the actual first char of boundary ‘‘.

To date, I still haven’t solved this problem yet, although I truly believe Datapower altered the HTTP content-type header.  I have tried a few things such as <dp:freeze-headers/> and set http request header’s content-type to var://service/original-content-type, in vain.

In comparison, without the XSLT routing, the content-type preserves correctly and the web services with multipart runs as expected without any issues. So the Content-Type loss is indeed related to the routing-url change.

I will update this issue when I found a solution by myself or from other resources.