Web Applications

November 9th, 1998

Ari Muittari
Electrical and Communications Engineering
Helsinki University of Technology
ari.muittari@ntc.nokia.com

Table of Contents

1. Java

1.1 Introduction

1.2 Language Features

1.3 Java Platform

1.3.1 Java Virtual Machine

1.3.2 Java programs

1.3.3 Application Programming Interface

1.3.4 Compile and Runtime Environments

1.3.5 About performance

1.4 Specifications

1.4.1 Standardization

1.4.2 White papers

1.5 Products

1.5.1 Products from Sun

1.5.2 JAMBALA - Ericsson's digital wireless IN Platform

2. JavaScript

2.1 Introduction

2.2 Components of JavaScript Language

2.2.1 Core language

2.2.2 Client-side JavaScript

2.2.3 Server-side JavaScript

2.3 LiveConnect

2.4 JavaScript vs. Java

3. HTTP Persistent Client State Mechanisms (Cookies)

3.1 Introduction

3.2 Specifications and Standards

3.3 State and Sessions

3.4 Origin Server (Server-side) Role

3.4.1 Phases of a session

3.4.2 Set-Cookie response header to User Agent

3.5 User Agent (Client-side) Role

3.5.1 Interpreting Set-Cookie

3.5.2 Rejecting Cookies

3.5.3 Cookie Management

3.5.4 Cookie request header to Origin Server

3.6 Example

3.7 User Agent Implementation

3.7.1 Implementation limits

3.7.2 Controlling privacy

4. Conclusions

5. References

1. Java

1.1 Introduction

The Java programming language has been introduced in late 1995 by Sun Microsystems. JavaSoft released a newer version of Java (JDK 1.1) in early 1997 and the next version (JDK 1.2) is coming soon. Java is becoming a platform of choice for application development in key areas such as Internet development, distributed computing, enterprise computing, and so on. With the Java platform being deployed in more and more widely-used operating systems, Java is well on its way to becoming the most important computing platform that promises "Write Once, Run Anywhere" capability [1].

1.2 Language features

Java originated as part of a research project at Sun to develop advanced software for a wide variety of network devices and embedded systems. The result was a language platform that has proven ideal for developing secure, network-based end-user applications which can be deployed in environments ranging from the Web and the desktop, to network-embedded systems. Sun desdcribes Java in its white paper The Java Language: An Overview [2] as following terms:

• Simple. Java is small and ''looks like'' C++. Sun designed Java as closely to C++ as possible in order to make the system more comprehensible, but removed many difficult and dangerous features of C++ (overloading, multiple inheritance, extensive automatic coercions, and goto statement). Java does not use pointers and implements automatic garbage collection to eliminate invalid pointer references and memory leaks of C++. In order to run Java also on small stand-alone machines, the size of the basic interpreter and class support is about 40 KB; the basic standard libraries and thread support require an additional 175KB.
• Object-oriented. The object-oriented paradigm fits well with Java's distributed client/server model. As compared to C++, Java is more strict in terms of its object-oriented nature. In Java, everything except the primitive types (numeric, character, boolean) is an object. Even strings are represented by objects. The entire application must be viewed as a collection of objects of various classes. An added benefit with Java is that it comes with an extensive pre-defined class hierarchy, which saves the programmer from writing code for a lot of support functions.
• Network-oriented. Java is designed to support applications on networks. It supports various levels of network connectivity through pre-defined classes for handling TCP/IP protocols like HTTP and FTP. For instance, the URL class provides a simple interface to networking -- opening and accessing of an object referred to by an URL on a remote site is as easy as opening and accessing a local file system. It also provides classes that support datagram and streaming sockets. The network connection (a "socket") is wrapped with stream objects, so the method calls are same as with all other streams. Underlying details of networking have been abstracted away and taken care of within the Java Virtual Machine (JVM) and local machine installation of Java. Java's built-in-multithreading is used to deal multiple connections [3].
• Robust. Java is a strongly-typed language. It employs early checking to catch potential problems and requires explicit method declarations unlike C/C++. Remove of pointers eliminate the possibility of overwriting memory and corrupting data and use of automatic garbage collection prevent memory leaks. Instead of pointer arithmetic, Java has true arrays with bounds-checking. The exception handling is sophisticated, since it allows use of try/catch/finally statement to simplify the task of error handling and recovery and enables all of the error handling code to be grouped together.
• Secure. Java implements several security mechanisms to ensure that malicious code that try to invade file system cannot gain access to system resources. Three major components are class loader, byte-code verifier and security manager. They defines how Java classes are loaded over the network, and ensure that untrusted classes will not execute dangerous instructions or gain access to protected system resources.
• Architecture-neutral and portable. Java programs are compiled to an architecture neutral byte-code format, rather than to a platform-specific binary format. The byte-code can be executed by the Java Virtual Machine (JVM) that runs on top of a specific computing platform. This allows a Java application to run on any system that implements the Java Virtual Machine. Java's portability actually comes from its architecture-neutrality. Java explicitly specifies the size of each of the primitive data types and their arithmetic behavior to eliminate implementation dependencies. Java compiler is written in Java. Sun's "100% Pure Java" program [2] helps developers ensure that their Java code is portable.
• Interpreted. The Java compiler generates byte-codes for the Java Virtual Machine. The JVM actually consists of the Java interpreter and the run-time environment. The interpreter is used to actually execute the compiled byte-codes.
• High-performance. Java, being an interpreted language, is never going to be as fast as a compiled language like C. It is probably reasonable to say that compiled C code runs ten times faster than interpreted Java byte-codes. This speed is usually enough for event-driven, GUI-based applications, or for networking applications. Much of the speed critical portion of the Java run-time environment has been implemented with efficient native methods.
• Multi-threaded. In a GUI-based network application such as a Web browsers, there are usually multiple things going on at the same time, e.g. a page is scrolled down while the browser is loading the contents of that page. Java provides support for multiple threads of execution that can handle different tasks simultaneously. Java's multi-threading comes with a set of synchronization primitives based on the monitor and condition variable paradigm. This makes programming in Java with threads much easier than programming in the conventional single-threaded C and C++ style.
• Dynamic. Java applications or applets reside on the network in centralized servers. A Java program can load in classes as they are needed, even from a remote site, and execute them. This is what happens when a Web browser downloads a Java applet. This allows clients to dynamically gain intelligence they did not have before, therefore the clients can adapt much easier to an evolving environment. This also makes software upgrades much easier and effective and cuts down maintenance cost.

1.3 Java Platform

The Java platform differents from other platforms (like MS Windows or UNIX), it sits on top of these platforms (or sits directly on the hardware) and is designed to deliver and run interactive, dynamic and secure applets and applications on a networked computer system.

1.3.1 Java Virtual Machine

The Java Virtual Machine (JVM) is an abstract machine designed to hide the underlying operating system from Java programs. It is a software processor that sits on the top of the existing processors. The JVM can also be implemented directly by hardware (java chip processor). The JVM specification defines the exact interfaces and adapters required to port the JVM to any platform. JVM specification also defines a machine-independent class file format for compiled Java programs.

Figure 1. Java Platform

1.3.2 Java programs

The Java language and runtime environment enables two different kinds of programs:

• Applets. Applets require a Java enabled browser to run. The <applet> tag is embedded in a Web page and names the program to be run. When that page is accessed by a browser it automatically downloads the applet code from the server and runs it on the local machine. Applets tend to be designed small and modular to avoid large download times. Since an applet is downloaded from an untrusted source, it runs under certain restrictions within the local machine (called "sandbox") and is prevented from doing certain system tasks such as creating or editing files on the local file system. This restriction can be relaxed when applets can be marked with digital signatures, which ensure that the applet has been downloaded from a trusted source.
• Applications. Java applications are similar to application programs developed in other languages. They do not require a browser to run - they have no built-in downloading mechanism. An application is run from the command line using the Java interpreter. Like an applet, an application requires the Java platform for it to run. The platform itself can be available as an independent program, can be embedded inside the operating system or can be embedded in the application itself. An application has full access to system services and resources.

The Java Server API enables server side programs:

• Servlets [4]. Servlets are modules of Java code that run in a server application (hence the name "Servlets", similar to "Applets" on the client side) to answer client requests. Servlets are not tied to a specific client-server protocol but they are most commonly used with HTTP and the word "Servlet" is often used in the meaning of "HTTP Servlet".

• Processing and/or storing data submitted by an HTML form.
• Providing dynamic content, e.g. returning the results of a database query to the client.
• Managing state information on top of the stateless HTTP, e.g. for an online shopping cart system which manages shopping carts for many concurrent customers and maps every request to the right customer.

1.3.3 Application Programming Interface

The application programming interface (API) provides a high level abstraction to low level system services, such as file I/O, process control, windowing system, etc. The Java language comes with a set of pre-defined classes which help user to implement complex tasks with minimum coding. APIs are grouped into Java packages by function. A package in Java provides a separate unique namespace. The APIs are divided into the Java Core APIs and the Java Standard Extension APIs.

• Core Language Classes. Contains classes which represent all the primitive data types (Boolean, Character, Byte, etc.), the superclass of all classes (Object), string classes (String, StringBuffer), and classes dealing with the extended capabilities of the language such as System, SecurityManager, Thread, and Throwable (the root class of the Java exception and error hierarchy). The System class provides the connection to the language environment and the underlying system environment. Other classes are Class (the class representing the run-time class information of an object), Runtime and Process (provides a platform-independent interface to platform-dependent processes).
• Windowing Classes. Abstract Windowing Toolkit (AWT) allows dealing with GUI objects without regard to the system. Programs will automatically run on all supported Java platforms. Classes may be roughly divided into three categories:
• Graphics: defines colors, fonts, images, polygons, and so forth.
• Components: defines GUI components such as buttons, menus, lists, and dialog boxes
• Layout Managers: controls the lay out of components within their container objects.
• Networking Classes. Contains classes to support network programming. These classes provide tools dealing with sockets, Internet addresses, network datagrams, uniform resource locators (URLs), and content handlers for data from a URL. The URL class downloads an object referred to by the URL with a single call and the Socket class connects to a specified port on a specified Internet host and reads and writes data.
• Applet Class. Contains the Applet class and related interfaces. Applet class implements an applet and is the superclass of all applets. An own applet can be created by creating a subclass of this class and overriding some or all of its methods.
• Input/Output and Stream Classes. Contains classes to support reading and writing streams, files, and pipes. Most classes implemented in this package are subclasses of InputStream or OutputStream. InputStream and OutputStream are classes that implement methods for reading and writing data from a byte stream.
• Utility Classes. Contains general purpose utility classes for data structures, such as hashtables, dates, stacks, bits, strings. There are classes for computing checksums on streams of data and for compressing and archiving (and the reverse) streams of data.
• Component model (JavaBeans). Contains APIs which define a portable, platform neutral set of APIs for building software components that can be plugged into existing component frameworks such as Microsoft's OLE/COM, Apple's OpenDoc, and Netscape's LiveConnect.
• Remote Method Invocation (RMI). RMI lets programmers create Java objects whose methods can be invoked from another virtual machine. RMI is the object-oriented counterpart of remote procedure calls (RPC) in the procedural-programming world.
• Java Security API. A framework for developers to include security functionality in their Java applets and applications. This functionality includes cryptography with digital signatures, encryption, and authentication.
• Java Database Connectivity (JDBC). Provides a standard interface to accessing local and remote SQL databases.
• Interface Definition Language (IDL). IDL is a language neutral way to specify an interface between an object and its client when they are on different platforms. IDL provides seamless connectivity and interoperability with applications written using the industry standard CORBA (Common Object Request Broker Architecture) system for heterogeneous computing. It provides a Java to IDL mapping specification, and an IDL-to-Java compiler.
• Java Foundation Classes (JFC). Extends the original AWT by adding a comprehensive set of GUI class libraries that is portable and delivered as part of the Java platform.
• Java Accessibility. Provides the tools that enable assistive technologies to interact with the accessibility support built into the JFC and track top level window creation and other events.
• Miscellaneous Packages. The java.math contains classes which support arithmetic on arbitrary-sized integers and arbitrary-precision floating-point numbers. Classes in the java.text package are used for internationalization.

The Java Standard Extension API extends the capabilities of Java beyond the Java Core API and contributes a lot to making Java into a software framework for various types of computing tasks. Examples of extension APIs are:

• Java Communications API. Can be used to write platform-independent communications applications for technologies such as voice mail, fax, and smartcards. Contains support for RS232 serial ports and IEEE 1284 parallel ports.
• Java Media API. Defines the classes that support a wide range of media, and interactive multi-media related activities. It is composed of several distinct component, each associated either with a specific type of media such as control of 2D and 3D objects, audio, and video, or a media-related activity such as collaboration, telephony, and animation. Some examples:
• Java Media Framework (JMF). Specifies unified architecture, messaging protocol, and programming interface for media players, media capture, and conferencing. Supports the synchronization, control, processing, and presentation of compressed streaming and stored time-based media.
• JavaSpeech API. Provides the classes to integrate speech technology into user interfaces. This API specifies a cross-platform interface to support command and control recognizers, dictation systems and speech synthesizers.
• Java Telephony API. Provides the classes to integrate telephones with computers. It provides the basic functionality for control of phone calls: 1st party call control (simple desktop phone), 3rd party call control (phone call distribution center), teleconferencing, call transfer and caller ID.

1.3.4 Compile and Runtime Environments

The Java Development Kit is a software development and deployment platform which contains a wide set of software and tools that developers need to compile, debug, and run Java applets and applications. These tools are designed to be used from the command line. The current release of JDK is 1.1 (newest one is 1.1.7). The upcoming version JDK 1.2 offers improvements in functionality, performance, security and global support.

Figure 2. Java Development Toolkit

The developer writes Java Language source code (.java files) and compiles it to bytecodes (.class files). These bytecodes are instructions for the Java Virtual Machine. To create an applet, the developer next stores these bytecode files on an HTTP server, and adds an <applet code=filename> tag to a Web page, which names the entry-point bytecode file.

When an end user visits that page, the <applet> tag causes the bytecode files to be transported over the network from the server to the end user's browser in the Java Platform. At this end, the bytecodes are loaded into memory and then verified for security before they enter the Virtual Machine.

Once in the Virtual Machine, the bytecodes are interpreted by the Intepreter, or optionally turned into machine code by the just-in-time (JIT) code generator, known more commonly as the JIT Compiler. The Interpreter and JIT Compiler operate in the context of the runtime system (threads, memory, other system resources). Any classes from the Java Class Libraries (API) are dynamically loaded as needed by the applet.

Once a Java application has been developed, the JRE can be bundled in as part of the final product. This is useful when the latest version of the Java runtime is not installed on the customer's machine, or if the runtime is not installed at all.

Figure 3. Source code is compiled to bytecodes, which are executed at runtime

1.3.5 About performance

There are many factors that affects the performance of Java. Some of them are [1]:

• Interpreter. An interpreted language is always slower than a compiled language.
• Dynamic linking. Java resolves all symbols when a new class is loaded into the environment and prepares it for execution.
• Bytecode verification. Before a class loader may permit a given applet to execute, Java validates the code to prevent it from doing anything dangerous.
• Reliance on pointers for objects. Each Java object access needs a pointer dereference, which adds a level of indirection.

There are also some techniques to be used to gain higher performance [5]:

• Better Java compilers. Compilers that translate Java source code into Java bytecode for execution JVMs could be optimized by classic compiler optimizations.
• Faster JVMs. The JVM is the software layer in a Web browser or OS that interprets Java bytecode and handles runtime operations such as garbage collection. Algorithms of garbage collection may be improved.
• Bytecode optimizers. These tools apply additional optimizations by recompiling the bytecode produced by Java compilers, yielding faster class files that still consist of standard bytecode.
• Just-in-time (JIT) compilers. When a JVM loads a program's classes, a JIT compiler quickly translates the bytecode into native machine code and then caches it in memory. JIT compilers are common in Web browsers.
• Dynamic or adaptive compilers. These compilers intelligently translate Java bytecode into native machine code at run time based on profiles of how the program is running and apply optimizations as needed.
• Static native compilers. These tools translate Java source code or bytecode into native object code at design time, just like compilers for C/C++.
• Native method calls. Java applications can invoke native executable files, including DLLs written in C++ and services in the native OS.
• Java chips. A new breed of microprocessors can directly execute Java bytecode as their native machine language, so this means that JVM is not virtual anymore - it comes real. Most of these chips are designated for low-cost devices.
• Writing better code. Developers can follow good programming practices and exploit Java's idiosyncrasies.

Currently Java programs which are compiled with JIT compilers can achieve 30 to 40 % of the performance of native C++ programs. It is estimated that Java could eventually attain 60 to 70 % of the speed of native C++, or even could match speed of native C++.

1.4 Specifications

1.4.1 Standardization

In March 1997 Sun standardized Java platform specificiations by applying to ISO/IEC JTC1 for recognition as a Publicly Available Specification (PAS) submitter. ISO/IEC JTC1 stands for International Organization for Standardization/International Electrotechnical Commission Joint Technical Committee. The new PAS process was designed by JTC1 to speed the conversion of de facto industry standards like the Java Platform into ISO International Standards [2].

1.4.2 White papers

There are many high-level, overview documents of different features and aspects of Java. These papers cover following topics:

• Java Language, Language Overview, Language Environment and Security
• Java Platform (Runtime Environment)
• JavaOS, A Standalone Java Environment
• Java Electronic Commerce Framework (JECF)
• JavaBeans, A Component Architecture for Java
• HotJava Views (Designing the HotJava Views User Environment)
• RMI: Java Remote Method Invocation (Distributed Computing for Java)
• Java Media and Communications APIs

1.5 Products

1.5.1 Products from Sun

There are many published and under development products. To name few of them:

• HotJava Browser. A lightweight solution for OEMs and developers creating Web-enabled devices and applications. HotJava Browser features include customizability, extensibility, flexible security model, SSL (Secure Sockets Layer) capability and internationalization support.
• Personal Applications. This suite is an integrated set of compact, memory efficient applications designed for personal networked devices such as screen phones, wireless phones, set-top boxes, and car navigation systems. Personal Applications offer security, extensibility, and portability across multiple operating systems and processors.
• JavaOS. An optimized Java computing platform for communication appliances. JavaOS provides a platform for consumers appliances such as Web phones, set-top boxes and handheld computing devices.

1.5.2 JAMBALA - Ericsson's digital wireless IN Platform

Ericsson has adapted Java technology in a new system for running a telecommunications network. JAMBALA [6] was published on September 1998 by Ericsson being the first telecommunications product which fully leverage the Java platform.

Network nodes like service control point (SCP) and a home location register/authentication center (HLR/AC) are implemented directly in JAMBALA. As an intelligent network (IN) node JAMBALA system e.g. tracks subscriber information, locates subscribers, handles special services like call forwarding and voice mail and manages subscriber registration and record-keeping.

JAMBALA platform uses Ericsson's own TelORB operating system. Java Virtual Machine (JVM) runs on top of TelORB enabling the use of Java technology for the development of new applications. By using JVM in platform, operators can use JavaBean technology and commercially available software development tools (like Java Studio) to implement and customize end-user services.

• The application platform hardware. Two OA&M UltraSPARC 300 MHz processors, 200 MHz Pentium boards (512 MB RAM), two 100 Mbit/s Ethernet switches, CD-ROM drive, 40 GB hard drive and SS7/C7 stack.
• The features of Jambala. Advanced administration and maintenance (OA&M). OA&M uses Corba 2.0 and there is a Web-based graphical user interface (GUI). System capacity may be linearly scaled by the number of used processors. JAMBALA is typically sold to operators who have a minimum of 100 000 subscribers. Other claimed features are flexible and future-compliant architecture and multi-application support.
• Zero-downtime operation. Achieved by automatic recovery from software errors, data fault tolerance and redundancy, on-line backup, adaptive hardware configuration, smooth software upgrade, n+1 hardware redundancy, hot-swap replacement and geographical node redundancy.

2. JavaScript

2.1 Introduction

JavaScript is Netscape's cross-platform, object-based scripting language for client and server applications. Client applications run in a browser and server applications run on a server.

Javascript can be thought of as an extension to HTML which allows developers to include functionality on their HTML pages. Client-side objects are mainly the components of an HTML web page (forms, text boxes, buttons) and they allow processing of user input. Server-side objects are those that facilitate the handling of requests that come from clients and maintain persistent data using special objects, files, and relational databases. Applications can access Java and CORBA distributed-object applications through JavaScript's LiveConnect functionality [7,8].

2.2 Components of JavaScript Language

The JavaScipt language comprises of three components: Core language, Server-side and Client-side JavaSript.

Figure 4. The components of JavaScript language

2.2.1 Core language

Server-side and client-side JavaScript share the same core language. This core language corresponds to ECMA-262 (ECMAScript Language Specification) [9]. The European standards body ECMA has approved ECMA-262 and submitted it to ISO/IEC JTC 1 for adoption. The core language contains a set of core objects. It also defines object model and other language features such as its expressions, statements and operators. Although server-side and client-side JavaScript use the same core functionality, in some cases they use them differently [7].

Microsoft incorporated its version of the language, called JScript, in Internet Explorer 3. The core language part of JScript is essentially identical to that of JavaScript 1.1 in Netscape Navigator 3. However, these two browsers differs in their document object models [10].

2.2.2 Client-side JavaScript

Both client-side and server-side JavaScript includes the core language. Both of these includes also some additions of their own, like predefined objects.

Client-side JavaScript statements are embedded directly in HTML pages and are interpreted by the browser at runtime. Because production applications frequently have greater performance demands, JavaScript applications that take advantage of its server-side capabilities are compiled before they are deployed.

When the browser (or client) requests HTML page, the server sends the full content of the document, including HTML and JavaScript statements to the client. The client reads the page from top to bottom, displaying the results of the HTML and executing JavaScript statements as it goes. This process produces the results that the user sees [7].

Figure 5. Client-side JavaScript

Client-side JavaScript statements in an HTML page can respond to user events such as mouse-clicks, form input, and page navigation. Without causing any network transmission a JavaScript function can e.g. verify that users enter valid information into a form requesting a telephone number.

2.2.3 Server-side JavaScript

On the server JavaScript is also embedded in HTML pages. The server-side statements can connect to databases, share information across users of an application, access the file system on the server, or communicate with other applications through LiveConnect and Java.

HTML pages that use server-side JavaScript are compiled into bytecode executable files. These application executables are run in concert with a Web server that contains the JavaScript runtime engine. This makes creating JavaScript applications a two-stage process.

In the first stage the developer creates HTML pages and JavaScript files. These files are then compiled into a single executable.

Figure 6. Server-side JavaScript during development

In the second stage a client browser requests a page that was compiled into the application. The runtime engine finds the compiled representation of that page in the executable, runs any server-side JavaScript statements found on the page, and dynamically generates the HTML page to return. The result of executing server-side JavaScript statements might add new HTML or client-side JavaScript statements to the original HTML page. The runtime engine then sends the newly generated page over the network to the client, which runs any client-side JavaScript and displays the results.

Figure 7. Server-side JavaScript during runtime

In contrast to standard CGI programs, all JavaScript source is integrated directly into HTML pages. This makes development and maintenance easier. Server-side JavaScript's Session Management Service contains objects that can be used to maintain data that persists across client requests, multiple clients, and multiple applications. Server-side JavaScript's LiveWire Database Service provides objects for database access that serve as an interface to Structured Query Language (SQL) database servers [7].

2.3 LiveConnect

LiveConnect creates a connection between HTML elements, Java, JavaScript, and plug-ins [7]:

• Objects of different types, such as Java applets, plug-ins, and HTML (forms, buttons, and images), can interact with each other to create live applications.
• JavaScript programmers can control plug-ins and Java applet functions.
• Programmers of Java and plug-ins can make functions available to JavaScript programmers.

LiveConnect extends the object model of JavaScript to include objects and data types that are not a part of the HTML world. HTML, for instance, does not have a form element that displays real-time stock ticker data; nor does HTML have the capability to treat a sound file like anything more than a URL to be handed off to a helper application. With LiveConnect scripts can treat the applet that displays the stock ticker as an object whose properties and methods can be modified after the applet loads; scripts can also tell the sound when to play or pause by controlling the plug-in that manages the incoming sound file.

The backbone of the LiveConnect functionality in the browser is the Java Virtual Machine (JVM). Because LiveConnect is a proprietary Netscape technology, not all facilities are available in Internet Explorer [10].

2.4 JavaScript vs. Java

JavaScript and Java are similar in some ways but fundamentally different in others. The JavaScript language resembles Java but does not have Java's static typing and strong type checking. JavaScript supports most Java expression syntax and basic control-flow constructs. Java's object-oriented model means that programs consist exclusively of classes and their methods. Java's class inheritance and strong typing generally require tightly coupled object hierarchies.

In contrast to Java's compile-time system of classes built by declarations, JavaScript supports a runtime system based on a small number of data types representing numeric, Boolean, and string values. These requirements make Java programming more complex than JavaScript authoring.

Programming in JavaScript is easier to learn particularly of those who already know the basics of HTML and it requires only a text editor and a JavaScript-enabled browser. Java and JavaScript together makes a powerful combination through JavaScript's LiveConnect functionality [7,10].

Table 1. JavaScript compared to Java.

3. HTTP Persistent Client State Mechanisms (Cookies)

3.1 Introduction

HTTP as such is a stateless protocol. HTTP servers respond to each client request without relating that request to previous or subsequent requests [11].

CGI provides only a limited means for a server to identify its repeat visitors. CGI includes a variable sent from the visitor's browser to the server identifying the visitors IP address. Earlier this was useful because Internet users were assigned a unique IP address which could identify their machine. As WWW has grown, Internet Service Providers (ISP's) have reserved pools of IP addresses for customers. When accessing the ISP's computer, customer is assigned one of those IP addresses; and when connection is terminated, that address is returned to the pool for assignment to a different customer. CGI couldn't anymore identify a customer by tracking dynamic IP-addresses.

A great deal of the value of Web is the ability to create "dynamic pages", whose content change depending on information provided by the particular visitor. As demand for a more exact system of identifying repeat visitors increased, Netscape published a "Magic Cookie" in its browser in 1995 [12].

Cookie is a piece of information sent by a server to a browser who is expected to save it and send it back to the server whenever the browser makes additional requests from the server. Cookies may contain information such as login or registration information, user preferences, etc. When a server receives a request from a browser that includes a Cookie, the server is able to use the information stored in that Cookie. For example, the server may customize what is sent back to the user, or keep a log of particular user's requests [13].

Use of Cookies has increased tremendously since they offer numerous benefits to the Web services as well as individual users. Still many Web users are barely aware of cookies, which might be one reason for fear and denial of using them. Due to a lot of hype and misunderstanding people think that their privacy is intruded on by cookies. It is not always clear who is placing information in the Cookie file, and for what purpose.

3.2 Specifications and Standards

The specifications and standards relating to Cookies are [14]:

• Netscape's original Cookie proposal. The first Cookie specification which was published in 1995. It offered a general mechanism which server side connections (like CGI scripts) could use to both store and retrieve information on the client side connection.
• HTTP State Management Mechanism, RFC 2109, Proposed Standard. In 1996, AT&T Bell Laboratorios and Netscape presented a new Cookie proposal to replace the previous one. This proposal presents a comprehensive scheme which gives users an extensive control of when and how a Cookie will be stored on and read from his or her computer. It specifies a way to create a stateful session with HTTP requests and responses. It describes two new HTTP headers, Cookie and Set-Cookie, which carry state information between participating origin servers and user agents. The newest version is written in February 1997.
• HTTP State Management Mechanism, Internet Draft. A follow-up Internet Draft which incorporates editorial changes to RFC 2109 and some changes to improve compatibility with existing implementations. It describes two new HTTP headers, Cookie and Set-Cookie2.
• HTTP Proxy State Management Mechanisms, Internet Draft. This document specifies a way to create a stateful session between an HTTP proxy server and its client. It describes two new headers, Pcookie and Set-Pcookie, which carry state information between participating HTTP proxy servers and their clients.

In this paper the following description of Cookies is based on HTTP State Management Mechanism, RFC 2109, Proposed Standard [11].

3.3 State and Sessions

A session is a series of HTTP requests and responses between clients and servers that want to exchange state information which relates to a larger context. This context might be used to create e.g. an online shopping cart in which user selections can be aggregated before purchase, or a magazine browsing system, in which a user's previous reading affects which offerings are presented.

There are many different potential contexts and thus many different potential types of session. The designers' paradigm for sessions created by the exchange of cookies has these key attributes:

• Each session has a beginning and an end.
• Each session is relatively short-lived.
• Either the user agent or the origin server may terminate a session.
• The session is implicit in the exchange of state information.

The session here doesn't refer to a persistent network connection but to a logical session created from HTTP requests and responses.

3.4 Origin Server (Server-side) Role

3.4.1 Phases of a session

• Initiate of a session. The origin server initiates a session, if it so desires. To initiate a session, the origin server returns an extra response header to the client, Set-Cookie.
• Continuation of a session by user agent. A user agent returns a Cookie request header to the origin server if it chooses to continue a session.
• State of a session determined by origin server. The origin server may use the Cookie request header to determine the current state of the session. It may send back to the client a Set-Cookie response header with the same or different information.
• Ending of a session by origin server. The origin server effectively ends a session by sending the client a Set-Cookie header with Max-Age=0.

3.4.2 Set-Cookie response header to User Agent

The syntax of Set-Cookie response header is

av comes from attribute-value pair, attr ["=" value]. Attributes are case-insensitive. White space is allowed between tokens. Most attributes require a value.

Set-Cookie response header comprises the token Set-Cookie:, followed by a comma-separated list of one or more cookies. Each cookie begins with a NAME=VALUE pair, followed by zero or more semi-colon-separated attribute-value pairs in any order.

• NAME=VALUE. Required. The name of the state information ("cookie") is NAME, and its value is VALUE. (NAMEs that begin with $ are not allowed for compatability reasons). The VALUE is opaque to the user agent and may be anything the origin server chooses to send, possibly in ASCII encoding. "Opaque" means that the content is of interest and relevance only to the origin server.
• Comment=comment. Optional. Because cookies can contain private information about a user, the Cookie attribute allows an origin server to document its intended use of a cookie. The user can inspect the information to decide whether to initiate or continue a session with this cookie.
• Domain=domain. Optional. The Domain attribute specifies the domain for which the cookie is valid. An explicitly specified domain must always start with a dot.
• Max-Age=delta-seconds. Optional. The Max-Age attribute defines the lifetime of the cookie in seconds. The delta-seconds value is a decimal non-negative integer. After time has elapsed, the client should discard the cookie. A zero value means that the cookie should be discarded immediately.
• Path=path. Optional. The Path attribute specifies the subset of URLs to which this cookie applies.
• Secure. Optional. The Secure attribute (with no value) directs the user agent to use only (unspecified) secure means to contact the origin server whenever it sends back this cookie.
• Version=version. Required. The Version attribute identifies to which version of the state management specification the cookie conforms. For RFC 2109 specification, Version=1 applies.

3.5 User Agent (Client-side) Role

3.5.1 Interpreting Set-Cookie

The user agent keeps separate track of state information that arrives via Set-Cookie response headers from each origin server (as distinguished by name or IP address and port). The user agent applies these defaults for optional attributes that are missing:

• Version. Defaults to "old cookie" behavior as originally specified by Netscape.
• Domain. Defaults to the request-host.
• Max-Age. The default behavior is to discard the cookie when the user agent exits.
• Path. Defaults to the path of the request URL that generated the Set-Cookie response, up to, but not including, the right-most /.
• Secure. If absent, the user agent may send the cookie over an insecure channel.

3.5.2 Rejecting Cookies

To prevent possible security or privacy violations, a user agent rejects a cookie (shall not store its information) if any of the following is true:

• The value for the Path attribute is not a prefix of the request-URI.
• The value for the Domain attribute contains no embedded dots or does not start with a dot.
• The value for the request-host does not domain-match the Domain attribute.
• The request-host is a fully-qualified domain name and has the form HD, where D is the value of the Domain attribute, and H is a string that contains one or more dots.

Examples:

• A Set-Cookie from request-host y.x.foo.com for Domain=.foo.com would be rejected, because H is y.x and contains a dot.
• A Set-Cookie from request-host x.foo.com for Domain=.foo.com would be accepted.
• A Set-Cookie with Domain=.com or Domain=.com., will always be rejected, because there is no embedded dot.
• A Set-Cookie with Domain=ajax.com will be rejected because the value for Domain does not begin with a dot.

3.5.3 Cookie Management

If a user agent receives a Set-Cookie response header whose NAME is the same as a pre-existing cookie, and whose Domain and Path attribute values exactly (string) match those of a pre-existing cookie, the new cookie supersedes the old. However, if the Set-Cookie has a value for Max-Age of zero, the (old and new) cookie is discarded. Otherwise cookies accumulate until they expire.

Because user agents have finite space in which to store cookies, they may also discard older cookies to make space for newer ones, using, for example, a least-recently-used algorithm.

If a Set-Cookie response header includes a Comment attribute, the user agent should store that information in a human-readable form with the cookie and should display the comment text as part of a cookie inspection user interface.

User agents should allow the user to control cookie destruction. An infrequently-used cookie may function as a "preferences file" for network applications, and a user may wish to keep it even if it is the least-recently-used cookie. One possible implementation would be an interface that allows the permanent storage of a cookie through a checkbox.

3.5.4 Cookie request header to Origin Server

When it sends a request to an origin server, the user agent sends a Cookie request header to the origin server if it has cookies that are applicable to the request, based on the request-host, the request-URI and the cookie's age. The syntax for the header is:

The value of the cookie-version attribute must be the value from the Version attribute, if any, of the corresponding Set-Cookie response header. Otherwise the value for cookie-version is 0. The value for the path attribute must be the value from the Path attribute, if any, of the corresponding Set-Cookie response header. Otherwise the attribute should be omitted from the Cookie request header. The value for the domain attribute must be the value from the Domain attribute, if any, of the corresponding Set-Cookie response header. Otherwise the attribute should be omitted from the Cookie request header.

The following rules apply to choosing applicable cookie-values from among all the cookies the user agent has.

• Domain Selection. The origin server's fully-qualified host name must domain-match the Domain attribute of the cookie.
• Path Selection. The Path attribute of the cookie must match a prefix of the request-URI.
• Max-Age Selection. Cookies that have expired should have been discarded and thus are not forwarded to an origin server.

If multiple cookies satisfy the criteria above, they are ordered in the Cookie header such that those with more specific Path attributes precede those with less specific.

3.6 Example

Most detail of request and response headers has been omitted.

1. User Agent -> Server. User identifies self via a form.

POST /acme/login HTTP/1.1

2. Server -> User Agent. Cookie reflects user's identity.

HTTP/1.1 200 OK

Set-Cookie: Customer="WILE_E_COYOTE"; Version="1"; Path="/acme"

3. User Agent -> Server. User selects an item for "shopping basket."

POST /acme/pickitem HTTP/1.1

Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"

4. Server -> User Agent. Shopping basket contains an item.

HTTP/1.1 200 OK

Set-Cookie:Part_Number="Rocket_Launcher_0001"; Version="1"; Path="/acme"

5. User Agent -> Server. User selects shipping method from form.

POST /acme/shipping HTTP/1.1

Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"; Part_Number="Rocket_Launcher_0001"; $Path="/acme"

6. Server -> User Agent. New cookie reflects shipping method.

HTTP/1.1 200 OK

Set-Cookie: Shipping="FedEx"; Version="1"; Path="/acme"

7. User Agent -> Server. User chooses to process order.

POST /acme/process HTTP/1.1

Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"; Part_Number="Rocket_Launcher_0001"; $Path="/acme"; Shipping="FedEx"; $Path="/acme"

8. Server -> User Agent. Transaction is complete.

The user agent makes a series of requests on the origin server, after each of which it receives a new cookie. All the cookies have the same Path attribute and (default) domain. Because the request URLs all have /acme as a prefix, and that matches the Path attribute, each request contains all the cookies received so far.

3.7 User Agent Implementation

3.7.1 Implementation limits

User agent implementations have limits on the number and size of cookies that they can store. User agents should provide each of the following minimum capabilities individually, although not necessarily simultaneously:

• at least 300 cookies
• at least 4096 bytes per cookie (the size of the characters that comprise the cookie non-terminals in the syntax of the Set-Cookie header)
• at least 20 cookies per unique host or domain name

User agents created for specific purposes or for limited-capacity devices should provide at least 20 cookies of 4096 bytes, to ensure that the user can interact with a session-based origin server.

3.7.2 Controlling privacy

An origin server could create a Set-Cookie header to track the path of a user through the server. Users may think this behavior as an intrusive accumulation of information. It is required that a user agent gives the user control over such a possible intrusion, although this user interface is unspecified. The control mechanisms provided shall at least allow the user

• to completely disable the sending and saving of cookies.
• to determine whether a stateful session is in progress.
• to control the saving of a cookie on the basis of the cookie's Domain attribute.

Such control could be provided by, for example, mechanisms

• to notify the user when the user agent is about to send a cookie to the origin server, offering the option not to begin a session.
• to display a visual indication that a stateful session is in progress.
• to let the user decide which cookies, if any, should be saved when the user concludes a window or user agent session.
• to let the user examine the contents of a cookie at any time.

It should be possible to configure a user agent never to send Cookie headers, in which case it can never sustain state with an origin server. When the user agent terminates execution, it should let the user discard all state information. Alternatively, the user agent may ask the user whether state information should be retained; the default should be "no". If the user chooses to retain state information, it would be restored the next time the user agent runs.

4. Conclusions

Java is a modern object oriented platform independent language and computing environment which has in a very short time acquired a recognized position as the language of Internet as well as in many other key areas, like embedded devices. JavaScript is an easy to use object based scripting language which allows wide audience of HTML page authors to add more functionality in their pages and at the same time minimizes the use of network bandwidth. Cookies make a Web site individual and customizable by letting Web application developers store information on the client so that this information is available from one session to another.

These three Web applications separately, and especially when used together, form a rich set of means to develope the use of Internet yet more versatile and user friendly.

5. References

[1] World Wide Web - Beyond the Basics, Prentice Hall, 1998 http://www.prenhall.com/abrams/

[2] Sun Microsystems' source for Java technology http://java.sun.com/

[3] Bruce Eckel. Thinking in Java, Prentice Hall, 1998 http://www.phptr.com

[4] Stefan Steiger, Servlet Essentials http://www.novocode.com/doc/servlet-essentials/

[5] Byte, May 1998, How to soup up Java

[6] JAMBALA - Ericsson's digital wireless IN Platform http://www.ericsson.se/Review/er3_98/art3/art3.html

[7] Netscape's DevEdge Online for Developers http://developer.netscape.com/

[8] A Beginner's Guide to JavaScript by Rajesh Vijayakumar http://jsguide.simplenet.com/

[9] ECMAScript Language Specification http://www.ecma.ch

[10] Danny Goodman's JavaScript Pages http://www.dannyg.com/javascript/index.html

[11] RFC 2109, HTTP State Management Mechanism, February 1997

[12] The Webmaster Report of Magic Cookies http://www.gh-interactive.com/WRTOC.HTML

[13] Glossary of Internet Terms http://www.matisse.net/files/glossary.html

[14] Cookie Specification http://portal.research.bell-labs.com/~dmk/cookie.html