Web Development

A Panther Web application can specify to open a screen in several ways:

• Enter the screen name in a URL.

• Create a hyperlink to the screen.

• Open the screen through application processing.

With the first two methods, the URL specified in the browser or hyperlink contains the name of the HTTP server where the Panther screen is located. The HTTP server passes the URL request to Panther using CGI's GET method.

Panther then performs any processing, generates the HTML for the screen, and sends the data to the browser. If the user activates a push button on the screen, the browser submits the screen back to the HTTP server. This time the HTTP server uses CGI's POST method to relay the submitted screen.

The protocol used to send the screen data is determined by the URL. For many requests on the Internet, the HTTP protocol is used, but to transfer data securely, the HTTPS protocol must be specified.

This chapter describes how to open Panther screens with a URL and which protocol to use in order to transfer the data.

Processing Screen Requests

When the URL reaches the HTTP server, the server passes information about the request to the CGI program named in the URL. This information is contained in a series of environment variables. Three variables facilitate data transfer:

• REQUEST_METHOD

• QUERY_STRING

• CONTENT_LENGTH

The value of REQUEST_METHOD indicates how data in your form is submitted back to the server. Form data can be submitted with two methods: GET and POST. The FORM tag in the HTML document contains a METHOD attribute that indicates which method is used.

If the GET method is used, all form data is passed in the URL. Data input appears as a name=value pairs, which are put into CGI's QUERY_STRING variable. The form's input field name must match the Panther widget or variable name.

Because GET passes all data to the CGI program in a URL, the amount of data that can be passed is limited. For this reason, most forms are submitted back to the server with POST. With POST, the form data appears in standard input and CGI's CONTENT_LENGTH variable determines the amount of data to process. This is the method that Panther uses.

A sample screen in the Panther Gallery uses the GET method to send data to a search engine. This sample entitled Search Engine is accessible from the web application server:

http://server-name/cgi-bin/jwsamp/main

After a Panther web application is started using the monitor command or started as a Windows service, a screen in the application is typically opened by:

• Entering the screen name in a URL.

• Creating a hyperlink to the screen.

Both methods require the screen's URL. URLs (Universal Resource Locator) use the naming convention developed by the World Wide Web to uniquely identify Web resources. The URL that opens a Panther screen contains this information:

• The protocol to use in accessing the server–for example, http or https.

• The Internet domain name for the HTTP server where the resource is stored.

• The port number of the HTTP server. If the port number is 80 (the default value) the port number is not displayed in the URL.

• The programs directory that contains the Panther requester program.

• The name of the Panther requester program. The default name for the CGI version is proweb (or proweb.exe).

• The name of the screen or report.

In the following URL, the HTTP protocol is used to access the server at prolifics.com. The CGI directory, cgi-bin, contains Panther's CGI requester program, vidbiz. This application directory contains the screen entitled main.scr:

http://prolifics.com/cgi-bin/vidbiz/main.scr

The GET method lets you add information in a URL beyond the resource name. Because certain ASCII characters have a specific use in a URL, you might need to encode the additional information so that it is correctly interpreted.

To format the URL correctly, apply the following rules:

• A question mark (?) follows the resource name, before any additional parameters.

• A space in the URL string is indicated by a plus sign (+).

• A percent sign (%) precedes any special characters encoded in hexadecimal notation.

• An ampersand (&) delimits each name=value pair from the next.

• An equal sign (=) separates the input field name from its value in each name=value pair. If nothing has been entered in the input field, the URL string will contain the entry "name=".

Example

The following URL retrieves the vid.scr screen in the vidbiz application:

http://myserver.com/cgi-bin/vidbiz/vid.scr

To pass data values in the URL, use the GET method to submit the form. The data in the form's input fields are included in the URL as name=value pairs. To map those values to a screen, the name of the input field must match the widget name. The following URL sends the values from the title_id and copy_id fields to the vid.scr screen:

http://myserver.com/cgi-bin/vidbiz/vid.scr?title_id=9&copy_id=2

To specify the occurrence number of an input array, place the occurrence number inside a pair of square brackets. The following URL sends the values to the fifth occurrence from a widget of the same name:

http://myserver.com/cgi-bin/vidbiz/vid.scr?title_id[5]=9

If the characters used to format the URL appear in the URL for any other purpose, they must be encoded. Table 4-1 lists common special characters and the hexadecimal value for each character.

In addition to special characters, there are several ASCII characters that can only be present in an encoded format. As with the special characters, the ASCII characters must also be preceded by the percent sign (%). Table 4-2 lists these disallowed ASCII characters along with their encoded format.

Transmitting Screens Securely

Information over the Internet travels through a network of many computer systems, each with the capacity of intercepting the information. In order to add a layer of security to this system, the SSL (Secure Sockets Layer) protocol was developed. SSL provides the features, such as server authentication and data encryption, that are needed to transfer data securely.

Setting Screen Properties

To use SSL in a Panther Web application, you must have a secure HTTP server, specify that HTTP server in the application's initialization file in the HTTPSHOST variable, and set the Secure POST property in Panther screens.

When Panther finds the Secure POST property set to Yes, that screen is submitted using the HTTPS protocol. Panther continues to use the HTTPS protocol until the application opens a screen that has the Secure POST property set to No.

Determining Screen Sequence

Graphical browsers use an icon to indicate whether the HTTPS protocol is in use. For example, Mozilla Firefox displays a lock icon in the address bar when the transmission is secure. However, this icon does not tell how the current screen is to be submitted back to the server; it only shows which protocol was used for the previous submission.

Given this limitation, you might want to build a certain screen sequence into your application surrounding the transmission of secure information. For example, an order entry application has a payment screen where the user enters their credit card information. To transfer this data securely, you might create this screen sequence:

1. After making selections, the user presses a push button to enter payment information.
2. A screen opens explaining that the user is making a secure transmission. The Secure POST property in this screen is set to Yes.
3. The push button on this screen opens the payment screen. The Secure POST property in this screen is also set to Yes.
4. The user enters the payment information and submits this screen back to the server.

By opening an introductory screen whose Secure POST property set to Yes, the user can visually see the secure icon on the payment screen.

Configuring Your Web Application

A Panther application's initialization file must include the variables for screens that are submitted with the HTTPS protocol, which transmits data to a secure server, and the HTTP protocol, which transmits data to an unsecured server.

HTTPHOST

Specifies the server for the HTTP protocol. This variable must be set only if both secure and unsecured servers are operational.

HTTPSHOST

Specifies the server for the HTTPS protocol. This variable must be set in order for the HTTPS protocol to be available.

If the two types of servers are on different hosts, the entries in an .ini file might appear as follows:

HTTPHOST=apphost.com
HTTPSHOST=safeserve.com

Note: Port numbers are not necessary if the default port is used–80 for http, 443 for https.

If the two types of servers are on different domains of the same host, the entries in the .ini file might appear as follows:

HTTPHOST=apphost.myserver.com
HTTPSHOST=safeserve.myserver.com

In order to use server caching, both servers must be able to access a common cache directory. Otherwise, the application must use browser caching.