locked
Exception with Silverlight 5 and WCF Data Services in Chrome only RRS feed

  • Question

  • I have a simple WCF Data Services 5 service using EF 4.3.1 to provide access to a couple of views in an Windows Server AppFabric monitoring database.  I also have a Silverlight 5 client which is using the service to retrieve the data and display it in a Telerik chart.  When I access the Silverlight application in IE 9 it works fine.  When I access the Silverlight application in Chrome 19 I get an InvalidOperationException in the LoadCompleted event handler with the message "An error has occured: The response payload is not a valid response payload. Please make sure that the top level element is a valid Atom element or belongs to 'http://schemas.microsoft.com/ado/2007/08/dataservices' namespace."

    The service, ASP.NET page and Silverlight xap are being served from an IIS server on a Windows Server 2008 R2 machine.  I've looked in Fiddler and confirmed the traffic coming back to the browser is the same for each browser and I don't believe it's a caching issue in Chrome as I deleted all recent files. 

    I'm wondering if anyone else has seen anything like this and/or has got any suggestions for what to look at next?

    Thanks

    Martin

    Thursday, May 17, 2012 9:15 PM

Answers

  • There's no super easy way to do this. You would either have to hook up something on the WCF level (not sure if this is possible, but it should be), or you would need a custom host for your WCF Data Service and "hack" the content type there. But then again this should only be done if the requesting client is Chrome, not sure if you can reliably detect that. And even on top of that I'm not sure if the WCF DS Client will read such a response if it has wrong content type.

    Maybe you can try setting the DataServiceContext.HttpStack to Client - I think that should side step the browser.

    Thanks,


    Vitek Karas [MSFT]

    Friday, May 18, 2012 10:09 AM
    Moderator
  • To follow up on this, the fix for this bug is included in the 5.0.2 release of WCF Data Services.

    If you have experienced the bug mentioned in this thread, we encourage you to try out these bits.


    Friday, October 19, 2012 12:18 AM
    Moderator

All replies

  • The debug tools in Chrome show that the download of the OData atom feed is interpreted as a text/plain MIME type instead of application/atom+xml.  If I set up a dummy static feed of an OData atom document and provide a Content-Type of application/xml suddenly (and confusingly) Chrome's debug tools recognise an application/atom+xml type document.  I think this yet to be fixed Chromium bug is probably the source the issue:

    http://code.google.com/p/chromium/issues/detail?id=104358

    As a work around is there a way I can override the Content-Type that WCF Data Services is returning the OData feed as?

    Thanks

    Martin

    Friday, May 18, 2012 9:58 AM
  • There's no super easy way to do this. You would either have to hook up something on the WCF level (not sure if this is possible, but it should be), or you would need a custom host for your WCF Data Service and "hack" the content type there. But then again this should only be done if the requesting client is Chrome, not sure if you can reliably detect that. And even on top of that I'm not sure if the WCF DS Client will read such a response if it has wrong content type.

    Maybe you can try setting the DataServiceContext.HttpStack to Client - I think that should side step the browser.

    Thanks,


    Vitek Karas [MSFT]

    Friday, May 18, 2012 10:09 AM
    Moderator
  • Setting the DataServiceContext.HttpStack to Client has resolved the issue.

    Many thanks

    Martin

    Friday, May 18, 2012 10:24 AM
  • The actual issue is that when not setting the HttpStack to client

    in IE the "Accept-Charset" header is sent as "UTF-8"

    in Chrome the "Accept-Charset" header is sent as "ISO-8859-1,utf-8;q=0.7,*;q=0.3"

    That's the only difference i could see in the fiddler.

    Not sure why the ODataClient library is not able to parse the data for that.

    Monday, May 21, 2012 11:49 AM
  • This is a fairly serious issue that seems like should get more attention than "here is a workaround".  I had code that was working fine in Chrome and IE, and now when I upgrade to WCF Data Service 5.0, I have to go in and retest everything in chrome and add HttpStack = HttpStack.ClientHttp to every area of my code that creates a new context - seems like it would be pretty easy to fix in the library if anyone cared enough to debug it and figure out why the charset info is being handled improperly.  FWIW, you need to test all CRUD operations, as it fails similarly for creates, updates, and deletes when it didn't before.

    I guess my argument for a fix isn't so much "is the bug in chrome or is it in wds" but instead "it worked before but now it doesn't".

    Wednesday, May 23, 2012 6:59 PM
  • Hi,

    I agree that just a workaround is not enough. I filed a bug and we will look what can be done here.

    Thanks,


    Vitek Karas [MSFT]

    Thursday, May 24, 2012 7:12 AM
    Moderator
  • One way to fix the issue without really setting the HttpStack to client is to handle this at the lowlevel WCF message handler.

    Here is a quick solution of what i am talking about.

    please follow the below link for a quick overview of handle messages for WCF Data Services or WCF Services in general.

    http://ashwini47-tts.blogspot.in/2012/04/how-to-implement-custom-wcf-data.html

    create a custom class for inspecting the incoming and outgoing messages for WCFDataServices and try to modify the Accept-Charset header to UTF - 8 which seems to be supported right now by the WCFDataServices 5.0. Remember this is just a simple stop gap,how to do implementation for a temporary fix for the issue.

            public class DataServicesContentTypeInspector : IDispatchMessageInspector

            {

    private const string HttpRequestMessagePropertyString = "httpRequest";

    private const string UnsupportedCharset = "ISO-8859-1,utf-8;q=0.7,*;q=0.3";

    private const string SupportedCharset = "UTF-8";

    private const string AcceptCharSetHeaderKey = "Accept-Charset";

    public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
    {
    HttpRequestMessageProperty httpRequestMessageProperty = (HttpRequestMessageProperty)request.Properties[HttpRequestMessagePropertyString];
    if (httpRequestMessageProperty != null && httpRequestMessageProperty.Headers != null && httpRequestMessageProperty.Headers.Keys != null)
    {
    int headerCount = httpRequestMessageProperty.Headers.Keys.Count;
    bool hasAcceptCharsetHeader = false;

    for (int i = 0; i < headerCount; i++)
    {
    hasAcceptCharsetHeader = httpRequestMessageProperty.Headers.Keys[i].Contains(AcceptCharSetHeaderKey);
    if (hasAcceptCharsetHeader)
    {
    break;
    }
    }

    if (hasAcceptCharsetHeader)
    {
    if (httpRequestMessageProperty.Headers[AcceptCharSetHeaderKey] == UnsupportedCharset)
    {
    httpRequestMessageProperty.Headers.Set(System.Net.HttpRequestHeader.AcceptCharset, SupportedCharset);
    }
    }
    }

    return null;
    }

    [SuppressMessage("Microsoft.Design", "CA1062:Validate arguments of public methods", MessageId = "0", Justification = "Validation not detected.")]
    public void BeforeSendReply(ref Message reply, object correlationState)
    {
    // Do Nothing here. all we have to do is to fix up the alteration of the
    // request message
    }
    }

    Hope this helps,

    Teja

    • Proposed as answer by Teja Guntu Thursday, May 31, 2012 9:34 AM
    Thursday, May 31, 2012 9:23 AM
  • @Vitek Is the bug reported on Microsoft Connect where I can vote it up or is it just internal?

    EDIT:

    I tried out setting the HttpStack.ClientHttp and it was working in Chrome. However, I was getting an invalid cross-thread exception (that I wasn't getting before this change) in the EndSaveChanges call to my WCF Data Service from Silverlight in one instance but not the other. I was also getting some other exceptions so I reverted back this change. So I'm stuck with Chrome not working (we officially don't support it, but we should) or reverting the upgrade for WCF Data Services (which I want to keep as I'm seeing bandwidth savings from the fact that they've removed a lot of extra unneeded formatting spaces).

    EDIT #2: I've used Teja Guntu approach with the IDispatchMessageInspector and it's working very well. I'd recommend that approach. Thanks Teja!
    • Edited by Aligned Wednesday, July 11, 2012 2:43 PM tried the other approache
    Monday, July 9, 2012 8:01 PM
  • To follow up on this, the fix for this bug is included in the 5.0.2 release of WCF Data Services.

    If you have experienced the bug mentioned in this thread, we encourage you to try out these bits.


    Friday, October 19, 2012 12:18 AM
    Moderator