Knowledge Base Articles » KB100217: Response.Write Statements DO NOT Show Up Under IIS 5.

A common technique for quickly debugging simple ASP pages is to place Response.Write statements at key points in the code. Then, when an error occurs in the page, the output from all the debug statements prior to the point of failure shows up in the browser, followed by the error message generated by the ASP interpreter. While this method works fine under IIS 4/ASP 2.0, by default it will not work under IIS 5/ASP 3.0. This article explains why, and describes how to make IIS 5 behave the same as IIS 4 in this respect.

Under IIS 5, when an error occurs in the processing of an ASP page, the only output sent to the browser is the error page. This is because, under ASP 3.0, the Response.Buffer property is set to True by default. The effect of this setting is to cause all ASP-generated output to be buffered on the server rather than being immediately sent to the client. The buffered output is only sent to the client when execution of the page is complete, or an explicit call to Response.Flush is made. In the event of an error however, the ASP engine clears the buffer and sends only the error page to the client. Thus none of the Response.Write debug statements (or indeed any of the HTML code in the page) ever reach the browser.

Further complicating this issue, is that there is a quirk concerning the default value of Response.Buffer that is dependent on how Window 2000 is initially installed on your computer. If you do a clean install, the ASP 3.0 default value will be True (as expected). However, if the install is an upgrade, the ASP 3.0 default value will be False (not as expected!).

Fortunately, it is an easy matter to set the buffering to be false. While you are debugging, simply placing the following statement at the top of your ASP page:

<% Response.Buffer = False %>

For more details of the Response.Buffer property, refer to the online DevGuru ASP Quick Reference which now covers ASP 3.0.