Checking Basic Functionality with Test Request Files

  • Article

Applies To: Windows Server 2003, Windows Server 2003 with SP1

Occasionally, you might need to assess the core functional health of the various request types in IIS. Determining which kinds of requests work and which do not is a fundamental step in the isolation phase. The easiest way to accomplish this is to create several test files that can be placed in various application roots in your various Web sites.

Making these test requests from different locations is as important as making requests of different types. Consider that a directory location determines which application, URL, and application pool a request will be routed through. These locations can indicate at which point a particular kind of request is failing. The following examples are test request files for static content, ASP ISAPI, and ASP.NET ISAPI requests, respectively.

Static Content Test Request File

To create a static content test request file, create an HTML file with the following HTML code:

<HTML>
<BODY>
<H3>Hello World</H3>
</BODY>
</HTML>

Save this code in a file called Simple_Request.htm and use it to troubleshoot static content problems.

ASP Test Request File

For an ASP test file, you need include only dynamic ASP code inside of <% %> delimiters. However, output that returns the current time, user, and application pool is useful, too. To create an ASP request file that returns this information, create an HTML file with the following code:

<%@ Language=VBScript %>
<html>
<body>
<%
Response.Write ("The time is now: " & Now() & "<p>")
Response.Write ("The authenticated user is (blank if anonymous) : " & _
         Request.ServerVariables("LOGON_USER") & _
         "<p>")
Response.Write ("The application pool that served this request is: " & _
         Request.ServerVariables("APP_POOL_ID") & _
         "<p>")
%>
</body>
</html>

Save this code in a file called Simple_Request.asp.

ASP.NET Test Request File

The code for an ASP.NET test request is similar to that of an ASP test request:

<%@ Page Language="VB" Debug="True" Trace="True" %>
<%@ Import Namespace=System.Web%>

<HTML>
   <script language="VB" >
   
      Sub Page_Load(Src As Object, E As EventArgs) 
         
      dim ctx as HttpContext = HttpContext.Current
         
      lblTime.Text = Now()
        lblUserIdentity.Text = ctx.Request.ServerVariables("LOGON_USER")
        lblAppPool.Text = ctx.Request.ServerVariables("APP_POOL_ID")
         
     End Sub

   </script>
   <body style="FONT: 8pt verdana">
     <form >
      The time is now:   
     <asp:Label id="lblTime"  /><p>
      The authenticated user is (blank if anonymous):
     <asp:Label id="lblUserIdentity"  /><p>
   The application pool that served this request is:
      <asp:Label id="lblAppPool"  /><p>
     </form>
   </body>
</HTML>

Save this code in a file called Simple_Request.aspx.

Testing Simple Object Creation

A simple COM or .NET object that returns a basic hello world string is a useful troubleshooting tool. Placing that object locally on the server running IIS or remotely on your application tier, and then testing from ASP or from a simple script file or compiled client can help you determine where problems exist in your distributed applications architecture.

Testing Application Code Outside of IIS

Another way to test basic functionality is to test your applications completely outside of IIS. For example, if you are testing COM object creation failures, you can create a simple Microsoft Visual Basic® Scripting Edition (VBScript) file that contains your object creation code and then run the script when you log on to the IIS Web server. Variations might involve creating other custom applications by using other development tools.