Web Development


Chapter 4 . Opening Screens

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

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:

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

Specifying a URL

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:

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:

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

Encoding Parameters in the URL

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:

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

Encoding ASCII Characters

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.

Table 4-1 Special characters in URLs

Special Characters Hexadecimal Representation

#

%23

/

%2F

?

%3F

=

%3D

&

%26

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.

Table 4-2 ASCII characters that are disallowed in URLs

Character Hexadecimal representation

TAB

%09

SPACE

%20

"

%22

<

%3C

>

%3E

%5C

^

%5E

{

%7B

}

%7D

[

%5B

]

%5D

\Q

%60

|

%7C

~

%7E


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.