Previous Contents Index Next
Sun ONE Web Server 6.1 Administrator's Guide

> ## Chapter 15
> Extending Your Server With Programs

> This chapter discusses how to install programs on the Sun ONE Web Server that dynamically generate HTML pages in response to requests from clients. These programs are known as server-side applications. (Client-side applications are downloaded to the client and run on the client machine.)

> This chapter includes the following sections:

> - Overview of Server-Side Programs
> - Java Servlets and JavaServer Pages (JSP)
> - Installing CGI Programs
> - Installing Windows CGI Programs
> - Installing Shell CGI Programs for Windows
> - Using the Query Handler

> ##

> Overview of Server-Side Programs

> Java servlets and CGI programs have different strengths and uses. The following list illustrates the differences between these server-side programs:

> - Java servlets are written in Java, which is a full-featured programming language for creating network applications.
> - CGI (Common Gateway Interface) programs can be written in C, Perl, or other programming languages. All CGI programs have a standard way of passing information between clients and servers.

> ### Types of Server-Side Applications That Run on the Server

> The Sun ONE Web Server can run the following types of server-side applications to dynamically generate content:

> - Java servlets
> - CGI programs

> The Sun ONE Web Server can also run programs that extend or modify the behavior of the server itself. These programs, known as plug-ins, are written using the Netscape Server Application Programming Interface (NSAPI). For information about writing and installing plug-in programs, see the Sun ONE Web Server 6.1 NSAPI Programmer’s Guide.

> ### How Server-Side Applications Are Installed on the Server

> Each type of program is installed onto the server differently. The following list summarizes the procedures:

> - For Java servlets, you can create and deploy web applications. For more information, see "What the Server Needs to Run Servlets".
> - For CGI programs, you can configure your server to recognize all files with certain filename extensions, or all files in specified directories as CGI programs, or both. For more information, see "Installing CGI Programs", "Installing Windows CGI Programs", and "Installing Shell CGI Programs for Windows".

> These installation procedures are described in the following sections.

> ##

> Java Servlets and JavaServer Pages (JSP)

> This section discusses how to install and use Java Servlets and JavaServer Pages on Sun ONE Web Server.

> The following topics are described:

> - Overview of Servlets and JavaServer Pages
> - What the Server Needs to Run Servlets
> - Deploying Web Applications
> - Deploying Servlets and JSPs Not in Web Applications
> - Configuring JVM Settings
> - Deleting Version Files

> ### Overview of Servlets and JavaServer Pages

> Sun ONE Web Server 6.1 supports the Servlet 2.3 API specification, which allows servlets and JSPs to be included in web applications.

> A web application is a collection of servlets, JavaServer Pages, HTML documents, and other web resources which might include image files, compressed archives, and other data. A web application may be packaged into an archive (a WAR file) or exist in an open directory structure.

> Note | Servlet API version 2.3 is fully backward compatible with version 2.1, so all existing servlets will continue to work without modification or recompilation.

> To develop servlets, use Sun Microsystems’ Java Servlet API. For information about using the Java Servlet API, see the documentation provided by Sun Microsystems at:

> http://java.sun.com/products/servlet/index.html

> A JSP is a page, much like an HTML page, that can be viewed in a web browser. However, in addition to HTML tags, it can include a set of JSP tags and directives intermixed with Java code that extend the ability of the web page designer to incorporate dynamic content in a page. These additional features provide functionality such as displaying property values and using simple conditionals. Sun ONE Web Server 6.1 supports the JavaServer Pages (JSP) 1.2 API specification.

> Note | Ensure that the case of the URI your application requests for (for example, /foo.JSP) matches the canonical case of the file system path (for example, C:\Program Files\WebServer\docs\foo.jsp). This is necessary because the Sun ONE Web Server 6.1 Java web container currently performs case-sensitive pattern matches.

> For information about creating JSPs, see Sun Microsystem’s JavaServer Pages web site at:

> http://java.sun.com/products/jsp/index.html

> For information about developing servlets and JSPs for use with Sun ONE Web Server, see the Sun ONE Web Server 6.1 Programmer’s Guide to Web Applications.

> ### What the Server Needs to Run Servlets

> Sun ONE Web Server includes the Java Development Kit (JDK) version 1.4.1_03. While in previous versions of the Web server, Java was configured server-wide, in the 6.1 release, you can configure Java per instance of the Web server.

> You may use the JDK that is bundled with Sun ONE Web Server 6.1 or you may use a JDK of your choice, in which case you must specify a path to the JDK. For more information on how you can do this, see "Configuring JVM Settings".

> By default, Java is disabled when you install the Sun ONE Web Server. In order to enable servlets, you must first enable Java.

> For information on how you can enable Java, see "Enabling and Disabling Java".

> ### Deploying Web Applications

> The following sections describe how to deploy, edit, and delete web applications either manually by using the wdeploy command line utility, or through the user interface.

> #### Using the server.xml File

> Once deployed, your web applications are enabled by default. To disable a deployed web application manually you would need to modify the server.xml file as follows:

> <VS>
> <WEBAPP uri="/mywebapp" path="/webappdir" enabled = "false" >
> </WEBAPP>

> ...

> </VS>

> If you inadvertently deploy or edit more than one web application with the same description, and one of them is disabled, the server will ignore enabled = “false” and continue with default setting of enabled = “true”.

> For more information about the server.xml file, see the Sun ONE Web Server 6.1 Programmer’s Guide to Web Applications.

> You can deploy and edit web applications in two ways:

> - Using the Administration Server Interface
> - Using the Command Line Interface

> #### Using the Administration Server Interface

> Using Sun ONE Web Server 6.1, you can deploy, edit, delete, disable, and enable web applications for a specified virtual server.

> ##### Deploying Web Applications

> You can access the Deploy Web Applications page by selecting Deploy Web Applications under the Web Applications tab of the Virtual Server Manager.

> To deploy a web application, follow these steps:

> 1. Select Local Machine or Server Machine from the WAR File On drop-down list.

> Select Local Machine when uploading a WAR file to your server. Select Server Machine when the WAR file already resides there.

> 2. Enter the path on the local or server machine to the WAR file containing the web application in the field provided.

> On server machines enter the absolute path to the WAR file.

> On local machines you can browse the available paths. Clicking browse will bring up the File Upload window, allowing you to select the WAR file to upload to your server.

> 3. Enter the URI on the virtual server for the web application in the field provided.
> 4. Enter the absolute path to the directory on the server machine into which the contents of the WAR file will be extracted. If the directory does not exist, one will be created.
> 5. Click OK.
> 6. Click Apply.
> 7. Select Dynamic Reconfiguration for your web application to be deployed.

> ##### Editing Web Applications

> You can edit, delete, disable, or enable an already deployed web application. Access the Edit Web Applications page by selecting Edit Web Applications under the Web Applications tab of the Virtual Server Manager.

> To edit, delete, disable, or enable an already deployed web application, follow these steps:

> 1. Select the action you wish to perform from the drop-down list in the Action column next to the web application you are editing. Choose:
> - Edit to change the URI where the web application can be accessed.
> - Delete to delete the web application entry from the web applications file and delete the directory where the application is deployed.
> - Disable to make the web application inaccessible from the URI, but not delete it.
> - Enable to reactivate web applications that were previously disabled.

>   Caution | Deleting a web application also deletes the directory the application is deployed in.

> 2. (Optional) Enter a new URI in the URI field if you are editing the web application.
> 3. Click OK.
> 4. Click Apply.
> 5. Select Dynamic Reconfiguration for your web application to be deployed.

> #### Using the Command Line Interface

> Before you can deploy a web application manually, you must make sure that the server_root/bin/https/httpsadmin/bin directory is in your path and that the IWS_SERVER_HOME environment variable is set to your server_root directory.

> ##### To deploy a virtual server web application:

> You can use the wdeploy utility at the command line to deploy a WAR file into a virtual server web application environment:

> wdeploy deploy -u <uri_path> -i <instance> -v <vs_id> [ [-V <verboseLevel>]| [-q] ] [-n] [-d <directory>] <war_file>

> ##### To delete a virtual server web application:

> wdeploy delete -u <uri_path> -i <instance> -v <vs_id> [ [-V <verboseLevel>] | [-q] ] [-n] hard|soft

> ##### To list the web application URIs and directories for a virtual server:

> wdeploy list -i <instance> -v <vs_id> [ [-V <verboseLevel>] | [ -q] ]

> The command parameters have the following meanings:

> uri_path | The URI prefix for the web application.
> instance | The server instance name.
> vs_id | The virtual server ID.
> directory | (optional) The directory to which the application is deployed, or from which the application is deleted. If not specified for deployment, the application is deployed to the document root directory.
> hard | soft | Specifies whether the directory and the server.xml entry are deleted (hard) or just the server.xml entry is deleted (soft).
> war_file | The WAR file name
> verboseLevel | The verbose level to display the log messages on console. The value can range from 0 to 4. The default value is 1. Note that in Sun ONE web Server 6.1, the loglevel attribute of the LOG element in server.xml is used in lieu of this element.
> -q | (quiet) Sets the verbose level to zero. It is equivalent to the setting -V 0.
> -n | prevents wdeploy from automatically sending the reconfigure command to the web server. For more information, see Using -n in the wdeploy Command.

> Caution | If you deploy a web application and do not specify a directory, the application is deployed to the document root directory. If you then delete the application using the hard parameter, the document root directory will be deleted.

> When you execute the wdeploy deploy command, three things happen:

> - A web application with the given uri_path and directory gets added to the server.xml file.
> - The WAR file gets extracted at the target directory.
> - The server is dynamically reconfigured to load the new web application.

> For example:

> wdeploy deploy -u /hello -i server.sun.com -v acme.com -d /s1ws61/https-server.sun.com/acme.com/web-apps/hello /s1ws61/plugins/servlets/examples/web-apps/HelloWorld/HelloWorld.wa r

> This utility results in the following server.xml entry:

> <VS>
> <WEBAPP uri="/hello"
> dir="/s1ws61/https-server.sun.com/acme.com/webapps/hello"/>
> </VS>

> The /s1ws61/https-server.sun.com/acme.com/web-apps/hello directory has the following contents:

> colors
> index.jsp
> META-INF
> WEB-INF/
> web.xml
> /classes/
> HelloWorldServlet.class
> HelloWorldServlet.java
> SnoopServlet.class
> SnoopServlet.java

> ##### Using -n in the wdeploy Command

> In Sun ONE Web Server 6.1, after deploying or deleting a web application, wdeploy dynamically reconfigures the server, causing the server to load or unload the web application that was deployed or deleted. Previously, you had to explicitly reconfigure the server in order for your changes to take effect by doing one of the following:

> - Using the reconfig script
> - Restarting the server
> - Clicking the Apply link in the Administration User Interface.

> Now a successful wdeploy command will automatically be enabled to service requests for a new web application, or to stop servicing requests for a deleted web application.

> The -n option prevents wdeploy from automatically sending the reconfigure command to the web server. Use the -n option in your command when deploying or undeploying multiple web applications (in a script for example), and you want to reconfigure the server only once after the last web application is deployed.

> ##### Accessing Deployed Web Applications

> After you have deployed an application, you can access it from a browser as follows:

> http://vs_urlhost[:vs_port]/uri_path/[index_page]

> The parts of the URL have the following meanings:

> vs_urlhost | One of the urlhosts values for the virtual server.
> vs_port | (optional) Only needed if the virtual server uses a non-default port.
> uri_path | The same one you used to deploy the application. This is also the context path.
> index_page | (optional) The page in the application that end users are meant to access first.

> For example:

> http://acme.com:80/hello/index.jsp

> or:

> http://acme.com/hello/

> ##### Return Values

> The wdeploy option returns following exit values:

> - 0. Indicates that the wdeploy option was executed successfully.
> - 1. Indicates that an error occurred while executing the wdeploy option due to invalid command line arguments or invalid content of the configuration files.
> - 2. Indicates that the error is due to operating system settings. Either the specified directory doesn't exist or the file permission is not set.

> ### Deploying Servlets and JSPs Not in Web Applications

> You can deploy 4.x servlets and JSPs outside of web applications, but only in the default virtual server. For information, see the Sun ONE Web Server 6.1 Programmer’s Guide to Web Applications.

> ### Configuring JVM Settings

> You can configure attributes for the Java Virtual Machine (JVM) in the Java tab in the Server Manager.

> For more information on these options, see the Sun ONE Web Server 6.1 Programmer’s Guide to Web Applications.

> ### Deleting Version Files

> The Delete Version Files page on the Java tab of the Server Manager allows you to delete the files that contain the version numbers for the JavaServer Pages class cache and the session data cache. This page has the following fields:

> Clear Session Data

> Deletes the SessionData directory, which stores persistent session information if the server uses the MMapSessionManager session manager.

> Delete JSP ClassCache Files

> Deletes the ClassCache directory, which caches information for JavaServer Pages (JSP). The default location of this directory is:

> server_root/https-server_id/ClassCache/virtual_server_id/webapp_uri /

> When the server serves a JSP page, it creates a .java and a .class file associated with the JSP and stores them in the JSP class cache under the ClassCache directory.

> The server uses two directories to cache information for JavaServer Pages (JSP) and servlets:

> - ClassCache

> The server uses the following directory to cache information for JavaServer Pages (JSP):

> server_root/https-server_id/ClassCache/virtual_server_id/webapp_uri/

> When the server serves a JSP page, it creates a .java and a .class file associated with the JSP and stores them in the JSP class cache under the ClassCache directory.

> - SessionData

> If the server uses the MMappedSessionManager session manager, it stores persistent session information in the SessionData directory.

> Each cache has a version file containing a version number that the server uses to determine the structure of the directories and files in the caches. You can clean out the caches by simply deleting the version file.

> When the server starts up, if it does not find the version files, it deletes the directory structure for the corresponding caches and re-creates the version files. Next time the server serves a JSP page, it recreates the JSP class cache. The next time the server serves a JSP page or servlet while using MMappedSessionManager session manager, it recreates the session data cache.

> If a future upgrade of the server uses a different format for the caches, the server will check the number in the version file and clean up the caches if the version number is not correct.

> ##

> Installing CGI Programs

> This section discusses how to install CGI programs. The following topics are described:

> - Overview of CGI
> - Specifying a CGI Directory
> - Specifying CGI as a File Type
> - Downloading Executable Files

> In addition, the following sections discuss how to install Windows-specific CGI programs:

> - Installing Windows CGI Programs
> - Installing Shell CGI Programs for Windows

> ### Overview of CGI

> Common Gateway Interface (CGI) programs can be defined with any number of programming languages. On a UNIX/Linux machine, you’re likely to find CGI programs written as Bourne shell or Perl scripts.

> Note | Under UNIX/Linux, there are extra CGIStub processes running that the server uses to aid in CGI execution. These processes are created only during the first access to a CGI. Their number varies depending upon the CGI load on the server. Do not kill these CGIStub processes. They disappear when the server is stopped.

> On a Windows computer, you might find CGI programs written in C++ or batch files. For Windows, CGI programs written in a Windows-based programming language such as Visual Basic use a different mechanism to operate with the server. They are called Windows CGI programs. See "Installing Windows CGI Programs" for information about Windows CGI.

> Note | In order to run the command-line utilities, you need to manually set the Path variable to include server_root/bin/https/bin.

> Regardless of the programming language, all CGI programs accept and return data in the same manner. For information about writing CGI programs, see the following sources of information:

> - Sun ONE Web Server 6.1 Programmer’s Guide
> - The Common Gateway Interface at:

> http://hoohoo.ncsa.uiuc.edu/cgi/overview.html

> - Articles about CGI available on the online documentation web site at:

> http://docs.sun.com

> There are two ways to store CGI programs on your server machine:

> - Specify a directory that contains only CGI programs. All files are run as programs regardless of the file extensions.
> - Specify that CGI programs are all a certain file type. That is, they all use the file extensions .cgi, .exe, or .bat. The programs can be located in any directory in or under the document root directory.

> You can enable both options at the same time if desired.

> There are benefits to either implementation. If you want to allow only a specific set of users to add CGI programs, keep the CGI programs in specified directories and restrict access to those directories. If you want to allow anyone who can add HTML files to be able to add CGI programs, use the file type alternative. Users can keep their CGI files in the same directories as their HTML files.

> If you choose the directory option, your server attempts to interpret any file in that directory as a CGI program. By the same token, if you choose the file type option, your server attempts to process any files with the file extensions .cgi, .exe, or .bat as CGI programs. If a file has one of these extensions but is not a CGI program, an error occurs when a user attempts to access it.

> Note | By default, the file extensions for CGI programs are .cgi, .exe and .bat. However, you can change which extensions indicate CGI programs by modifying the MIME types file. You can do this by choosing the Server Preferences tab and clicking the MIME Types link.

> ### Specifying a CGI Directory

> To specify a CGI-only directory for a class of virtual servers, perform the following steps:

> 1. From the Class Manager, choose the Programs tab.

> The CGI Directory window appears.

> 2. In the URL Prefix field, type the URL prefix to use for this directory. That is, the text you type appears as the directory for the CGI programs in URLs.

> For example, if you type cgi-bin as the URL prefix, then all URLs to these CGI programs have the following structure:

> http://yourserver.domain.com/cgi-bin/program-name

> Note | The URL prefix you specify can be different from the real CGI directory you specify in the previous step.

> 3. In the CGI Directory text field, type the location of the directory as an absolute path. Note that this directory doesn’t have to be under your document root. This is the reason that you need to specify a URL prefix in the next step.
> 4. Click OK.
> 5. Save and apply your changes.

> To remove an existing CGI directory, click that directory’s Remove button in the CGI Directory form. To change the URL prefix or CGI directory of an existing directory, click that directory’s Edit button.

> Copy your CGI programs into the directories you’ve specified. Remember that any files in those directories will be processed as CGI files, so don’t put HTML files in your CGI directory.

> #### Configuring Unique CGI Attributes for Each Software Virtual Server

> To specify CGI attributes for a single virtual server, perform the following steps:

> 1. From the Class Manager, choose the Manager Virtual Servers button.
> 2. From the Virtual Server Manager, choose the Settings link.
> 3. In the CGI User text field, type the name of the user to execute CGI programs as.
> 4. In the CGI Grouptext field, type the name of the group to execute CGI programs as.
> 5. In the CGI Directory text field, type the directory to chdir to after chroot but before execution begins.
> 6. (UNIX only) In the CGI Nice text field, type an increment that determines the CGI program's priority relative to the server. Typically, the server is run with a nice value of 0 and the nice increment would be between 0 (the CGI program runs at same priority as server) and 19 (the CGI program runs at much lower priority than server). While it is possible to increase the priority of the CGI program above that of the server by specifying a nice increment of -1, this is not recommended.
> 7. In the Chroot Directory text field, type the directory to chroot to before execution begins.
> 8. Click OK.
> 9. Save and apply your changes.

> ### Specifying CGI as a File Type

> To specify CGI programs as a file type, perform the following steps:

> 1. From the Class Manager, choose the Programs tab.
> 2. Click the CGI File Type page.

> The CGI as a File Type window appears.

> 3. From the Editing picker, choose the resource you want this change to apply to.
> 4. Click the Yes radio button under Activate CGI as a File Type.
> 5. Click OK.
> 6. Save and apply your changes.

> The CGI files must have the file extensions .bat, .exe, or .cgi. Any non-CGI files with those extensions are processed by your server as CGI files, causing errors.

> ### Downloading Executable Files

> If you’re using .exe as a CGI file type, you cannot download .exe files as executables.

> One solution to this problem is to compress the executable files that you want users to be able to download, so that the extension is not .exe. This solution has the added benefit of making the download time shorter.

> Another possible solution is to remove .exe as a file extension from the magnus-internal/cgi type and add it instead to the application/octet-stream type (the MIME type for normal downloadable files). You can do this through the Server Manager, by choosing the Server Preferences tab and clicking the MIME Types link. However, the disadvantage to this method is that after making this change you cannot use .exe files as CGI programs.

> Another solution is to edit your server’s obj.conf file to set up a download directory, where any file in the directory is downloaded automatically. The rest of the server won’t be affected. For directions on setting up this directory, see the technical note at:

> http://help.netscape.com/kb/server/960513-130.html

> ##

> Installing Windows CGI Programs

> This section discusses how to install Windows CGI Programs. The following topics are included in this section:

> - Overview of Windows CGI Programs
> - Specifying a Windows CGI Directory
> - Specifying Windows CGI as a File Type

> ### Overview of Windows CGI Programs

> Windows CGI programs are handled much as other CGI programs. You specify a directory that contains only Windows CGI programs, or you specify that all Windows CGI programs have the same file extension. Note that like other CGI programs, you can use both methods at the same time if you want to. For example, you can create a directory for all your Windows CGI programs, and specify a Windows CGI file extension.

> Although Windows CGI programs behave like regular CGI programs, your server processes the actual programs slightly differently. Therefore, you need to specify different directories for Windows CGI programs. If you enable the Windows CGI file type, it uses the file extension .wcg.

> Sun ONE Web Servers support the Windows CGI 1.3a informal specification, with the following differences:

> - The following keywords have been added to the [CGI] section to support security methods:
> - HTTPS: its value is on or off, depending on whether the transaction is conducted through SSL.
> - HTTPS Keysize: when HTTPS is on, this value reports the number of bits in the session key used for encryption.
> - HTTPS Secret Keysize: when HTTPS is on, this value reports the number of bits used to generate the server’s private key.
> - The keyword Document Root in the [CGI] section might not refer to the expected document root because the server does not have a single document root. The directory returned in this variable is the root directory for the Windows CGI program.
> - The keyword Server Admin in the [CGI] section is not supported.
> - The keyword Authentication Realm in the [CGI] section is not supported.
> - Forms sent with multi-part/form-data encoding are not supported.

> ### Specifying a Windows CGI Directory

> To specify a Windows CGI-only directory:

> 1. From the Class Manager, choose the Programs tab.
> 2. Click the WinCGI Directory link.

> The WinCGI Directory window appears.

> 3. In the URL Prefix text field, enter the URL prefix you want to use for this directory.

> That is, the text you type appears as the directory for the Windows CGI programs in URLs. For example, if you type wcgi-programs as the URL prefix, then all URLs to these Windows CGI programs have the following structure:

> http://yourserver.domain.com/wcgi-programs/program-name

> Note | The URL prefix you specify can be different from the real Windows CGI directory you specify in Step 5.

> 4. Choose whether you want to enable script tracing.

> Click the Yes or No radio button under “Enable Script Tracing?”.

> CGI parameters are passed from the server to Windows CGI programs through files, which the server normally deletes after the Windows CGI program finishes execution. If you enable script tracing, these files are retained in a /temp directory or wherever the environment variables TMP and TEMP are pointing. Also, any window that the Windows CGI program brings up is shown when script tracing is enabled.

> 5. In the WinCGI Directory field, enter the location of the directory as an absolute path.

> Note that this directory doesn’t have to be under your document root. This is the reason that you need to specify a URL prefix in Step 3.

> 6. Click OK.
> 7. Save and apply your changes.

> To remove an existing Windows CGI directory, click that directory’s Remove button in the Windows CGI Directory form. To change the URL prefix or Windows CGI directory of an existing directory, click that directory’s Edit button.

> Copy your Windows CGI programs into the directories you’ve specified. Remember that any file in those directories is processed as a Windows CGI file.

> ### Specifying Windows CGI as a File Type

> To specify a file extension for Windows CGI files, perform the following steps:

> 1. From the Server Manager, choose the Server Preferences tab.
> 2. Click the MIME Types link.

> The Global MIME Types window appears. For more information on the Global MIME Types, see "Choosing MIME Types".

> 3. Add a new MIME type with the following settings:
> - Type: type
> - Content type: magnus-internal/wincgi.
> - File Suffix: Enter the file suffixes that you want the server to associate with Windows CGI. If you activated CGI, WinCGI, and shell CGI file types, you must specify a different suffix for each type of CGI. For example, you can’t use the suffix .exe for both a CGI program and a shell CGI program. If you need to, you can edit the other MIME type fields on the page so that the suffixes are unique.
> 4. Click the New Type button.
> 5. Save and apply your changes.

> ##

> Installing Shell CGI Programs for Windows

> This section discusses how to install Shell CGI Programs for Windows. The following topics are included in this section:

> - Overview of Shell CGI Programs for Windows
> - Specifying a Shell CGI Directory (Windows)
> - Specifying Shell CGI as a File Type (Windows)

> ### Overview of Shell CGI Programs for Windows

> Shell CGI is a server configuration that lets you run CGI applications using the file associations set in Windows.

> For example, if the server gets a request for a shell CGI file called hello.pl, the server uses the Windows file associations to run the file using the program associated with the .pl extension. If the .pl extension is associated with the program C:\bin\perl.exe, the server attempts to execute the hello.pl file as follows:

> c:\bin\perl.exe hello.pl

> The easiest way to configure shell CGI is to create a directory in your server’s document root that contains only shell CGI files. However, you can also configure the server to associate specific file extensions with shell CGI by editing MIME types from the Sun ONE Web Server.

> Note | For information on setting Windows file extensions, see your Windows documentation.

> ### Specifying a Shell CGI Directory (Windows)

> To create a directory for your shell CGI files, perform the following steps:

> 1. Create the shell directory on your computer. This directory doesn’t have to be a subdirectory of your document root directory.
> 2. From the Server Manager, choose the Class Manager link.
> 3. Next, choose Class Manager.

> The shell CGI Directory link is highlighted and the CGI window appears.

> 4. In the URL Prefix field, enter the URL prefix you want to associate with your shell CGI directory.

> For example, suppose you store all shell CGI files in a directory called
> C:\docs\programs\cgi\shell-cgi, but you want users to see the directory as http://www.yourserver.com/shell/. In this case, you would type shell as the URL prefix.

> 5. In the Shell CGI Directory field, enter the absolute path to the directory you created.

> Caution | The server must have read and execute permissions to this directory. For Windows, the user account the server runs as (for example, LocalSystem) must have rights to read and execute programs in the shell CGI directory.

> 6. Make sure that any files in the shell CGI directory also have file associations set in Windows. The server returns an error if it attempts to run a file that has no file-extension association.

> ### Specifying Shell CGI as a File Type (Windows)

> You can use the Sun ONE Web Server’s MIME Types window to associate a file extension with the shell CGI feature. This is different from creating an association in Windows.

> To associate a file extension with the shell CGI feature in the server, for example, you can create an association for files with the .pl extension. When the server gets a request for a file with that extension, the server knows to treat the file as a shell CGI file by calling the executable associated in Windows with that file extension.

> To associate a file extension as a shell CGI file, perform the following steps:

> 1. Create the shell directory on your computer. This directory doesn’t have to be a subdirectory of your document root directory.
> 2. From the Server Manager, choose Server Preferences.
> 3. Click the MIME Types link.

> The Global MIME Types window appears. For more information on the Global MIME Types, see "Choosing MIME Types".

> 4. Add a new MIME type with these settings:
> - Type: type
> - Content type: magnus-internal/shellcgi.
> - File Suffix: Enter the file suffixes that you want the server to associate with shell CGI. If you activated CGI, WinCGI, and shell CGI file types, you must specify a different suffix for each type of CGI. For example, you can’t use the suffix .exe for both a CGI program and a shell CGI program. If you need to, you can edit the other MIME type fields on the page so that the suffixes are unique.
> 5. Click the New Type button.
> 6. Save and apply your changes.

> ##

> Using the Query Handler

> Note | The use of Query Handlers is outdated. Although Sun ONE Web Server and Netscape Navigator clients still support it, it is rarely used. It is much more common for people to use forms in their HTML pages to submit queries.

> You can specify a default query handler CGI program. A query handler processes text sent to it via the ISINDEX tag in an HTML file.

> ISINDEX is similar to a form text field in that it creates a text field in the HTML page that can accept typed input. Unlike the information in a form text field, however, the information in the ISINDEX box is immediately submitted when the user presses Return. When you specify your default query handler, you tell your server to which program to direct the input. For an in-depth discussion of the ISINDEX tag, see an HTML reference manual.

> To set a query handler, perform the following steps:

> 1. From the Class Manager, choose the Programs tab.
> 2. Click the Query Handler link.

> The Query Handler window appears.

> 3. Use the Editing Picker to select the resource you want to set with a default query handler.

> If you choose a directory, the query handler you specify runs only when the server receives a URL for that directory or any file in that directory.

> 4. In the Default Query Handler field, enter the full path for the CGI program you want to use as the default for the resource you chose.
> 5. Click OK.
> 6. Save and apply your changes.

> Previous Contents Index Next

> Copyright 2004 Sun Microsystems, Inc. All rights reserved.