By creating an alp.site file in a directory you will instruct ALP to treat that directory as a root of a virtual WEB server or also called Virtual ALP site in the ALP documentation. If you create a Virtual ALP site this file will be created for you. This will implicitly assume that this is also a start point of an ALP application and will apply the default directory settings to it. To override them you will need to define explicitly an ALP application and directory settings in this directory or some of its sub-directories (if you need to simulate virtual site with many ASP applications you can create separate ALP applications in subdirectories of a single virtual ALP site). In many cases the default settings are good enough but if your application requires some specific configuration settings you will need to create ALP application or/and directory settings and edit them.
ALP Site is like a virtual WEB site. ALP will present the full path of the root site directory as a host name to the ASP pages and CGI programs in it (and its sub-directories) and the rest of the path will be presented as virtual path in the site. This affects for example the Request.ServerVariables, Server.MapPath, include directive, the way the relative/virtual URL used in the HTML are translated.
If you own a DEVELOPER license you can import it into the ALP site from the Virtual ALP site screen.
The application settings are the most important part of the ALP settings. They are kept in a file named alp.application and the ALP application screens will create and manage it in the selected directory.
The ALP Application settings define various options. For example they define the size of the ALP internal buffers used for the application, the application's browser requirements, the worker thread priority and many other rules which ALP will obey for any page served from that ALP application.
In the ALP Application settings you are also able to specify how the different file extensions are executed - tell the ALP what to do with the different files. For example ASP files are mapped to the ASP processor but you can map other file extensions to it as well. All the files that are not managed by a specific ALP module are served by the so called RAW spooler - they are just transferred to the browser. However the RAW spooler needs to know their content type. So as like in IIS and Apache you have a form that allows you to specify mappings between MIME types and file extensions. Each file extension mapped to certain ALP module (Content Generator) has its own configuration. If you need to edit the ASP settings you should edit ASP and/or ASA files configuration.
Are the MIME types important? Yes - it is recommended to review them before deploying your application and correct/add settings for the file types you are using in your application. Windows OS has its own MIME to file extension map in the registry, but you have absolutely no guarantee that it will be correct and the same on all the machines where your application will run. So ALP uses its own application settings in order to avoid problems caused by other software products. By configuring the settings here you will be sure what content type will be assumed for each file type no matter what the local machine registry claims for it.
ALP application is like ASP application on IIS. The major difference is that ALP maintains the application settings in its core and not like IIS in the ASP ISAPI plug-in. In theory other WEB programming technologies may benefit of this mechanism without need to implement it themselves. However you do not need to be concerned of this fact as long as you are not involved in development of ALP extensions.
For the ASP pages the ALP application also defines the boundaries for the Application and Session objects. All the ASP files in the ALP application share the same objects which are separate from the Application and Session objects in the other ASP applications outside the ALP application's boundaries.
In directory where ALP application is defined explicitly or implicitly (when you have Virtual ALP site) you can put a global.asa file which initializes the ASP application when it is first entered.
This allows you to specify directory settings for this directory and its sub-directories. They include the default documents and some flags - like permission to execute scripts or browse the directory. Many of them may look a bit strange in ALP for it runs locally and the security considerations are not the same as on a WEB server. However these settings may help you when building application compatible with both IIS and ALP and also may prevent your customers from accessing the application from a wrong place.
Special attention deserve the security settings, such as Unattended execution prevention and Security URL. Any application able to perform operations over the local file system should turn on the Unattended execution protection in order to block hacker attacks based on internal page invocation (with parameters that will cause it to modify/remove system files for example). This flag will prevent that by simply requiring the application to be entered from one of its default documents.
ALP 1.2 supports one custom error page - for the File Not Found case (404 HTTP error). It can be specified here.