Response.Flush: Differences between IIS 6.0 and 5.0?

From: Anthony Marchesini (Arm07470_at_newsgroup.nospam)
Date: 09/19/04 

Date: Sun, 19 Sep 2004 13:23:45 -0400

It has always been my expectation and observation that Response.Flush is a
synchronous operation. In other words, I do not expect my ASP script to
continue running until the entire response buffer has been sent to the
client.

It appears that this is no longer the case under IIS 6.0. Here's an ASP
page that I created to document this unexpected (and, for my application,
undesirable) behavior:

<%
With Response
 'Buffer 1 MB of HTML output
 .Buffer = True
 .Write "<html><body><!--" & String(1048559, "-") & ">"

 'See how long it takes to Flush to the browser
 StartTime = Timer()
 .Flush
 StopTime = Timer()

 'Output result
 .Write "Flush took "
 .Write FormatNumber(StopTime - StartTime, 3, -1)
 .Write " seconds to send 1 MB to the browser.</body></html>"
 .End
End With
%>

Browsing to this ASP page hosted on an IIS 5.0 server yield the following
output in the browser:

   Flush took 5.938 seconds to send 1 MB to the browser.

With the following response headers:

   HTTP/1.1 200 OK
   Server: Microsoft-IIS/5.0
   Date: Sun, 19 Sep 2004 16:29:27 GMT
   X-Powered-By: ASP.NET
   Connection: close
   Content-Type: text/html
   Cache-control: private

Hosted on an IIS 6.0 server, I get this output in the browser:

   Flush took 0.016 seconds to send 1 MB to the browser.

With the following response headers:

   HTTP/1.1 200 OK
   Connection: close
   Date: Sun, 19 Sep 2004 16:31:22 GMT
   Server: Microsoft-IIS/6.0
   MicrosoftOfficeWebServer: 5.0_Pub
   X-Powered-By: ASP.NET
   Content-Type: text/html
   Cache-control: private

The headers don't seem to reveal anything interesting. I have included them
just to prove that there's no transfer encoding or compression going on that
would explain the different results from the two servers.

The interesting result is that Flush took almost no time to execute on IIS
6.0 and it took nearly 6 seconds on IIS 5.0. The 6 second result is
expected if Flush is a synchronous operation since that's about how long it
took to receive the page in my browser from both of the servers. The only
explanation for the 0 second result on the 6.0 server is that Response.Flush
is behaving asynchronously on that server.

While I'm sure that asynchronous flushes would be desirable for many
applications, it is highly undesirable for mine. I won't make this post any
longer explaining why (unless someone really wants to know), just trust that
I have a good reason.

All of this boils down to two questions:

   1) Is this change in behavior documented and expected?
   2) Is there a way to get the old behavior back?

- Anthony Marchesini

Relevant Pages

  • Re: Response.Flush: Differences between IIS 6.0 and 5.0?
    ... I do not expect my ASP script to continue running until the ... ASP did send the entire response buffer to the client prior to continuing ... 'See how long it takes to Flush to the browser ... Browsing to this ASP page hosted on an IIS 5.0 server yield the following ...
    (microsoft.public.inetserver.iis)
  • w3wp.exe 100% CPU
    ... I'm developing my website with asp with IIS and 2003 server. ... did some test after editing my asp script, my browser just took forever to ...
    (microsoft.public.dotnet.framework.aspnet)
  • RE: ASP security in HTML pages
    ... I know ASP ... as the server has in his directory ... > executed at run time and never sent to the browser. ... > pen testing experience in our state of the art hacking lab. ...
    (Security-Basics)
  • Re: asp changes do not show on clustered IIS 5.0
    ... access to the server where I did not. ... name refresh the browser and see if that works. ... >>out a confusing problem though. ... All of the asp pages ...
    (microsoft.public.inetserver.asp.general)
  • Re: User interface for process that takess a long time...
    ... stored procedure at the end of the script. ... of the flushfunction -- which can't *force* a server (much less the ... browser) to flush output. ...
    (comp.lang.php)