0

Calling my WCF service from my client silverlight app, I sometimes get a ProtocolException:

The content type text/html; charset=UTF-8 of the response message does not match the content type of the binding (text/xml; charset=utf-8).

Normally, I can step into the WCF service code and see it build an object then return it in serialised form.

But when the request exceeds ~4MB (as reported by Fiddler2), breakpoints in the WCF service code are not hit, and the content of the response (where the serialised object should be) is the HTML for the standard HTML page you'd see if you browsed to the service - the one that looks like this:

Service intro page

I can make any request fail or succeed by randomly adding characters to strings within the request object graph, or trimming chunks off the graph, so I'm fairly confident this is about the size of the request.

I'd be really grateful if anyone could explain why the response contains HTML, and even more grateful if you can tell me how to fix it.

I'm using VS2010. My server side config is:

<httpRuntime executionTimeout="10800"
               maxRequestLength="10240" />

...

<system.web>
    <httpRuntime maxRequestLength="2147483647" />
</system.web>

...

<serviceBehaviors>
    <behavior name="StandardServiceBehavior">
        <serviceMetadata httpGetEnabled="true"/>
        <dataContractSerializer maxItemsInObjectGraph="2147483647"/>
        <serviceDebug includeExceptionDetailInFaults="true"/>
    </behavior>
</serviceBehaviors>

...

<binding name="BasicHttpBinding_SilverlightService"
         useDefaultWebProxy="false"
         transferMode="Streamed"
         bypassProxyOnLocal="true"
         receiveTimeout="00:20:00"
         sendTimeout="00:20:00"
         maxBufferSize="2147483647"
         maxReceivedMessageSize="2147483647"
         maxBufferPoolSize="2147483647">
    <readerQuotas maxStringContentLength="2147483647"
                  maxArrayLength="2147483647"
                  maxBytesPerRead="2147483647"
                  maxDepth="2147483647"
                  maxNameTableCharCount="2147483647"/>
    <security mode="TransportCredentialOnly">
        <transport clientCredentialType="None"/>
    </security>
</binding>

And client-side I have:

<binding name="BasicHttpBinding_SilverlightService" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">
    <security mode="None" />
</binding>

Update

I've also tried removing the name from the binding tag, as suggested by this post.

Community
  • 1
  • 1
OutstandingBill
  • 2,614
  • 26
  • 38
  • 1
    For a request of that size, you'll probably need to use streaming or chunkify. – Tim Sep 20 '13 at 02:34
  • @Tim - thanks for the suggestion, but why would that be necessary when the maxMessageReceivedSize is larger (2GB) than the apparent 4MB limit? – OutstandingBill Oct 01 '13 at 03:28
  • Setting `transferMode="Streamed"` makes no difference - the response is still the "you have created a service" page. – OutstandingBill Oct 01 '13 at 05:15
  • Good question - I had read 4MB as 4**GB** (good thing I don't work for NASA - the next Mars probe would probably wind up in Alpha Centauri). I'm wondering if the size of the message is a red herring, and it's actually something else triggering the issue (though I'm not sure what it could be at this point)? I've never used Silverlight, but I seem to recall seeing stuff posted that leads me to believe there are some differences between "normal" WCF and SL WCF...maybe it has something to do with SL? But that's just a guess, and in this case not even a very educated one. – Tim Oct 01 '13 at 05:29
  • Have you tried to increase your server config: as well? – Doug Knudsen Oct 29 '13 at 17:52

1 Answers1

1

Have you had a look at this post:

http://smehrozalam.wordpress.com/2009/01/29/retrieving-huge-amount-of-data-from-wcf-service-in-silverlight-application/

You obviously have the dataContractSerializer section covered, just wondering whether anything else is missing.

JayD
  • 26
  • 2
  • thank you for the link - it gave me ``, which overrides the default of 4MB, but alas does not fix the problem. (Apologies for not responding sooner - new baby arrived!) – OutstandingBill Oct 04 '13 at 05:06
  • Actually, my first implementation was incorrect, but I've now found that it was indeed the `` setting. It helps if you don't put this inside a ` – OutstandingBill Feb 11 '14 at 03:46