[thelist] Custom Errors in IIS

Ken Schaefer ken at adOpenStatic.com
Fri Aug 29 00:32:36 CDT 2003

Hi Micheal,

From: "Michael Robertson" <mike at mikeemedia.com>
Subject: Re: [thelist] Custom Errors in IIS

: In IIS I have the custom error mesage for 500-100 errors set to
: go to URL (not File) /ASPErrorHandler.asp. That is just what
: worked for me. If Ichange this to File and not URL it merely
: displays the source code for the page.

Yes, that is how it should work. That option is only really suitable for
static custom error pages. For ASP code to be processed, the page needs to
be pre-parsed by the server, and that requires a HTTP request (so that the
ASP engine can be hooked into the processing).

: Furthermore in some instances where an error occurs in the middle
: of a page ASPErrorHandler will be displayed in the middle of the
: page with elements from the original target page surrounding it.
: It never complete redirects it, it simply treats the error code page
: like an include file.
: Are you saying to add Response.Clear to the top of the
: ErrorHAndler file?

When IIS v5+ encounters an ASP generated exception it invokes a
Server.Transfer() call to the configured page. This is not a
Response.Redirect(), it is an internal, server-side transfer to the
configured page.

To dump the rest of the stuff you should have two things configured:
a) Buffering should be on. It's on by default (configured in the IIS MMC
Snapin). If it has been turned off, you can programmatically turn it back on
in your pages by doing:

Response.Buffer = True

This prevents the server from sending anything to the browser until the
entire page life-cycle has been completed. You should have this on anyway
for performance reasons.

Then, in your 500-100 error handler page, you dump the current contents of
the buffer (ie the stuff from the page that generated the error), by doing:

' Dumps existing buffer

' The rest of your error handling logic using ASPErrorObject
        <p>Whatever you want to tell the user</p>

That said, the way to structure your content pages would involve doing
something like this:

<% @Language="VBScript" %>
Option Explicit
<!-- #include files here -->
Dim variables here

Do all your ADO work here
Move recordsets to VBScript arrays using .getRows() etc

Dispose of ADO objects

so, you shouldn't be encountering errors in your ADO-related code in the
middle of your page - that should all happen *before* anything has been sent
to the client.


More information about the thelist mailing list