I am debugging a SOAP webservice hosted by SQL Server 2008. I know that those are deprecated in future versions and we should consider a different technology, of course. There is an exposed procedure which legitimately runs for quite a long time sometimes, depending on circumstances. Now, when it spills over 120 seconds, the connection gets reset due to a timeout, in the http error log there is an entry

443 HTTP/1.1 POST /APIDevelop/ - - Timer_EntityBody -

and the CURL-based library on the clientside gets a 104 error (CONNRESET). We have tried to adjust the timeout settings for http.sys by running

netsh http add timeout timeouttype=idleconnectiontimeout value=480

but it seems that http.sys is not impressed by these settings (which end up in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters), not after restarting SQL Server and eventually the whole server, either. The timeout is still there at 120 seconds. Actually, the call takes around 130s but I attribute the difference (maybe, mistakenly) to other latencies.

Anyway, the question is: SQL Server is using http.sys for running its SOAP endpoints - how can I configure http.sys's in this case? Specifically for timeouts?

  • 1
    A timeout is a client setting. You need to look there.
    – Jon Seigel
    Apr 8, 2014 at 13:26

1 Answer 1


For anyone who might stumble into this, too. It turned out to be not a matter of timeouts, but sizes of the POSTed payload. The transfer would always get stuck if the size of the posted parameter would be over a certain threshold (somewhere between 8 and 9 Mb). What fixed it was setting the SSL version to 3 as one of the CURL options (we have a custom SOAP client library).

A big complication in debugging it in our case was that certain servers were behind a load balancer built on Nginx proxy. For those, the call worked fine! But not for the ones that we connected to directly. My guess (I am no specialist in neither Nginx nor SSL) is that Nginx has enough compatible interfaces on "both ends" and was able to receive the call and forward it to the server properly.

What lead to the solution was trying communicating from different clients. When it worked fine from SoapUI but not from our library it was only a matter of prying on every detail of the connection parameters until something made a difference.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.