Yes, IIS6 (via HTTP.SYS) tracks several connection-oriented statistics and
proactively closes connections if it thinks it's an attack. These checks
were not present in IIS5.
For example, IIS6 now enforces a certain minimal data transfer rate from the
client to prevent byte-dribbling attacks. I think this is what's snagging
you -- Timer_EntityBody or Timer_MinBytesPerSecond.
I think your dropped connections are logged in
%SYSTEMROOT%\System32\LogFiles\HTTPERR\*.log with a short reason why (and
you can look at this URL for explanations --
<a style='text-decoration: underline;' href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/http/http/error_logging_in_the_http_api.asp" target="_blank">http://msdn.microsoft.com/library/default.asp?url=/library/en-us/http/...p/error</a> )
..
--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Amit" <amitg_newsgroupsREMOVE_CAPS.TakeThisOut@hotmail.com> wrote in message
news:10b8901c3bee9$49ee3070$a601280a@phx.gbl...
You got it right. IIS does not terminate the GET request
while it terminates the POST request. Thanks for letting
me know about the granularity of ~30 sec. I thought it is
so but could not find it mentioned anywhere or may be I
did not read well enough.
>ConnectionTimeout as well as POST. In your case, the
response to the POST
>request IS by definition inactive, so I see no problems
with
So you mean to say that if any request (GET or POST) does
not write anything to Response object for about
ConnectionTimeout + granularity, it will be deemed as
inactive and so will be terminated by IIS? Was it changed
in IIS 6.0 because this doesn't happen in IIS 5.0. The
application that I am talking about has been running
without any problem for about 2 years now. I got to this
only when we decided to move the application to a Win2k3
server.
I can reproduce this problem consistently with the test
asp I had posted in this question. I have used 3 options
for SomeLongRunningTask()
1) A while loop in ASP that checks the time and waits for
given period. Obviously it puts CPU to 100%.
2) A VC++ ATL COM that exposes a method to sleep for given
period of time and calls sleep API internally.
3) Same COM registered in COM+.
In all 3 methods I see the same behavior. With 3rd method
I can observe the COM running in COM+ Administration
(Component Services) even after the IIS has broken
connection. In fact if I use IE as client, it tries to
resubmit the request one more time but obviously second
time also IIS terminates the request after about 50-60
seconds (with 30 secs as ConnectionTimeout).
Thanks for looking into it.
Amit
>-----Original Message-----
>I do not understand what you are saying here:
>>As per the documentation the ConnectionTimeout is to
>>disconnect idle clients and is to be used in conjunction
>>with HTTP Keep-Alives. That is a valid use. Why IIS 6.0
is
>>treating this POST request to be inactive while it
doesn't
>>treat a similar GET request to be inactive?
>
>IIS6 would terminate the GET request if it lingered
longer than
>ConnectionTimeout as well as POST. In your case, the
response to the POST
>request IS by definition inactive, so I see no problems
with
>ConnectionTimeout kicking in. Are you saying that you
can make a GET
>request that wasn't disconnected after ConnectionTimeout
(+ granularity)
>expired?
>
>As for the granularity of the ConnectionTimeout, it is
~30seconds -- so if
>you set a value of 30, it could happen anywhere between
30-59 seconds.
>
>--
>//David
>IIS
>This posting is provided "AS IS" with no warranties, and
confers no rights.
>//
>"Amit" <anonymous.TakeThisOut@discussions.microsoft.com> wrote in
message
>news:050901c3bebd$0317e5a0$a401280a@phx.gbl...
>Initially it was set to default 120 secs but I have tried
>different values and the connection disconnects little
>later than that. For example for value of 120 it
>disconnects after around 150-180 secs. For a value of 30
>secs it disconnects after around 40-50 secs.
>
>As you can see I have set ScriptTimeout to 1 hour in this
>asp. I have few asps that have high amount of processing
>and they do take about 20-30 minutes to process the
>request. I can set about 30 min of ConnectionTimeout for
>the site and then it works but I don't want to do that
>because most of the files do not take more than few
>seconds. Moreover if MS has reduced the default from 900
>secs (in IIS 5) to 120 secs (in IIS 6), it must be for
>some reason. Another way to solve it is to put something
>in Response object before I begin the long running process
>but that requires a code change and I will have to find
>out all such cases where this happens.
>
>As per the documentation the ConnectionTimeout is to
>disconnect idle clients and is to be used in conjunction
>with HTTP Keep-Alives. That is a valid use. Why IIS 6.0 is
>treating this POST request to be inactive while it doesn't
>treat a similar GET request to be inactive?
>
>Thanks,
>Amit
>
>>-----Original Message-----
>>What is your Connection timeout set to?
>>
>>--
>>//David
>>IIS
>>This posting is provided "AS IS" with no warranties, and
>confers no rights.
>>//
>>"Amit" <amitg_newsgroupsREMOVE_CAPS.TakeThisOut@hotmail.com> wrote in
>message
>>news:02d701c3bea1$2827b990$a501280a@phx.gbl...
>>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("<!-- Some Dummy
>>Output -->")
>>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?
>>
>>BTW, how and where can one submit a bug (if one finds)
for
>>MS products?
>>
>>
>>.
>>
>
>
>.
><!-- ~MESSAGE_AFTER~ -->
>> Stay informed about: IIS 6.0 Disconnects Client 
FAQ
Profile
Private Messages
Log in
