How ASP connects with IIS

Iis

The ASP itself contains a DLL file, named ASP.DLL, which is installed by default in the Winnt\System32\Inetsrv directory. This DLL file is responsible for getting an ASP page (by file name extension). ASP identification), and then analyze it to look for server-side script content. This script is routed to the appropriate script engine, and the results of the script are combined with the HTML and template text in the ASP page. The full page is sent to the Web server from where it was sent to the client who originally made the request.
About the application mapping
To better understand this process, you need to look at how application mapping works in Windows 2000. For each Web site that is set up under IIS, there is a root directory on the server. When you install IIS, the default Web site is usually C:\InetPub\WWWRoot, unless you change the path during installation. For this directory and the subdirectories (which we'll discuss later), there's a set of definitions that define how the directory fits into the IIS properties.
Opening Internet Services Manger from Administrative Tools in the Start menu will run the Microsoft Management Console (Microsoft Management CONSOLE,MMC) to show IIS.
Right-click the default Web Site, select Properties, and the Home Directory tab appears, as shown in Figure 1-4.
You can see that the default site is set up as a virtual application. There are applicationname, Execute permissions, and Application protection options in the lower half of the tab. IIS uses a virtual application to isolate the page set and instances of the components that are used, affecting the prevention of Web servers with failure. As has been seen earlier, this is done through the execution of page and out-of-process components in a separate memory space. We will discuss this issue later in this chapter.


Click the Configuration button to open the Application Configuration dialog box, as shown in Figure 1-5. In the App Mappings tab, you can see that IIS is linked to various files using a specific DLL. Any file containing the extended filename. ASP's Web pages are sent to ASP.DLL for processing; pages with unmapped extension filenames, such as. html and. htm and XML files for HTML pages, simply upload them from disk and send them directly to the client.

Readers may want to know more about the other file types on this tab. Ida,. IDC and. idq file extensions are used by IDC template files and query files, so an IDC query page (. idc) will be sent directly to the dynamic link library httpodbc. DLL for processing. It can also be guessed from the file name, which uses ODBC to execute the SQL statement and returns a set of data records contained in the page. Similarly, the. shtm,. shtml and. stm file extensions correspond to dynamic-link libraries with file names of Ssinc.DLL, which are generally used to request files that are processed by the server side (Server-sideinclude,ssi). We will give some relevant examples in the following sections of this book.
When you open the application Configuration and Properties dialog box, readers may want to know the features of each setting. These dialogs and settings are used in many parts of the book, and viewing these settings can help increase perceptual knowledge, but do not change these settings unless you know why.
Working with an ASP file
We know that an ASP page provided to the ASP dynamic link library to wait for interpretation and execution, then what will the ASP do?
The first step is to determine whether there is an ASP server-side code that needs to be executed. If not, it simply notifies IIS of this situation and lets IIS send the page to the client. In fact, a new feature of Windows 2000 allows extensions to be used for all pages. ASP, including scripting code for those not on the server side, without sacrificing any performance.
In earlier versions of IIS and ASP, all have. ASP extension pages are interpreted line-by-row, even if they contain non-ASP server-side code. This is certainly much slower than IIS sending them directly from disk to the client.
When an ASP receives a page from IIS that contains server-side scripting code, it interprets it row by line. Those that are not server-side scripts or that do not require ASP to be processed by the server will be returned to IIS and sent to the client. The script is sent to the appropriate script engine, and the script engine's processed results are sent back to IIS and are inserted in the appropriate position on the page.
To improve the efficiency of the operation, ASP also often put the script engine to create the compiled code, in the cache in order to call again. This code is not the same as the output to the client. The customer sees the execution result of the scripting code after interpretation, syntax checking, and compilation. Caching on the server is only compiled code, which is discarded after the original source file changes.
1. Identify server-side script segments
The ASP's interpreter can tell whether the code is a server-side script based on one of two separate ways.
(1) using <%%> script separator
The most commonly used characters for <% and% > for separating script segments are:

This method is also used to return the remaining text and HTML in the page where you want to insert variable values or small script statements:

This code produces the following results:
The result of calculating seven plus six minus one is 12
(2) Use of <SCRIPT> elements
Use the <SCRIPT> element when writing scripts that are executed in the browser. This element can also be used on the server side when the Runat attribute is included in this element and the value is set to "server":


It is important to recognize that ASP pages can contain server-side scripts and client script. The client's script (containing runat= "client", or omitting the runat attribute) is not processed by the ASP interpreter, as with. htm or. HTML file name extension to the normal HTML page directly to the client:

(3) contains a separate script file
An ASP page can contain a separate file, and the file contains scripting code, which is handy for writing common functions that can be used on other web pages. In this way, to change the script code in this file, all scripts that contain this file are automatically changed when they are executed. To include a separate script file, you can use the S R C attribute of the <SCRIPT> element to specify a relative, physical, or virtual path and file name.

This individual file must contain only valid scripting code and cannot contain the original page contents such as text or HTML. If you use this technique, other code cannot be placed within the <SCRIPT> element, it must be empty. If you want to add additional scripts for the page, use a different <SCRIPT> element or a separate script from <% ...% >.
You can also include text from a file that contains script, text, or HTML, which can be accomplished by using the server-side include (Server-side include,ssi) directive. This issue will be studied in the 4th chapter.
2. Define the scripting language
ASP has two scripting engines: VBScript and JScript. The two scripting engines were installed by default when you installed ASP. There are also scripting engines used by other applications, such as Microsoft's Internet Explorer Web browser and Windows Scriptinghost. The current version of the browser in Windows 2000 is 5.0, and there may be a new upgrade version. There are other scripting engines, such as TCL and PerlScript (an ActiveX script interpreter rather than traditional CGI based Perl).
So you have to tell the asp,asp page what engine to use. The usual approach is to define the engine in a particular environment declaration element, which must be placed on the first line of the file and defined only once. This element is typically used after the ASP code delimiter followed by the character @:

This definition row can also contain other definitions, which you can see later in this chapter. Define a page that is encoded in VBScript, as follows:
<%language= "VBScript"%>
For the JScript engine, use:
<% @LANGUAGE = "JScript"%>
After the above definition, all the code in the <% > section of the page will be sent to the scripting engine defined by the definition element. This is the only way to specify a scripting language for this type of code separation.
However, using the <SCRIPT> definition element, you can define the scripting language for each segment individually, and use more than one scripting language on the same page if needed:

Unlike on the client side, there is no need to hide script code within the annotation element, because when it executes, the code is removed from the page and replaced by the output only. When the client views the ASP page (select View Source in the browser), only text, HTML, and other client script code are visible. All server scripts are executed, only the results are sent to the client.
The default scripting language
ASP uses the default scripting engine when no scripting language is specified for ASP pages or when there are no separate <SCRIPT> elements. When you first install IIS, the default scripting language is VBScript. However, for an entire Web site or a stand-alone virtual application within a site, you can change the settings as needed.
In the Application Configuration dialog box mentioned earlier in this chapter, there is an app Options tab that contains a text box that sets the default language, as shown in Figure 1-6.
The default language can also change settings in IIS by editing the values of Active Directory segments. The settings you can see in the Internet Servicesmanager MMC plug-in are stored in Active Directory in Windows 2000, and can be read and edited as long as they have the appropriate permissions. This book will detail active Directory in later chapters.
In addition, you can choose a scripting language based on your preferences. If the reader thinks a language is good, keep using it. Because all ASP code executes on the server side without worrying about browser compatibility issues. If the reader is proficient in VBScript and JScript or other languages, choose the one that is best suited to your needs. However, because the functionality of VBScript versions is constantly expanding (for example, VBScript 5.0 now supports regular expressions), VBScript is usually selected. Its requirements for type and syntax are not very high, and there is a simpler multiple-statement structure, so it is an easy-to-use tool.

3. Scripting Performance Issues
In general, the speed of a Web server processor is sufficient to be used (unless a particularly busy site) because their primary task is to load the page from disk into the client. Therefore, each page's request result causes the processor to wait for the disk. This means that performing ASP scripts typically has a very small impact on performance. And if a piece of scripting code executes more than once on a page, and the compiled version of the code is cached, then it is only necessary to execute it without having to compile it multiple times, which will have less impact on performance.
Of course, as the number of requests increases, the server load is increasing, and parsing and executing each ASP page has a corresponding cost. The workload of the ASP interpreter should be compressed as much as possible. Here are some helpful tips.
(1) Avoid mixing scripting languages on the same page
If there are several scripting languages on the same page, the ASP has to load multiple scripting engines one after another and send the corresponding code to the appropriate engine. This will reduce processing speed and increase memory usage. Another side effect is that if you write a sequential code (rather than a series of functions or subroutines that are called from another code snippet), you might do so in a different order than they would appear in the page.
For example, the following code might not produce the desired result because it is not possible to ensure that the results of the JScript code appear first in the Web page or in the third place.


(2) Avoid excessive environment switching in scripts and other content
Whenever an ASP encounters a script segment, it must execute and send the results to IIS, and then return to explain the page again. Therefore, using the Response.Write statement (which creates only text destined for the client, similar to the Print command line) can make the page more efficient. For example, the following VBScript:

(3) Building a separate component
If you have to do a lot of work on one page, or run an overly complex script, it's usually a good idea to build a component and install it on a Web server. Components are usually compiled executable code, which is more efficient than interpreting ASP script code. The issue of building components is discussed later in this book.