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

Lecture 20: Web Commerce Technologies

Server-Side Programming and Web Commerce

FORM-based Web pages and Web "server-side" programming are the key enabling technologies for Web Commerce. The most common server-side programming technology has been the Common Gateway interface (CGI), commonly using the Perl programming language, but this is gradually changing.

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 server-side dynamically generated 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.
Subsequent FORM submission from the browser to this server will thus also contain the hidden field.
The server-side program 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 server-side code sends a cookie to the browser:

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 a (very) large random number possibly combined with a (hashed) combination of the some other client information -- maybe the IP address of the client.
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 could 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.

Internet Payment Systems

One of the most difficult issues in Web Commerce is setting up a method of collecting monetary payment. Since the early days of the Web, this has attracted a great deal of theorietical interest (eg, this 1997 PDF report on Micropayments), but in the end the "traditional" payment modes (ie, credit card companies) have mostly dominated.

Approaches to Payment: Use a third-party payment "clearing house" service, eg WorldPay, DirectOne.; Direct merchant relationship with bank -- uses bank-supplied "back-end" software.; "New" approaches, eg PayPal.
Issues: Risk of credit-card fraud; Where is the transaction information stored?; Cost issues: may be as high as 2.5% to 5% of transaction.

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

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