SUN CERTIFIED WEB COMPONENT DEVELOPER FOR J2EE[tm] PLATFORM
Most of the following document comes straight from the Servlet 2.3 and JSP 1.2 specifications, The Servlet Model ;7题；
1.1 For each of the HTTP methods, GET, POST and PUT, identify the corresponding method in the HttpServlet class.
; HttpServlet is an abstract class that requires sub classing to create an HTTP servlet suitable for a Web site. HttpServlet
must override at least one method, usually one of the following:
doGet, if the servlet supports HTTP GET requests
doPost for the HTTP POST requests
doPut for the HTTP put requests
; There is no reason to override the class‟s service method since service handles HTTP requests by dispatching them
to handler methods for each type of HTTP request.
1.2 For each of the HTTP methods, GET, POST and HEAD identify the triggers that might cause a browser to use the method and identify benefits or functionality of the method.
; HTTP POST method allows the client to send data of unlimited length to the Web server a single time and is useful
when posting information such as credit card numbers. The information is usually posted from a HTML form. ; HTTP GET method retrieves whatever information (in the form of an entity) is identified by the Request-URI. If the
Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the
response and not the source text of the process, unless that text happens to be the output of the process. ; HTTP HEAD method is a GET request that returns no body in the response, on the request header fields. The client
sends a HEAD request when it wants to see only the headers of a response, such as Content-Type or Content-Length.
The HTTP HEAD method counts the number of output bytes in the response to set the Content-Length header
accurately. This method can be used for obtaining meta-information about the entity implied by the request without
; entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification.
The servlet container must write the headers before committing the response,
; because in HTTP the headers must be sent before the response body.
1.3 For each of the following operations, identify the interface and method name
that should be used:
Retrieve HTML form parameters from the request
; Request parameters are strings sent by the client to a servlet container as part of a request.
When the request is an HttpServletRequest, the attributes are populated from the URI query string and posted form
data. The parameters are stored by the servlet container as a set of name-value pairs. Multiple parameter values can
exist for any given parameter name. The following methods of the ServletRequest interface are available to access
The getParameterValues method returns an array of String objects containing all the parameter values associated
with a parameter name. The value returned from the getParameter method must be the first value in the array of String
objects returned by getParameterValues. All form data from both the query string and the post body are aggregated
into the request parameter set. The order of the aggregation puts the query string data before post body data. For
example, if a request is made with a query string of a=hello and a post body of a=goodbye&a=world, the resulting
parameter set would be ordered a=(hello, goodbye, world).
Retrieve a servlet initialization parameter
; The ServletConfig interface has the getInitParameter(String) as well as the
; public String getInitParameter(String)Returns a String containing the value of the named initialization parameter, or
null if the parameter does not exist.
; public Enumeration getInitParameterNames() Returns the names of the servlet‟s initialization parameters as an
Enumeration of String objects.
Retrieve HTTP request header information
; A servlet can access the headers of an HTTP request through the following methods of the HttpServletRequest
interface:getHeader; getHeaders; getHeaderNames
; The getHeader method returns a header given the name of the header. There can be multiple headers with the same
name, e.g. Cache-Control headers, in an HTTP request.
If there are multiple headers with the same name, the getHeader method returns the first head in the request. The
getHeaders method allows access to all the header values associated with a particular header name, returning an
Enumeration of String objects. Headers may contain String representations of int or Date data. ; The following convenience methods of the HttpServletRequest interface provide access to header data in a one of
If the getIntHeader method cannot translate the header value to an int, a
NumberFormatException is thrown. If the getDateHeader method cannot translate the header to a Date object, an
IllegalArgumentException is thrown.
Set an HTTP response header
; A servlet can set headers of an HTTP response via the following methods of the HttpServletResponse interface:
The setHeader method sets a header with a given name and value. A previous header is replaced by the new header. Where a set of header values exist for the name, the values are cleared and replaced with the new value. The addHeader method adds a header value to the set with a given name. If there are no headers already associated with the name, a new set is created. Headers may contain data that represents an int or a Date object.
; The following convenience methods of the HttpServletResponse interface allow a servlet to set a header using the
correct formatting for the appropriate data type:
To be successfully transmitted back to the client, headers must be set before the response is committed. Headers set after the response is committed will be ignored by the servlet container.
； Set the content type of the response
The ServletResponse interface has the method setContentType(String).
public void setContentType(java.lang.String type)Sets the content type of the response being sent to the client.The content type may include the type of character encoding used, for example: text/html; charset=ISO-8859-4. ； Acquire a text stream for the response
The ServletResponse interface has the method getWriter(). To send character data, use the PrintWriter object
returned by getWriter(). public java.io.PrintWriter getWriter() throws java.io.IOException Returns a PrintWriter
object that can send character text to the client. Calling flush() on the PrintWriter commits the response.
； Acquire a binary stream for the response
The ServletResponse interface has the method getOutputStream(). To send binary data in a MIME body response,
use the ServletOutputStream returned by getOutputStream(). public ServletOutputStream getOutputStream()
throws IOException Returns a ServletOutputStream suitable for writing binary data in the response. The servlet container does not encode the binary data.Calling flush() on the ServletOutputStream commits the response.
； Redirect an HTTP request to another URL
The HttpServletResponse interface has the method sendRedirect(String) method that sends a temporary redirect
response to the client using the specified redirect location URL. public void sendRedirect(String location) throws
IOException Sends a temporary redirect response to the client using the specified redirect location URL. This method can accept relative URLs; the servlet container must convert the relative URL to an absolute URL before sending the response to the client. If the location is relative without a leading '/' the container interprets it as relative to the current request URI. If the location is relative with a leading '/' the container interprets it as relative to the servlet container root.
If the response has already been committed, this method throws an IllegalStateException. After using this method, the response should be considered to be committed and should not be written to.
1.4 Identify the interface and method to access values and resources and to set object attributes within the
following three Web scopes:
; Request: ServletRequest interface has the following methods:
； public java.lang.Object getAttribute(java.lang.String name): Returns the value of the named attribute as an
Object, or null if noattribute of the given name exists.
； public java.util.Enumeration getAttributeNames():Returns an Enumeration containing the names of the attributes
availableto this request.
； public ServletInputStream getInputStream() throws java.io.IOException:Retrieves the body of the request as
binary data using a ServletInputStream.
； public void setAttribute(java.lang.String name, java.lang.Object o):Stores an attribute in this request. Attributes
are reset between requests.This method is most often used in conjunction with RequestDispatcher.
； public void removeAttribute(java.lang.String name): Removes an attribute from this request. This method is not
generallyneeded as attributes only persist as long as the request is being handled.
; Session: The HttpSession interface has the following methods:
； public java.lang.Object getAttribute(java.lang.String name): Returns the object bound with the specified name in
this session, or null if no object is bound under the name
； public java.util.Enumeration getAttributeNames():Returns an Enumeration of String objects containing the names
of all the objects bound to this session.
； public void setAttribute(java.lang.String name, java.lang.Object value): Binds an object to this session, using the
； public void removeAttribute(java.lang.String name): Removes the object bound with the specified name from this
session. If the session does not have an object bound with the specified name, this method does nothing.
; Context: The ServletContext has the following methods:
； A servlet can bind an object attribute into the context by name. Any attribute bound into a context is available to
any other servlet that is part of the same web application. The following methods of ServletContext interface allow
access to this functionality:
The ServletContext interface provides direct access to the hierarchy of static content documents that are part of
the web application, including HTML, GIF, and JPEG files, via the following methods of the ServletContext
The getResource and getResourceAsStream methods take a String with a leading “/” as argument which gives
the path of the resource relative to the root of the context. This hierarchy of documents may exist in the server‟s file
system, in a web application archive file, on a remote server, or at some other location. These methods are not
used to obtain dynamic content. For example, in a container supporting the JavaServer Pages specification 1, a
method call of the form getResource("/index.jsp") would return the JSP source code and not the processed
1.5 Given a life-cycle method: init, service or destroy, identify correct statements about its purpose or about how
and when it is invoked.
; Servlet:This interface defines methods to initialize a servlet, to service requests, and to remove a servlet from the server. These are known as life-cycle methods and are called in the following sequence:
The servlet is constructed, and then initialized with the init method. Any calls from clients to the service method are
handled. The servlet is taken out of service, then destroyed with the destroy method, then garbage collected and
finalized. In addition to the life-cycle methods, this interface provides the getServletConfig method, which the servlet
can use to get any startup information, and the getServletInfo method, which allows the servlet to return basic
information about itself, such as author, version, and copyright.
1.6 Use a RequestDispatcher to include or forward to a web resource.
; ServletContext:Servlets (and JSP pages also) may be given names via server administration or via a web application
deployment descriptor. A servlet instance can determine its name using ServletConfig.getServletName().Returns
a RequestDispatcher object that acts as a wrapper for the resource
located at the given path. A RequestDispatcher object can be used to forward a request to the resource or to
include the resource in a response. The resource can be dynamic or static. The pathname must begin with a "/"
and is interpreted as relative to the current context root. Use getContext to obtain a RequestDispatcher for
resources in foreign contexts.This method returns null if the ServletContext cannot return a equestDispatcher.
; ServletRequest: The pathname specified may be relative, although it cannot extend outside the current servlet context.
If the path begins with a "/" it is interpreted as relative to the current context root. This method returns null if the
servlet container cannot return a RequestDispatcher. The difference between this method and
ServletContext.getRequestDispatcher(java.lang.String) is that this method can take a relative path.
; Forward: Forwards a request from a servlet to another resource (servlet, JSP file, or HTML file) on the server. This
method allows one servlet to do preliminary processing of a request and another resource to generate the
response. For a RequestDispatcher obtained via getRequestDispatcher(), the ServletRequest object has its path
elements and parameters adjusted to match the path of the target resource.
forward should be called before the response has been committed to the client (before response body output has
been flushed). If the response already has been committed, this method throws an IllegalStateException.
Uncommitted output in the response buffer is automatically cleared before the forward.
; Include: Includes the content of a resource (servlet, JSP page, HTML file) in the response. In essence, this method
enables programmatic server-side includes. The ServletResponse object has its path elements and parameters
remain unchanged from the caller's. The included servlet cannot change the response status code or set headers;
any attempt to make a change is ignored.
The Structure and Deployment of Modern Servlet Web Applications;4题；
2.1 Identify the structure of the Web Application and Web Archive file, the name of the WebApp deployment descriptor and the name of the directories where you place the following:
The WebApp deployment descriptor. The WebApp class files. Any auxiliary JAR files
A web application exists as a structured hierarchy of directories. The root of this hierarchy serves as a document root files that are part of the application. For example, for a web application with the context path /catalog in a web container, the index.html file the base of the web application hierarchy can be served to satisfy a request from /catalog/index.html. Since the context path of an application determines the URL namespace of the contents of the web application, web containers must reject web applications defining a context path that is the same, determined case sensitively, as the context path of a web application already deployed that exposes a potentially conflicting URL namespace.
A special directory exists within the application hierarchy named “WEB-INF”. This directory contains all things related to the
application that aren‟t in the document root of the application. The WEB-INF node is not part of the public document tree of the application. No file contained in the WEB-INF directory may be served directly to a client by the container. However, the contents of the WEBINF directory are visible to servlet code using the getResource() and getResourceAsStream()
method calls on the ServletContext.Any application specific configuration information that the developer needs access to from servlet code yet does not wish to be exposed to the web client may be placed under this directory.Since requests are matched to resource mappings case-sensitively, client requests for „/WEB-INF/ foo‟, „/WEb-iNf/foo‟, for example, should not
result in contents of the web application located under /WEB-INF being returned, nor any form of directory listing thereof. The contents of the WEB-INF directory are: The /WEB-INF/web.xml
Deployment descriptor: The /WEB-INF/classes/*
Directory for servlet and utility classes. The classes in this directory are available to the application class loader. The /WEB-INF/lib/*.jar
Area for Java ARchive files. These files contain servlets, beans, and other utility classes useful to the web application. The web application class loader can load class from any of these archive files. The web application classloader loads classes from the WEB-INF/classes directory first, and then from library JARs in the WEB-INF/lib directory. Library JARs are loaded from in the same order as they appear in the WAR archive entries.
2.2 Match the name with a description of purpose or functionality, for each of the
following deployment descriptor elements:
The servlet element contains the declarative data of a servlet. If a jsp-file is specified and the load-on-startup element is
present, then the JSP should be precompiled and loaded.
servlet (icon?, servlet-name, display-name?, description?, (servlet-class|jsp-file), init-param*,
load-on-startup?, run-as?, security-role-ref*)>
The servlet-name element contains the canonical name of the servlet. Each servlet name is unique within the web
The servlet-class element contains the fully qualified class name of the servlet. Initialization parameters
The init-param element contains a name/value pair as an initialization param of the servlet
(param-name, param-value, description?)>
URL to named servlet mapping
The servlet-mapping element defines a mapping between a servlet and a url pattern
The servlet-name element contains the canonical name of the servlet. Each servlet name is unique within the web
The url-pattern element contains the url pattern of the mapping. Must follow the rules specified in Section 11.2 of the
Servlet API Specification.
The Servlet Container Model ;5题；
3.1 Identify the uses for and the interfaces (or classes) and methods to achieve the following features: Servlet context init parameters
The following methods of the ServletContext interface allow the servlet access to context initialization parameters associated with a web application through its deployment descriptor:
Initialization parameters are used by an application developer to convey setup information. Typical examples are a webmaster‟s e-mail address, or the name of a system that holds critical data.
Servlet context listener
Implementations of this interface receive notifications about changes to the servlet context of the web application they are part of. To receive notification events, the implementation class must be configured in the deployment descriptor for the web application.
public void contextInitialized(ServletContextEvent sce) Notification that the web application is ready to process requests. public void contextDestroyed(ServletContextEvent sce) Notification that the servlet context is about to be shut down. Servlet context attribute listener
ServletContextAttributeListener Implementations of this interface receive notifications of changes to the attribute list on the servlet context of a web application. To receive notification events, the implementation class must be configured in the deployment descriptor for the web application.
public void attributeAdded(ServletContextAttributeEvent scab) Notification that a new attribute was added to the servlet context. Called after the attribute is added.
public void attributeRemoved(ServletContextAttributeEvent scab) Notification that an existing attribute has been removed from the servlet context. Called after the attribute is removed.
public void attributeReplaced(ServletContextAttributeEvent scab) Notification that an attribute on the servlet context has been replaced. Called after the attribute is replaced.
Session attribute listeners
HttpSessionAttributeListener This listener interface can be implemented in order to get notifications of changes to the attribute lists of sessions within this web application.
public void attributeAdded(HttpSessionBindingEvent se) Notification that an attribute has been added to a session. Called after the attribute is added.
public void attributeRemoved(HttpSessionBindingEvent se) Notification that an attribute has been removed from a session. Called after the attribute is removed.
public void attributeReplaced(HttpSessionBindingEvent se) Notification that an attribute has been replaced in a session. Called after the attribute is replaced.
HttpSessionListener Implementations of this interface may are notified of changes to the list of active sessions in a web application. To receive notification events, the implementation class must be configured in the deployment descriptor for the web application.
public void sessionCreated(HttpSessionEvent se) Notification that a session was created.
public void sessionDestroyed(HttpSessionEvent se) Notification that a session was invalidated.
HttpSessionActivationListener Objects that are bound to a session may listen to container events notifying them that sessions will be passivated and that session will be activated. A container that migrates session between VMs or persists sessions is required to notify all attributes bound to sessions implementing HttpSessionActivationListener. HttpSessionBindingListener Causes an object to be notified when it is bound to or unbound from a session. The object is notified by an HttpSessionBindingEvent object. This may be as a result of a servlet programmer explicitly unbinding an attribute from a session, due to a session being invalidated, or die to a session timing out. 3.2 Identify the WebApp deployment descriptor element name that declares the following features: Servlet context init parameters
The context-param element contains the declaration of a web application‟s servlet context initialization parameters.
The param-name element contains the name of a parameter. Each parameter name must be unique in the web application.
The param-value element contains the value of a parameter.
Servlet context listener & Session attribute listeners & Servlet context attribute listeners
The listener element indicates the deployment properties for a web application listener bean.
The listener-class element declares a class in the application must be registered as a web application listener bean. The value is the fully qualified class name of the listener class.
The following example is the deployment grammar for registering two servlet context lifecycle listeners and an HttpSession listener. Suppose that com.acme.MyConnectionManager and com.acme.MyLoggingModule both implement
javax.servlet.ServletContextListener, and that com.acme.MyLoggingModule additionally implements
javax.servlet.HttpSessionListener. Also the developer wants com.acme.MyConnectionManager to be notified of servlet context lifecycle events before com.acme.MyLoggingModule. Here is the deployment descriptor for this application:
3.3 Distinguish the behavior of the following in a distributable:
o Servlet context init parameters
o Servlet context listener
o Servlet context attribute listeners
o Session attribute listeners See 3.2
Designing and Developing Servlets to Handle Server-side Expectations ;3题；
4.1 For each of the following cases, identify correctly constructed code for handling business logic exceptions and match that code with the correct statements about the code‟s behavior: Return an HTTP error using the sendError
response method; Return and HTTP error using the setStatus method.
Error Pages: To allow developers to customize the appearance of content returned to a web client when a servlet generates an error, the deployment descriptor defines a list of error page descriptions. The syntax allows the configuration of resources to be returned by the container either when a servlet sets a status code to indicate an error on the response, or if the servlet generates a Java exception or error that propagates to the container. If a status code indicating an error is set
on the response, the container consults the list of error page declarations for the web application that use the status-code syntax and attempts a match. If there is a match, the container serves back the resource as indicated by the location entry. A Servlet may throw the following exceptions during processing of a request:
o runtime exceptions or errors
o ServletExceptions or subclasses thereof
o IOExceptions or subclasses thereof
The web application may have declared error pages using the exception-type syntax. In this case the container matches the exception type by comparing the exception thrown with the list of error-page definitions that use the exception-type syntax. A match results in the container serving back the resource indicated in the location entry. The closest match in the class hierarchy wins.
If no error-page declaration containing an exception-type fits using the classhierarchy match, and the exception thrown is a ServletException or subclass thereof, the container extracts the wrapped exception, as defined by the ServletException.getRootCause() method. It makes a second pass over the error page declarations, again attempting the match against the error page declarations, but using the wrapped exception instead. Error-page declarations using the exception-type syntax in the deployment descriptor must be unique up to the classname of the exception-type. Similarly, error-page declarations using the status-code syntax must be unique in the deployment descriptor up to the status code. The error page mechanism described does not intervene when errors occur in servlets invoked using the RequestDispatcher. In this way, a servlet using the RequestDispatcher to call another servlets has the opportunity to handle errors generated in the servlet it calls.
If a Servlet generates an error that is unhandled by the error page mechanism as described above, the container must ensure the status code of the response is set to status code 500.
The following convenience methods exist in the HttpServletResponse interface:
The sendRedirect method will set the appropriate headers and content body to redirect the client to a different URL. It is legal to call this method with a relative URL path, however the underlying container must translate the relative path to a fully qualified URL for transmission back to the client. If a partial URL is given and, for whatever reason, cannot be converted
into a valid URL, then this method must throw an IllegalArgumentException.
The sendError method will set the appropriate headers and content body for an error message to return to the client. An optional String argument can be provided to the sendError method which can be used in the content body of the error.
These methods will have the side effect of committing the response, if it has not already been committed, and terminating it. No further output to the client should be made by the servlet after these methods are called. If data is written to the response after these methods are called, the data is ignored. If data has been written to the response buffer, but not returned to the client (i.e. the response is not committed), the data in the response buffer must be cleared and replaced with the data set by these methods. If the response is committed, these methods must throw an IllegalStateException. HttpServletResponse
public void sendError(int sc) throws java.io.IOException Sends an error response to the client using the specified status code and clearing the buffer. If the response has already been committed, this method throws an IllegalStateException. After using this method, the response should be considered to be committed and should not be written to. public void sendError(int sc, String msg) throws IOException Sends an error response to the client using the specified status clearing the buffer. The server defaults to creating the response to look like an HTML-formatted server error page containing the specified message, setting the content type to "text/html", leaving cookies and other headers unmodified. If an error-page declaration has been made for the web application corresponding to the status code passed in, it will be served back in preference to the suggested msg parameter. If the response has already been committed, this method throws an IllegalStateException. After using this method, the response should be considered to be committed and should not be written to.
public void setStatus(int sc) Sets the status code for this response. This method is used to set the return status code when there is no error (for example, for the status codes SC_OK or SC_MOVED_TEMPORARILY). If there is an error, and the caller wishes to invoke an defined in the web application, the sendError method should be used instead. 4.2 Given a set of business logic exceptions, identify the following: The configuration that the deployment descriptor uses to handle each exception; How to use the RequestDispatcher to forward the request to an error page; specify the handling declaratively in the deployment descriptor.
The error-page element contains a mapping between an error code or exception type to the path of a resource in the web application The error-code contains an HTTP error code, ex: 404 The exception type contains a fully qualified class name of a Java exception type.
The location element contains the location of the resource in the web application relative to the root of the web application. The value of the location must have a leading „/‟.
4.3 Identify the method used for the following: Write a message to the WebApp log; Write a message and an exception to the WebApp log.HttpServlet (inherited from GenericServlet)
public void log(java.lang.String msg) Writes the specified message to a servlet log file, prepended by the servlet's name. public void log(java.lang.String message, java.lang.Throwable t) Writes an explanatory message and a stack trace for a given Throwable exception to the servlet log file, prepended by the servlet's name
public void log(java.lang.String msg) Writes the specified message to a servlet log file, usually an event log. The name and type of the servlet log file is specific to the servlet container.
public void log(java.lang.String message, java.lang.Throwable throwable) Writes an explanatory message and a stack trace for a given Throwable exception to the servlet log file. The name and type of the servlet log file is specific to the servlet container, usually an event log.
Designing and Developing Servlets Using Session Management ;4题；
5.1 Identify the interface and method for each of the following: Retrieve a session object across multiple requests to the same or different servlets within the same WebApp.
Provides a way to identify a user across more than one page request or visit to a Web site and to store information about that user. The servlet container uses this interface to create a session between an HTTP client and an HTTP server. The session persists for a specified time period,across more than one connection or page request from the user. A session usually corresponds to one user, who may visit a site many times. The server can maintain a session in many ways such as using cookies or rewriting URLs.
Store objects into a session object.
public void setAttribute(String name, Object value) Binds an object to this session, using the name specified. If an object of the same name is already bound to the session, the object is replaced.
Retrieve objects from a session object.
public Object getAttribute(String name) Returns the object bound with the specified name in this session, or null if no object is bound under the name.
Respond to the event when a particular object is added to a session.
Causes an object to be notified when it is bound to or unbound from a session. The object is notified by an HttpSessionBindingEvent object. This may be as a result of a servlet programmer explicitly unbinding an attribute from a session, due to a session being invalidated, or die to a session timing out. After setAttribute(String) method executes and
if the new object implements HttpSessionBindingListener, the container calls HttpSessionBindingListener.valueBound. The
container then notifies any HttpSessionAttributeListeners in the web application. If an object was already bound to this session of this name that implements HttpSessionBindingListener, its HttpSessionBindingListener.valueUnbound method is called. If the value passed in is null, this has the same effect as calling
Respond to the event when a session is created and destroyed.
Implementations of this interface may are notified of changes to the list of active sessions in a web application. To receive notification events, the implementation class must be configured in the deployment descriptor for the web application. public void sessionCreated(HttpSessionEvent se) Notification that a session was created.
public void sessionDestroyed(HttpSessionEvent se) Notification that a session was invalidated.
Expunge a session object.
public void invalidate() Invalidates this session then unbinds any objects bound to it.
5.2 Given a scenario, state whether a session object will be invalidated.
In the HTTP protocol, there is no explicit termination signal when a client is no longer active. This means that the only mechanism that can be used to indicate when a client is no longer active is a timeout period. The default timeout period for sessions is defined by the servlet container and can be obtained via the
getMaxInactiveInterval method of the HttpSession interface. This timeout can be changed by the Developer using the
setMaxInactiveInterval method of the HttpSession interface. The timeout periods used by these methods are defined in
seconds. By definition, if the timeout period for a session is set to -
1, the session will never expire.
The session-config element defines the session parameters for this web application.
The session-timeout element defines the default session timeout interval for all sessions created in this web application. The specified timeout must be expressed in a whole number of minutes. If the timeout is 0 or less, the container ensures the default behavior of sessions is never to time out.
5.3 Given that URL-rewriting must be used for session management, identify the design requirement on session-related HTML pages.
Session tracking through HTTP cookies is the most used session tracking mechanism and is required to be supported by all servlet containers. The container sends a cookie to the client. The client will then return the cookie on each subsequent request to the server, unambiguously associating the request with a session. The name of the session tracking cookie must be
URL rewriting is the lowest common denominator of session tracking. When a client will not accept a cookie, URL rewriting may be used by the server as the basis for session tracking. URL rewriting involves adding data, a session id, to the URL path that is interpreted by the container to associate the request with a session. The session id must be encoded as a path parameter in the URL string. The name of the parameter must be jsessionid. Here is an example of a URL containing encoded path information:
Designing and Developing Secure Web Applications ;4题；
6.1 Identify correct descriptions or statements about the security issues:
o data integrity
o malicious code
o Web site attacks
A web application contains resources that can be accessed by many users. These resources often traverse unprotected, open networks such as the Internet. In such an environment, a substantial number of web applications will have security requirements. Although the quality assurances and implementation details may vary, servlet containers have mechanisms and infrastructure for meeting these requirements that share some of the following characteristics: Authentication: The means by which communicating entities prove to one another that they are acting on behalf of specific identities that are authorized for access.
Access control for resources: The means by which interactions with resources are limited to collections of users or programs for the purpose of enforcing integrity, confidentiality, or availability constraints.
Data Integrity: The means used to prove that information has not been modified by a third party while in transit. Confidentiality or Data Privacy: The means used to ensure that information is made available only to users who are authorized to access it.
6.2 Identify the deployment descriptor element names, and their structure, that
declare the following:
o a security constraint
o a Web resource
o the login configuration
o a security role
Security constraints are a declarative way of annotating the intended protection of web content.
A constraint consists of the following elements:
o web resource collection
o authorization constraint
o user data constraint
A web resource collection is a set of URL patterns and HTTP methods that describe a set of resources to be protected. All requests that contain a request path that matches a URL pattern described in the web resource collection is subject to the constraint. The container matches URL patterns defined in security constraints using the same algorithm described in this specification for matching client requests to servlets and static resources.
An authorization constraint is a set of security roles to which users must belong for access to resources described by the web resource collection. If the user is not part of an allowed role, the user must be denied access to the resource requiring it.
If the authorization constraint defines no roles, no user is allowed access to the portion of the web application defined by the
A user data constraint describes requirements for the transport layer of the client server: The requirement may be for content integrity (preventing data tampering in the communication process) or for confidentiality (preventing reading while in transit). The container must at least use SSL to respond to requests to resources marked integral or confidential. If the original request was over HTTP, the container must redirect the client to the HTTPS port. Where there are multiple security constraints specified, the container matches authentication methods and authorizations to security constraints on a „first
match wins‟ basis.
A security role is a logical grouping of users defined by the Application Developer or Assembler. When the application is deployed, roles are mapped by a Deployer to principals or groups in the runtime environment. A servlet container enforces declarative or programmatic security for the principal associated with an incoming request based on the security attributes of the principal. This may happen in either of the following ways: A deployer has mapped a security role to a user group in the operational environment. The user group to which the calling principal belongs is retrieved from its security attributes. The principal is in the security role only if the principal‟s user group matches the user group to which the security role has been
mapped by the deployer. A deployer has mapped a security role to a principal name in a security policy domain. In this case, the principal name of the calling principal is retrieved from its security attributes. The principal is in the security role only if
the principal name is the same as a principal name to which the security role was mapped. The security-constraint element is used to associate security constraints with one or more web resource collections.
The web-resource-collection element is used to identify a subset of the resources and HTTP methods on those resources within a web application to which a security constraint applies. If no HTTP methods are specified, then the security constraint applies to all HTTP methods.