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=changestatusdocument.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 = FirefoxVersion = 3.6.15

Major Version = 3Minor Version = 0.6Platform = WinNTIs Beta = FalseIs Crawler = FalseIs AOL = FalseIs Win16 = FalseIs Win32 = TrueSupports Frames = TrueSupports Tables = TrueSupports Cookies = TrueSupports VBScript = FalseSupports JavaScript = 1.4Supports Java Applets = TrueSupports 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 cliento 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 containera. 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, IOException10: {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, IOException10: { ...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

EfficiencyMore efficient –uses lightweight java threads as opposed to individual processes

PersistencyServlets remain in memory Servlets can maintain state between requests

PortabilitySince servlets are written in Java, they are platform independent

RobustnessError 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 needsInheritance, polymorphism, etc.

SecuritySecurity provided by the server as well as the Java Security ManagerEliminates problems associated with executing cgi scripts using operating system “shells”

PowerfulServlets can directly talk to web serverFacilitates database connection pooling, session tracking etc.

ConvenientParsing 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.