REST Stream's OutgoingResponse.ContentType is ignored, always shows "application/xml" on receiving browser

Question

I have a self-hosted WCF REST/webHttpBinding-endpoint-bound service. I have a few streams of different content types that it serves. The content itself is delivered correctly, but any OutgoingResponse.ContentType setting seems to be ignored and instead delivered as "application/xml" every time.

Browsers seems to get over it for javascript and html (depending on how it's to be consumed), but not for css files which are interpreted more strictly. CSS files are how I realized the problem but it's a problem for all Streams. Chromebug and IE developer tools both show "application/xml" regardless of what I put in the serving code for a content type. I've also tried setting the content type header as a Header in OutgoingResponse but that makes no difference and it probably just a long way of doing what OutgoingResponse.ContentType does already.

[OperationBehavior]
System.IO.Stream IContentChannel.Code_js()
{
    WebOperationContext.Current.OutgoingResponse.ContentType = "text/javascript;charset=utf-8";

    var ms = new System.IO.MemoryStream();

    using (var sw = new System.IO.StreamWriter(ms, Encoding.UTF8, 512, true))
    {
        sw.Write(Resources.code_js);
        sw.Flush();
    }

    ms.Position = 0;

    return ms;
}

This behavior is added:

var whb = new WebHttpBehavior
{
    DefaultBodyStyle = System.ServiceModel.Web.WebMessageBodyStyle.WrappedRequest,
    DefaultOutgoingRequestFormat = System.ServiceModel.Web.WebMessageFormat.Json,
    DefaultOutgoingResponseFormat = System.ServiceModel.Web.WebMessageFormat.Json,
    HelpEnabled = false
};

I've tried setting AutomaticFormatSelectionEnabled = true and false just in case because it came up in google searches on this issue, but that has no effect on this.

I'm finding enough articles that show Stream and ContentType working together to confuse the heck out of me as to why this isn't working. I believe that the Stream is only intended to be the body of the response, not the entire envelope.

My .svclog doesn't show anything interesting/relevant that I recognize.

============

I can confirm in Fiddler2 that the headers are being delivered as shown in the browser.

...
Content-Type: application/xml; charset=utf-8
Server: Microsoft-HTTPAPI/2.0
...

Answer 1

Solved!

I had something like the following in a MessageInspector:

HttpResponseMessageProperty responseProperty = new HttpResponseMessageProperty(); responseProperty.Headers.Add("Access-Control-Allow-Origin", "*"); reply.Properties["httpResponse"] = responseProperty;

and this was overwriting the already-present HttpResponseMessageProperty in reply.Properties, including any contentType settings. Instead, I tryget the HttpResponseMessageProperty first and use the existing one if found.

I lucked out seeing that one.