Subjects -> Computer Networks -> Lectures -> Lecture #20

Lecture 20: Web Commerce #1

CGIs and Web Commerce

FORM-based Web pages and CGI are the key enabling technologies for Web Commerce.

Web sites can sell either tangible goods (merchandise) or content. Important issues include:

Marketing: getting customers to your site, and presenting and selling your product, ultimately convincing them to order something.
Ordering: typically managed by a shopping cart application, see next slide.
Order Processing: check order, verify payment, address, etc. Possibly send customer email confirmation.
Order Fulfilment: packaging, shipping, etc

Shopping Carts

A shopping cart application is a CGI-based set of Web pages which allow a user to browse items, and add them to their "cart" at the click of a button.

The user can (usually) examine and modify the contents of their "cart". When they are ready, they move to a final "commit" page, where they finalise the ordering process, with (for example) a credit card number, shipping address and an email contact address.

Image used with permission of Raven Records, the "THE ULTIMATE IN REISSUES".

State Maintenance -- Hidden Fields

A shopping cart application is more difficult to implement than it may seem. Because the HTTP protocol is stateless, a Web server regards every connection as entirely new, with no relationship to any previous or future connections.

However, a shopping cart application requires persistent state maintenance - each HTML page sent contains information derived from earlier pages.

A hidden field within a form is the simplest way to maintain state. A hidden field is like any other FORM entity; it is simply not displayed by the browser. It can be inspected using, for example, the "View Source" option of the browser, where it will look something like: <input type="hidden" name="sid" value="XYZZY">.

When an initial connection is made to the server, the HTML page which is sent contains the indentifying hidden field value within the page FORM.
A subsequent HTTP CGI request issued by the browser to this server will thus also contain the hidden field.
The CGI which processes the FORM at the server can return the same hidden field to the browser. The hidden field value thus acts as a "session identifier" between the shopping cart application and the browser.

State Maintenance -- Cookies

Whilst hidden fields are a simple technique for state maintenance, they are not a general solution. A cookie is a small piece of information which a server can store "within" a Web browser. For example, the following segment of Perl CGI code sends a cookie:

print "Content-type: text/html", "\n";
print "Set-cookie: MeLove=Cookie%20Monster", "\n\n"
print "<HTML">;.....rest of Web page

This stores "MeLove=Cookie Monster" with the browser. The following Perl CGI code reads a cookie:

print "Cookie:", $ENV{'HTTP_COOKIE'}, "\n";

Each cookie can have several extra attributes:

Name=Value: this attribute is compulsory, and more than one is allowed. Both "Name" and "Value" can be any ASCII string.
expires=DATE: defines the lifetime of the cookie. Default is the current browser session.
domain=DOMAIN: an Internet domain name to which this cookie may be sent.
path=PATH: defines the subset of URLs within a domain for which this cookie is valid and may be sent.

Security and Cookies

Cookies have caused a great deal of debate. The following are some of the issues:

Some users don't like the idea that a Web server can write to their hard disk, however innocuously. In fact, there is no (real) danger in accepting cookies - for example, cookies cannot spread viruses.
Users worry that cookies might be used to send secret information about them to a server. In fact, the cookie which is returned is exactly the same as that which was sent.
Users are concerned that other Web servers might find out information about you by reading cookies set by different servers. In fact, browsers follow very strict rules to ensure that cookies are only returned to the server (and/or specific CGI program) which originally sent them.
Users worry that Web servers can track their "click-through" behaviour using cookies. In fact, this is true, and is a potential privacy issue.
Browsers allow the user to turn off acceptance of cookies, and some users do this. Therefore a shopping cart application cannot rely on the existence of cookies to maintain state information.

Some sites with useful information on cookies include:

State Maintenance and Sessions

Most modern Web Commerce sites use the concept of a Web session -- a series of Web requests and responses linked together by a state variable called a session identifier. A first visit to the sites "home page" creates a new session, and the HTTP response is associated with a new session identifier, or SID. All subsequent transactions are labelled with the same SID.

The session identifier is commonly generated as some combination of the current time, the IP address of the client, or maybe just as a random number.
Session management can be rather messy on the server, since information must be maintained about all "current" sessions, and decisions must be made as to the deletion of "expired" sessions.
The SID must (obviously) be passed back and forward between the server and the browser on every transaction. Modern practice is to use a "belt-and-braces" approach here, with the information duplicated in hidden fields, cookies (which may be disabled in the browser) and also in dynamically-generated Extra Path Information URLs. For example, the CDnow page on your lecturer's browser at this instant has the URL (some sections deleted to fit): http://www.cdnow.com/cgi-bin/mserver/SID=1391321707 It's obvious that every URL in the page has to have exactly the same information, and a quick "View Source" verfies this. At this particular site, the same information is also sent as a cookie, although hidden fields are (apparently) not used.

CGI and Database Integration

A shopping cart application almost certainly needs a "back end" database to store product and inventory information, as well as transaction records of purchases, etc. There are several options:

For "small scale" operations, this can be done using simple text files. Many Unix utilities are designed to manipulate data stored in files of this type, and Perl is very well suited to the job. These utilities can be "glued" together to build quite advanced systems.
If the task is sufficiently large or complex, there are many "low end" cheap, or free, database solutions. In this case, the CGI program interfaces to the database, normally by sending SQL queries. The standard Perl database access module is DBI::, which interfaces to virtually all DMBSs in a standardises way. The current defacto Web DBMS is probably mySQL, but lots of others are available.
Proprietory databases such as Microsoft "Access" can be used in conjunction with an associated proprietory Web server such as IIS. Perl's CBI:: can also talk to most of these.
At the "big end" of town, companies like Oracle are positioning themselves as major Web database vendors.

Java (and JavaScript) Applications in E.Commerce

The Java and Javascript languages execute programs or applets in the browser. However, since not all browsers will necessarily have this functionality, it's doubtful whether a Web Commerce system should utilise them -- certainly they shouldn't depend on them. Nevertheless, they can be useful:

Interactivity can, if well done, make a page more attractive to some users.
A Java applet can communicate with the server using other protocols than HTTP. This opens up a range of possibilties.
An applet (or a Javascript program) can be used to check FORM information for consistency and completeness before allowing it to be sent to the server. For example:
- check if all important TEXT boxes have been filled in.
- perform limited syntax check of email addresses, phone numbers, addresses, etc.
- check credit card numbers for correctness (prefix and checksum)

The tutorial for this lecture is Tutorial #20.
La Trobe Uni Logo

[Previous Lecture] [Lecture Index] [Next Lecture]