Question

We have an ASP.NET web application running in IIS that uses the SoapHttpClientProtocol class to make SOAP calls. In the last few days several XP machines have started to report timeout errors when making SOAP services calls.

Stack Trace from a test app:

System.Net.WebException: The operation has timed out
   at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)
   at System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest request)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   at TestWS.localhost.Service1.HelloWorld() in C:\Prototypes\TestWS\Web References\localhost\Reference.cs:line 78
   at ASP.default_aspx.__Renderform1(HtmlTextWriter __w, Control parameterContainer) in c:\Inetpub\wwwroot\TestWS\Default.aspx:line 17

Using TCP/ Trace and Wireshark we can see that the header of the request is being sent but not the content. However, the content-length HTTP parameter is correct, it’s almost as if the content stream has not been flushed.

We suspect a microsoft update has caused this issue. Potentially KB970430, KB971737 and KB968389. The problem appears to be isolated to IIS 5.x (XP version of IIS).

Answer 1

UPDATE: This turned out to be an issue with ESET antivirus running on the Web Server and performing on-the-fly checking of HTTP connections from the web server to a SOAP server.

Full Description: For the record this is a defect in the HTTP protocol handling in .NET. The scenario is as follows:

Client sends header of HTTP POST:

POST /WS/Test.asmx HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.3603) 
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://testuri.org/HelloWorld"
Host: loadtest-app
Content-Length: 288
Expect: 100-continue
Connection: Keep-Alive

The content is not sent because of Expect: 100-Continue. The server now responds:

HTTP/1.1 100 Continue

At this point the client does not respond. A workaround for this is to disable the 100-continue which essentially forces the request header and content to be sent in one chunk. This can be done in the web.config with:

<system.net>
   <settings>
      <servicePointManager expect100Continue="false"/>
   </settings>
</system.net>

However, if we also switch client-side trace logging on then a protocol exception is thrown stating that CR should be followed by LF in HTTP headers. There appears to be some fragile code in the .Net network logic somewhere. And to recap this is only an issue with ASP.NET in IIS 5.1 (the version that runs on XP).