Internet Information Services 5.0, part of Windows 2000, promises to be the most sturdy IIS yet.

Microsoft® Internet Information Services (IIS) 5.0, the next version of the Microsoft Web server, is planned to be incorporated as part of the Web services in Windows® 2000. Aside from IIS, Windows 2000 Web Services is expected to encompass the add-on services found in the Windows NT® 4.0 Option Pack, such as Certificate Server and Index Server. Installation of IIS is straightforward, and using the Internet Service Manager with the Microsoft Management Console (MMC) gives IIS 5.0 the same appearance as IIS 4.0.     Lets take a look at specific improvements that have been implemented in version 5.0. I will review and examine the newest methods found in the built-in objects for ASP. I'll also take a look at improvements in Active Data Objects (ADO), incorporation of industry-standard protocols, and the newest security implementations in IIS 5.0.     This evolution of IIS 5.0 is based on the Web services that have shipped with Windows NT 5.0 Server beta 2, but the final release of Windows 2000 is yet to be determined. (Windows 2000 beta 3 is expected to be released in Spring 1999.) Final implementation of the components I'll review here could potentially be different.     Microsoft has emphasized improvement in IIS 5.0 in a few key areas, notably security and manageability. There are changes in store for content authors and application developers as new methods of publishing are implemented in this version. Updates and modifications to the ASP model will help to improve processing capacity and efficiency.     IIS 5.0 brings new versions of the Web Service (inetinfo.exe), ASP parser (ASP.DLL), and scripting engine binaries (vbscript.dll and jscript.dll). Additionally, Windows 2000 is expected to include version 2.1 of ADO. Each of these contains new features that you can take advantage of when writing applications that will take advantage of the planned Web services in Windows 2000. Improved ASP-based App Support     Some efficiency has been built into the Web Service engine that should make ASP applications easier for developers to manage. One nice feature is scriptless ASP processing, which eliminates a call to the ASP parser in the absence of server-side scripting. To explain this more thoroughly, let's review how IIS processes an ASP request.     When IIS receives an HTTP request, its job is to return the requested resource, such as a static or dynamic page (see Figure 1). Registry entries map file extension names to isapi extensions. When IIS receives a request, if the resource is available, IIS will examine the resource being requested. Depending on the resource extension name, it will load the appropriate isapi extension, forward the request to it, receive a return call, and return that data stream to the requesting user's browser. For example, when a request for an ASP page is received, IIS forwards the request to ASP.DLL, the ASP parser. ASP.DLL processes the space page and sends the return data to IIS (INETINFO.EXE), which simply returns the data to the user.

Figure 1: IIS Receiving a Request

    In prior versions, IIS would channel all requests to the assigned extension. For example, if an ASP page is requested, IIS makes a call to ASP.DLL to process the page. However, an ASP page can consist entirely of client-side HTML tags and function correctly. If an ASP page with no server-side script is requested, a call is still made to ASP.DLL. This is inefficient processing. To avoid the call to the ASP parser, developers had to name all pages lacking server-side scripting with an .HTM extension because prior to version 5.0, IIS would serve up HTML files without a call to an isapi extension. While technically better, this creates a problem with complex sites that have multiple links to both ASP and HTML files: the Web server incurs an unnecessary call to ASP.DLL. Also, given that Web site content changes constantly, this can create a huge maintenance headache.

    IIS 5.0 now includes some initial-check features that will examine an ASP page to make sure it has server-side scripting prior to forwarding it to the ASP parser for processing. The efficiency of an ASP retrieval is not equal to that of a simple HTML file request, but it does represent a significant improvement compared to the processing routines of earlier IIS versions. The biggest benefit of this feature is that you may code your entire site with .ASP extensions, whether or not server-side scripts are present. This will permit you to more readily update your site and implement server-side scripting on those pages that need it, but without the maintenance concerns.

    The ASP parser has improved in several areas as well, mostly through the expansion of new metabase properties. Introduced in IIS 4.0, the metabase is a hierarchical database that controls the behavior of IIS. The metabase exposes settings to the IIS/ASP environment registry settings through three different interfaces. The Internet Service Manager is a Microsoft Management Console (MMC) snap-in with functionality similar to IIS 4.0; these properties can be set manually. The IIS Admin objects user interface conforms to the Microsoft Active Directory Services Interface (ADSI) structure. The third interface is the IIS Admin base object, which is implemented with a standard COM interface. While these properties can be set manually, the IIS Admin objects provide the opportunity to administer IIS programmatically through applications and mechanisms other than the Internet Service Manager.

    Which approach is best? It depends on your situation and the needs of your site. If your Web site doesn't require much modification of the processing environment, the Internet Service Manager will most likely be just fine for setting all properties for your site and Web applications. However, if your site requires considerable maintenance with these settings, programmatic administration might be more suitable.

    Before I explain the programmatic approaches, I should define Microsoft Active Directory. The Active Directory is a collection of network resources, referred to as objects. The intent of the Active Directory model is to provide a centralized directory that contains all of these objects at a single management point, regardless of physical machine location. Computing environments continue to grow to include multiple systems that cross application and platform boundaries. Active Directory is designed to manage those objects more effectively.

    Active Directory Services are the services that provide access to the Active Directory's member objects. The ADSI provides programmatic access to these objects. As previously described, IIS 5.0 provides programmatic administration through two interfaces, ADSI and COM.

    The ADSI approach is ideal for script-based administration of automated tasks. A perfect scenario for this is an ASP page that allows users to create Web directories for themselves on a Web server. All of the properties that can be configured through the Internet Service Manager can be applied through ADSI, which is the implementation used by Microsoft in the HTML version of the Internet Service Manager. For sample code, just look at the source code of the ASP pages in your favorite editor. ADSI references can be made in VBScript or JScript® within ASP, Visual Basic®, or C++. The Java language will support ADSI, but the only current supporting Java implementation for ADSI is in J/Direct™, found in the Microsoft SDK for Java 2.0.

    The COM interface in ADSI is best suited to Visual Basic, C++, or any COM-compliant tool. A COM implementation is most practical as a server-side isapi extension or simply a server-side object. Using COM can be advantageous if your site supports a high user or resource workload, or where performance is critical.

ASP Improvements

    Some of the best improvements in IIS 5.0 are the newest features exposed in ASP. These include new methods in existing objects, a new component, and an upgrade to ADO and the scripting engines.

    The Application and Session objects are built-in and have been available since the incorporation of ASP with IIS 3.0. Both objects hold a Contents collection, which consists of all variables that are currently in memory for the object. You can review the collection, loop through its contents, and change the various values of its items.

    Two new methods of the Contents collection are introduced with IIS 5.0, Remove and RemoveAll. The Remove method can be used to delete an item from the Contents collection, and RemoveAll clears the entire collection from memory. These methods offer the advantage of letting developers write more efficient code to manage server resources during script execution. For the Application and Session objects, which use server resources even when a request is not occurring, memory can be freed when a series of variables are not needed. The syntax is simple. With the Remove method, you simply reference either the variable name or its numeric place in the 1-based collection. The RemoveAll method will delete all items from your collection.

    The Server object has been spruced up with three new methods. The Execute method is literally a procedure call, executing whatever resource you pass it. The Transfer method is a functional direction controller, transferring page execution from one page to the next. The GetLastError method returns a reference to an ASPError object, which is also being introduced in IIS 5.0.

    Server.Execute can be used to force execution of an ASP file within one page. For example, I'll start with the two ASP pages shown in Figure 2. If you request Date.asp, you receive the page shown in Figure 3 in your browser.

Figure 3: Date.asp

    The Execute method calls the referenced resource, which in this case is Time.asp. Time.asp is executed exactly as if it were called from the browser request directly, but the server—not the browser—actually makes the request. Adding some additional code illustrates this point.

<% Language=VBScript %> <html> <body> The time is <%=Time()%>. <table> <tr><td><b>Server Variable</b></td> <td><b>Value</b></td></tr> <tr><td><b>Request.ServerVariables("URL")</b></td> <td><b><%=Request.ServerVariables("URL")%></b></td></tr> </table> </body> </html>

The lines of code added here to Time.asp evaluate the URL header value, which is the requested resource passed by the browser.

Figure 4: Time.asp

    Requesting the Time.asp page, you receive the response shown in Figure 4. The URL value is the requested resource, which is time.asp. When you request date.asp, which issues the Server.Execute command of time.asp, you get a different response (shown in Figure 5).

Figure 5: Date.asp, Different Response

    Note that the requested URL is the original request for date.asp. The Server.Execute command issues an execution request for a resource directly, rather than as a command from the browser. The URL value shows that the original request never changed, and no round-trip from browser to server was needed to execute time.asp. Control never leaves the server until the page has completed processing, making processing the resource efficient.

    Server.Transfer is a control redirection function, transferring processing to the requested path. This is different from the Response object's Redirect function where control never leaves the server. Response.Redirect actually sends a response to the browser, which makes an additional request to the server for another resource. The server then returns that new resource as requested. Server.Transfer performs essentially the same function, but there's no secondary response and request between browser and server, making the control transfer from one page to the next much more efficient.

    The Server.Transfer method addresses many of the problems of the Response.Redirect method, not the least of which was efficiency. When the Server.Transfer method is called, any session-level or application-level variables or objects assigned in the calling page up to the invocation of the method are available to the next resource.

Figure 7: ThatPage Hyperlink

    For example, let's start with the pages shown in Figure 6. Opening /Windows2000/ThisPage.asp returns a page with a hyperlink to another page, /Windows2000/ThatPage.asp. The page that loaded this hyperlink was /OtherWebApp/NextPage.asp, which used a Session variable set in /Windows2000/ThisPage.asp. Clicking the hyperlink (see Figure 7) returns ThatPage.asp (shown in Figure 8).

Figure 8: ThatPage.asp

    Though not shown here, content from ThisPage.asp could be returned to the browser prior to calling Server.Transfer. The Response.Redirect method requires that all content is buffered before calling the method, but Server.Transfer manages that issue, making the code to work with this method less burdensome.

    An important aspect of the Server.Transfer method is that the same Session ID is maintained when requesting a page in another Web application. When the Server.Transfer method is called, the requested page is still functioning within the Web application containing the original resource that was requested. However, the other application's Global.asa file will not activate, so any variables or objects instantiated in this file will not be created.

    The GetLastError method may be the best improvement to the Server object. Server.GetLastError returns an ASPError object in the event an error has occurred in processing. The ASPError object is the first version of an error handling mechanism implemented in ASP, with a number of properties to provide information regarding the offending error. The GetLastError method's purpose is to return a reference to this object when applicable. There are three basic problems in ASP server-side script processing that will generate an error the ASPError object will capture: preprocessing errors such as an include file; compile errors such as incorrect code; and runtime errors, which can be generated by incorrect data handling.

    When IIS encounters one of these errors while processing an ASP request, the Server.Transfer method is called and the 500-100.ASP error page (see Figure 9) is requested. You can customize this page to your heart's content, and the ASPError object can be used on that customized error page to provide detailed information about the error that occurred.

    The following ASP code is from a file called Badcode.asp:

<% Language=VBScript %> <html> <body> <% ' We dim an array, then assign a value to the ' array that is out of scope. Dim nArray(3) nArray(0) = 0 nArray(1) = 1 nArray(5) = 5 %> </body> </html>

This page generates a compile error by referencing an element of the nArray outside of its dimensioned scope. When this page is requested, an error occurs and the Web server calls the Server.Transfer method to send control to the defined error page. While you can use the default page, I've opted to construct my own error page here (see Figure 10).

Figure 10: Error Page

    You access the ASPError object via Server.GetLastError. I've implemented my version here, and you can see the Microsoft implementation by accessing the custom error page that is installed by default on your server in <windir>\ help\iishelp\common\.

Active Data Objects 2.1

    IIS 5.0 includes the latest release of ADO, version 2.1. This new version includes clever new implementations that weren't present in ADO 2.0. ADO is provided by Microsoft as an interface layer to OLE DB and is designed to be sufficiently generic to accommodate any OLE DB provider, whether a database, a mail server, a text file, or another platform entirely.

    A new feature known as the Microsoft OLE DB Persistence Provider works with the Recordset object's Save and Open methods, allowing you to save a recordset to a file. The Save method adds an optional adPersistXML parameter, saving the file in XML format. The Web application can then reopen that recordset from that XML file, and can let that file be shared with other applications.

    A typical use of the ADO Recordset object is for retrieving data for use in server-side processing. While a SQL query can apply the appropriate filters in building a recordset, you may need to locate a specific record. You can always accomplish this by looping through the recordset to find the record that contains your value, but the Seek command now provides an efficient way of locating a record in a recordset. Using the Recordset's new Index property, you can move to records within a recordset quickly to locate the applicable row or rows.

    Data shaping was introduced in ADO 2.0, and ADO 2.1 puts a few new twists on this data service. Data shaping involves the use of hierarchical recordsets with parent and child relationships. An excellent article on data shaping, "Shape Up Your Data: Using ADO 2.0 Hierarchical Recordsets in API," appeared in the January 1999 issue of MIND.

    ADO now permits reshaping. With data reshaping, you can effectively reconfigure your hierarchical recordsets to reflect different relationships. This is handy because it's not necessary to make a round-trip to the database server to reload the same data. There are some limitations on reshaping, but overall this feature improves efficiency when working with data in a Web application. An additional improvement to data shaping is its expanded capacity to perform aggregate calculations at varying levels within the hierarchical recordset structure.

Version 5.0 Script Engines

    The Windows 2000 prerelease includes the most recent binaries of VBScript and JScript, now in beta at version 5.0. Both have had some new features added that will be very useful in developing ASP applications for IIS 5.0. The script engines are available for download from the Microsoft Scripting Web site (http://msdn.microsoft.com/scripting). You can refer to the Web site for working examples, but I'll touch on the newest features of the script languages.

    VBScript has been given a tune-up, including adding a new object and Class support. The Class statement in VBScript is very similar to a Class module in Visual Basic. You can add properties and methods, complete with Public or Private scope. Since ASP pages are evaluated at runtime, the Class statement is included directly with the server-side code. This is handy, but the Class itself is only in existence while a page is being processed, and it goes out of scope once processing is complete. So the Class statement does not maintain persistence on the Web server.

    Both VBScript and JScript have incorporated DCOM support. The CreateObject function has been expanded to accept an extra parameter, the server name. By referencing the server name, an object on a remote machine can be instantiated and used in the script application's memory space.

    The new RegExp object now adds regular expressions to VBScript. Regular expressions are used for string evaluation and manipulation. The RegExp object essentially performs the equivalent of a series of InStr evaluations in a much more efficient manner. The power of the RegExp object is its capacity to evaluate an expression for a pattern as opposed to a specific string.

    Another convention added to VBScript is support for the With statement. The With statement's implementation is borrowed from Visual Basic, and is useful when instantiating an object and calling a series of properties or methods. The code is neater, and object references are already there, so the property or method calls should be a little more efficient.

    JScript did receive extra attention by adding error exception handling. If you're familiar with C/C++ notation, you'll recognize the Try/Catch format. Microsoft is working to ensure that implementation of this method is consistent with other efforts for implementation into ECMAScript standards.

Industry Standard Support

    Microsoft is planning to incorporate Distributed Authoring and Versioning (DAV) support into IIS 5.0. DAV is a proposed standard for permitting remote authors to access and update resources on a Web server. DAV is an extension to the HTTP 1.1 protocol and is implemented using well-formed XML.

    DAV works as a method of procedures for authors to maintain content on a Web server by providing the security structure that defines access to hierarchical elements such as directories and files. IIS 5.0 will implement DAV to allow remote authors to open, edit, move, search, or delete files and directories on the Web server. The DAV specification includes additional features such as version management and access control via digest authentication, a security scheme that is also a new extension to HTTP 1.1.

    DAV is expected to be incorporated into Windows 2000 through the implementation of Web folders. You can view your Web folders by opening the Windows Explorer. Scroll down in the All Folders window on the left-hand side of the Explorer and highlight Web Folders. An Add Web Folder wizard will walk you through making a connection to a Web server's directory. After establishing your connection, you can then access the files just as if they were on your local hard drive or network file server (see Figure 11).

Figure 11: Accessing the Web Server's Directory

    The Microsoft FrontPage® Server Extensions are a proprietary equivalent of DAV. Microsoft plans to continue supporting FrontPage Server Extensions in IIS 5.0, and to add Office Server Extensions for incorporation of Web publishing features into the Office 2000 application suite.

Security Implementations

    The most recent industry standard development in Web security is the Digest Authentication specification. Digest Authentication is slated to be a replacement for the Basic Authentication implementation. Basic Authentication is the present industry standard means of identifying the credentials of a user submitting a browser request. But Basic Authentication has a glaring weakness in that the user ID and password are sent as clear text. Digest Authentication is intended to be a stopgap measure by the W3C to fix the security holes of the Basic Authentication mechanism.

    Digest Authentication uses a hashing algorithm to form a hexadecimal representation of a combination of user name, password, the requested resource, the HTTP method, and a given nonce (randomly generated) value sent with the return challenge from the server. This is a rudimentary encryption of the password and is not a strong form of security. Digest Authentication is not as secure as Kerberos or a client-side key implementation, but it does represent a stronger form of security than Basic Authentication.

    Digest Authentication is an HTTP 1.1 specification, which requires that a browser be compliant to this specification. Since a hashing function must encrypt the user name and password, the browser must handle that prior to submitting it to the server. If an IIS 5.0 virtual directory has Digest Authentication enabled, a request from a browser that is not HTTP 1.1-compliant will generate an error in the browser request. Microsoft Internet Explorer 4.0 was the first HTTP 1.1-compliant browser available from Microsoft.

    Enabling Digest Authentication in IIS 5.0 simply requires selecting another checkbox on the Authentication Methods dialog box. Open a directory or site's properties, then click on the Directory Security tab (see Figure 12).

Figure 12: Enabling Digest Authentication

    The IIS 5.0 implementation of Digest Authentication involves some idiosyncrasies. Digest Authentication can only be enabled on a virtual directory or server if that server has access to a plain-text copy of a user's password. Since the domain controller has this information, there must be cooperation between the Web server and the domain.

What Else?

    HTTP compression is also available in IIS 5.0. You can enable compression for static files, dynamic application files, or both. A browser request for a compressed file will retrieve the compressed version of the file to decrease download time, then decompress the file locally. This requires a browser capable of supporting HTTP compression, such as Internet Explorer 5.0. HTTP compression is simply a property setting for IIS 5.0, and there is no advantage or strategy in coding for HTTP compression. However, HTTP compression can be an excellent tool in the appropriate environment, allowing you to maximize the processing efficiency for your Web site or application.

    In a low-bandwidth network, compressed files can reduce the amount of network traffic and thus eliminate delays. Additionally, from the client perspective, a compressed file (as opposed to its native structure and size) would decrease download time through a modem connection. When dealing with dynamic pages, the server is required to regenerate the page at each request, then compress the output and return it to the browser. Sites that utilize many dynamic pages may not want to implement HTTP compression on those pages.

    IIS 5.0 is also expected to include Fortezza token support. The Fortezza token is a security creation of the United States Department of Defense that identifies a user in an encrypted format similar to that of a client certificate. Its primary purpose is to encrypt messages and identify the client user to the server. Incorporating Fortezza security requires special card-reading equipment to perform the authentication process.

    A planned addition to IIS 5.0 is known as Server Gated Cryptography, which allows the Web server to support both 40-bit and 128-bit SSL packet encryption. Presently, the Windows 2000 prerelease does not include Server Gated Cryptography, so its final implementation could vary.

Summary

    Internet Information Services 5.0 builds on the success of its prior versions by addressing areas of concern to developers, content managers, and administrators, incorporating a number of substantive enhancements. This preview doesn't begin to address all of the newest features planned for IIS 5.0, but it should give you an idea of what will be available for producing truly world-class Web applications and content servers.

From the April 1999 issue of Microsoft Internet Developer.