asked on

IIS 6.0 on Win2k3 disconnects client's (IE in my case) POST request

IIS 6.0 on Win2k3 disconnects client's (IE in my case) POST request if the processing asp is running some time consuming task and it hasn't written anything in Response object. For example

<%@ Language=VBScript %>
<%option explicit%>
<%
      Server.ScriptTimeout = 3600
      Response.Buffer = false
%>
<%
      nSleepTime = 70

      if (Request("Text1") = "10") then
            Call SomeLongRunningTask()
      end if

      Response.Write "Complete."
%>
<HTML>
<HEAD>
</HEAD>

<BODY>

<form name="frmMyForm" method="post" action="Test.asp">
      <input type="Text" name="Text1" value="12">
      <input type="Text" name="Text2" value="20">
      <input type="submit" name="SubmitButton" value="Submit Form">
</form>

</BODY>

</HTML>

This happens only if the request is a POST. GET request continues running however long it takes. The time it terminates the request is slightly larger than Connection Timeout given in IIS 6.0 (default value 120 secs). Please note that same code works in IIS 5.0 on Win2k without any problem. The Connection Timeout value in IIS 5.0 is 900 sec but I have changed it to 120 secs and IIS 5.0 never disconnects the client POST request.

IIS 6.0 doesn't disconnect the request if asp has written something before starting the long running task. For example if I change the code to ...

      if (Request("Text1") = "10") then
Call Response.Write("")
            Call SomeLongRunningTask()
      end if

it works with IIS 6.0

Could this be a bug in IIS 6.0 or a desired behavior? If it is a desired behavior then why it happens only for POST and not for GET?

belthasar

Your application pool might be getting overloaded. There are 2 things you could try. Go into the properties of the application pool and click on the performance tab. Increase the web garden value from the default 1 to 2 or 3. Also go to the health tab and turn off or increase the threshold for rapid fail protection. Hope this helps. :)

amit_g

ASKER

This is not a load issue. I have only one request on the server when I am testing. Also the worker process is neither killed nor recycled. The IIS simply disconnects the socket after 140-180 seconds even though the asp is still processing. This is also verified by looking into COM+ application if the long running process is a COM application. The COM application continues working. I have made the long running process by having a COM that sleeps. I also have tested it with a long running asp while loop. Either way the socket is disconnected by IIS 6.0.

The connection timeout property is there so that IIS disconnects inactive clients and it is used along with HTTP Keep-Alives property. For some reason IIS 6.0 is treating this request as inactive. This happens only if the request is a POST request. It doesn't happen if the request is GET.

I can fix it by increasing the Connection Timeout but there are only few pages that takes long time to process a request and just for those I don't want to increase the Timeout for the whole site. I can also fix it by putting something in response before starting the long running process but that is a unnecessary code change. Basically an application working perfectly and smoothly for so long on Win2k doesn't work on Win2k3 server. What I am asking here is if someone else has seen this happening or if someone can find a MS support article explaining it.

ap_sajith

Hmmm.... could be another one of those undocumented IIS 6 security features... I had a tough time with the upload size limit restriction setting. Finally read about it in some news group. If i remember correctly, i had to modify the web.config (or config.web) file to rectify that. Try something on those lines...

Also, I am sure you are aware of this issue with IE 6...
http://www.iisfaq.com/?View=A508&P=1

Cheers!!

ASKER CERTIFIED SOLUTION

amit_g

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial