Chapter 9

Internet Applications
M. L. Liu
01/13/24 Distributed Computing, M. L. Liu 1

The World Wide Web
By far the best known distributed application is the
World Wide Web (WWW), or the Web for short.
Technically, the web is a distributed system of HTTP
servers and clients, more commonly known as web
servers and web browsers.
Prior to the emergence of the web, the user community
of the Internet largely comprised of researchers and
academics who used network services such as electronic
mail and file transfer to exchange data.
The World Wide Web originated with Tim Berners-Lee
in late 1990 for CERN, the European Particle Physics
Laboratory in Geneva, Switzerland. A proposal for a
"universal hypertext system" was submitted in
November 1990 by Tim Berners-Lee and Robert
Cailliau for a "universal hypertext system."

The World Wide Web
Since the original proposal, the growth of the World-Wide Web
has been extraordinary (see Figure 1), and has expanded far
beyond the research and academic community into all sectors
world-wide, including commerce and private homes. The
continued development of the Web technology is currently
coordinated by the World-Wide Web Consortium, W3C.

The World Wide Web
The genius of the World-Wide Web is that it
combines three important and well-established
computing technologies:
 Hypertext documents: documents in which chosen words or
phrases, typically highlighted, can be marked as links to other
documents, so that a user is able to access the linked documents
by clicking with a mouse on the highlighted text.
 Network based information retrieval: the File Transfer Protocol
(FTP) service was the most widely used service for such
information retrieval.
 Standard Generalized Markup Language (SGML), an ISO
standard which allows documents to be “marked up” with tags so
that they can be displayed in a uniform format on any platform,
independent of the presentation mechanics.

The World Wide Web
At its most basic, the World-Wide Web is a client-
server application based on a protocol named the
HyperText Transfer Protocol (HTTP).
A web server is a connection-oriented server that
implements the HTTP. By default, an HTTP server
runs at the well-known port 80.
A user runs a World-Wide Web client (sometimes
referred to as a browser) on a local computer. The
client interacts with a web server according to the
HTTP, specifying a document to be fetched. If the
document is located by the server in its directory, the
document’s contents is returned to the client, which
presents the it to the user.

The Hypertext Markup Language (HTML)
HTML is a markup language used to create
documents that can be retrieved using the World
Web Web.
HTML is based on SGML, with semantics that are
appropriate for representing information of a wide
range of types. HTML markup can represent
hypertext news, mail, documentation, and
hypermedia; menus of options; database query
results; simple structured documents with in-lined
graphics; and hypertext views of existing bodies
of information.

HTML
<HTML>
<HEAD>
<TITLE>A Sample Web Page</TITLE>
</HEAD>
<HR>
<BODY>
<center>
<H1>My Home Page</H1>
<IMG SRC="/images/myPhoto.gif">
<b>Welcome to Kelly's page!</b>
<p>
<! A list of hyperlinks follows.>
<a href="/doc/myResume.html"> My resume</a>.
<p>
<a href="http://www.someUniversity.edu/">My university<a>
</center>
<HR>
</BODY>

The Extensible Markup Language XML
Whereas HTML is a language that allows a document
to be marked up for the presentation or display of the
information contained in a document, XML allows a
document to be marked up for structured information.
Also based on SGML, XML uses tags to describe the
information contained in a document.
<message>
<to>you@yourAddress.com</to>
<from>me@myAddress.com</from>
<subject>This is a message</subject>
<text>
Hello world!
</text>
</message>

HTTP

The HyperText Transfer Protocol (HTTP)
Originally conceived for fetching and displaying text
files, HTTP has been extended to allow the transfering
of web contents of virtually unlimited types.
The first version of HTTP, HTTP/0.9, was a simple
protocol for raw data transfer.
The most widely used HTTP version is HTTP/1.0,
which has a draft proposed by Tim Berners Lee[13],
but has no formal specification, although its ``common
usage'' is described in RFC1945[8].
Since then, an improved protocol, known as HTTP/1.1,
has been developed and often adopted. HTTP/1.1 is a
far more extensive protocol than HTTP/1.0. However,
the basics of the protocol is well represened in the
simpler HTTP/1.0.

HTTP is a connection-oriented, stateless,
request-response protocol.
An HTTP server, or web server, runs on
TCP port 80 by default.
HTTP clients, colloquially called web
browsers, are processes which implements
HTTP to interacts with a web server to
retrieve documents phrased in HTML,
whose contents are displayed according to
the documents’ markups.
In HTTP/1.0, each connection allows only one
round of request-response.
A client obtains a connection, issues a request
The server processes the request, issues a
response, and closes the connection thereafter.
w eb s erv er w eb b r o w s er
req u es t is a m es s ag e in 3 p arts :
req u es t
- < c o m m an d > < d o c u m en t ad d d res s > < HT T P v ers io n >
- an o p tio n al h ead er
- o p tio n al d ata fo r C G I d ata u s in g p o s t m eth o d
res p o n s e res p o n s e is a m es s ag e c o n s is tin g o f 3 p arts :

- a s tatu s lin e o f th e fo r m at < p ro to c o l> < s tatu s c o d e> < d es c rip tio n >
- h ead er in fo rm atio n , w h ic h m ay s p an s ev eral lin es ;
- th e d o c u m en t its elf.

HTTP is text-based: the request and

responses are character strings.
Each request and response is composed of
these parts, in order:
1) The request/response line
2) A header section
3) A blank line
4) The body

A sample HTTP session
Script started on Tue Oct 10 21:49:28 2000
9:49pm telnet www.csc.calpoly.edu 80
Trying 129.65.241.20...
Connected to tiedye2-srv.csc.calpoly.edu.
Escape character is '^]'.
GET /~mliu/ HTTP/1.0 HTTP Request
HTTP/1.1 200 OK HTTP response status line

Date: Wed, 11 Oct 2000 04:51:18 GMT HTTP response header
Server: Apache/1.3.9 (Unix) ApacheJServ/1.0
Last-Modified: Tue, 10 Oct 2000 16:51:54 GMT
ETag: "1dd1e-e27-39e3492a"
Accept-Ranges: bytes
Content-Length: 3623
Connection: close
Content-Type: text/html
<HTML> document content

<HEAD>
<TITLE> Mei-Ling L. Liu's Home Page
</TITLE>
</HEAD>
<BODY bgcolor=#ffffff>
…

The HTTP request
A client request is sent to the server after the client has
established a connection to the server.
A request line is of the following form:
<HTTP method><space><Request-URI><space><protocol
specification>\r\n
where
 <HTTP method> is the name of a method defined for the
protocol,
 <Request-URI> is the URI of a web document, or, more
generally, a web object,
 <protocol specification> is a specification of the
protocol observed by the client, and
 <space> is a space character.
An example client request is as follows:

GET /index.html HTTP/1.0

HTTP Methods in a client request
The HTTP method in a client request is a reserved
word (in uppercase) which specifies an operation of the
server that the client desires.
Some of the key client request methods are listed
below:
~ GET: for retrieving the contents of web object referenced by
the specified URI
~ HEAD: for retrieving a header from the server only, not the
object itself.
~ POST: used to send data to a process on the server host.
~ PUT: used to request the server to store the contents enclosed
with the request to the server machine in the file location
specified by the URI.

The Request Header
“The request header fields allow the client
to pass additional information about the
request, and about the client itself, to the
server. These fields act as request modifiers,
with semantics equivalent to the parameters
on a programming language method
(procedure) invocation.”
A header is composed of one or more lines,
each line in the form of
<keyword>: <value>\r\n
The Request Header
Some of the keywords and values that may appear
in a request header are:
 Accept: content types acceptable by the client
 User-Agent: specifies the type of browser
 Connection: “Keep-Alive” can be specified so that the
server does not immediately close a connection after
sending a response.
 Host: host name of the server
An example request header is as follows:
Accept: */*
Connection: Keep-Alive
Host: www.someU.edu
User-Agent: Generic

Request Body
A request optionally ends with a request
body, which contains data that needs to be
transferred to the server in association with
the request.
For example, if the POST method is
specified in the request line, then the body
contains data to be passed to the target
process. (This is an important feature and
will become clearer when we discuss CGI,
servlet, and SOAP.)
Examples of a complete client request
Example1:
GET / HTTP/1.1
<blank line>
Example2:
HEAD / HTTP/1.1
Accept: */*
Host: somehost.com
User-Agent: Generic
<blank line>

Examples of a complete client request
Example3:
POST /servlet/myServer.servlet HTTP/1.0
Accept: */*
Host: somehost.com
User-Agent: Generic
<blank line>
Name=donald&email=donald@someU.edu

The HTTP Server Response
In response to a request received from a
client, the HTTP server sends to it a
response.
Like the request, an HTTP response is
composed of these parts, in order:
1.The response or status line
2. A header section
3. A blank line
4. The body

The response status line
The status line is in the form of:
<protocol><sp><status-code><sp><description>\r\n
The status code designations are as follows:
100-199 Informational
200-299 Client request successful
300-399 Client request redirected
400-499 Client request incomplete
500-599 Server errors
Example 1:
HTTP/1.0 200 OK
Example 2:
HTTP/1.1 404 NOT FOUND

HTTP Response Header
The status line is followed by a response
header. A response header is composed of
one or more lines, each line in the form of
<keyword>: <value>\r\n
There are two types of response header
lines:
1. Response header lines
2. Entity header lines

Response header lines – these header
lines return information about the
response, the server, and further
access to the resource requested, as
follows:
Age: seconds
Location: URI
Retry-After: date|seconds
Server: string
WWW-Authenticate: scheme realm

Entity header lines – these header
lines contain information about the
contents of the object requested by the
client, as follows:
Content-Encoding
Content-Length
Content-Type: type/subtype (see
MIME)
Expires: date
Last-Modified: date

An Example response header is as follows:
Date: Mon, 30 Oct 2000 18:52:08 GMT
Last-modified: Mon, 17 June 2001 16:45:13 GMT
Content-Length: 1255
Connection: close
The Content-Type specifies the type of the data, using the contents
type designation of the MIME protocol.
The Content-Encoding specifies the encoding scheme (such as
uuencode or base64) of the data, usually for the purpose of data
compression.
The expiration date gives the date/time (specified in a format defined
with HTTP)after which the web object should be considered stale
The Last-Modifed date specifies the date that the object was last
modified.

HTTP Response Body
The body of the response follows the header and a
blank line, and contains the contents of the web
object requested.
HTTP/1.1 200 OK
Date: Sat, 15 Sep 2001 06:55:30 GMT
Last-Modified: Mon, 30 Apr 2001 23:02:36 GMT
ETag: "5b381-ec-3aedef0c"
Accept-Ranges: bytes
Content-Length: 236
Connection: close
<html>
<head>
<title>My web page </title>
</head>
<body>
Hello world!
</BODY></HTML>

Content Type – MIME Protocol

Content Type and the Mime Protocol
One of the header lines returned in a server
response is the Contents Type of the object
requested.
Specification of the contents type follows the
scheme established in a protocol known as
MIME (Multipurpose Internet Mail Extension.)
Originally used for Email, MIME is now widely
used for describing the content of a document
sent over a network.
It supports a large number and evolving set of
predefined content types, specified in the format
Type/Subtype.

The Mime Protocol
A small subset of the types and subtypes are:
Type Subtype
text plain, rich text, html, tab-separated-values, xml
message Email, news
Application Octet-stream (can be used for transferring Java .class files, for example), Adobe-postscript, Mac-
binhex40, xml
image jpeg, gif
audio basic,midi,mp3
video mpeg, quicktime

Simple implementations of an
HTTP Client

A Basic HTTP Client implememtation
InetAddress host =
InetAddress.getByName(args[0]);
int port = Integer.parseInt(args[1]);
String fileName = args[2].trim();
String request =
"GET " + fileName + " HTTP/1.0\n\n";
MyStreamSocket mySocket =
new MyStreamSocket(host, port);
mySocket.sendMessage(request);
// now receive the response from the HTTP server
String response = mySocket.receiveMessage();
// read and display one line at a time
while (response != null) {
System.out.println(response);
response = mySocket.receiveMessage();
}

The Java URL Class
The Java API provides a class called URL
specifically for retrieving the data from a
web object identified using a URI.
Method/Constructor Description
URL(String spec) Creates a URL object from the URL name contained in a String
.
URL(String protocol,String host, Creates a URL object from the specified protocol, host, port
int port,String file) number, and file.
InputStream openStream( ) Opens a connection to this URL and returns an InputStream for
reading from that connection.

The URLBrowser
String host = args[0];
String port = args[1].trim();
String fileName = args[2].trim();
String HTTPString =
"http://"+host+":"+port+"/"+fileName;
URL theURL = new URL(HTTPString);
InputStream inStream = theURL.openStream( );
BufferedReader input =
new BufferedReader
(new InputStreamReader(inStream));
String response = input.readLine();
// read and display one line at a time
while (response != null) {
System.out.println(response);
response = input.readLine();
} //end while
Characteristics of HTTP

HTTP is a Connection-Oriented Protocol
With HTTP1.0, a connection to a server is
automatically closed as soon as the server
returns a response. Thus exactly one round
of exchange is allowed between a client and
a web server; if a client needs to contact the
same server in one session, it must
reconnect to the server to reissue another
request.

The scheme is adequate for the original
intent of HTTP for retrieving simple
network documents.
It is inefficient for documents such as those
that contain a large number of links to
image objects to be fetched by the server,
since fetching each of these links require a
reestablishment of a connection.
It is also insufficient fors ophisticated web
applications based on HTTP (such as
shopping carts).
HTTP is a stateless Protocol
HTTP 1.0 (as well as version 1.1) is also a
stateless protocol: the server does not maintain
any state information on a client’s session.
Regardless of whether the connection is kept alive,
each request is handled by a server as a new
request. As with non-persistent connectons
originally in practice with HTTP, a stateless
protocol is adequate for the original intent of the
protocol, but not so for the more complex
applications for which HTTP has been extended,
the next topic that we will study.

HTTP1.0 was extended to allow a request
header line Connection: Keep-Alive to be
issued by a client who wishes to maintain a
persistent connection with the server; a
cooperating server will keep the connection
open after sending a response. In HTTP/1.1,
connections are persistent by default. Such
a connection allows multiple requests to be
send over the same TCP connection.

Dynamically generated web
contents

Dynamically-generated Web Contents
In the beginning, HTTP was employed to
transfer static contents, that is, contents that
exist in a constant state, such as a plain text
file or an image file.
As the web evolved, applications began to
use HTTP for a purpose not originally
intended: an application which allows a
browser user to retrieve data based on
dynamic information entered during an
HTTP session.
Dynamicly-generated Web Contents
A typical web application, such as a shopping cart, requires fetching
remote data based on data entered by a client at runtime.
For example, an enterprise application typically allows a user to key in
data, which is then used to formulate a query to retreive data from a
database, and the outcome is displayed to the user.
Applied to the web, it is desirable to allow a client to submit data
during a web session to retrieve data from the web server host, to be
W e b s e rv e r h o s t
displayed by the web browser W e b clie n t h o s t
we b s e rv e r we b clie n t
"id = 1 2 3 4 5 "
"in c o m e= 3 0 0 0 0 "
" id = 1 2 3 4 5 "
" in c o m e = 3 0 0 0 0 "
da ta ba s e s y s te m

A generic HTTP server does not possess the
application logic for fetching the data from the
data source.
Instead, an external process that has the
application logic will serve as an intermediary.
The external process runs on the server host,
accepts input data from the web server,
exercises its application logic to obtain data
from the data source, returns the outcome to
the web server, which transmits the outcome
to the client.

The first widely adopted protocol to augment
HTTP in supporting run-time generated web
contents is the Common Gateway Interface
(CGI) protocol.
Although rudimentary by comparison, CGI is
the predecessor of more sophisticated
protocols and facilities (such the Java
Servlet) that serve similar purpose.
The understanding of CGI and some of its
supplementary protocols is important in that it
prepares us for the understanding of more
advanced protocols and facilities.

The Common Gateway Interface
(CGI) Protocol

Common Gateway Interface (CGI)
The Common Gateway Interface (CGI) is a standard for
providing an interface, or a gateway, between an
information server and an external process (that is, a
process external to the server).
Using the protocol, a web client may specify a program,
known as a CGI script, as the target web object in an
HTTP request.
The web server fetches the CGI script, activates it as a
process, passing to the process input data transmitted by
the web client. The web script executes and transmits its
output to the web server, which returns the web-script
generated data as the body of a response to the web client.

CGI - 2
An HTTP request may specify a CGI program, or CGI
script.
A CGI program can be written in:
 Programming languages: C. Ada, C++, Fortran; such a
program needs to be compiled to generate an
executable.
 Script languages such as Perl, Tkl, cobra, such a
program, referred to as a CGI script, requires the
appropriate language interpreter to be present at the
server host.
 Commonly used for processing user input from HTML
forms, and subsequently composing a web page sent as
part of the server response.

CGI Program - 3
When a web server receives a request
whose URI specifies a web program, the
web server initiates the execution of the
web program.
The web program formulates its output in
HTML, which is sent to the server and
forwarded to the web client as the HTTP
response.

CGI program
s e rve r h os t clie n t h os t
C GI program HTTP s e rve r

HTTP clie n t
re qu e s t
re s pon s e

Action field in a web page
A web script can be specified in an action field of
a web page. When the web page is submitted, an
HTTP request is issued by the browser specifying
the web script as the URI:
<HTML>
<HEAD>
<TITLE>A Simple Web Page which illustrates CGI</TITLE>
</HEAD>
<BODY>
<FORM ACTION="Hello.cgi">
<CENTER>
Click on the SUBMIT button to activate
the CGI script Hello.cgi:<br>
<INPUT TYPE="Submit" NAME="submit" VALUE="SUBMIT">
</CENTER>
</FORM>
</BODY>
</HTML>

Common Gateway Interface (CGI)
W e b s e rv e r h o s t
we b clie n t h o s t
HT T P s erv er
C G I s c rip t
w eb c lien t
req u es t fo r h ello .h tm l
c o n ten ts o f h ello .h tm l
req u es t fo r h ello .c g i
d ata, if an y , fro m th e c lien t
HT T P s erv er res p o n s e, in c lu d in g d y n am ic ally g en erated w eb p ag e

A sample web page (hello.html) which invokes a CGI script
<HTML>
<HEAD>
<TITLE>A web page which invokes a web script</TITLE>
</HEAD>
<BODY>
<H1>This web page illustrates the use of a web script</H1>
<P>
<BR>
The script or program is either a run-script written in a
script language such as Perl, or an executable generated
from a source program written in a language such as C/C++.
</P>
<HR>
<FORM METHOD="post" ACTION="hello.cgi">
<HR>
Press <input type="submit" value="here"> to submit your query.
</FORM>
<HR>
</BODY>
</HTML>
A sample web script hello.c
/**
* This C program is for a CGI script which generates
* the output for a web page. When displayed by a
* browser, the message "Hello there!" will be shown
* in blue.
*/
#include <stdio.h>
main(int argc, char *argv[]) {

printf("Content-type: text/html%c%c",10,10);
printf("<font color = blue>");
printf("<H1>Hello there!</H1>");
printf("</font>");
}

A sample web script hello.pl
#!/usr/local/bin/perl
# A simple Perl CGI script
print "Content-type: text/html\n\n";
print "<head>\n";
print "<title>Hello, World</title>\n";
print "</head>\n";
print "<body>\n";
print "<font color = blue>\n";
print "<h1>Hello, World</h1>\n";
print "</font>\n";
print "</body>\n";

Web forms

A Web Form
You may have noticed that the “hello” example
presented does not make use of any user input, and
the contents of the dynamically generated web
page is predeterminable. This is because the
example is provided as an overview of the CGI
protocol.
In practice, a CGI script is typically invoked by a
special kind of web page known as a web form, to
be described in the next section, which accepts
input at run time, and invokes a CGI script which
makes use of such input. We will next look at the
the CGI

A web form
A web form is a special kind of web page
which
 provides a graphical user interface that prompts
input data from a user
 invokes the execution of an external program
on the web server host, when a submit button
on the page is pressed by the user
See form.html

A web form
The code that generates a web form is enclosed between the HTML
tags <FORM> ... </FORM>
Within the <FORM> tag attributes can be specified to provide
additional information related to the CGI protocol, including:
~ ACTION=<a character string containing the absolute or relative
URL of the identification of the external program which is to be
initiated by the web server when the form is submitted>
~ METHOD=<a reserved word, POST or GET, which specifies
the manner that the external program expects to receive from the
web server the collection of data submitted by the user, called
the query data.>
FORM METHOD="post" ACTION="form.cgi”

A web form
In the coding for the form, each of the input items (also called an input
elements) has a NAME tag.
For each of these items, the browser user enters or selects a value.
What is thy NAME: <INPUT NAME=“name"><P>
What is thy favorite color:
<SELECT NAME="color">
The collection of the data for the input items is a character string, called
a query string, of name=value pairs separated by the & character.
name=John%20Chen&color=red
Each name=value pair is encoded using URL-encoding, so that some
“unsafe” characters (such as spaces,quotes, %, and &) are mapped to a
hexadecimal representation.
For example, the value string
“The return is >17%” is encoded as “The%20return%20is
%20%3E17%25”.

A Web Form Query String
An example of a query string for the example form is:
name=John%20Doe&quest=peace%20on
%20earth&color=azure
&swallow=continental&text=The%20return%20is
%20%3E17%25 (all on one line)
The collection of the data into a query string, including the
encoding of the values, is performed by the browser.
When the form is submitted by the user, the query string
is passed to the server in the HTTP request, in a manner
depending on the FORM METHOD specified in the form.
The query string is then forwarded by the server to the
external program.

Web Form Query String Processing
Based on the form input, the browser
assembles the query string.
The string is transmitted to the web server,
which in turn passes it on to the external
program (the CGI script named in the
form).
The manner that the string is transmitted
depends on the specification of the FORM
METHOD in the web form.

FORM GET Method – browser to server
If GET is specified with the FORM METHOD tag, the
query string is transmitted to the server in a HTTP request
with a GET method line.
<FORM METHOD=“get" ACTION=“getForm.cgi">
Recall that an HTTP GET request specifies a URI for the
web object requested by the client. To accommodate the
query string, the syntax for the URI specification was
extended to allow the attachment of the query string to the
end of the URI (for the CGI script), delimited by the ‘?’
character, as, for example:
GET /cgi/getForm.cgi?name=John%20Doe&quest=peace HTTP/1.0
Since the length of the GET Request-URI line is limited,
the length of the query string that can be appended in this
manner is also limited. Hence this method is not suitable
if the form needs to send a large amount of data, such as
data in a text box.
Form GET method – server to external program
The server invokes the CGI script and passes on the query
string that it received from the browser, as appended to the
URI in the HTTP request.
The CGI program, or the external program in general, will
receive the encoded form input in an environment variable
called QUERY_STRING.
Environment variables are variables maintained by the
operating system of the server host.
The CGI program retrieves the query string from the
environment variable, decode the character string to obtain
the name-value pairs, and uses the parameters during the
execution of the program to generate output phrased in
HTML.

The getForm example
See:
getForm.html
getForm.c

>telnet www 80
Trying 129.65.241.7...
Connected to tiedye-srv.csc.calpoly.edu.
GET /~mliu/form/getForm.cgi?name=Donald HTTP/1.0
HTTP/1.1 200 OK
Date: Sun, 24 Feb 2002 22:30:55 GMT
Connection: close
<body bgcolor="#CCFFCC"><h2>This page is generated dynamically by

getForm.cgi.</
h2><H1>Query Results</H1>You submitted the following name/value
pairs:<p>
<ul>
<li> <code>name = Donald</code>
</body></html>Connection closed by foreign host.

FORM POST Method – browser to server
If POST is specified with the FORM METHOD tag, the query string
is transmitted to the server in a HTTP request with a POST method
line previous described.
<FORM METHOD=“post" ACTION=“postForm.cgi">
Recall that an HTTP POST request is followed by a request body,
which holds text contents to be sent to the server. Using the POST
METHOD, the URI of the CGI script is specified with the POST
request line, followed by the request header, a blank line, then the
query string, as, for example:
POST /cgi/postForm.cgi HTTP/1.0
Accept: */*
Host: myHost.someU.edu
User-Agent: Generic
name=John%20Doe&quest=peace%20on%20earth&color=azure
Since the length of the request body is unlimited, the query string can
be of arbitrary length. Hence the POST method can be used to send
any amount of query data to the server.
Form POST method – server to external program
The server invokes the CGI script and passes on the query
string that it received from the browser via the request
body.
The CGI program, or the external program in general, will
receive the encoded form input on the standard input.
“The server will NOT send you an EOF on the end of the
data, instead you should use the environment variable
CONTENT_LENGTH to determine how much data you
should read from (the standard input).”
The CGI program reads the query string from the standard
input, decode the character string to obtain the name-value
pairs, and uses the parameters during the execution of the
program to generate output phrased in HTML.

The postForm example
See:
postForm.html
postForm.c

>telnet www 80
Trying 129.65.241.7...
Connected to tiedye-srv.csc.calpoly.edu.
POST /~mliu/form/postForm.cgi HTTP/1.0
Content-type: application/x-www-form-urlencoded
Content-length: 11
name=Donald
HTTP/1.1 200 OK
Date: Sun, 24 Feb 2002 22:52:33 GMT
Connection: close
<body bgcolor="#FFFF99"><H1>Query Results</H1>You submitted the following

name/v
alue pairs:<p>
<ul>
<li> <code>name = Donald</code>
</body></html>Connection closed by foreign host.

Encoding and decoding query strings
Whether a query string is obtained from the
QUERY_STRING environment variable, or from the
standard input, the CGI program must decode the string
and extract the name-value pairs from it, so that the
parameters may be used for the program’s execution.
Due to the popularity of CGI programs, there are a number
of existing libraries or classes that provide
routines(functions) and methods for this purpose. For
example, Perl has easy-to-use procedures in a library
called CGI-lib for the decoding and for extracting the
name-value pairs into a data structure called an associative
array; and NCSA provides a library of C routines for the
same purpose.
See getForm.c, postform.c

Environment Variables used with CGI
An environment variable defines is a parameter of
a user's working environment on a computer
system, such as the default directory path for the
system to locate a program invoked by the user.
On a computer system, environment variables are
used across multiple languages and operating
systems to provide information to applications that
may be specific to a user.
CGI uses environment variables that are set by the
HTTP server to pass information about requests
from the server to the external program (CGI
script).

Environment Variables used with CGI
Some of the key environment variables related to
CGI are listed below:
~ REQUEST_METHOD: The method with which the
request was made. For CGI, this is "GET" or "POST".
~ QUERY_STRING: If the GET method was specified
in the form, this variable contains a character string for
the form data.
~ CONTENT_TYPE: the content type of the data, which
should be “application/x-www-form-urlencoded” for a
query string
~ CONTENT_LENGTH : The length of the query
string.

Web Session State Data

Web Session and session state data
During a session of a web application such
as a shopping cart, several HTTP requests
are issued, each of which invokes an
external program such as a CGI script.
we b s cript
we b s cript W e b s e rve r B rows e r
form .cgi
form 2.cgi
req u es t fo r fo rm .h tm l
fo rm .h tm l
fo rm .c g i?id = 1 2 3 4 5
id = 1 2 3 4 5
fo rm 2 .h tm l(d y n am ic )
fo rm 2 .h tm l (d y n am ic )
fo rm 2 .c g i?b u y = T V
buy=T V
"c u s to m er 1 2 3 4 5 h as a T V in s h o p p in g c art"
"c u s to m er 1 2 3 4 5 h as a T V in s h o p p in g c art"

Web Session and session state data
Note that in our example it is necessary for the second CGI
script, form2.cgi, to have knowledge of value of the data
item id in the query string sent to the first CGI script,
form1.cgi.
However, the two web scripts are two separate programs
and are executed by the web server independently.
Data that needs to be shared among CGI scripts invoked
successively during a web session are called session state
data.
There is no provision in HTTP nor CGI to allow for such
sharing, as both of these protocols are stateless and do not
support the notion of a session.

Session Data Sharing Mechanisms
Because of the popularity of Internet
applications, a variety of mechanisms have
emerged to allow the sharing of session data
among CGI scripts (and other external
programs).
These mechansims can be classified as
follows:
 Server-side facilities
 Client-side facilities

Server-side facilities for session state data
secondary storage (file or database) on the
server host may be used as a repository of
session state data
software objects which may be employed as
state data repository: java beans, session
objects, application context state data
objects.

Client-side facilities for session state data
An ingenious idea for maintaining session state data is to maintain the
data through the web client.
Since each session is associated with a single client, this scheme
allows the state data to be maintained in a decentralized fashion.
Specifically, the scheme allows the state data to be passed from a web
script to the web client, which passes the data to a subsequent web
script. The data passing can be repeated throughout the duration of the
web session.
S e rv e r h o s t C lie n t h o s t
C GI we b
we b clie n t
s cript 1 s e rv e r i d =1 2 3 4 5
C GI
s cript 2 i d =1 2 3 4 5
i d =1 2 3 4 5 & b u y =TV
C GI
s cript 3 i d =1 2 3 4 5 & b u y =TV
i d =1 2 3 4 5 & b u y - TV & c h a r g e =5 0 0 .3 5

Client-side facilities for session state data
Two schemes which makes use of client-
side facilities to maintain session data:
~ HIDDEN FORM fields: this scheme embeds
session state data in dynamically generated web
forms
~ cookies: this mechanism uses transient or
persistent storage on the client host to hold state
data, which is passed in the HTTP request
header to web scripts that require the data.

Maintaining state data using
hidden form fields

Using HIDDEN FORM Fields
A hidden form field or a hidden field is an INPUT
element in a web form specified with
`TYPE=HIDDEN'.
Unlike other other INPUT elements, a hidden
field is not displayed by the browser and requires
no input. Rather, the value of the element is the
VALUE attribute specified with the field, and the
name-value of the field is collected by the
browser, along with the name-value pairs of other
INPUT elements, in the query string when the
form is submitted.

W e b fo rm s Q u e ryS trin g
fo r m .htm l
...
< F O R M M E T H O D = P O ST A C T I O N = " /c gi- bin /f o r m 1 .c gi"
...
< I N P U T n a m e = " Y o ur N a m e " >
Yo urnam e = J o hn B ro wn
fo r m 1 .c g i
...
p ir n t f ( " < I N P U T n a m e = Y o ur I D > " ;
p r in t f ( " < I N P U T T Y P E = " H I D D E N " N A M E = % s VA L U E = % s> " , e n t r ie s[ 0 ] .n a m e , e n t r ie s[ 0 ] . v a l) ;
...
Yo urID = 1 2 3 4 5 & Yo urN am e = J o hn B ro wn
fo r m 2 .c g i
...
p r in t f ( " < I N P U T T Y P E = " H I D D E N " N A M E = " Y o ur N a m e " VA L U E = " Jo h n B r o wn " > " ) ;
...
Yo urID = 1 2 3 4 5 & Yo urN am e = J o hn B ro wn

The first web script form.cgi generates the element
<input type=hidden name=id value="l2345">
in the dynamically generated form2.html.
form2.html, when presented by the browser, will not
display this field, but another input field is displayed
which prompts for a purchase.
When form2.html is submitted, the query string
“id=12345&buy=tv” is sent to the second web form,
form2.cgi.
When the query string is decoded, the value of the state
data item id becomes available to form2.cgi.

we b s cript
we b s cript W e b s e rv e r B ro ws e r
fo rm .cg i
fo rm 2 .cg i
r e que st f o r f o r m .h t m l
f o r m .h t m l
f o r m .c gi? id= 1 2 3 4 5
id= 1 2 3 4 5
f o r m 2 .h t m l c o n t a in s
< in p ut t y p e = h idde n n a m e = id v a lue = " l2 3 4 5 " >
f o r m 2 .h t m l ( dy n a m ic )
f o r m 2 .c gi? id= 1 2 3 4 5 & buy = T V

id= 1 2 3 4 5 & buy = T V
" c ust o m e r 1 2 3 4 5 h a s a T V in sh o p p in g c a r t "

" c ust o m e r 1 2 3 4 5 h a s a T V in sh o p p in g c a r t "

The hidden field is a rudimentary scheme for
maintaining session data. It has the merit of
simplicity, requiring only the introduction of a new
form field element and no additional resources on
either the server-side or the client-side.
In the scheme, the HTTP client becomes a
temporary repository for the state information, and
the session data is sent using the normal
mechanisms for transmitting query strings.
The simplicity of the scheme comes at the cost a
security risk, in the sense that the state data
transmitted using hidden form field is unprotected.

Although a hidden input element is not displayed
by the browser, it is embedded in the source code
of the dynamically generated web page
form2.html, which is plainly viewable by any
browser user who exercises the view-source
capability provided by the user. Hence the
scheme allows data to become exposed, and
therefore poses a security risk.
Hidden fields should not be used to transmit
sensitive data such as an identification or account
balances.

Example code of using hidden fields to pass state data
See files in the CGI/hiddenFields folder of

the program samples:
 Form.html
 hiddenForm.c
 hiddenForm2.c

Maintaining state data using
cookies

Using cookies for state data
A more sophisticated scheme for session state data
repository on the client side is a mechanism
known as a cookie, “for no compelling reason”.
The scheme makes use of an extension of the
basic HTTP to allow a server’s response to contain
a piece of state information for which the client
will provide storage in an object.
“Included in that state object is a description of the
range of URLs for which that state is valid. Any
future HTTP requests made by the client which
fall in that range will include a transmittal of the
current value of the state object from the client
back to the server.”
A CGI script creates a cookie by including a Set-
Cookie header line as part of the HTTP response
that it outputs.
Each cookie contains a URL-encoded name-value
pair, similar to a name-value pair in a query string,
for a state data item (for example, id=12345).
When the response is received by the browser, it
creates an object (a cookie) which contains the
name-value pair.
The cookie is sent as a request header line in each
subsequent request sent by the browser to the web
server, which appends the name-value pair to the
query string being sent to a web script.
W e b fo rm s
fo r m .htm l
...
< F O R M M E T H O D = P O ST A C T I O N = " /c gi- bin / f o r m 1 .c gi"
...
< I N P U T n a m e = " Y o ur N a m e " >
fo r m 1 .c g i B ro w s e r
... Yo u rn am e= J o h n Bro w n
p rin tf ("s et-c o o k ie:% s = % s ", en tries [0 ].n am e, en tr ies [0 ]. v al);
...
Yo u rn am e= J o h n Bro w n
fo r m 2 .c g i
...
Yo u rID = 1 2 3 4 5
p rin tf ("s et-c o o k ie:% s = % s % c \n ", en tries [0 ].n am e, en tries [0 ]. v al,'\0 ');
item 1 = b o o k 1 3 7 1 4
p rin tf ("s et-c o o k ie:% s = % s % c \n ", en tries [4 ].n am e, en tries [4 ]. v al,'\0 ');
...
fo r m 3 ,c g i
Yo u rn am e= J o h n Bro w n & Yo u rID = 1 2 3 4 5 & item 1 = b o o k 1 3 7 1 4

we b s cript
we b s cript W e b s e rv e r B ro ws e r
fo rm .cg i
fo rm 2 .cg i
r e q u e s t f o r f o r m .h t m l
we b s cript
fo rm 3 .cg i f o r m .h t m l
f o r m .c g i ? i d =1 2 3 4 5
i d =1 2 3 4 5
S e t - C o o k i e : i d =1 2 3 4 5
f o r m 2 .h t m l ( d y n a m i c )
f o r m 2 .h t m l ( d y n a m i c ) i d =1 2 3 4 5
f o r m 2 .c g i ? n a m e =M a t t
i d =1 2 3 4 5
i d =1 2 3 4 5 & n a m e =M a t t
S e t - C o o k i e : n a m e =M a t t f o r m 3 .h t m l ( d y n a m i c )
f o r m 3 .h t m l ( d y n a m i c ) n a m e =M a t t
i d =1 2 3 4 5 & n a m e =M a t t i d =1 2 3 4 5 n a m e =M a t t

Syntax of the Set-Cookie HTTP Response
Header Line
The core syntax of the set-cookie header line is a
string in the following format (keywords are listed
in bold):
Set-Cookie: NAME=VALUE; expires=DATE;
path=PATH; domain=DOMAIN_NAME; secure
The line starts with the keyword “Set-Cookie” and
the delimiter colon (‘:’), followed by a list of
attributes separated by semi-colons. The attributes
are explained as follows:

Syntax of the Set-Cookie
HTTP Response Header Line
NAME=VALUE
URL-encoded name-value pair for the state
data to be stored in the cookie created. This
is the only required attribute on the Set-
Cookie header line.

expires=DATE
The expires attribute specifies a date string that defines the
valid life time of that cookie. Once the expiration date has
been reached, the client host is free to deallocate the
cookie and the state data contain in the cookie can no
longer be assumed to be sent to the server.
The date string is formatted as:
Wdy, DD-Mon-YYYY HH:MM:SS GMT
The time format is based on RFC 822, RFC 850,
RFC 1036, and RFC 1123, with the variations that the only
legal time zone is GMT and the separators between the
elements of the date must be dashes.
expires is an optional attribute. If not specified, the cookie
will expire when the user's session ends.

domain=DOMAIN_NAME
This attribtues sets the domain for the cookie created.
Among the cookies stored on the client host, a browser is
supposed to send only cookies whose domain attributes of
the cookie is made with the Internet domain name of the
host name specified in the URI of the object in the HTTP
request (with which the cookie is sent).
If there is a “tail match”, then the cookie will go through
path matching to see if it should be sent. "Tail matching"
means that the domain attribute is matched against the tail
of the fully qualified domain name in the URI.

Header Line
For example:
A domain attribute of "acme.com" would match host
names
"anvil.acme.com"
as well as
"shipping.crate.acme.com“
so that the name-value pair in the cookie tagged with the
domain attribute of acme.com will be sent with a HTTP
request where the requested object has a URI containing
the host name
anvil.acme.com (such as anvil.acme.com/index.html)
or
shipping.crate.acme.com (such as
shipping.crate.acme.com/sales/shop.htm).
Header Line
The default value of domain is the host
name of the server which generated the
cookie response.
For example, if the server is www.someU.
edu, then, if no domain attribute is set with
a cookie, then the cookie’s domain is
www.someU.edu.

Header Line
path=PATH
The path attribute is used to specify the subset of URIs in
a domain for which the cookie is valid.
If a cookie has already passed the domain matching, then
the pathname component of the URI is compared with the
path attribute, and if there is a match, the cookie is
considered valid and is sent along with the HTTP request.
The path "/foo" would match "/foobar" and
"/foo/bar.html". The path "/" is the most general path.
If the path is not specified, it as assumed to be the same
path as the document being described by the header which
contains the cookie.

The path attribute in set cookie
Examples:
Cookie Domain Cookie Path Request URI that will cause the name-value pair in
attribute attribute the cookie to be sent in the request header.
www.someU.edu none www.someU.edu/*
www.someU.edu / www.someU.edu/*
www.someU.edu /foo www.someU.edu/foo*
www.someU.edu /foo/foo www.someU.edu/foo/foo*

The secure attribute in set cookie
secure
If a cookie is marked secure, it will only be
transmitted if the communications channel
with the host is a secure one. Currently this
means that secure cookies will only be sent
to HTTPS (HTTP over SSL) servers.
If secure is not specified, a cookie is
considered safe to be sent in the clear over
unsecured channels.

How cookies are passed from the browser to the server
When requesting a URL from an

HTTP server, the browser will match
the URI against all cookies stored on
the client host.
If any matching cookie is found, then a
line containing the name/value pairs of
all matching cookies will be included in
the HTTP request. The format of the
line is:
Cookie: NAME1=VALUE1; NAME2=VALUE2; ...; NAMEn=VALUEn

How cookies are passed
from the browser to the server
Cookie: NAME1=VALUE1; NAME2=VALUE2; ...;
NAMEn=VALUEn
When such a line is encountered by the HTTP

server in the request header, the server extracts the
substrings containing the name-value pairs from
the line and place the string in an environment
variable named HTTP_COOKIE.
When the CGI script is executed, it may retreive
the state data, as name-value pairs, from the
environment variable HTTP_COOKIE.

Example:
If the following request is sent to the server
GET /cgi/hello.cgi?name=John&quest=peace HTTP/1.0
Cookie: age=25
<blank line>
then the server will place the string
“name=John&quest=peace” in the
environment variable QUERY_STRING
and the string “age=25” in
HTTP_COOKIE for the invoked CGI
script.

Example:
If a request sent to a server is:
POST /cgi/hello.cgi HTTP/1.0
Cookie: age=25
<blank line>
name=John&quest=peace
then the string “name=John&quest=peace” will
be sent by the server to the standard input of the
CGI script, while the string “age=25” will be
placed in the environment variable
HTTP_COOKIE.

The domain and path attributes for the
cookies are designed to allow state data to
be shared among selective CGI scripts.
Two transaction examples to follow.

First Example transaction sequence:
Client requests a document, and receives in the response:
Set-Cookie: CUSTOMER=WILE_E_COYOTE; path=/; expires=Wednesday,
09-Nov-99 23:12:40 GMT
When client requests a URL in path "/" on this server, it sends:
Cookie: CUSTOMER=WILE_E_COYOTE
Client requests a document, and receives in the response:
Set-Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001; path=/
Cookie: CUSTOMER=WILE_E_COYOTE;
PART_NUMBER=ROCKET_LAUNCHER_0001
Client receives:
Set-Cookie: SHIPPING=FEDEX; path=/foo
When client requests a URL in path "/foo" on this server, it sends:
PART_NUMBER=ROCKET_LAUNCHER_0001; SHIPPING=FEDEX

Second Example transaction sequence
Client receives:
Set-Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001;
path=/ When client requests a URL in path "/" on this server,
it sends:
Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001
Client receives:
Set-Cookie: PART_NUMBER=RIDING_ROCKET_0023;
path=/ammo When client requests a URL in path "/ammo" on
this server, it sends:
Cookie: PART_NUMBER=RIDING_ROCKET_0023;
NOTE: There are two name/value pairs named
"PART_NUMBER" since there are two cookies that match
the path attribute: the "/" and "/ammo".

A sample set of CGI script which make use of cookies
Cookie/Cookie.html
Cookie/Cookie.c
Cookie/Cookie2.c

Summary - 1
You have been introduced to Internet applications
and the key protocols that support them.
 The Hypertext Markup Language (HTML) is
a markup language used to create documents
that can be retrieved using the World Web
Web.
 The XML(Extensible Markup Language)
allows a document to be marked up for
structured information.

Summary - 2
The HTTP (HyperText Hyperlink Protocol) is the
transport protocol on the web
It allows the transferring of web contents of
virtually unlimited types
It is a connection-oriented, stateless, request-
response protocol
In HTTP/1.0, each connection allows only one
round of request-response
HTTP is text-based: the request and responses are
character strings
Each HTTP request and response is composed of
four parts: The request/response line; a header
section; a blank line; the body
Summary - 3
The Common Gateway Interface (CGI) protocol
is a protocol to augment HTTP in supporting run-
time generated web.
Using the protocol, a web client may specify an
external program, known as a CGI script, as the
target web object in an HTTP request.
When requested, the web server fetches the CGI
script, activates it as a process, passing to the
process input data transmitted by the web client.
The web script executes and transmits its output to
the web server, which returns the web-script
generated data as the body of a response to the web
client.
Summary - 4
A web form is a special kind of web page
which (i) provides a graphical user interface
that prompts input data from a user, and, (ii)
when a submit button on the page is pressed
by the user, invokes the execution of an
external program on the web server host.
The input data is gathered in a query string,
which is sent to a web script.

Summary - 5
To allow session data to be shared among
the web scripts invoked during a web
session, there are a number of mechanisms:
 Server-side facilities: files, database, and
others.
 Client-side: hidden-form tags and cookies
The use of hidden-form tags and cookies

raises privacy and security concerns.

Chapter 9

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 9

Uploaded by

Copyright:

Available Formats

Internet Applications

01/13/24 Distributed Computing, M. L. Liu 1

01/13/24 Distributed Computing, M. L. Liu 2

01/13/24 Distributed Computing, M. L. Liu 3

01/13/24 Distributed Computing, M. L. Liu 4

01/13/24 Distributed Computing, M. L. Liu 5

01/13/24 Distributed Computing, M. L. Liu 6

01/13/24 Distributed Computing, M. L. Liu 7

01/13/24 Distributed Computing, M. L. Liu 8

01/13/24 Distributed Computing, M. L. Liu 9

01/13/24 Distributed Computing, M. L. Liu 10

res p o n s e res p o n s e is a m es s ag e c o n s is tin g o f 3 p arts :

01/13/24 Distributed Computing, M. L. Liu 12

HTTP is text-based: the request and

01/13/24 Distributed Computing, M. L. Liu 13

HTTP/1.1 200 OK HTTP response status line

<HTML> document content

01/13/24 Distributed Computing, M. L. Liu 14

An example client request is as follows:

01/13/24 Distributed Computing, M. L. Liu 15

01/13/24 Distributed Computing, M. L. Liu 16

01/13/24 Distributed Computing, M. L. Liu 18

01/13/24 Distributed Computing, M. L. Liu 20

01/13/24 Distributed Computing, M. L. Liu 21

01/13/24 Distributed Computing, M. L. Liu 22

01/13/24 Distributed Computing, M. L. Liu 23

01/13/24 Distributed Computing, M. L. Liu 24

01/13/24 Distributed Computing, M. L. Liu 25

01/13/24 Distributed Computing, M. L. Liu 26

01/13/24 Distributed Computing, M. L. Liu 27

01/13/24 Distributed Computing, M. L. Liu 28

01/13/24 Distributed Computing, M. L. Liu 29

01/13/24 Distributed Computing, M. L. Liu 30

text plain, rich text, html, tab-separated-values, xml

message Email, news

image jpeg, gif

video mpeg, quicktime

01/13/24 Distributed Computing, M. L. Liu 31

01/13/24 Distributed Computing, M. L. Liu 32

01/13/24 Distributed Computing, M. L. Liu 33

01/13/24 Distributed Computing, M. L. Liu 34

01/13/24 Distributed Computing, M. L. Liu 36

01/13/24 Distributed Computing, M. L. Liu 37

01/13/24 Distributed Computing, M. L. Liu 39

01/13/24 Distributed Computing, M. L. Liu 40

01/13/24 Distributed Computing, M. L. Liu 41

01/13/24 Distributed Computing, M. L. Liu 43

01/13/24 Distributed Computing, M. L. Liu 44

01/13/24 Distributed Computing, M. L. Liu 45

01/13/24 Distributed Computing, M. L. Liu 46

01/13/24 Distributed Computing, M. L. Liu 47

01/13/24 Distributed Computing, M. L. Liu 48

01/13/24 Distributed Computing, M. L. Liu 49

C GI program HTTP s e rve r

01/13/24 Distributed Computing, M. L. Liu 50

01/13/24 Distributed Computing, M. L. Liu 51

HT T P s erv er res p o n s e, in c lu d in g d y n am ic ally g en erated w eb p ag e

01/13/24 Distributed Computing, M. L. Liu 52

main(int argc, char *argv[]) {

01/13/24 Distributed Computing, M. L. Liu 54

01/13/24 Distributed Computing, M. L. Liu 55

01/13/24 Distributed Computing, M. L. Liu 56