Buffering controls how content is written out from ASP to the end user. It affects how response.redirect works as well as the speed of your webpage!
First, by default buffering in ASP is turned ON. You can see this in Home Directory – Configuration – App Options. The checkbox there is called “Enable Buffering”.
What this means is that the ASP processor starts at the top of your ASP script and starts reading your commands. It looks through them, deciding what to do and what to write out. It doesn’t actually SEND any of this to the end user, though. It waits until it gets to the end of the page (or an explicit Response.End command) and then sends the whole block to the user at once. This is the most efficient way of handling ASP and should be your default mode of working.
Let’s say, though, that you have a REALLY long script that makes a gigantic page. First, I have to recommend against this because users are not very patient and don’t like giant pages. They would much rather have small, quick pages that you move between. But let’s say you are forced to make this giant page. One way of dealing with the time issue is to break the page up into sections and show each section as you finish it.
So let’s say your page has 5 sections. At the end of each section, give the command
response.flush
that dumps whatever ASP has finished up to that point out to the user so the user can see it, and then ASP keeps churning. This at least lets the user see what has been done to this point.
If for some reason you have that checkbox unchecked but want to do a response.redirect, then at the very top of the page in question you need to put a
response.buffer = TRUE
and then right before your response.redirect put the command
response.clear
The clear tells the buffer to empty out completely. So anything that went into the buffer for that user’s webpage is emptied out, and the page switch can now happen without the user getting a partial HTML page.