Creating a Web Application

Creating a Web application within Internet Information Services is as simple as designating the application's starting-point directory from within the IIS snap-in (to the MMC). When it's created, the MMC indicates a Web application by placing a package icon next to the directory name.

Of course, you can do a lot more to customize the application for your requirements. You can configure a Web application from the Home Directory tab of the Web site property sheet. After choosing an application name and designating the starting point, you're ready to set the properties for the application. Figure 7.3 displays the application settings options for enabling scripting within a Web site.

Most of the configuration discussed in the remainder of this section is completely optional, and you probably will not ever need to use it. As a good practice, however, you should give some thought to the effect of the Execute Permissions and the Application Protection drop-down boxes.

Internet Information Services 5 provides you with three options in the Execute Permissions drop-down list: None, Scripts Only, and Scripts and Executables:

• None. Specifies that no script or application can be called from within the Web site.

• Scripts Only. Supports ASP code, such as VBScript and Jscript only. In this case, code can be embedded into a Web page, but pages cannot call ISAPI or CGI applications.

• Scripts and Executables. Allows all scripts also enabled with Scripts Only, plus executable files and DLLs. Although this option provides a Web programmer the most flexibility, it also provides the Web administrator with a bit of concern. Not only can a "bad" application cause problems for your Web server, but so can a "bad" programmer. They can now have the flexibility of running any script or program that they choose on your Web server and within its memory space and security context. Just be sure that you trust the Web programmer first.

Application Protection provides a nice level of security against those bad applications, but not against a bad programmer. In this case, Application Protection refers to shielding the Web server and other applications from an application that has failed. A detailed discussion of this configuration option can be found in Chapter 13.

When the Web application has been configured, you can further control the application by removing subdirectories from the application and by loading it to, or unloading it from, memory. All these actions are available through the use of buttons that appear within the Properties dialog box. Note, though, that the application can be loaded and unloaded only from its root directory; otherwise, the button is dimmed.

Selecting the Configuration button produces the Application Configuration dialog box with three tabs: App Mappings, App Options, and App Debugging.

App Mappings

The App Mappings property sheet is used to map filename extensions to the program that processes the files. This is applicable to ISAPI files, ASP files, IDC files, and other files that use server-side includes. For example, when a Web client requests an ASP file, the configured application mappings tell Internet Information Services to call asp.dll to process that page. Figure 7.4 displays the App Mappings property sheet.

Enabling the "Cache ISAPI Applications" check box tells Internet Information Services to cache API DLLs so that further applications can be run without again calling the program that processes the application. The check box is enabled by default and should stay that way unless it specifically needs to be disabled for testing purposes. Also, the check box will then need to be disabled for all applications that use that program; otherwise, Internet Information Services will not unload the program from memory.

App Options

You can use the App Options property sheet to control how ASP scripts are run within the application. These defaults generally work for all ASP applications, but you may want to customize them for your environment. The default settings shown in the App Options property sheet (displayed in Figure 7.5) ease a little of the coding required by a Web developer.

Application Configuration displays three check boxes:

• Enable session state. Causes ASP to create a session for each user who accesses an ASP application. With this enabled, Web programmers can track users across ASP pages in the Web site and store information in the Session object. The user session expires when the user does not request another ASP page within the specified timeout period.

• Enable buffering. Tells Internet Information Services to collect all output created by an ASP page before delivering it to the Web client. Enabling this check box allows the Web programmer to set HTTP headers from anywhere within the ASP script.

• Enable parent paths. Allows the Web programmer to use relative paths in ASP scripts. This makes programming a bit simpler but may allow the Web programmer to run an unauthorized application from the parent directory. If you want to tighten security for running applications on your Internet Information Services server, then clear this check box.

Application Configuration also displays two text boxes. The "Default ASP language" check box indicates the ActiveX script engine used to process ASP pages by default. Here you can specify any language for which an ActiveX script engine is installed on the Internet Information Services server. The "ASP Script timeout" text box specifies the amount of time, in seconds, that ASP will allow a script to run before stopping the script.

More information on any of these options can be found in any standard ASP reference manual. For the Web programmer, all the options you select here, except for the "Enable parent paths" check box, can be overridden in the actual ASP script.

App Debugging

The App Debugging property sheet can be used to either help debug scripts or to inform Web clients what to do when a script error occurs. Unless your Web developer intends to analyze the information you gather, however, application debugging is something you will probably never use. One of the most underutilized features of Internet Information Services 5 is the capability to send custom ASP error messages to Web clients by configuring the App Debugging property sheet, as displayed in Figure 7.6. You may, however, choose to send a clear message to your Web clients in the event of a script error. By default, Internet Information Services will send the Web client the detailed ASP error—not very useful to most. You instead could say something like, "Oops! Please call us and we'll have someone look at this problem, and probably even fix it."

The technologies described in this chapter enable a Web developer of any level to create dynamic, functional Web applications. However, those Web designers who are not Web developers would also like to create exciting Web sites. The next chapter discusses one method of doing this: by using Microsoft FrontPage.