All Packages Class Hierarchy This Package Previous Next Index
Object | +----GenericServlet | +----javax.servlet.http.HttpServlet
GenericServlet
base class and provides an framework
for handling the HTTP protocol. Because it is an abstract class,
servlet writers must subclass it and override at least one method.
The methods normally overridden are:
doGet
, if HTTP GET requests are supported.
Overriding the doGet
method automatically also
provides support for the HEAD and conditional GET operations.
Where practical, the getLastModified
method should
also be overridden, to facilitate caching the HTTP response
data. This improves performance by enabling smarter
conditional GET support.
doPost
, if HTTP POST requests are supported.
doPut
, if HTTP PUT requests are supported.
doDelete
, if HTTP DELETE requests are supported.
init
and
destroy
, if the servlet writer needs to manage
resources that are held for the lifetime of the servlet.
Servlets that do not manage resources do not need to specialize
these methods.
getServletInfo
, to provide descriptive
information through a service's administrative interfaces.
Notice that the service
method is not typically
overridden. The service
method, as provided, supports
standard HTTP requests by dispatching them to appropriate methods,
such as the methods listed above that have the prefix "do". In
addition, the service method also supports the HTTP 1.1 protocol's
TRACE and OPTIONS methods by dispatching to the doTrace
and doOptions
methods. The doTrace
and
doOptions
methods are not typically overridden.
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.
Servlet.service
method, which accepts HTTP specific
parameters.
Servlet.service
method by
delegating to the HTTP-specific service method.
public HttpServlet()
protected void doDelete(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException
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.
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException
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.
protected void doOptions(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException
doGet
method, then
this method will return the following header: Allow: GET,HEAD,TRACE,OPTIONS
This method does not need to be overridden unless the servlet implements new methods, beyond those supported by the HTTP/1.1 protocol.
protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException
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.
protected void doPut(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException
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.
protected void doTrace(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException
protected long getLastModified(HttpServletRequest req)
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.
protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException
Servlet.service
method, which accepts HTTP specific
parameters. This method is rarely overridden. Standard HTTP
requests are supported by dispatching to Java methods
specialized to implement them.
public void service(ServletRequest req, ServletResponse res) throws ServletException, IOException
Servlet.service
method by
delegating to the HTTP-specific service method. This method is
not normally overriden.
All Packages Class Hierarchy This Package Previous Next Index