As we saw in the FoxWeb Overview topic, there are two types of content served by Web servers: Static content and dynamic content. Static content is stored in files and is directly served by the Web server. The majority of the content viewed on the Internet is static content. Dynamic content on the other hand, is not predetermined, but is rather created on the fly (dynamically) by a program that is called by the Web server. Content generated by FoxWeb scripts is dynamic.
Most Web applications use a combination of static and dynamic content. In general, most text content is generated dynamically by the application, while graphics and other static content is stored in files in the server's Web tree.
Files containing static content are stored in the Web server's Web tree. The Web tree is defined as the Web server's root directory and all its subdirectories, plus all virtual directories set up in the server's configuration program. For example, the default root directory of Microsoft Internet Information Server (IIS) and Microsoft Personal Web Server (PWS) is
The dynamic content returned by FoxWeb applications is generated by FoxWeb scripts. Depending on how you have configured FoxWeb, script files are either located in the FoxWeb program tree, or in the Web tree. The FoxWeb Program Tree is comprised by the Program Root -- configured in the FoxWeb Control Center -- and all its subdirectories.
By default, FoxWeb is set up not to look for scripts in the Web tree, but rather to look for them in the FoxWeb Program Tree. The setting that determines this behavior is the Use Web Server's Directory Mappings check box in the FoxWeb Control Center. If this setting is disabled then FoxWeb looks for scripts in the FoxWeb Program Tree. If on the other hand the setting is enabled and the URL utilizes script mapping, then FoxWeb looks for scripts in the Web tree.
There are pros and cons for storing FoxWeb scripts in the Web tree. The main problem, and the reason why this is not the default setting, is that files located in the Web tree can be downloaded over the Web. This means that, unless you configure your Web server properly, files used by your application, such as databases, and programs, will be exposed to the Internet. On the other hand, storing scripts in the Web tree along with static files keeps the file structure more organized and makes it easier to move your applications to another location or another server.
This is the default configuration of FoxWeb. With this configuration all scripts are stored in the Program Root and its subdirectories. Since the FoxWeb Program Tree is outside the Web tree, there is no danger that your data or other files used by your application would get downloaded by prying users. This same fact, however, means that you need to store all static files, used by your application, in the Web tree, separately from the rest of your files. The FoxWeb Program Root directory is configured in the Virtual Servers page of the FoxWeb Control Center. Note that if FoxWeb is configured to serve multiple host names (virtual roots), then each host can have its own Program Root. If you do not specify a program root for a particular server, then its program root defaults to the Default Program Root directory.
This method should be used in conjunction with the Use Web Server's Mappings setting, and with Script Mapped URLs. If you chose to configure your server in this manner, then FoxWeb uses the PATH_TRANSLATED Server Variable to determine where to look for your scripts. There is no danger that users would be able to download your FWX files, because they would normally be mapped to foxweb.exe or foxweb.dll, but other files used by your application, such as data files, PRG and FXP files, will be exposed via your server, unless you protect them somehow. If you wish you can store your data files in a directory outside your Web tree and write your programs so that they include fully qualified paths in USE, SELECT, and other data access commands. Another solution is to configure your Web server, so that it does not allow the direct retrieval of files that should not be downloaded. If your Web server does not support the ability to prevent retrieval, based on file extension, you can also map the extensions of these files to a program that simply returns an error message. The FoxWeb setup program installs the file deny.exe, which can be used for this purpose. With the proper configuration you can be sure that your server will be equally secure no matter where you chose to store your script files.
FoxWeb channels are written in VFP in order to take advantage of Visual FoxPro's super fast data access engine, and to maintain 100% compatibility with the FoxPro language. Because of the significant overhead of VFP, it is impractical to open a new channel with every hit. Instead, channels are initialized when FoxWeb is started, and quitely sit in the background waiting for user requests. In order to connect to these channels, the Web server has to first call one of the two FoxWeb stub programs -- the ISAPI module (foxweb.dll), or the CGI module (foxweb.exe). These programs are designed to be extremely efficient and light, simply acting as a middle layer between the Web server and the resident FoxWeb channels. The ISAPI module runs an in-process DLL, so it is more efficient than the CGI module, which has to load as a separate process for each hit. For Web servers that support the ISAPI interface, such as Microsoft Internet Information Server (IIS) and Microsoft Personal Web Server (PWS), it is recommended that you use the ISAPI module. The CGI module, on the other hand, will work with virtually any Web server, so you should use it in environments where ISAPI is not supported.
The FoxWeb setup program asks for the location of the CGI directory and installs both foxweb.exe and foxweb.dll in that location. Most Web servers create a default CGI directory when they are installed. For example, in the default configuration IIS and PWS the directory
Once FoxWeb is installed properly, the Web server passes all requests for FoxWeb scripts to either foxweb.exe or foxweb.dll, which in turn transfer the information to the next free FoxWeb channel. There are two ways that you can instruct the server to call a FoxWeb program:
As we saw in the FoxWeb Overview topic, in order to request a resource such as an HTML file from a Web server a user needs to enter a URL in the browser's Location field. A URL specifies the location of a target such as a file, directory, HTML page, image, program, and so on, stored on a local or networked computer. The general format of a URL is:
Syntax:
scheme://server/path/resource
Definitions:
scheme | Specifies how the resource is to be accessed. For example HTTP accesses a resource on a Web server using the HTTP protocol. Some other commonly used schemes are HTTPS, FTP, NEWS, and FILE. |
server | Specifies the name of the computer where the resource is located. |
path | Specifies the sequence of directories leading to the target. If resource is omitted then the target is the last directory in path. |
resource | If included, resource is the target, and is typically the name of a file. |
URLs can be either fully qualified, absolute, or relative, based on which of the above qualifiers they include. A fully qualified URL includes the scheme and server names, as opposed to absolute and relative URLs, which include only a path and the resource name. Absolute and relative URLs can only exist in links included in content returned by a resource on a server and are always taken in the context of the fully qualified URL that was used to retrieve that resource. When requesting a file or script from a Web browser, users must enter a fully qualified URL. Note that modern browsers do not require user to enter the scheme portion of the URL. If the scheme is missing then most browsers try to retrieve the requested resource via HTTP. We will examine absolute and relative URLs later in this topic.
You probably already have some experience calling static files from a Web server. To call the file example.htm from the subdirectory chapter1 of the server's root directory, you would use the URL:
http://server/chapter1/example.htm
The URL syntax for calling a FoxWeb script follows the same general rules that URLs for static files follow, but the exact form depends on a number of factors:
The full syntax of URLs that call FoxWeb scripts is as follows:
Syntax:
http://server[/CGIPath/StubModule]/ScriptPath/[ProcName@]ScriptName[?QueryString]
Definitions:
server | Specifies the name of the computer where the script is located. |
CGIPath | The path of the CGI/ISAPI directory. The path should only be included if you are not using script mappings. |
StubModule | The name of the CGI or ISAPI module. This will either be foxweb.exe or foxweb.dll and should only be included if you are not using script mappings. |
ScriptPath |
The path to the FoxWeb script being called. Depending on the setting of "Use Web Server's Directory Mappings", this path will be relative to the FoxWeb Program Root, or the Web root directory. If "Use Web Server's Directory Mappings" is disabled, and "Full Paths in URLs" is enabled, this string can specify a full path including a drive letter or a UNC mapping. UNC mappings should be in the form |
ProcName | This optional part of the URL specifies the name of a procedure within the script file that is to be executed. |
ScriptName | The name of the script being executed. If script mapping is being utilized then you must include the .fwx extension whether you are calling an .fwx script or a .prg script. |
QueryString | This is an optional string that can be used to send additional information to the script. The values included in the Query String can be retrieved, using the Request.QueryString method. |
The following examples illustrate URLs that call FoxWeb scripts in a number of different situations:
This example assumes the following server configuration:
Server Name: |
|
Web Root: |
|
CGI/ISAPI directory: |
|
CGI/ISAPI path: | /scripts |
FoxWeb Program Root: |
|
"Use Web Server's Directory Mappings" setting: | Disabled |
Script Mapping: | Not used |
Following are URLs that can be used to call various scripts on the above server:
http://www.foxweb.com/scripts/foxweb.dll/MyApp.fwx
This URL calls the program
http://www.foxweb.com/scripts/foxweb.exe/ContactMine/search@contact.fwx
This URL calls the procedure search in the program
This example illustrates the use of script mappings and assumes the following server configuration:
Server Name: |
|
Web Root: |
|
FoxWeb Program Root: |
|
"Use Web Server's Directory Mappings" setting: | Disabled |
Script Mapping: | The extension .fwx is mapped to the ISAPI module, foxweb.dll |
Following are URLs that can be used to call various scripts on the above server. Note how the URL strings are shorter and simpler than the ones in example 1:
http://www.foxweb.com/MyApp.fwx
This URL calls the program
http://www.foxweb.com/ContactMine/search@contact.fwx
This URL calls the procedure search in the program
http://www.foxweb.com/c:/OtherScripts/SomeScript.fwx
This URL calls the program
This example illustrates use of FoxWeb with the "Use Web Server's Directory Mappings" setting enabled. Note that you must always use script mappings in conjunction with this setting:
Server Name: |
|
Web Root: |
|
FoxWeb Program Root: | Since "Use Web Server's Directory Mappings" is enabled, this setting is only used to locate global procedures. |
"Use Web Server's Directory Mappings" setting: | Enabled |
Script Mapping: | The extension .fwx is mapped to the ISAPI module, foxweb.dll |
Following are URLs that can be used to call various scripts on a server with the above configuration:
http://www.foxweb.com/MyApp.fwx
This URL calls the program
http://www.foxweb.com/ContactMine/search@contact.fwx
This URL calls the procedure search in the program
Your scripts will most probably need to include URLs that point to other scripts or static files. Whether these URLs are part of inline image tags
As a general rule, you can always include fully qualified URLs as described in the previous paragraphs to call static files and other scripts from FoxWeb-generated content. This, however, is not a good idea, because it prevents your code from being portable. For example, suppose that a script that is called with the URL
The solution to the portability problem is to use the correct type of URL (fully qualified, absolute, or relative) depending on the situation. The following table defines each type, lists their differences and describes the types of situations that each type is appropriate for:
This is the complete format of the URL as described earlier in this topic. It is in the form scheme://server/path/resource, so it includes all the information needed to fully resolve an address. It does not inherit any information from the context it is contained in.
You should use relative URLs in the following situations:
This type of URL must be taken in the context of the fully qualified URL that was used to retrieve the resource it is contained in. Absolute URLs inherit the server name but not the path. They are in the form /path/resource and their distinguishing characteristic is that they start with a forward slash. The path in absolute URLs is relative to the root directory (either the Web root or the FoxWeb Program Root, depending on the situation) of the server.
For example, assuming that the user calls a FoxWeb script with the URL
You should use relative URLs in the following situations:
Like absolute URLs, relative URLs must be taken in the context a fully qualified URL. The syntax of relative URLs is path/resource, which is different from that of absolute URLs in the fact that it does not start with a slash. Relative URLs inherit both the server name and the path from the URL that is setting the current context.
For example, assuming that the user calls a FoxWeb script with the URL
Relative URLs are very convenient, because they maintain portability of the code and are very easy to construct. You should use them in the following situations:
The following examples illustrate the use of links in FoxWeb scripts:
This example illustrates the simplest possible situation, in which both scripts and static files are in the same directory. This is achieved by enabling the "Use Web Server's Directory Mappings" setting, and placing scripts in the Web root. In this particular case, all files are located in the directory
<html> |
As you can see, all links included in the above code are relative, except the last link, which points to a resource on another server.
This example is very similar to the preceding example, with some important distinctions: In this case, scripts and static files are not in the same directory. The "Use Web Server's Directory Mappings" setting is disabled, which means that scripts reside in the FoxWeb program tree, as opposed to static files, which are always stored in the Web tree. In order to retain the convenience of relative paths, the server is configured so that the absolute path to FoxWeb scripts is exactly the same as the absolute path to the static files they are associated with. For the purposes of this example the FoxWeb Program Root is
As you can see, the absolute paths, needed to call both our scripts and static files, are identical and equal to "/jobs". The reason for this is that, with "Use Web Server's Directory Mappings" disabled, FoxWeb uses the FoxWeb Program Root as the root directory, while the Web server will use the Web root.
Just like in example 2a, the various static files and scripts in our application can use relative links to call each other, even though in this case they are in different directories. The output of menu.fwx can be identical to the one in example 2a.
In this example our Web server and FoxWeb are configured with the same directory structure as in example 2b, but unlike 2b, in this case our Web server does not support script mapping. To call our scripts we need to directly reference the CGI (or ISAPI) stub program in the URL. To call menu.fwx, for example, we must use the URL
As you can see, the absolute path to our application's static files is different than that pointing to our application's scripts. For this reason, we must use absolute paths to cross-reference scripts and static files. We can keep using relative paths to reference scripts from other scripts, and static files from other static files.
The following is some sample content that could be returned by the static file default.htm:
<html> |
The above content is returned by a static file, so it uses relative URLs to point to other static files, and absolute URLs to point to scripts. Scripts, on the other hand, must use the opposite approach. The following is content generated by the script menu.fwx:
<html> |