Why is Response.BufferOutput = False not working?

Question

This problem started on another board , but Dave Ward , who was very quick and useful there, is also here, so I would like to pick up here, hopefully, the last remaining part of the puzzle.

Basically, I was looking for a way to do continuous web page updates from a lengthy process. I thought AJAX is the way to go, but Dave is a good article about using JavaScript . I included it in my application and it worked fine on my client, but not on my WebHost4Life server. I have another @Brinkster server and decided to try it there and it works. All the code is the same on my client, WebHost4Life and Brinkster, so obviously something is happening with WebHost4Life.

I plan to write them an email or request technical support, but I would like to be active and try to figure out what could happen with their purpose in order to make this difference. I did everything I could with my code to disable Buffering, e.g. Page.Response.BufferOutput = False . What server parameters could they implement to cause this difference? Can I get around this on my own without their help? If not, what do they need to do?

For reference, a link to the working version of a simpler version of my application is located @ http://www.jasoncomedy.com/javascriptfun/javascriptfun.aspx and the same version that does not work @ http://www.tabroom.org/Ajaxfun/Default .aspx . You will notice that in the working version you get updates with every step, but in the one that does not, it sits there for a long time until everything is completed, and then all the updates for the client at once ... and it saddens me.

Answer 1

Hey Jason. Sorry, you still have problems with this.

What I would do is create a simple page, for example:

 protected void Page_Load(object sender, EventArgs e) { for (int i = 0; i < 10; i++) { Response.Write(i + "<br />"); Response.Flush(); Thread.Sleep(1000); } } 

As we discussed earlier, make sure that the .aspx file does not contain any markup other than the @Page declaration. This can sometimes trigger page buffering when this would not be normal.

Then specify the technical support technicians in this file and describe the desired behavior (10 updates, 1 per second). I have found that providing them with a simple test case is of great importance in solving these problems.

Definitely let us know how it ends. I assume some kind of built-in caching or reverse proxy, but I'm curious.

Answer 2

I do not know that you can force buffering, but a reverse proxy between you and the server will affect buffering (since the buffer then affects the proxy connection, not your browser).

Answer 3

I have done some fruitless research on this, but I will share my line of thinking in the dim hope that it will help.

IIS is one of the things that are between the client and the server in this case, so it would be useful to find out which version of IIS is involved in each case - and investigate if there is a way that IIS can perform its own buffering on an open connection.

Although it’s not entirely for money, this article about IIS6 v IIS 5 is what I’m thinking about.

Answer 4

You must make sure that neither IIS nor any other filter tries to compress your response. It is very possible that your production server has IIS compression for dynamic pages, such as the suffix .aspx, and your development server does not.

If so, IIS can expect the whole response (or a significant chunk) before it tries to compress and send any result to the client.

I suggest using Fiddler to track the response from your production server and find out if the responses are gzip'd.

If response compression is a problem, you can instruct IIS to ignore compression for specific responses through the Content-Encoding: Identity header.

Answer 5

The problem is that IIS will additionally output output (besides ASP.NET buffering) if you have enabled gzip dynamic compression (the default these days).

Therefore, to stop IIS buffering your response, you can hack IIS a bit to think that the client cannot handle compression by overwriting the Request.Headers["Accept-Encoding"] header (yes, .Headers Request , trust me):

 Response.BufferOutput = false; Request.Headers["Accept-Encoding"] = ""; // suppresses gzip compression on output 

As the response is sent, the IIS compression filter checks the request headers for Accept-Encoding: gzip ... , and if it does not exist, it does not compress (and, therefore, additionally buffers the output).