How does an .asp file, full of calls to the ASP intrinsic objects and other components, get translated into an HTML page that a standard browser can view (and execute)? In fact, the process is reasonably simple:
The client requests an ASP page by sending an HTTP Get or Post Request to the server. All things being equal, one of two things will happen here. If the server cannot find the file then it responds with the familiar HTTP 404 Not Found message. If the file is found, it will be recognized as an Active Server Page because of its .asp extension and sent to the ASP Scripting engine to be parsed. (All things not being equal, then something untoward like a Server Error may occur.)
The Scripting Host, located in asp.dll, can now do two things. If this is the first ASP page to be sent to this client from the server, this means a new session, and possibly a new application too, has begun and it will check global.asa for anything to do before it gets to the requested page. Once that has been done, or if this is not the first ASP page the client has requested, the host then executes all the server-side scripting code in the page as delimited by either <% ... %> or <SCRIPT RUNAT=SERVER> ... </SCRIPT> tags. Once this has been done, the engine passes back one of three things: an error page, an object moved status code, or an HTML page.
If either an error page or a correctly-formed HTML page is passed back, it is then displayed. If the ASP page contained a call to Response.Redirect, the server will pass back to the client the HTTP code 302 telling it that the page requested has moved temporarily. Note that if response buffering had previously been set to true, it will seem to the client that the server automatically transferred him to the new location of the page. If response buffering is set to false, which is the current ASP default, they will see an error page telling them the page they wanted has moved temporarily.
Before we go any further, it would be a good idea to tie a few loose ends together and explain a few of the concepts that we've encountered in a little more detail, starting with exactly what a web application is. As we mentioned earlier, more sites are being developed for the web that mimic the functionality of an application you would go and buy from a shop.
A web application is really no more than a collection of ASP pages and server components, and a website can contain several. The distinction between them is made by the definition of the application's starting-point or root directory within the site. All the content within this directory and the physical directory structure underneath it is considered to be part of the application until another application root directory is found (although ideally one application shouldn't exist below another we'll come to this in a moment). Thus the scope of an application is defined by the directories under the root not belonging to another application. The scope itself specifies the reach of changes to application state or to server-related attributes.
Each application has its own set of variables and attributes that define its current state, and these are maintained throughout the lifetime of the application from the moment it is first run until the end of the last session is closed. As we pointed out earlier, the problem with web-based applications is that the under-lying protocol of the web, HTTP, has less memory than a goldfish and retains no information from one client request to the next. ASP gets around this by using the Application and Session objects to store information for the duration of the application, and for the duration of a user's session, respectively. Both application and session states are initialized and destroyed by code contained in the global.asa file. Global.asa can be found in the root directory of any web application. Code in global.asa is triggered off at the initialization and termination of the application, and also at the beginning and end of each user session, governing the lifecycle of the state variables. Global.asa might also contain some 'global code' for use throughout the application.
An application's global.asa file is valid throughout the scope of that application, i.e. the application root directory and its physical subdirectories. If at all possible, you should avoid creating another application below an existing application, because this new application's root directory will be a subdirectory of the existing application. If both application root directories contain global.asa files, it's possible that they will conflict, with the wrong global.asa being executed. The safest option is to preserve a separate directory structure for each application.