How do I prevent a DataPower processing rule from injecting a Content-Type response header to the originating client when the backend service does not provide this header?
When a back-end server does not provide a Content-Type response header, a DataPower processing rule injects a Content-Type header by default. To change this behavior, you can specify a Transformation action (or a GatewayScript action in firmware version 7.0.0 or later) that removes the header after the final Results action.
A Content-Type response header is returned to the client application when the back-end server does not provide this header in its response.
By default, a DataPower processing rule injects a Content-Type response header if this header is not provided by the back-end server.
Diagnosing the problem
If the back-end server returns a response without a Content-Type response header, and yet the client receives a response from the DataPower appliance with the Content-Type response header set, then you might be experiencing this situation.
Resolving the problem
The Content-Type response header can be removed by specifying a Transformation action (or a GatewayScript action if using firmware version 7.0.0 or later) that follows the final Results action of the response processing rule. This action must take the special NULL context as the input context of the processing action and must use the special OUTPUT context as the output context of the processing action.
The style sheet or script used by these processing actions should simply remove the Content-Type header. For example, use a style sheet in a Transformation action:
Or, use a GatewayScript action:
var hm = require('header-metadata');
Note that the probe injects a Content-Type response header with a value of text/xml, negating the results of both of these processing actions. The probe should not be used for use cases with the requirement to ensure the Content-Type response header is not provided to the client.
Also, this solution works only for the Multi-Protocol Gateway service. There is no solution currently for this issue for the XML Firewall service.