Most Web administrators don’t need to create Web server content. Typically, content creation is the job of Web designers and content management is the job of Web administrators. Designers and administrators often work closely together to ensure that corporate sites, intranets, and extranets have the exact look and feel that management wants. A large part of this is customizing the way the Web server uses content. You might need to configure the server to redirect browser requests to other directories or Web sites. You might need to create custom headers and footers or assign specific types of default documents to be used.
You can customize the content in many other ways as well. Rather than use generic error messages, you might want to create custom error messages that are specific to your company’s Web pages. Custom error messages can contain menus, graphics, links, and text that help lost users find their way. If your organization uses unique types of content, you might need to configure servers to use additional content types. To help track advertising, you might want to create jump pages. To better manage outages, you might want to create an update site. These techniques and more are discussed in this chapter.
Don’t worry. You don’t have to master every technique in this chapter, but the more you know about customizing content and the options available, the better you’ll be as an administrator.
Unlike previous versions, Microsoft Internet Information Services (IIS) 6.0 is configured by default to serve only static content. This means the standard default configuration serves only static Hypertext Markup Language (HTML) documents. Before a Web server can serve any other type of document, the appropriate Web Service extension must be enabled.
A Web Service extension is any type of nonstatic document or functionality that requires special processing. Web Service extensions that can be configured on IIS include:
Active Server Pages. Controls whether server-side scripts written as Active Server Pages (ASP) can be used. This extension is always installed.
ASP.NET. Controls whether ASP.NET applications can be used. This extension is made available when you install ASP.NET as a Web Application Server component.
BITS Server Extensions. Controls whether background Internet transfers can be used. This extension is made available when you install the Background Intelligent Transfer Service (BITS) server extension as an IIS component.
Indexing Service. Controls whether Web server content can be indexed and then searched. This extension is made available when you install Indexing Service as a Microsoft Windows component.
Internet Data Connector. Controls whether pages can use the Internet Data Connector. This extension is always installed.
Internet Printing. Controls whether the server can be used for Internet printing. This extension is made available when you install Internet Printing as an IIS component.
Server Side Includes. Controls whether pages can use Server Side Includes. This extension is always installed.
WebDAV. Controls whether pages can use Web Distributed Authoring and Versioning (WebDAV). This extension is always installed.
IIS also makes use of Common Gateway Interface (CGI) and Internet Server Application Programming Interface (ISAPI) extensions. Generally speaking, CGI is enabled through a processing engine for a specific scripting language, such as Perl, that’s implemented as an ISAPI filter. IIS also makes use of ISAPI filters when processing some types of requests. ASP.NET requests are in fact handled by an ISAPI filter. You can configure ISAPI filters globally for all sites on a server through Web Sites properties or for individual Web sites through the individual site properties.
To enhance security, IIS 6 makes a distinction between known and unknown CGI/ISAPI extensions. By default, all unknown CGI and ISAPI extensions are prohibited, and you must specifically add and configure a CGI/ISAPI filter before it can be used. If you remove this restriction by allowing unknown CGI and ISAPI extensions to be used, filters that haven’t been specifically added and configured might be used.
You configure Web Service extensions globally for all sites on a Web server using the Web Service Extensions node in the IIS snap-in. When you access the Web Service Extensions node, each extension that’s installed on the server is listed along with the status of the extension, as shown in Figure 4-1.
Web Service extensions can be individually allowed or prohibited. Allowing an extension tells IIS that requests for related content can be served and that the server can process the requests. Prohibiting an extension tells IIS that requests for related content shouldn’t be handled; instead, they should be rejected, as IIS does with requests for file extensions that it doesn’t recognize.
Allowing and prohibiting extensions is fairly straightforward using any of the following options:
Allow Extension. To allow an extension to be serviced, select it and then click Allow.
Prohibit Extension. To prohibit an extension, select it and then click Prohibit. Afterward, confirm the action by clicking Yes when prompted.
Prohibit All Extensions. To prohibit all extensions and lock down a server so that only static content can be served, click Prohibit All Web Service Extensions and then confirm the action by clicking Yes when prompted.