views:

11389

answers:

4

This exception is consistently thrown on a SOAP Request which takes almost three minutes to receive and is 2.25 megs in size.

When scouring the web I find all sorts of posts which all seem to be about setting headers on the Request, some want me to not send the "Expect:" header, some want me to send the "Keep-Alive:" header, but irregardless of the headers I send I still get this pesky error. I don't believe that setting any headers is my answer, because I can recreate the exact same request using "curl" and a response does eventually come back with no problems what-so-ever.

My <httpRuntime maxRequestLength="409600" executionTimeout="900"/>.

I feel as if I'm running out of options. If anyone can provide any assistance I would be most grateful. A few other things to note would be that the server I'm Requesting data from is out of my hands, also these requests are over https and other requests with smaller responses work flawlessly.

Thanks

A: 

Have you tried the sugestion of this Blog Post? The problem will most probably lie in the TCP/HTTP stack implementation of .NET .

mkoeller
Yeah tried that, no luck, to me it just appears to set a header "Connection: Keep-Alive"
Dave
So you need to debug what the .NET HTTP/TCP stack is actually doing. Especially what it's doing wrong in comparison to curl.You should place either Wireshark (TCP network sniffer) or Fiddler (HTTP proxy) between your SOAP request and the server. This way you should be able to spot the difference.
mkoeller
Well, I've already convert the "web service" to a WCF service, if that doesn't help, I'll try this, but will need to investigate how to better filter the results from wireshark... or maybe Fiddler is nicer.
Dave
Fiddler is generally more appropriate for HTTP debugging. However, sometimes TCP level analysis may be needed. Have you noticed the "follow TCP stream" feature in Wireshark? That saves quite some time.
mkoeller
no I hadn't noticed that, I will definitely look in to that, thanks!
Dave
+4  A: 

You tagged the post as .NET35, so are you using WCF?

If so, here is an example of the App.config we use for large data sets:

<system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding name="BasicHttpBinding" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">
          <readerQuotas maxDepth="32" maxStringContentLength="8388608" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
        </binding>
      </basicHttpBinding>
    </bindings>
    <client>
      <endpoint address="http://localhost:1602/EndPoint.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding" contract="IEndPointContract" name="EndPoint" behaviorConfiguration="EndpointBehaviour" />     
    </client>
    <behaviors>
      <endpointBehaviors>
        <behavior name="EndpointBehaviour">
          <dataContractSerializer maxItemsInObjectGraph="2147483647" />
        </behavior>
      </endpointBehaviors>
    </behaviors>
  </system.serviceModel>
Robert Wagner
No, I guess I might look into converting to WCF though... I think the original code was a ported from a pilot written in 2.0 or maybe even 1.1.
Dave
Things seem happy, thanks for the suggestion
Dave
A: 

I hope it's not too late for answering this question.

Try adding the following attribute on the definition of your contract interface:

[ServiceKnownType(typeof(ReturnClass))]

For more generic solution that allows returning polymorphic classes please refer to this post: http://www.goeleven.com/blog/entryDetail.aspx?entry=45

Boris Modylevsky
+1  A: 

Hi, I've got the same issue, and after deep investigations I found this artical:

Merrick Chaffer's Blog

It was all related to setting the "dataContractSerializer" for both client and server. Hope this to be helpful.

Goldy