Problem
With the .NET agent enabled for a Windows Communication Foundation (WCF) application, the response header Content-Type is unexpectedly changed to application/xml.
Solution
Basic solutions | Comments |
|---|---|
Disable the Cross Application Tracing (CAT) feature. | Read about how to change the CAT configuration. If you need CAT to remain enabled, see the other solutions. |
Use the Distributed Tracing (DT) feature instead of CAT. | Read about how to enable the DT configuration. DT is a new and improved way to accomplish tracing and has enhanced features, compared to CAT, in the New Relic UI. DT doesn't require modifications to response headers and won't be affected by changing response headers. |
Add your desired | This solution requires you to modify your application code. |
Cause
The Cross Application Tracing (CAT) feature is enabled by default in the .NET agent. CAT works by adding headers to both request messages and response messages.
This is what happens in the agent:
- The WCF service method implementation executes.
- The agent will attempt to add CAT headers to the WCF response by adding an
HttpResponseMessagePropertyinstance, with the CAT headers, toOperationContext.Current.OutgoingMessageProperties. - The custom
DispatchMessageFormatterexecutes and creates a new message where the expectedContent-Typeheader is added directly to the new message. - Microsoft’s WCF implementation will attempt to merge the message properties defined in the response message with the message properties defined in the
OperationContext. See this Microsoft reference on ImmutableDispatchRuntime.cs for more details. - The
HttpResponseMessagePropertydoesn't support merging, so the value defined in theOperationContextis used instead of the value defined in the message. - As a result, the
Content-Typeheader that was originally added to the formatted message is thrown away, and the defaultContent-Typeheader is used.
Since the agent must support multiple WCF Bindings, it needs to add our CAT headers to the OperationContext.