All Packages  Class Hierarchy  This Package  Previous  Next  Index

Class javax.servlet.http.HttpServlet

java.lang.Object
   |
   +----javax.servlet.GenericServlet
           |
           +----javax.servlet.http.HttpServlet

public abstract class HttpServlet
extends GenericServlet
The HttpServlet class is an abstract class that simplifies writing HTTP 1.0 servlets. It extends the GenericServlet base class and provides a protocol handling framework. Because it is abstract, servlet writers must subclass it and override at least one method. The methods normally overridden are:

By subclassing HttpServlet and implementing the doGet method, a servlet automatically supports the HTTP 1.0 protocol's GET, HEAD and conditional GET operations. Adding support for the getLastModified method improves performance by enabling smarter conditional GET support through caches.

To support HTTP 1.1 methods such as OPTIONS, PUT, DELETE, and TRACE, or other extensions, override the service method and handle those additional HTTP methods directly. Calling super.service from within the overridden service method provides the default handling on the other methods (such as GET).

Note that servlets typically run inside multi-threaded servers; servlets must be written to handle multiple service requests simultaneously. It is the servlet writer's responsibility to synchronize access to any shared resources. Such resources include in-memory data such as instance or class variables of the servlet, as well as external components such as files, database and network connections. Information on multithreaded programming in Java can be found in the Java Tutorial on Multithreaded Programming.


Constructor Index

 o HttpServlet()
The default constructor does nothing.

Method Index

 o doGet(HttpServletRequest, HttpServletResponse)
Performs the HTTP GET operation.
 o doPost(HttpServletRequest, HttpServletResponse)
Performs the HTTP POST operation.
 o getLastModified(HttpServletRequest)
Returns the time the requested entity was last modified.
 o service(HttpServletRequest, HttpServletResponse)
This is an HTTP-specific version of the Servlet.service method, which accepts HTTP specific parameters.
 o service(ServletRequest, ServletResponse)
Implements the high level Servlet.service method by delegating to the HTTP-specific service method.

Constructors

 o HttpServlet
 protected HttpServlet()
The default constructor does nothing.

Methods

 o 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. When overriding this method, servlet writers should set the headers for the requested entity (including content type, length, and encoding) then write that entity's data using the servlet output stream from the response. The response headers must be written 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.

By supporting GET, the HEAD operation is automatically supported. (HEAD is a GET that returns no body in the response; it just returns the request HEADer fields.) Entity data written for a HEAD request is ignored. Servlet writers can, as a simple performance optimization, omit writing response data for HEAD methods.

Note that 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, meaning that 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 - encapsulates the request to the servlet
resp - encapsulates the response from the servlet
Throws: ServletException
if the request could not be handled
Throws: IOException
if detected when handling the request
 o getLastModified
 protected long getLastModified(HttpServletRequest req)
Returns the time the requested entity was last modified. The default implementation returns a negative number, indicating that the modification time is unknown and hence should not be used for conditional GET operations or for other cache control operations.

Implementations supporting the GET request should override this method to provide an accurate object modification time. This makes browser and proxy caches work more effectively, reducing the load on server and network resources.

Parameters:
req - encapsulates the request to the servlet
Returns:
the time the requested entity was last modified, in milliseconds since the epoch. Negative numbers indicate this time is unknown.
 o 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. Subclassers should read any data from the request (for example, form parameters), set entity headers in the response, and then write any response data using the servlet output stream. The headers that are set should include content type, length, and encoding. 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. 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

This method does not need to be either "safe" or "idempotent". Operations requested through POST could be ones for which users need to be held accountable. Specific examples including updating stored data or buying things online.

Parameters:
req - encapsulates the request to the servlet
resp - encapsulates the response from the servlet
Throws: ServletException
if the request could not be handled
Throws: IOException
if detected when handling the request
 o service
 protected void service(HttpServletRequest req,
                        HttpServletResponse resp) throws ServletException, IOException
This is an HTTP-specific version of the Servlet.service method, which accepts HTTP specific parameters. This method is rarely overridden. Standard HTTP 1.0 requests are supported by dispatching to Java methods specialized to implement them.

Parameters:
req - encapsulates the request to the servlet
resp - encapsulates the response from the servlet
Throws: ServletException
if the request could not be handled
Throws: IOException
if detected when handling the request
 o service
 public void service(ServletRequest req,
                     ServletResponse res) throws ServletException, IOException
Implements the high level Servlet.service method by delegating to the HTTP-specific service method. This method is not normally overriden.

Parameters:
req - the servlet request
res - the servlet response
Throws: ServletException
if a servlet exception has occurred
Throws: IOException
if an I/O exception has occurred
Overrides:
service in class GenericServlet

All Packages  Class Hierarchy  This Package  Previous  Next  Index