UNIT III

Host Objects : Browsers and the DOM-Introduction to the Document Object Model DOM History
and Levels-Intrinsic Event Handling-Modifying Element Style-The Document Tree-DOM Event
Handling-Accommodating Noncompliant Browsers Properties of window-Case Study. Server-Side
Programming: Java Servlets- Architecture -Overview-A Servelet-Generating Dynamic Content-Life
Cycle- Parameter Data-Sessions-Cookies- URL Rewriting-Other Capabilities-Data Storage Servlets
and Concurrency-Case Study-Related Technologies.

Document Object Model:

Introduction:

The Document Object Model is a platform- and language-neutral interface that will allow programs
and scripts to dynamically access and update the content, structure and style of documents.

When we see a document using a browser, DOM presents documents as a hierarchy of HTML or
XML objects in the document. This hierarchy structure makes it possible for programmers or
browsers to access and delete, add, or edit their content, attributes and style.

The DOM makes it possible for programmers to write applications which work properly on all
browsers and servers and on all platforms.

What is DOM?

The DOM is a W3C (World Wide Web Consortium) standard.

The DOM defines a standard for accessing documents like XML and HTML:

"The W3C Document Object Model (DOM) is a platform and language-neutral interface that allows
programs and scripts to dynamically access and update the content, structure, and style of a
document."

The DOM is separated into 3 different parts / levels:

• Core DOM - standard model for any structured document

• XML DOM - standard model for XML documents
• HTML DOM - standard model for HTML documents
DOM History

The DOM originated as a specification to allow JavaScript scripts and Java programs to be
portable among Web browsers.
"Dynamic HTML" was the immediate ancestor of the Document Object Model, and it was
originally thought of largely in terms of browsers.
However, when the DOM Working Group was formed at W3C, it was also joined by vendors
in other domains, including HTML or XML editors and document repositories.
Several of these vendors had worked with SGML before XML was developed; as a result, the
DOM has been influenced by SGML Groves and the HyTime standard.
Some of these vendors had also developed their own object models for documents in order to
provide an API for SGML/XML editors or document repositories, and these object models have also
influenced the DOM.
The World Wide Web Consortium (W3C) developed the W3C Document Obeject Model in
response to the development of various proprietary models for HTML, particularly those used in
Web Browsers.
W3C began development of the DOM in mid-1990s. Although the W3C never produced a
specification for DOM 0, it was nonetheless a partially documented model and was included in the
specification of HTML4. By October 1998, the first specification of DOM (DOM 1) was released.
DOM 2 was issued in November 2000, with specifics on the style sheet object model and
style information manipulation. DOM 3 was released in April 2004 and is the current release of the
DOM specification.

Levels of DOM

The W3C DOM specifications are divided into levels, each of which contains required and
optional modules.
To claim to support a level, an application must implement all the requirements of the
claimed level and levels below it. As of 2005, Level 1, Level 2, and some modules of Level 3 are
W3C Recommendations which means they have reached their final form.
DOM Level 1 Specifications
Document Object Model Level 1 is a platform- and language-neutral interface that allows
programs and scripts to dynamically access and update the content, structure and style of documents.
The Document Object Model provides a standard set of objects for representing HTML and
XML documents, a standard model of how these objects can be combined, and a standard interface
for accessing and manipulating them.
Vendors can support the DOM as an interface to their proprietary data structures and APIs,
and content authors can write to the standard DOM interfaces rather than product-specific APIs, thus
increasing interoperability on the Web.
The goal of the DOM specification is to define a programmatic interface for XML and
HTML.

The DOM Level 1 specification is separated into two parts:

Core and HTML.

The Core DOM Level 1 section provides a low-level set of fundamental interfaces that can
represent any structured document, as well as defining extended interfaces for representing an XML
document.
These extended XML interfaces need not be implemented by a DOM implementation that
only provides access to HTML documents; all of the fundamental interfaces in the Core section must
be implemented.
A compliant DOM implementation that implements the extended XML interfaces is required
to also implement the fundamental Core interfaces, but not the HTML interfaces.
The HTML Level 1 section provides additional, higher-level interfaces that are used with the
fundamental interfaces defined in the Core Level 1 section to provide a more convenient view of an
HTML document.
A compliant implementation of the HTML DOM implements all of the fundamental Core
interfaces as well as the HTML interfaces.
DOM Level 2 Specifications

The Document Object Model Level 2 specification reflects cross-industry agreement on a

standard API (Applications Programming Interface) for manipulating documents and data through a
programming language (such as Java).
Created and developed by the W3C Document Object Model (DOM) Working Group, this
specification extends the platform- and language-neutral interface to access and update dynamically
a document's content, structure, and style first described by the DOM Level 1 Recommendation.
The DOM Level 2 provides a standard set of objects for representing Extensible Markup
Language (XML) documents and data, including namespace support, a style sheet platform which
adds support for CSS 1 and 2, a standard model of how these objects may be combined, and a
standard interface for accessing and manipulating them.

DOM Level 1 was designed for HTML 4.0 and XML 1.0. With DOM Level 2, authors can
take further advantage of the extensibility of XML.
Simply put, anywhere you use XML, you can now use the DOM to manipulate it. The
standard DOM interface makes it possible to write software (similar to plug-ins) for processing
customized tag-sets in a language- and platform-independent way.
A standard API makes it easier to develop modules that can be re-used in different
applications. DOM Level 2 provides support for XML namespaces, extending and improving the
XML platform.
As more sites move to XML for content delivery, DOM Level 2 emerges as a critical tool for
developing dynamic Web content.
The DOM defines a standard API that allows authors to write programs that work without
changes across tools and browsers from different vendors.
But beyond this, it provides a uniform way to produce programs that work across a variety of
different devices, so all may benefit from dynamically generated content.
 The DOM Level 2 Cascading Style Sheet (CSS) API makes it possible for a script author to
access and manipulate style information associated with contents, while preserving accessibility.
In web development, Cascading Style Sheets (CSS) is a stylesheet language used to describe
the presentation of a document written in a markup language.
Its most common application is to style web pages written in HTML and XHTML, but the
language can be applied to any kind of XML document, including SVG and XUL.
CSS is used by both the authors and readers of web pages to define colors, fonts, layout, and
other aspects of document presentation.
It is designed primarily to enable the separation of document content (written in HTML or a
similar markup language) from document presentation (written in CSS).
This separation can improve content accessibility, provide more flexibility and control in the
specification of presentational characteristics, and reduce complexity and repetition in the structural
content.
CSS can also allow the same markup page to be presented in different styles for different
rendering methods, such as on-screen, in print, by voice (when read out by a speech-based browser
or screen reader) and on Braille-based, tactile devices. CSS specifies a priority scheme to determine
which style rules apply if more than one rule matches against a particular element.
In this so-called cascade, priorities or weights are calculated and assigned to rules, so that the
results are predictable.

DOM Level 3 Specifications

The Document Object Model Events Level 3, a platform- and language-neutral interface that
allows programs and scripts to dynamically access and update the content, structure and style of
documents.
The goal of the DOM Level 3 Events specification is to expand upon the functionality
specified in the DOM Level 2 Event Specification.
 The specification does this by adding new interfaces which are complimentary to the
interfaces defined in the DOM Level 2 Event Specification as well as adding new event sets to those
already defined.
This specification requires the previously designed interfaces in order to be functional. It is
not designed to be standalone.
These interfaces are not designed to supercede the interfaces already provided but instead to
add to the functionality contained within them.

DOM Events allow event-driven programming languages like JavaScript, JScript,

ECMAScript, VBScript and Java to register various event handlers/listeners on the element nodes
inside a DOM tree, e.g. HTML, XHTML, XUL and SVG documents. Common/W3C events that
can be generated by most element nodes:
• Mouse events
• Keyboard events
• HTML frame/object events
• HTML form events
• User interface events
• Mutation events (notification of any changes to the structure of a document)

DOM Tree
DOM defines a logical tree-structure for an XML document. The basic building block of the
tree-structure is a node.
Nodes are generic containers that hold information about the elements, attributes, content,
comments and processing instructions that are stored in an XML document. An XML document can
be viewed as a single node that contains all the other nodes.
Consider the following code snippet:

<html>
<head>
<title>This is Shankar</title>
</head>
<body bgcolot=red>
<h1>Shankar</h1>
<p>DOM Tree</p>
</body>
</html>

This code is represented by using XML DOM, as shown below:

Difference between SAX and DOM-

• SAX is read only , DOM is read and write both.

• SAX is forward only where as DOM can access both was forward as well as backwards.
• SAX is an event based parser, but DOM is not.
• SAX parses the file as it reads where as the DOM loads the file into memory to parse the file.
• SAX does not have memory constraints where as the DOM has memory constraints as xml
file is loaded into the memory to parse the file.
Advantages of HTML DOM-

• Robust API for DOM tree.

• Relatively simple to modify the data structure and extract data.

Disadvantages of HTML DOM-

• Stores the entire document in memory.

• As DOM was written for any language, method naming conventions don't follow standard
java programming conventions

Handling events with the DOM

There are two basic ways of assigning an event handler. The first, most used, and certainly obtrusive
technique is embedding it directly into the HTML markup, while the second is just including the
event handler within the own piece of JavaScript code. Definitely, this last one is the recommended
approach, since it allows us to maintain the HTML and the JavaScript pieces residing in different
layers, making the code much more flexible and portable.

Let’s illustrate the first approach, inserting the event handler inside its own HTML tag, appending it
as a regular attribute:

<a href="http://www.devarticles.com" title="Opens link in a new window"

onclick="window.open('http://www.devarticles.com');return false;">Click here for great Web
Development articles</a>

In the above example, we’ve embedded the event handler along with the JavaScript code to be
executed. As we can see, the HTML markup is rather dirty using the inline approach. Now, let’s
implement the same functionality, this time by inserting the event handler within the JavaScript
code. Like this:

<script language="javascript">

openLink=function(){

var devlink=document.getElementById('devlink');

devlink.onclick=function(){

window.open('http://www.devarticles.com');
 return false;

window.onload=openLink;

</script>

And rewriting the HTML markup, in the following manner:

<a href="http://www.devarticles.com" title="Opens link in a new window" id="devlink">Click here

for great Web Development articles</a>

An explanation is in order here. In this second example, we’ve built a completely separate script,
inserted the "onclick" event handler within the "openLink()" function, and then executed the script
when the page is loaded (utilizing "onload", another event handler). Note how we have dynamically
attached a new function to the link, without the need of declaring the function name. Undoubtedly,
this last technique is much better and cleaner than the first one.

Now we’ve grasped the general concept for assigning event handlers. Having explained the two
conventional ways to assign event handlers, let’s go one step further and learn a little more about the
manner the DOM handles events.

Understanding the DOM event flow: Event Capture and Event Bubble

Detecting events and assigning the proper event handlers with the DOM is really a
straightforward process, introducing a new manner for doing this.

What’s more, the two conventional approaches previously described are perfectly supported
and valid.

For a complete understanding of assigning event handlers with the DOM, it’s really necessary
first to explain the way that events are handled within its context.

Let’s assume we’re representing an extremely common situation, where the user passes the
mouse over a regular link present in a Web document. From a user’s point of view, the process
consists of just hovering on the link and that’s all.

Period. On the other hand, for the DOM, things are more complex and technical, generating a set
of processes that involves two phases, called Event Capturing and Event Bubbling respectively.
 According to the previous example, when a user is passing the mouse over the link, these are the
events that take place, in the following order:

• The user moves the mouse over the document.

• The user moves the mouse over any tag containing the target <a> element.

• The user moves the mouse over the specific target <a> element.

The two processes prior to reaching the target <a> element are defined as taking place at the
event capturing phase. Once the event has reached the target, it travels back in the following way:

• The user moves the mouse over any tag containing the target <a> element.

• The user moves the mouse over the document.

The two last steps involve the event bubbling phase.

As we can see, the complete process, including the two phases, is quite lengthy, and considerably
different from a user’s point of view. In order to clarify this explanation, here are a couple of
diagrams that show the entire event, as interpreted by theDOM:
 The above images illustrate the event capturing and the event bubble phases, according to the
model implemented by the W3CDOM. As we’ll see shortly, there are significant differences
between the way that today’s browsers support event bubbling and event capturing.

Inline and scripted event handlers into action

Indeed, inline event handlers have been in use for a long time. As applications became more
complex, a clear need developed to implement HTML and JavaScript code in different layers.

Although basic, it’s quite useful to demonstrate how event phases are handled with inline
event handlers. Here’s is a sample of this:

<div id="testdiv" onclick="alert('Reacting to Event bubble phase');">

<p><a href="#">Click here activate the alert method</a></p>

</div>

In the previous example, we’ve attached the "onclick" event handler to the <div> element,
instead of assigning it directly to the link.

However, if we’re using a browser that supports event bubble, by just clicking on the <a>
element, the event will traverse the paragraph, reaching the <div> element and firing up the "alert"
box.

However, since messing up HTML with JavaScript is not recommended, the sample might be
rewritten as follows:

<script language="javascript">

var div=document.getElementById('testdiv');

div.onclick=function(){

alert('Reacting to Event bubble phase');

</script>
And the HTML would be reduced to this:

<div id="testdiv">

<p><a href="#">Click here activate the alert method</a></p>

</div>

For both cases, the result is the same, but the last one is definitely the way to go, since we removed
the inline event handler from the HTML.

At this point, we’ve playing around with some core definitions, explaining different
techniques for assigning event handling that have been in use for a long time, hopefully as a
reminder for choosing the right method when we’re dealing with event handlers nowadays.

In the browser arena, not so surprisingly, Nestcape and Microsoft came up with different
conclusions for event handling. Netscape’s approach was originally based in the capture phase,
establishing that any event should be handled when the event was traversing the Web document,
going through all of the containing elements, until reaching the target.

On the other hand, Microsoft branched to the event bubble direction, specifying that events
should take precedence at the bubble phase.

As we can see, the two models are radically opposed. Netscape 4 only supports event
capturing, while Internet Explorer only supports event bubbling. Mozilla, Opera 7 and Konqueror
support both approaches.

Older versions of Opera and iCab support neither. We’ll see more event handling browser
implementations in more detail shortly. As an introductory process, it’s more than enough.

Traditional ways of assigning event handlers

Let's first review (for most of us, at least) the 2 common and conventional ways of setting up
an event handler- via HTML, or scripting. In both cases, a function or code is attached at the end,
which is executed when the handler detects the specified event.

1) Via HTML, using attributes

We can define an event handler directly inside the relevant HTML tag, by embedding it as a
attribute. A piece of JavaScript is also included to tell the browser to perform something when the
event occurs. For example,
<a href="http://freewarejava.com" onMouseover="window.status='Click here for Java applets';return
true" onMouseout="window.status=''">Freewarejava.com</a>

Demo:

Here the event handler (onMouseover) is directly added inside the desired element (A), along with
the JavaScript to execute.

2) Via scripting

You can also assign and set up event handlers to elements using scripting, and inside your
script . This allows for the event handlers to be dynamically set up, without having to mess around
with the HTML codes on the page.

When setting up event handlers for an element directly inside your script, the code to execute
for the events must be defined inside a function.

Just look at the below, which does the same thing as above, but with the event handler
defined using scripting:

<a ID="test" href="http://freewarejava.com">Freewarejava.com</a>

<script type="text/javascript">

function changestatus(){
window.status="Click here for Java applets"
return true
}

function changebackstatus(){
window.status=''
}

document.getElementById("test").onmouseover=changestatus
document.getElementById("test").onmouseout=changebackstatus

</script>
Event Handlers:
onclick: Use this to invoke JavaScript upon clicking (a link, or form boxes)

onload: Use this to invoke JavaScript after the page or an image has finished loading.

onmouseover: Use this to invoke JavaScript if the mouse passes by some link

onmouseout: Use this to invoke JavaScript if the mouse goes pass some link

onunload: Use this to invoke JavaScript right after someone leaves this page.

Accommodating Non-Compliant Browser

This is used check the browser compatibility mode and display the web page based on the
compatibility.

If there is no possibility to display the web page in specified format then the page itself shows error
message indicating that the browser you are using is not supported by the current page use specified
browser to display the web page.

Example:

This is /www.ildashboard.com site is specifically designed for Internet Explorer (IE).

if we try to open this website in FireFox(FF) then you will get error message.

Our Application detected that you are using browser other than IE6 and above. This website has
been designed to best fit with Internet explorer 6.0 and above.

Your browser Detail :

Type = Firefox3.6.15
Name = Firefox
Version = 3.6.15
Major Version = 3
Minor Version = 0.6
Platform = WinNT
Is Beta = False
Is Crawler = False
Is AOL = False
Is Win16 = False
Is Win32 = True
Supports Frames = True
Supports Tables = True
Supports Cookies = True
Supports VBScript = False
Supports JavaScript = 1.4
Supports Java Applets = True
Supports ActiveX Controls = False

Detecting Host Objects

A famous example of this specification allowance (taken to a perverse extreme) is the case of host
objects in Internet Explorer that are implemented as ActiveX objects. Simply evaluating their
methods (as well as some properties) will cause an exception to be thrown.

var el = document.createElement('div');
var parent = el.offsetParent; // IE throws an exception here

if (window.external && window.external.addFavorite) {

// Though the method exists, IE will never get here

window.alert('Found it!');
} else {
window.alert('No such object or method');
}
Java Script Browser Detection

<div id="example"></div>

<script type="text/javascript">

txt = "<p>Browser CodeName: " + navigator.appCodeName + "</p>";

txt+= "<p>Browser Name: " + navigator.appName + "</p>";
txt+= "<p>Browser Version: " + navigator.appVersion + "</p>";
txt+= "<p>Cookies Enabled: " + navigator.cookieEnabled + "</p>";
txt+= "<p>Platform: " + navigator.platform + "</p>";
txt+= "<p>User-agent header: " + navigator.userAgent + "</p>";

document.getElementById("example").innerHTML=txt;

</script>

Server-Side Programming

Introduction to Java Servlets

Servlet: a java program that runs within the web server.

 Big applets require long download time

 Applets do not have access to all the system resources
 Server-side Java solves problems that applets face
o Code executed on the server side and only the results sent to client
o Servlets can access legacy applications and data sources
 Servlets are generic extensions to Java-enabled servers
 Servlets are secure, portable, and easy to use replacement for CGI
 Servlet is a dynamically loaded module that services requests from a Web server
 Servlets are executed within the Java Virtual Machine
 Because the servlet is running on the server side, it does not depend on browser compatibility

Servlet Architecture

Two packages make up the servlet architecture

 javax.servlet
Contains generic interfaces and classes that are implemented and extended by all servlets
 javax.servlet.http
Contains classes that are extended when creating HTTP-specific servlets
 The heart of servlet architecture is the interface class javax.servlet.Servlet
 It provides the framework for all servlets
 Defines five basic methods –init, service, destroy, getServletConfig and getServletInfo

 Read explicit data sent by client (form data)

 Read implicit data sent by client (request headers)
 Generate the results
 Send the explicit data back to client (HTML)
 Send the implicit data to client(status codes and response headers)
Life Cycle of Servlet

The life cycle of a servlet is controlled by the container in which the servlet has been deployed.
When a request is mapped to a servlet, the container performs the following steps.

1. If an instance of the servlet does not exist, the Web container

a. Loads the servlet class.
b. Creates an instance of the servlet class.
c. Initializes the servlet instance by calling the init method.
2. Invokes the service method, passing a request and response object.

Servlet Life Cycle Methods

The following are the life cycle methods of a servlet instance:

• init()
• service()
• destroy()

We will look into the each method in detail.

init()

This method is called once for a servlet instance. When first time servlet is called, servlet container
creates instance of that servlet and loaded into the memory. Future requests will be served by the
same instance without creating the new instance. Servlet by default multithreaded application.init()
method is used for inilializing servlet variables which are required to be passed from the deployment
descriptor web.xml. ServletConfig is passed as the parameter to init() method which stores all the
values configured in the web.xml. It is more convenient way to initialize the servlet.

service()

This method is called for the each request. This is the entry point for the every servlet request and
here we have to write our businesslogic or any other processes. This method takes
HttpServletRequest and HttpServletresponse as the parameters. It is not mandatory to write this
method, normally developers are interested in writing doGet() or doPost() methods which is by
default called from the service() method. If you override service(), it is your reponsibility to call the
appropriate methods. If you are not overridden the service() method, based on the types of the
request the methods will be called.
destroy()

This method will be called once for a instance. It is used for releasing any resources used by the
servlet instance. Most of the times it could be database connections, Fill IO operations, etc. destroy()
is called by the container when it is removing the instance from the servlet container. Servlet
instance is deleted or garbage collected by the container only when the web server issues shut down
or the instance is not used for a long time.

Servlets Step by Step

Hello ClientServlet.java

1: import java.io.*;
2: import javax.servlet.*;
3: import javax.servlet.http.*;
4:
5: public class HelloClientServlet extends HttpServlet
6: {
7: protected void doGet(HttpServletRequest req,
8: HttpServletResponse res)
9: throws ServletException, IOException
10: {
11: res.setContentType("text/html");
12: PrintWriter out = res.getWriter();
13: out.println("<HTML><HEAD><TITLE>Hello Client!</TITLE>"+
14: "</HEAD><BODY>Hello Client!</BODY></HTML>");
15: out.close();
16: }
17:
18: public String getServletInfo()
19: {
20: return "HelloClientServlet 1.0 by Stefan Zeiger";
21: }
22: }

how the Servlet works.

Lines 1 to 3 import some packages which contain many classes which are used by the Servlet
(almost every Servlet needs classes from these packages).

1: import java.io.*;
2: import javax.servlet.*;
3: import javax.servlet.http.*;

The Servlet class is declared in line 5. Our Servlet extends javax.servlet.http.HttpServlet, the
standard base class for HTTP Servlets.

5: public class HelloClientServlet extends HttpServlet

In lines 7 through 16 HttpServlet's doGet method is getting overridden.

7: protected void doGet(HttpServletRequest req,

8: HttpServletResponse res)
9: throws ServletException, IOException
10: {
...
16: }

In line 11 we use a method of the HttpServletResponse object to set the content type of the
response that we are going to send. All response headers must be set before a PrintWriter or
ServletOutputStream is requested to write body data to the response.

11: res.setContentType("text/html");

In line 12 we request a PrintWriter object to write text to the response message.

 12: PrintWriter out = res.getWriter();

In lines 13 and 14 we use the PrintWriter to write the text of type text/html (as specified through
the content type).

13: out.println("<HTML><HEAD><TITLE>Hello Client!</TITLE>"+

14: "</HEAD><BODY>Hello Client!</BODY></HTML>");

The PrintWriter gets closed in line 15 when we are finished writing to it.

15: out.close();

This line is included for completeness. It is not strictly necessary. The Web Server closes the
PrintWriter or ServletOutputStream automatically when a service call returns. An explicit call to
close() is useful when you want to do some post-processing after the response to the client has
been fully written. Calling close() tells the Web Server that the response is finished and the
connection to the client may be closed as well.

In lines 18 through 21 we override the getServletInfo() method which is supposed to return

information about the Servlet, e.g. the Servlet name, version, author and copyright notice. This is
not required for the function of the HelloClientServlet but can provide valuable information to
the user of a Servlet who sees the returned text in the administration tool of the Web Server.

18: public String getServletInfo()

19: {
20: return "HelloClientServlet 1.0 by Stefan Zeiger";
21: }

Advantages of Servlets

 Efficiency
More efficient –uses lightweight java threads as opposed to individual processes
 Persistency
Servlets remain in memory
Servlets can maintain state between requests
 Portability
Since servlets are written in Java, they are platform independent
 Robustness
Error handling, Garbage collector to prevent problems with memory leaks
Large class library –network, file, database, distributed object components, security, etc.
 Extensibility
Creating new subclasses that suite your needs
 Inheritance, polymorphism, etc.
 Security
Security provided by the server as well as the Java Security Manager
Eliminates problems associated with executing cgi scripts using operating system “shells”
 Powerful
Servlets can directly talk to web server
Facilitates database connection pooling, session tracking etc.
 Convenient
Parsing and decoding HTML form data, reading and setting HTTP headers, handling cookies,
etc.

Methods in HttpServlet

There are 7 methods present in the HttpServlet.

doGet().
doPost()
doPut().
doTrace()
doDelete()
doHead()
doOptions()

i. doGet

• protected void doGet(HttpServletRequest req,

HttpServletResponse resp) throws ServletException, IOException

• Performs the HTTP GET operation; the default implementation reports an HTTP
BAD_REQUEST error. Overriding this method to support the GET operation also
automatically supports the HEAD operation. (HEAD is a GET that returns no body in the
response; it just returns the request HEADer fields.)
• Servlet writers who override this method should read any data from the request, set entity
headers in the response, access the writer or output stream, and, finally, write any response
data. The headers that are set should include content type, and encoding. If a writer is to be
used to write response data, the content type must be set before the writer is accessed. In
general, the servlet implementor must write the headers before the response data because the
headers can be flushed at any time after the data starts to be written.
• Setting content length allows the servlet to take advantage of HTTP "connection keep alive".
If content length can not be set in advance, the performance penalties associated with not
using keep alives will sometimes be avoided if the response entity fits in an internal buffer.
• Entity data written for a HEAD request is ignored. Servlet writers can, as a simple
performance optimization, omit writing response data for HEAD methods. If no response data
is to be written, then the content length field must be set explicitly.
 • The GET operation is expected to be safe: without any side effects for which users might be
held responsible. For example, most form queries have no side effects. Requests intended to
change stored data should use some other HTTP method. (There have been cases of
significant security breaches reported because web-based applications used GET
inappropriately.)
• The GET operation is also expected to be idempotent: it can safely be repeated. This is not
quite the same as being safe, but in some common examples the requirements have the same
result. For example, repeating queries is both safe and idempotent (unless payment is
required!), but buying something or modifying data is neither safe nor idempotent.

Parameters:
• req - HttpServletRequest that encapsulates the request to the servlet
• resp - HttpServletResponse that encapsulates the response from the servlet
Throws: IOException
• if detected when handling the request
Throws: ServletException
• if the request could not be handled

Syntax of Using doGet

public void doGet (HttpServletRequest request,HttpServletResponse
response)
throws ServletException, IOException
{
...servlet code goes here...
}

ii. doPost

• protected void doPost(HttpServletRequest req,

HttpServletResponse resp) throws ServletException, IOException
• Performs the HTTP POST operation; the default implementation reports an HTTP
BAD_REQUEST error. Servlet writers who override this method should read any data from
the request (for example, form parameters), set entity headers in the response, access the
writer or output stream and, finally, write any response data using the servlet output stream.
The headers that are set should include content type, and encoding. If a writer is to be used to
write response data, the content type must be set before the writer is accessed. In general, the
servlet implementor must write the headers before the response data because the headers can
be flushed at any time after the data starts to be written.
• If HTTP/1.1 chunked encoding is used (that is, if the transfer-encoding header is present),
then the content-length header should not be set. For HTTP/1.1 communications that do not
use chunked encoding and HTTP 1.0 communications, setting content length allows the
servlet to take advantage of HTTP "connection keep alive". For just such communications, if
 content length can not be set, the performance penalties associated with not using keep alives
will sometimes be avoided if the response entity fits in an internal buffer.
• This method does not need to be either "safe" or "idempotent". Operations requested through
POST can have side effects for which the user can be held accountable. Specific examples
including updating stored data or buying things online.

Parameters:
• req - HttpServletRequest that encapsulates the request to the servlet
• resp - HttpServletResponse that encapsulates the response from the servlet
Throws: IOException
• if detected when handling the request
Throws: ServletException
• if the request could not be handled

Syntax of Using doPost

public void doPost (HttpServletRequest request,HttpServletResponse
response)
throws ServletException, IOException
{
...servlet code goes here...
}

iii. doPut

• protected void doPut(HttpServletRequest req,

HttpServletResponse resp) throws ServletException, IOException
• Performs the HTTP PUT operation; the default implementation reports an HTTP
BAD_REQUEST error. The PUT operation is analogous to sending a file via FTP.
• Servlet writers who override this method must respect any Content-* headers sent with the
request. (These headers include content-length, content-type, content-transfer-encoding,
content-encoding, content-base, content-language, content-location, content-MD5, and
content-range.) If the subclass cannot honor a content header, then it must issue an error
response (501) and discard the request. For more information, see the HTTP 1.1 RFC.
• This method does not need to be either "safe" or "idempotent". Operations requested through
PUT can have side effects for which the user can be held accountable. Although not required,
servlet writers who override this method may wish to save a copy of the affected URI in
temporary storage.

Parameters:
• req - HttpServletRequest that encapsulates the request to the servlet
• resp - HttpServletResponse that encapsulates the response from the servlet
Throws: IOException
• if detected when handling the request
 Throws: ServletException
• if the request could not be handled

iv. doTrace

protected void doTrace(HttpServletRequest req,

•
HttpServletResponse resp) throws ServletException, IOException
• Performs the HTTP TRACE operation; the default implementation of this method causes a
response with a message containing all of the headers sent in the trace request. This method is
not typically overridden.
Parameters:
• req - HttpServletRequest that encapsulates the request to the servlet
• resp - HttpServletResponse that encapsulates the response from the servlet
Throws: IOException
• if detected when handling the request
Throws: ServletException
• if the request could not be handled

v. doDelete

• protected void doDelete(HttpServletRequest req,

HttpServletResponse resp) throws ServletException, IOException
• Performs the HTTP DELETE operation; the default implementation reports an HTTP
BAD_REQUEST error. The DELETE operation allows a client to request a URI to be
removed from the server.
• This method does not need to be either "safe" or "idempotent". Operations requested through
DELETE can have side-effects for which users may be held accountable. Although not
required, servlet writers who subclass this method may wish to save a copy of the affected
URI in temporary storage.

Parameters:
• req - HttpServletRequest that encapsulates the request to the servlet
• resp - HttpServletResponse that encapsulates the response from the servlet
Throws: IOException
• if detected when handling the request
Throws: ServletException
• if the request could not be handled
Sessions

The basic premise of sessions is that only a session ID is stored on the client. On the server, that
ID is associated with other "real world" information such as a user name, shopping cart etc.

(This is a difference compared to using "raw" cookies to store information such as a user name
on the client.) HTTP sessions typically operate is as follows:

• when a client first requests a page where we need to start a session (e.g. the "login" page), our
server allocates a random session ID;
• that session ID is then communicated back to the client;
• whenever the client subsequently requests a page from our server (or relevant path from our
server), it sends back the same session ID;
• on the server, we can associate information with that session ID;
• on the server, we can eventually decide that the session has "expired", and/or provide the user
with a means to manually tell our server to "expire" the session.
• HTTP is the stateless protocol: it provides no way for the server to recognize that a sequence
of requests are all from the same client.

• Privacy advocates may consider this the feature, but it causes problems because many web
applications aren't stateless.

Session Tracking

To support the software that needs keep track of the state, Java Servlet technology provides an API
for managing sessions and allows several mechanisms for implementing sessions.

Session tracking is a great thing. Every user can be associated with a javax.servlet.http.HttpSession
object that servlets can use to store or retrieve information about that user.

Any set of arbitry can be saved by the Java objects in a session object.

For example, a user s session object provides a convenient location for a servlet to store the user s
shopping cart contents.

Methods to Track the Session

There are four types of techniques used in servlet to handle the session which are as follows:
1.URL Rewritting

2.Hidden Form Fieds

3.Http Session

4.Secure Socket Layer(SSL)

1.URL Rewritting
You can append some extra data on the end of the each URL that identifies the session, and the
server can associate that session identifier with data it has stored about that session only. This is also
an excellent solution, and even has advantage that it works with the browsers that don't support
cookies or where the user has disabled cookies. However, it has most of same problems as cookies,
namely that the server-side program has a lot of straightforward but tedious processing to do. In
addition, you have to be very careful that every URL returned to user (even via indirect means like
Location fields in server redirects) has the extra information appended. And, if the user leaves
session and comes back via a bookmark or link, the session information can be lost.

2.Hidden Form Fieds

HTML forms have an entry that looks like following: <input type="hidden" name="session"
value="...">. This means that, when the form is submitted, the specified name and value are included
in GET or POST data. This can be used to store information about the session. However, it has the
major disadvantage that it only works if every page is dynamically generated, since the whole point
is that each session has the unique identifier.

3.Http Session
The HttpSession interface is implemented by the services to provide an association between an
HTTP client and HTTP server. This association, or session, persists over multiple connection and/or
requests during a given time period. Sessions are used to maintain the state and user identity across
multiple page requests.

A session can be maintained either by using the cookies or by URL rewriting. To expose whether the
client supports cookies, HttpSession defines the isCookieSupportDetermined method and an
isUsingCookies method.
HttpSession defines the methods which store these types of data:

• Standard session properties, such as an identifier for the session, and the context for the
session.

• Application layer data, accessed using this interface and stored using the dictionary-like
interface.
4.Secure Socket Layer(SSL)
The Secure Sockets Layer protocol, or SSL, sits between application-level protocol (in this case
HTTP) and the low-level transport protocol (for the Internet, almost exclusively TCP/IP). It handles
the details of the security management using public key cryptography to encrypt all client/server
communication. SSL was introduced by Netscape with Netscape Navigator 1. It has since become
the de facto standard for the secure online communications and forms the basis of he Transport
Layer Security (TLS) protocol currently under development by the Internet Engineering Task Force.

SSL Version 2.0, the version first to gain the widespread acceptance, includes support for server
certificates only. It provides the authentication of the server, confidentiality, and integrity. Here's
how it works:

• A user connects to the secure site using the HTTPS (HTTP plus SSL) protocol. (You can
detect sites using the HTTPS protocol because their URLs begin with https: instead of http:.)

• The server signs its public key with its private key and sends it back to browser.

• The browser uses server's public key to verify that the same person who signed the key
actually owns it.

• The browser check to see whether a trusted certificate authority signed the key. If one didn't,
the browser asks the user if the key can be trusted and proceeds as directed.

• The client generates a symmetric ( DES) key for session, which is encrypted with the server's
public key and sent back to the server. This new key is used to encrypt all the subsequent
transactions. The symmetric key is used because of high computational cost of public key
cryptosystems.
Cookies

Cookies are small bits of textual information that the Web server sends to the browser and that the
browser returns unchanged when visiting the same Web site or domain later

You can use HTTP cookies to store information about a shopping session, and each subsequent
connection can look up the current session and then extract information about that session from
some location on the server machine. This is an excellent alternative, and is the most widely used
approach. However, even though servlets have a high-level and easy-to-use interface to cookies,
there are still a number of relatively tedious details that need to be handled:

• Extracting the cookie that stores the session identifier from the other cookies (there may be
many, after all),
• Setting an appropriate expiration time for the cookie (sessions interrupted by 24 hours
probably should be reset), and
• Associating information on the server with the session identifier (there may be far too much
information to actually store it in the cookie, plus sensitive data like credit card numbers
should never go in cookies).

Advantages of using Cookies

By having the server read information it sent the client previously, the site can provide visitors with
the number of conveniences:

• Identifying the user during an e-commerce session. Many on-line stores use the "shopping
cart" metaphor in which the user selects an item, adds it to his shopping cart, then continues
shopping. Since HTTP connection is closed after each page is sent, when the user select a
new item for his cart, how does the store know that he is the same user that put the previous
item in his cart? Cookies are the good way of accomplishing this. In fact, this is so useful that
servlet have an API specifically for this, and servlet authors don't need to manipulate cookies
directly to make use of it.
• Avoiding username and password. Many large sites require you to register in order to use
their service, but it is inconvenient to remember the username and password. Cookies are the
good alternative for low-security sites. When a user registers, a cookie is sent with a unique
user ID. When the client reconnects at the later date, the user ID is returned, the server looks
 it up, determines it belongs to the registered user, and doesn't require an explicit username
and password.
• Customizing a site. Many "portal" sites let you customize the look of main page. They use
cookies to remember what you wanted, so that you get that result initially for the next time.
I'll give an example like this later in this section of the tutorial.

• Focusing advertising. The search engine charge their customers much more for displaying
"directed" ads than "random" ads. That is, if you do a search on "Java Servlets", a search site
can charge much more for an ad for the servlets development environment than an ad for an
on-line travel agent. On the other hand, if the search had been "Bali Hotels", the situation
would be the reversed. The problem is that they have to show a random ad when you first
arrive and haven't yet performed the search, as well as when you search on something that
doesn't match any ad categories. Cookies let them remember "Oh, that's the person who was
searching for such and such previously" and displays an appropriate (read "high priced") ad
instead of a random (read "cheap") one.
Creating Cookies
A Cookie is created by calling Cookie constructor, which takes two string: the cookie name and the
cookie value
The following example describes how to create a cookie
Cookie userCookie = new Cookie("user", "uid1234"); response.addCookie(userCookie);

URLRewriting

URLRewriting can be used in place where we don't want to use cookies.

It is used to maintain the session. Whenever the browser sends a request then it is always
interpreted as a new request because http protocol is a stateless protocol as it is not persistent.

Whenever we want that out request object to stay alive till we decide to end the request object
then, there we use the concept of session tracking.

In session tracking firstly a session object is created when the first request goes to the server.
Then server creates a token which will be used to maintain the session.

The token is transmitted to the client by the response object and gets stored on the client
machine. By default the server creates a cookie and the cookie get stored on the client machine.