## Jakarta Servlet
Servlet - 5.0
Specification Assertion Detail

Totals | Total | Active | Deprecated | Removed
# of Assertions | 566 | 543 | 2 | 21
# of Required Assertions | 530 | 510 | 2 | 18
# of Optional Assertions | 36 | 33 | 0 | 3

ID | Chapter | Section | Description | Required | Dependency | Implementation Specific | Defined by | Status | Testable
Servlet:SPEC:1 | 1 | 2 | All servlet containers must support HTTP/1.0 and HTTP/1.1 protocols | true |  | false | technology | active | true
Servlet:SPEC:2 | 1 | 2 | Java SE 7 is the minimum version of the underlying Java platform with which containers must be built. | true |  | false | technology | active | false
Servlet:SPEC:269 | 1 | 6.1 | In Servlet 2.5, metadata-complete only affected the scanning of annotations at deployment time. The notion of web-fragments did not exist in servlet 2.5. However in servlet 3.0 and later, metadata-complete affects scanning of all annotations that specify deployment information and web-fragments at deployment time. The version of the descriptor MUST not affect which annotations you scan for in a web application. An implementation of a particular version of the specification MUST scan for all annotations supported in that configuration, unless metadata-complete is specified. | true |  | false | technology | active | true
Servlet:SPEC:3 | 2 | 2 | A servlet hosted in a non-distributed environment, the servlet container must use only one instance per servlet declaration. | true |  | false | technology | active | true
Servlet:SPEC:4 | 2 | 2 | A servlet deployed as part of an application marked in the deployment descriptor as distributable, a container may have only one instance per servlet declaration per virtual machine (VM). | true |  | false | technology | active | false
Servlet:SPEC:5 | 2 | 3 | The life cycle of a servlet is expressed in the API by the 'init', 'service', and 'destroy' methods of the jakarta.servlet.Servlet interface that all servlets must implement directly, or indirectly through the GenericServlet or HttpServlet abstract classes. | true |  | false | technology | active | true
Servlet:SPEC:6 | 2 | 3.1 | The servlet container is responsible for loading and instantiating servlets. | true |  | false | technology | active | true
Servlet:SPEC:6.1 | 2 | 3.1 | When the servlet engine is started, needed servlet classes must be located by the servlet container using normal Java class loading facilities. | true |  | false | technology | active | false
Servlet:SPEC:7 | 2 | 3.2 | After the servlet object is instantiated, the container must initialize the servlet before it can handle requests from clients by calling the init method of the Server interface with a unique (per servlet declaration) object implementing the ServerConfig interface. | true |  | false | technology | active | true
Servlet:SPEC:8 | 2 | 3.2.1 | The servlet container must not call the destroy method on a Servlet that threw an Exception during the initialization process. | true |  | false | technology | active | true
Servlet:SPEC:9 | 2 | 3.2.1 | A servlet throwing an UnavailableException that indicates a minimum time of unavailability, the container must wait for the period of time specified to pass before creating and initializing a new servlet instance. | true |  | false | technology | active | false
Servlet:SPEC:10 | 2 | 3.3.1 | For servlets not implementing the SingleThreadModel interface, if the service method (or methods such as doGet or doPost which are dispatched to the service method of the HttpServlet abstract class) has been defined with the synchronized keyword, the servlet container must serialize request through it. | true |  | false | technology | deprecated | true
Servlet:SPEC:11 | 2 | 3.3.2 | If a permanent unavailability is indicated by the UnavailableException, the servlet container must remove the servlet from service, call its destroy method, and release the servlet instance. | true |  | false | technology | active | true
Servlet:SPEC:11.1 | 2 | 3.3.2 | Any requests refused by the container by the cause, must be returned with a SC_NOT_FOUND(404) response. | true |  | false | technology | active | true
Servlet:SPEC:270 | 2 | 3.3.3 | public ServletRequest getRequest() - returns the request that was used to initialize the AsyncContext by calling one of the startAsync methods. Calling getRequest when complete or any of the dispatch methods has been previously called in the asynchronous cycle will result in an IllegalStateException. | true |  | false | technology | active | true
Servlet:SPEC:271 | 2 | 3.3.3 | public ServletResponse getResponse() - returns the response that was used to initialize the AsyncContext by calling one of the startAsync methods. Calling getResponse when complete or any of the dispatch methods has been previously called in the asynchronous cycle will result in an IllegalStateException. | true |  | false | technology | active | true
Servlet:SPEC:272 | 2 | 3.3.5 | The servlet container provides an HTTP upgrade mechanism. However the servlet container itself does not have knowledge about the upgraded protocol. The protocol processing is encapsulated in the HttpUpgradeHandler. Data reading or writing between the servlet container and the HttpUpgradeHandler is in byte streams.. | true |  | false | technology | active | true
Servlet:SPEC:273 | 2 | 3.3.5 | When an upgrade request is received, the servlet can invoke the HttpServletRequest.upgrade method, which starts the upgrade process. This method instantiates the given HttpUpgradeHandler class. The returned HttpUpgradeHandler instance may be further customized. The application prepares and sends an appropriate response to the client. After exiting the service method of the servlet, the servlet container completes the processing of all filters and marks the connection to be handled by the HttpUpgradeHandler. It then calls the HttpUpgradeHandler's init method, passing a WebConnection to allow the protocol handler access to the data streams. | true |  | false | technology | active | true
Servlet:SPEC:274 | 2 | 3.3.5 | The servlet filters only process the initial HTTP request and response. They are not involved in subsequent communications. In other words, they are not invoked once the request has been upgraded. | true |  | false | technology | active | true
Servlet:SPEC:275 | 2 | 3.3.5 | The HttpUpgradeHandler may use non blocking IO to consume and produce messages. | true |  | false | technology | active | true
Servlet:SPEC:299 | 2 | 3.3.5 | When the upgrade processing is done, HttpUpgradeHandler.destroy will be invoked. | true |  | false | technology | active | true
Servlet:SPEC:12 | 2 | 3.4 | When the servlet container determines that a Servlet should be removed from service, it must call the destroy method of the Servlet interface to allow the servlet to release any resources it is using and save any persistent state. | true |  | false | technology | active | false
Servlet:SPEC:12.1 | 2 | 3.4 | Before the container calls the destroy method, it must allow any threads that are currently running in the service method of the servlet to complete execution, or exceed a server defined time limit. | true |  | false | technology | active | false
Servlet:SPEC:12.2 | 2 | 3.4 | Once the destroy method is called on a servlet instance, the container must not route other requests to that instance of the Servlet. | true |  | false | technology | active | false
Servlet:SPEC:12.3 | 2 | 3.4 | After the destroy method completes, the servlet container must release the servlet instance so that it is eligible for garbage collection. | true |  | false | technology | active | false
Servlet:SPEC:20 | 3 | 1 | Data from the query string and the post body are aggregated into the request parameter set. Query string data is presented before post body data. | true |  | false | technology | active | true
Servlet:SPEC:21 | 3 | 1 | Path parameters that are a part of a GET request (as defined by HTTP 1.1) are not exposed by these APIs. They must be parsed from the String values returned by the getRequestURI method or the getPathInfo method. | true |  | false | technology | active | true
Servlet:SPEC:22 | 3 | 1.1 | The following conditions must be met before post form data will be populated to the parameter set: | true |  | false | technology | active | true
Servlet:SPEC:22.1 | 3 | 1.1 | The request is an HTTP or HTTPS request | true |  | false | technology | active | true
Servlet:SPEC:22.2 | 3 | 1.1 | The HTTP method is POST | true |  | false | technology | active | true
Servlet:SPEC:22.3 | 3 | 1.1 | The content type is application/x-www-form-urlencoded | true |  | false | technology | active | true
Servlet:SPEC:22.4 | 3 | 1.1 | The servlet has made an initial call to any of the getParameter family of methods on the request object. | true |  | false | technology | active | true
Servlet:SPEC:22.5 | 3 | 1.1 | If the conditions are not met, and the post form data is not included in the parameter set, the post data must still be available to the servlet via the request object's input stream. | true |  | false | technology | active | true
Servlet:SPEC:22.6 | 3 | 1.1 | If the conditions are met, post form data will no longer be available for reading directly from the request object?s input stream. | true |  | false | technology | active | true
Servlet:SPEC:276 | 3 | 2 | Servlet container allows files to be uploaded when data is sent as multipart/form-data. | true |  | false | technology | active | true
Servlet:SPEC:277 | 3 | 2 | The servlet container provides multipart/form-data processing if any one of the following conditions is met. | true |  | false | technology | active | true
Servlet:SPEC:277.1 | 3 | 2 | The servlet handling the request is annotated with the @MultipartConfig as defined in Section 8.1.5, "@MultipartConfig" on page8-68. | true |  | false | technology | active | true
Servlet:SPEC:277.2 | 3 | 2 | Deployment descriptors contain a multipart-config element for the servlet handling the request. | true |  | false | technology | active | true
Servlet:SPEC:278 | 3 | 2 | How data in a request of type multipart/form-data is made available depends on whether the servlet container provides multipart/form-data processing: | true |  | false | technology | active | true
Servlet:SPEC:278.1 | 3 | 2 | If the servlet container provides multipart/form-data processing, the data is made available through the following methods in HttpServletRequest: | true |  | false | technology | active | true
Servlet:SPEC:278.1.1 | 3 | 2 | public Collection <Part> getParts() | true |  | false | technology | active | true
Servlet:SPEC:278.1.2 | 3 | 2 | public Part getPart(String name) | true |  | false | technology | active | true
Servlet:SPEC:278.1.3 | 3 | 2 | Each part provides access to the headers, content type related with it and the content via the Part.getInputStream method. | true |  | false | technology | active | true
Servlet:SPEC:278.1.4 | 3 | 2 | For parts with form-data as the Content-Disposition, but without a filename, the string value of the part will also be available through the getParameter and getParameterValues methods on HttpServletRequest, using the name of the part. | true |  | false | technology | active | true
Servlet:SPEC:278.2 | 3 | 2 | If the servlet container does not provide the multi-part/form-data processing, the data will be available through the HttpServletReuqest.getInputStream. | true |  | false | technology | active | true
Servlet:SPEC:23 | 3 | 5 | (Servlet Path)This path starts with a '/' character except in the case where the request is matched with the '/*' or "" pattern, in which case it is an empty string. | true |  | false | technology | active | true
Servlet:SPEC:24 | 3 | 5 | (Servlet Path)The path section that directly corresponds to the mapping which activated this request. This path starts with a '/' character except... | true |  | false | technology | active | true
Servlet:SPEC:25 | 3 | 5 | The part of the request path that is not part of the Context Path or the Servlet Path. It is either null if there is no extra path, or is a string with a leading '/'. | true |  | false | technology | active | true
Servlet:SPEC:279 | 3 | 5 | It is important to note that, except for URL encoding differences between the request URI and the path parts, the following equation is always true: requestURI = contextPath + servletPath + pathInfo | true |  | false | technology | active | true
Servlet:SPEC:280 | 3 | 6 | In situations where the servlet container cannot determine a valid file path for these methods, such as when the Web application is executed from an archive, on a remote file system not accessible locally, or in a database, these methods must return null. | true |  | false | technology | active | true
Servlet:SPEC:281 | 3 | 6 | Resources inside the META-INF/resources directory of JAR file must be considered only if the container has unpacked them from their containing JAR file when a call to getRealPath() is made, and in this case MUST return the unpacked location. | true |  | false | technology | active | true
Servlet:SPEC:282 | 3 | 7 | The ReadListener provides the following callback methods for non blocking IO - | true |  | false | technology | active | true
Servlet:SPEC:282.1 | 3 | 7 | ReadListener.onDataAvailable(). The onDataAvailable method is invoked on the ReadListener when data is available to read from the incoming request stream. The container will invoke the method. This method will be invoked once for every set of data available. | true |  | false | technology | active | true
Servlet:SPEC:282.2 | 3 | 7 | ReadListener.onAllDataRead(). The onAllDataRead method is invoked when you have finished reading all the data for the ServletRequest for which the listener was registered. | true |  | false | technology | active | true
Servlet:SPEC:282.3 | 3 | 7 | ReadListener.onError(Throwable t). The onError method is invoked if there is any error or exception that occurs while processing the request. | true |  | false | technology | active | true
Servlet:SPEC:282.5 | 3 | 7 | boolean ServletInputStream.isFinished(). The isFinished method returns true when all the data for the request associated with the ServletInputStream has been read. Otherwise it returns false. | true |  | false | technology | active | true
Servlet:SPEC:282.6 | 3 | 7 | boolean ServletInputStream.isReady(). The isReady method returns true if data can be read without blocking. If no data can be read without blocking it returns false. If isReady returns false it is illegal to call the read method and an IllegalStateException MUST be thrown. | true |  | false | technology | active | true
Servlet:SPEC:282.7 | 3 | 7 | void ServletInputStream.setReadListener(ReadListener listener). Sets the ReadListener defined above to get invoked to read data in a non-blocking fashion. Once the listener is associated for the given ServletInputStream, the container invokes the methods on the ReadListener when data is available to read, all the data has been read or if there was an error processing the request. Registering a ReadListener will start non-blocking IO. It is illegal to switch to the traditional blocking IO at that point and an IllegalStateException MUST be thrown. A subsequent call to setReadListener in the scope of the current request is illegal and an IllegalStateException MUST be thrown.. | true |  | false | technology | active | true
Servlet:SPEC:26 | 3 | 9 | If a request has been transmitted over a secure protocol, such as HTTPS, this information must be exposed via the isSecure method of the ServletRequest interface. The Web container must expose the following attributes to the servlet programmer: | true |  | false | platform | active | true
Servlet:SPEC:26.1 | 3 | 9 | attribute: cipher suite - attribute name: jakarta.servlet.request.cipher_suite - Java type: String | true |  | false | platform | active | true
Servlet:SPEC:26.2 | 3 | 9 | attribute: bit size of the algorithm - attribute name: jakarta.servlet.request.key_size - Java type: Integer | true |  | false | platform | active | true
Servlet:SPEC:26.4 | 3 | 9 | attribute: SSL session id - attribute name: jakarta.servlet.request.ssl_session_id - Java type: String | true |  | false | platform | active | true
Servlet:SPEC:26.3 | 3 | 9 | If there is an SSL certificate associated with the request, it must be exposed by the servlet container to the servlet programmer as an array of objects of type java.security.cert.X509Certificate and accessible via a ServletRequest attribute of jakarta.servlet.request.X509Certificate. | true |  | false | platform | active | true
Servlet:SPEC:26.3.1 | 3 | 9 | The order of this array (associated with the jakarta.servlet.request.X509Certificate request attribute) is being defined as being in ascending order of trust. The first certificate in the chain is the one set by the client, the next is the one used to authenticate first, and so on. | true |  | false | platform | active | true
Servlet:SPEC:27 | 3 | 11 | The default encoding of a request the container uses to create the request reader and parse POST data must be "ISO-8859-1", if none has been specified by the client request. | true |  | false | technology | active | true
Servlet:SPEC:28 | 3 | 11 | Calling the (setCharacterEncoding(String enc)) method after once data has been read will not affect the encoding. | true |  | false | technology | active | true
Servlet:SPEC:29 | 3 | 12 | Each request object is valid only within the scope of a servlet's service method, or within the scope of a filter's doFilter method, unless the asynchronous processing is enabled for the component and the startAsync method is invoked on the request object. | true |  | false | technology | active | false
Servlet:SPEC:283 | 3 | 12 | In the case where asynchronous processing occurs, the request object remains valid until complete is invoked on the AsyncContext. | true |  | false | technology | active | true
Servlet:SPEC:305 | 3 | 12 | In case of upgrade, the above is still true. | true |  | false | technology | active | true
Servlet:SPEC:13 | 4 | 2 | There is only one instance object of the ServletContext interface associated with each web application deployed into a container. | true |  | false | technology | active | true
Servlet:SPEC:14 | 4 | 2 | In cases where the container is distributed over many virtual machines, a Web application will have an instance of the ServletContext for each JVM. | true |  | false | technology | active | false
Servlet:SPEC:15 | 4 | 2 | A default ServletContext must be made available to servlets not deployed as a web application. | true |  | false | technology | active | false
Servlet:SPEC:15.1 | 4 | 2 | In a distributed container, the default ServletContext is non-distributable and must only exist in one VM. | true |  | false | technology | active | false
Servlet:SPEC:16 | 4 | 5 | Any attribute bound into a context is available to any other servlet that is part of the same web application. | true |  | false | technology | active | false
Servlet:SPEC:17 | 4 | 7 | Web servers may support multiple logical hosts sharing one IP address on a server. This capability is sometimes referred to as "virtual hosting". In this case, each logical host must have its own servlet context or set of servlet contexts. Servlet contexts can not be shared across virtual hosts. | true |  | false | technology | active | false
Servlet:SPEC:18 | 4 | 8 | Although a Container Provider implementation of a class reloading scheme for ease of development is not required, any such implementation must ensure that all servlets, and classes that they may use, are loaded in the scope of a single class loader. | false |  | true | technology | active | false
Servlet:SPEC:18.1 | 4 | 8 | The full semantics of notification to session binding listeners should be supported by containers for use in the monitoring of session termination upon class reloading. | false |  | true | technology | active | false
Servlet:SPEC:19 | 4 | 8.1 | Servlet containers must provide a private temporary directory for each servlet context. | true |  | false | technology | active | true
Servlet:SPEC:19.1 | 4 | 8.1 | (The container must) make it available via the jakarta.servlet.context.tempdir context attribute. The objects associated with the attribute must be of type java.io.File. | true |  | false | technology | active | true
Servlet:SPEC:19.2 | 4 | 8.1 | Servlet containers are required to ensure that the contents of the temporary directory of one servlet context is not visible to the servlet contexts of other Web applications running on the servlet container. | true |  | false | technology | active | true
Servlet:SPEC:30 | 5 | 1 | A servlet container is allowed, but not required, to buffer output going to the client for efficiency purposes. | false |  | false | technology | active | false
Servlet:SPEC:31 | 5 | 1 | If a response has been committed and the reset or resetBuffer methods have been called, an IllegalStateException must be thrown. The response and its associated buffer will be unchanged. | true |  | false | technology | active | true
Servlet:SPEC:32 | 5 | 1 | When using a buffer, the container must immediately flush the contents of a filled buffer to the client. If this is the first data sent to the client, the response is considered to be committed. | true |  | false | technology | active | true
Servlet:SPEC:33 | 5 | 2 | 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. | true |  | false | technology | active | true
Servlet:SPEC:34 | 5 | 2 | Servlet containers must not set a default content type when the servlet programmer does not set the type. | true |  | false | technology | active | true
Servlet:SPEC:183 | 5 | 2 | 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. | true |  | false | technology | active | true
Servlet:SPEC:300 | 5 | 3 | Non-blocking IO only works with async request processing in Servlets and Filters as defined in Section 2.3.3.3, "Asynchronous processing" on page 2-10, and upgrade processing (as defined in Section 2.3.3.5, ?Upgrade Processing? on page 2-20). | true |  | false | technology | active | true
Servlet:SPEC:306 | 5 | 3 | Otherwise, an IllegalStateException must be thrown when ServletInputStream.setReadListener or ServletOutputStream.setWriteListener is invoked. | true |  | false | technology | active | true
Servlet:SPEC:35 | 5 | 4 | If a partial URL is given and, for whatever reason, cannot be converted into a valid URL, then this method(sendRedirect) must throw an IllegalArgumentException. | true |  | false | technology | active | true
Servlet:SPEC:36 | 5 | 4 | These methods(sendError) 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. | true |  | false | technology | active | true
Servlet:SPEC:37 | 5 | 4 | These methods(sendRedirect) will have the side effect of commiting 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. | true |  | false | technology | active | true
Servlet:SPEC:38 | 5 | 4 | 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 sendRedirect. | true |  | false | technology | active | true
Servlet:SPEC:39 | 5 | 4 | 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 sendError. | true |  | false | technology | active | true
Servlet:SPEC:40 | 5 | 4 | If data is written to the response after sendRedirect has been called, the data is ignored. | true |  | false | technology | active | true
Servlet:SPEC:41 | 5 | 4 | If data is written to the response after sendError has been called, the data is ignored. | true |  | false | technology | active | true
Servlet:SPEC:284 | 5 | 6 | When a response is closed, the container must immediately flush all remaining content in the response buffer to the client. | true |  | false | technology | active | true
Servlet:SPEC:42 | 5 | 6 | The following events indicate that the servlet has satisfied the request and that the response object is to be closed: | true |  | false | technology | active | true
Servlet:SPEC:42.1 | 5 | 6 | The termination of the service method of the servlet. | true |  | false | technology | active | false
Servlet:SPEC:42.2 | 5 | 6 | The amount of content specified in the setContentLength or setContentLengthLong method of the response has been greater than zero and has been written to the response. | true |  | false | technology | active | true
Servlet:SPEC:42.3 | 5 | 6 | The sendError method is called. | true |  | false | technology | active | true
Servlet:SPEC:42.4 | 5 | 6 | The sendRedirect method is called. | true |  | false | technology | active | true
Servlet:SPEC:42.5 | 5 | 6 | The complete method on AsyncContext is called. | true |  | false | technology | active | true
Servlet:SPEC:43 | 5 | 7 | Each response object is valid only within the scope of a servlet's service method, or within the scope of a filter's doFilter method, unless the associated request object has asynchronous processing enabled for the component. | true |  | false | technology | active | false
Servlet:SPEC:285 | 5 | 7 | If asynchronous processing on the associated request is started, then the request object remains valid until complete method on AsyncContext is called. | true |  | false | technology | active | false
Servlet:SPEC:44 | 6 | 2.1 | After deployment of a web application, and before a request causes the container to access a web resource, The container must locate the list of filters that must be applied to the Web resource as described below. | true |  | false | technology | active | false
Servlet:SPEC:45 | 6 | 2.1 | The container must ensure that it has instantiated a filter of the appropriate class for each filter in the list, and called its init(FilterConfig config) method. | true |  | false | technology | active | true
Servlet:SPEC:286 | 6 | 2.1 | The filter may throw an exception to indicate that it cannot function properly. | true |  | false | technology | active | false
Servlet:SPEC:46 | 6 | 2.1 | If the exception thrown by a Filter is of type UnavailableException, the container may examine the isPermanent attribute of the exception and may choose to retry the filter at some later time. | false |  | false | technology | active | false
Servlet:SPEC:47 | 6 | 2.1 | Only one instance per <filter> declaration in the deployment descriptor is instantiated per JVM of the container. The container provides the filter config as declared in the filter's deployment descriptor, the reference to the ServletContext for the Web application, and the set of initialization parameters. | true |  | false | technology | active | false
Servlet:SPEC:48 | 6 | 2.1 | When the container receives an incoming request it takes the first filter instance in the list and calls its doFilter method, passing in the ServletRequest and ServletResponse, and a reference to the FilterChain object it will use. | true |  | false | technology | active | true
Servlet:SPEC:287 | 6 | 2.1 | The doFilter method of a filter will typically be implemented following this or some subset of the following pattern: | true |  | false | technology | active | false
Servlet:SPEC:287.1 | 6 | 2.1 | The method examines the request's headers. | true |  | false | technology | active | true
Servlet:SPEC:287.2 | 6 | 2.1 | The method may wrap the request object with a customized implementation of ServletRequest or HttpServletRequest in order to modify request headers or data. | true |  | false | technology | active | true
Servlet:SPEC:287.3 | 6 | 2.1 | The method may wrap the response object passed in to its doFilter method with a customized implementation of ServletResponse or HttpServletResponse to modify response headers or data. | true |  | false | technology | active | true
Servlet:SPEC:287.4 | 6 | 2.1 | The filter may invoke the next entity in the filter chain. The next entity may be another filter, or if the filter making the invocation is the last filter configured in the deployment descriptor for this chain, the next entity is the target Web resource. The invocation of the next entity is effected by calling the doFilter method on the FilterChain object, and passing in the request and response with which it was called or passing in wrapped versions it may have created. | true |  | false | technology | active | true
Servlet:SPEC:50 | 6 | 2.1 | The filter chain's implementation of the doFilter method, provided by the container, must locate the next entity in the filter chain and invoke its doFilter method, passing in the appropriate request and response objects. | true |  | false | technology | active | true
Servlet:SPEC:287.5 | 6 | 2.1 | Alternatively, the filter chain can block the request by not making the call to invoke the next entity, leaving the filter responsible for filling out the response object. | true |  | false | technology | active | true
Servlet:SPEC:287.6 | 6 | 2.1 | The service method is required to run in the same thread as all filters that apply to the servlet. | true |  | false | technology | active | true
Servlet:SPEC:287.7 | 6 | 2.1 | After invocation of the next filter in the chain, the filter may examine response headers. | true |  | false | technology | active | true
Servlet:SPEC:287.8 | 6 | 2.1 | Alternatively, the filter may have thrown an exception to indicate an error in processing. If the filter throws an UnavailableException during its doFilter processing, the container must not attempt continued processing down the filter chain. It may choose to retry the whole chain at a later time if the exception is not marked permanent. | true |  | false | technology | active | true
Servlet:SPEC:287.9 | 6 | 2.1 | When the last filter in the chain has been invoked, the next entity accessed is the target servlet or resource at the end of the chain. | true |  | false | technology | active | true
Servlet:SPEC:49 | 6 | 2.1 | Before a filter instance can be removed from service by the container, the container must first call the destroy method on the filter to enable the filter to release any resources and perform other cleanup operations. | true |  | false | technology | active | false
Servlet:SPEC:288 | 6 | 2.2 | When a filter invokes the doFilter method on the container's filter chain implementation, the container must ensure that the request and response object that it passes to the next entity in the filter chain, or to the target web resource if the filter was the last in the chain, is the same object that was passed into the doFilter method by the calling filter. | true |  | false | technology | active | true
Servlet:SPEC:51 | 6 | 2.2 | The same requirement of wrapper object identity applies to the calls from a servlet or a filter to RequestDispatcher.forward or RequestDispatcher.include, when the caller wraps the request or response objects. In this case, the request and response objects seen by the called servlet must be the same wrapper objects that were passed in by the calling servlet or filter. | true |  | false | technology | active | true
Servlet:SPEC:52 | 6 | 2.4 | The order the container uses in building the chain of filters to be applied for a particular request URI is as follows: | true |  | false | technology | active | true
Servlet:SPEC:52.1 | 6 | 2.4 | the <url-pattern> matching filter-mappings in the same order that these elements appear in the deployment descriptor. | true |  | false | technology | active | true
Servlet:SPEC:52.2 | 6 | 2.4 | The <servlet-name> matching filter-mappings in the same order that these elements appear in the deployment descriptor. | true |  | false | technology | active | true
Servlet:SPEC:53 | 6 | 2.4 | It is expected that high performance Web containers will cache filter chains so that they do not need to compute them on a per-request basis. | false |  | true | technology | active | false
Servlet:SPEC:302 | 6 | 2.5 | By using the new <dispatcher> element in the deployment descriptor, the developer can indicate for a filter-mapping whether he would like the filter to be applied to requests when: | false |  | true | technology | active | true
Servlet:SPEC:54 | 6 | 2.5 | The request comes directly from the client. This is indicated by a <dispatcher> element with value REQUEST, | true |  | false | technology | active | true
Servlet:SPEC:58 | 6 | 2.5 | The request comes directly from the client. This is indicated by the absence of any <dispatcher> elements. | true |  | false | technology | active | true
Servlet:SPEC:55 | 6 | 2.5 | The request is being processed under a request dispatcher representing the Web component matching the <url-pattern> or <servlet-name> using a forward() call. This is indicated by a <distpatcher> element with value FORWARD. | true |  | false | technology | active | true
Servlet:SPEC:56 | 6 | 2.5 | The request is being processed under a request dispatcher representing the Web component matching the <url-pattern> or <servlet-name> using an include() call. This is indicated by a <distpatcher> element with value INCLUDE. | true |  | false | technology | active | true
Servlet:SPEC:57 | 6 | 2.5 | The request is being processed with the error page mechanism specified in ?Error Handling? on page 106 to an error resource matching the <url-pattern>. This is indicated by a <dispatcher> element with the value ERROR. | true |  | false | technology | active | true
Servlet:SPEC:301 | 6 | 2.5 | The request is being processed with the async context dispatch mechanism specified in ?Asynchronous processing? on page 10 to a web component using a dispatch call. This is indicated by a <dispatcher> element with the value ASYNC. | true |  | false | technology | active | true
Servlet:SPEC:59 | 6 | 2.5 | (The container must be able to support) any combination of 1, 2, 3, 4 or 5 above. | true |  | false | technology | active | true
Servlet:SPEC:202 | 7 | 1.1 | Session tracking through HTTP cookies is the most used session tracking mechanism and is required to be supported by all servlet containers. | true |  | false | technology | active | true
Servlet:SPEC:303 | 7 | 1.1 | 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 JSESSIONID. | true |  | false | technology | active | true
Servlet:SPEC:60 | 7 | 1.3 | 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. | true |  | false | technology | active | false
Servlet:SPEC:60.2 | 7 | 1.3 | The session ID must be encoded as a path parameter in the URL string. | true |  | false | technology | active | true
Servlet:SPEC:60.1 | 7 | 1.3 | The name of the parameter must be 'jsessionid'. | true |  | false | technology | active | true
Servlet:SPEC:61 | 7 | 1.4 | Web container must be able to support HTTP session tracking while servicing HTTP request from clients that do no support the use of cookies. | true |  | false | technology | active | false
Servlet:SPEC:62 | 7 | 2 | A session is considered 'new' if either of the following are true: | true |  | false | technology | active | true
Servlet:SPEC:62.1 | 7 | 2 | The client does not yet know about the session. | true |  | false | technology | active | true
Servlet:SPEC:62.2 | 7 | 2 | The client chooses not to join a session. | true |  | false | technology | active | true
Servlet:SPEC:63 | 7 | 3 | HttpSession objects must be scoped at the application (or servlet context) level. | true |  | false | technology | active | true
Servlet:SPEC:63.1 | 7 | 3 | The underlying mechanism, such as the cookies used to establish the session, including the attributes in that object, must never be shared between context by the container. | true |  | false | technology | active | true
Servlet:SPEC:63.2 | 7 | 3 | Additionally, sessions of a context must be resumable by requests into that context regardless of whether their associated context was being accessed directly or as the target of a request dispatch at the time the sessions were created. | true |  | false | technology | active | true
Servlet:SPEC:64 | 7 | 4 | The valueBound method must be called before the object is made available vai the getAttribute method of the HttpSession interface. | true |  | false | technology | active | false
Servlet:SPEC:65 | 7 | 4 | The valueUnbound method must be called after the object is no longer available via the getAttribute method of the HttpSession interface. | true |  | false | technology | active | false
Servlet:SPEC:66 | 7 | 5 | The default timeout period for sessions is defined by the servlet container and can be obtained via the getMaxInactiveInterval method of the HttpSession interface. | true |  | false | technology | active | true
Servlet:SPEC:67 | 7 | 5 | Invalidation will not take effect until all servlets using that session have exited the service method. | true |  | false | technology | active | true
Servlet:SPEC:203 | 7 | 6 | The getLastAccessedTime method of the HttpSession interface allows a servlet to determine the last time the session was accessed before the current request. The session is considered to be accessed when a request that is part of the session is first handled by the servlet container. | true |  | false | technology | active | true
Servlet:SPEC:68 | 7 | 7.2 | Within an application marked as distributable, all request that are part of a session must be handled by one virtual machine at a time. | false |  | false | technology | active | false
Servlet:SPEC:69 | 7 | 7.2 | The container must be able to handle all objects placed into instances of the HttpSession class using the setAttribute or putValue methods appropriately, with the following restrictions: | true |  | false | technology | active | false
Servlet:SPEC:69.1 | 7 | 7.2 | The container must accept objects that implement the Serializable interface. | true |  | false | technology | active | false
Servlet:SPEC:69.2 | 7 | 7.2 | The container may choose to support storage of other designated objects in the HttpSession, such as references to Jakarta Enterprise Bean components and transactions. | false |  | false | technology | active | false
Servlet:SPEC:69.3 | 7 | 7.2 | Migration of sessions will be handled by container-specific facilities. | false |  | true | technology | active | false
Servlet:SPEC:70 | 7 | 7.2 | The distributed servlet container must throw an IllegalArgumentException for objects where the container cannot support the mechanism necessary for migration of the session storing them. | true |  | false | technology | active | false
Servlet:SPEC:71 | 7 | 7.2 | The distributed servlet container must support the mechanism necessary for migrating objects that implement Serializable. | true |  | false | technology | active | false
Servlet:SPEC:72 | 7 | 7.2 | Distributed servlet containers must support the mechanism necessary for migrating objects that implements Serializable. | true |  | false | platform | active | false
Servlet:SPEC:73 | 7 | 7.2 | If distributed contains persist or migrate sessions to provide quality of service features, they are not restricted to using the native JVM Serialization mechanism for serializing HttpSessions and their attributes. | false |  | true | technology | active | false
Servlet:SPEC:74 | 7 | 7.2 | Containers must notify any session attributes implementing the HttpSessionActivationListener during migration of a session. They must notify listeners of passivation prior to serialization of a session, and of activation after deserialization of a session | true |  | false | technology | active | false
Servlet:SPEC:307 | 8 | 1 | In a web application, classes using annotations will have their annotations processed only if they are located in the WEB-INF/classes directory, or if they are packaged in a jar file located in WEB-INF/lib within the application. | true |  | false | technology | active | true
Servlet:SPEC:308 | 8 | 1 | The web application deployment descriptor contains a new ?metadata-complete? attribute on the web-app element. The ?metadata-complete? attribute defines whether the web descriptor is complete, or whether the class files of the jar file should be examined for annotations and web fragments at deployment time. If ?metadata-complete? is set to "true", the deployment tool MUST ignore any servlet annotations that specify deployment information present in the class files of the application and web fragments. If the metadata-complete attribute is not specified or is set to "false", the deployment tool must examine the class files of the application for annotations, and scan for web fragments. | true |  | false | technology | active | true
Servlet:SPEC:221 | 8 | 1.1 | This annotation(@WebServlet) is used to define a Servlet component in a web application. | true |  | false | technology | active | true
Servlet:SPEC:221.1 | 8 | 1.1 | This annotation is specified on a class and contains metadata about the Servlet being declared. | true |  | false | technology | active | true
Servlet:SPEC:221.2 | 8 | 1.1 | The urlPatterns or the value attribute on the annotation MUST be present. | true |  | false | technology | active | true
Servlet:SPEC:221.3 | 8 | 1.1 | All other attributes are optional with default settings (see javadocs for more details). | true |  | false | technology | active | true
Servlet:SPEC:221.4 | 8 | 1.1 | It is recommended to use value when the only attribute on the annotation is the url pattern and to use the urlPatterns attribute when the other attributes are also used. | false |  | false | technology | active | true
Servlet:SPEC:221.5 | 8 | 1.1 | It is illegal to have both value and urlPatterns attribute used together on the same annotation. | true |  | false | technology | active | false
Servlet:SPEC:221.6 | 8 | 1.1 | The default name of the Servlet if not specified is the fully qualified class name. | true |  | false | technology | active | true
Servlet:SPEC:221.7 | 8 | 1.1 | The annotated servlet MUST specify at least one url pattern to be deployed. | true |  | false | technology | active | true
Servlet:SPEC:221.8 | 8 | 1.1 | If the same servlet class is declared in the deployment descriptor under a different name, a new instance of the servlet MUST be instantiated. | true |  | false | technology | active | true
Servlet:SPEC:221.9 | 8 | 1.1 | If the same servlet class is added to the ServletContext via the programmatic API defined in Section 4.4.1, "Programmatically adding and configuring Servlets" on page 4-35, the attribute values declared via the @WebServlet annotation MUST be ignored and a new instance of the servlet with the name specified MUST be created. | true |  | false | technology | active | true
Servlet:SPEC:221.10 | 8 | 1.1 | Classes annotated with @WebServlet class MUST extend the jakarta.servlet.http.HttpServlet class. | true |  | false | technology | active | true
Servlet:SPEC:222 | 8 | 1.5 | This annotation(@MultipartConfig), when specified on a Servlet, indicates that the request it expects is of type mime/multipart. The HttpServletRequest object of the corresponding servlet MUST make available the mime attachments via the getParts and getPart methods to iterate over the various mime attachments. | true |  | false | technology | active | true
Servlet:SPEC:223 | 8 | 1.5 | The location attribute of the jakarta.servlet.annotation.MultipartConfig and the <location> element of the <multipart-config> is interpreted as an absolut path and defaults to the value of the jakarta.servlet.context.tempdir. | true |  | false | technology | active | true
Servlet:SPEC:224 | 8 | 1.5 | If a relative path is specified(in <location>), it will be relative to the tempdir location. | true |  | false | technology | active | true
Servlet:SPEC:225 | 8 | 1.5 | The test for absolute path vs relative path (in <location>) MUST be done via java.io.File.isAbsolute. | true |  | false | technology | active | true
Servlet:SPEC:226 | 8 | 2.1 | Using the annotations(@WebServlet, @WebFilter, @WebInitParam, @WebListener, @MultipartConfig) defined above makes the use of web.xml optional. | true |  | false | technology | active | true
Servlet:SPEC:227 | 8 | 2.1 | However for overriding either the default values or the values set via annotations, the deployment descriptor is used. | true |  | false | technology | active | true
Servlet:SPEC:228 | 8 | 2.1 | As before, if the metadata-complete element is set to true in the web.xml descriptor, annotations that specify deployment information present in the class files and web-fragments bundled in jars will not be processed. It implies that all the metadata for the application is specified via the web.xml descriptor. | true |  | false | technology | active | true
Servlet:SPEC:229 | 8 | 2.1 | A plain old jar file in the WEB-INF/lib directory with no web-fragment.xml is also considered a fragment. Any annotations specified in it will be processed according to the rules defined in 8.2.3. The container will pick up and use the configuration as per the rules defined below. | true |  | false | technology | active | true
Servlet:SPEC:230 | 8 | 2.2 | A web-fragment.xml may have a top level <name> element of type javaee:java-identifierType. There can only be one <name> element in a web-fragment.xml. If a <name> element is present, it must be considered for the ordering of artifacts (unless the duplicate name exception applies, as described below). | true |  | false | technology | active | true
Servlet:SPEC:231 | 8 | 2.2 | There can only be one <absolute-ordering> element in a web.xml. | true |  | false | technology | active | true
Servlet:SPEC:232 | 8 | 2.2 | The web.xml and WEB-INF/classes MUST be processed before any of the web-fragments listed in the absolute-ordering element. | true |  | false | technology | active | true
Servlet:SPEC:233 | 8 | 2.2 | Any <name> element direct children of the <absolute-ordering> MUST be interpreted as indicating the absolute ordering in which those named web-fragments, which may or may not be present, must be processed. | true |  | false | technology | active | true
Servlet:SPEC:234 | 8 | 2.2 | The <absolute-ordering> element may contain zero or one <others /> element. | true |  | false | technology | active | true
Servlet:SPEC:235 | 8 | 2.2 | If the <absolute-ordering> element does not contain an <others/> element, any web-fragment not specifically mentioned within <name /> elements MUST be ignored. | true |  | false | technology | active | true
Servlet:SPEC:236 | 8 | 2.2 | Excluded jars are not scanned for annotated servlets, filters or listeners. | true |  | false | technology | active | true
Servlet:SPEC:237 | 8 | 2.2 | However, if a servlet, filter or listener from an excluded jar is listed in web.xml or a non-excluded web-fragment.xml, then it's annotations will apply unless otherwise excluded by metadata-complete. | true |  | false | technology | active | true
Servlet:SPEC:238 | 8 | 2.2 | ServletContextListeners discovered in TLD files of excluded jars are not able to configure filters and servlets using the programmatic APIs. Any attempt to do so will result in an IllegalStateException. | true |  | false | platform | active | true
Servlet:SPEC:239 | 8 | 2.2 | If a discovered ServletContainerInitializer is loaded from an excluded jar, it will be ignored. Irrespective of the setting of metadata-complete, jars excluded by <absolute-ordering> elements are not scanned for classes to be handled by any ServletContainerInitializer. | true |  | false | technology | active | true
Servlet:SPEC:240 | 8 | 2.2 | Duplicate name exception: if, when traversing the children of <absolute-ordering>, multiple children with the same <name> element are encountered, only the first such occurrence must be considered. | true |  | false | technology | active | true
Servlet:SPEC:241 | 8 | 2.2 | There can only be one <ordering> element in a web-fragment.xml. | true |  | false | technology | active | true
Servlet:SPEC:242 | 8 | 2.2 | A web-fragment.xml may have an <ordering> element. If so, this element must contain zero or one <before> element and zero or one <after> element. | true |  | false | technology | active | true
Servlet:SPEC:243 | 8 | 2.2 | Duplicate name exception: if, when traversing the web-fragments, multiple members with the same <name> element are encountered, the application must log an informative error message including information to help fix the problem, and must fail to deploy. For example, one way to fix this problem is for the user to use absolute ordering, in which case relative ordering is ignored. | true |  | false | technology | active | true
Servlet:SPEC:244 | 8 | 2.2 | <before> means the document must be ordered before the document with the name matching what is specified within the nested <name> element. | true |  | false | technology | active | true
Servlet:SPEC:245 | 8 | 2.2 | <after> means the document must be ordered after the document with the name matching what is specified within the nested <name> element. | true |  | false | technology | active | true
Servlet:SPEC:246 | 8 | 2.2 | There is a special element <others/> which may be included zero or one time within the <before> or <after> element, or zero or one time directly within the <absolute-ordering> element. The element must be handled as follows. | true |  | false | technology | active | true
Servlet:SPEC:246.1 | 8 | 2.2 | If the <before> element contains a nested , the document will be moved to the beginning of the list of sorted documents. If there are multiple documents stating <before> , they will all be at the beginning of the list of sorted documents, but the ordering within the group of such documents is unspecified. | true |  | false | technology | active | true
Servlet:SPEC:246.2 | 8 | 2.2 | If the <after> element contains a nested , the document will be moved to the end of the list of sorted documents. If there are multiple documents requiring <after> , they will all be at the end of the list of sorted documents, but the ordering within the group of such documents is unspecified. | true |  | false | technology | active | true
Servlet:SPEC:246.3 | 8 | 2.2 | Within a <before> or <after> element, if an element is present, but is not the only <name> element within its parent element, the other elements within that parent must be considered in the ordering process. | true |  | false | technology | active | true
Servlet:SPEC:246.4 | 8 | 2.2 | If the element appears directly within the <absolute-ordering> element, the runtime must ensure that any web-fragments not explicitly named in the <absolute-ordering> section are included at that point in the processing order. ` | true |  | false | technology | active | true
Servlet:SPEC:247 | 8 | 2.2 | If a web-fragment.xml file does not have an <ordering> or the web.xml does not have an <absolute-ordering> element the artifacts are assumed to not have any ordering dependency. | true |  | false | technology | active | true
Servlet:SPEC:248 | 8 | 2.2 | If the runtime discovers circular references, an informative message must be logged, and the application must fail to deploy. Again, one course of action the user may take is to use absolute ordering in the web.xml. | true |  | false | technology | active | false
Servlet:SPEC:249 | 8 | 2.3 | If the order in which the listeners, servlets, filters are invoked is important to an application then a deployment descriptor must be used. | true |  | false | technology | active | false
Servlet:SPEC:250 | 8 | 2.3 | when using annotations to define the listeners, servlets and filters, the order in which they are invoked is unspecified. | true |  | false | technology | active | true
Servlet:SPEC:251 | 8 | 2.3 | The order for listeners, servlets, filters if relevant must be specified in either the web-fragment.xml or the web.xml. | true |  | false | technology | active | true
Servlet:SPEC:252 | 8 | 2.3 | The ordering will be based on the order in which they are defined in the descriptor and on the absolute-ordering element in the web.xml or an ordering element in the web-fragment.xml, if present. | true |  | false | technology | active | true
Servlet:SPEC:253 | 8 | 2.3 | Filters that match a request are chained in the order in which they are declared in the web.xml. | true |  | false | technology | active | true
Servlet:SPEC:254 | 8 | 2.3 | Servlets are initialized either lazily at request processing time or eagerly during deployment. In the latter case, they are initialized in the order indicated by their load-on-startup elements. | true |  | false | technology | active | true
Servlet:SPEC:255 | 8 | 2.3 | The listeners are invoked in the order in which they are declared in the web.xml as specified below: | true |  | false | technology | active | true
Servlet:SPEC:255.1 | 8 | 2.3 | Implementations of jakarta.servlet.ServletContextListener are invoked at their contextInitialized method in the order in which they have been declared, and at their contextDestroyed method in reverse order. | true |  | false | technology | active | true
Servlet:SPEC:255.2 | 8 | 2.3 | Implementations of jakarta.servlet.ServletRequestListener are invoked at their requestInitialized method in the order in which they have been declared, and at their requestDestroyed method in reverse order. | true |  | false | technology | active | true
Servlet:SPEC:255.3 | 8 | 2.3 | Implementations of jakarta.servlet.http.HttpSessionListener are invoked at their sessionCreated method in the order in which they have been declared, and at their sessionDestroyed method in reverse order. | true |  | false | technology | active | true
Servlet:SPEC:255.4 | 8 | 2.3 | The methods of implementation of jakarta.servlet.ServletContextAttributeListener, jakarta.servlet.ServletRequestAttributeListener and jakarta.servlet.HttpSessionAttributeListener are invoked in the order in which they are declared when corresponding events are fired. | true |  | false | technology | active | true
Servlet:SPEC:256 | 8 | 2.3 | If a servlet is disabled using the enabled element introduced in the web.xml then the servlet will not be available at the url-pattern specified for the servlet. | true |  | false | technology | active | true
Servlet:SPEC:257 | 8 | 2.3 | The web.xml of the web application has the highest precedence when resolving conflicts between the web.xml, web-fragment.xml and annotations. | true |  | false | technology | active | true
Servlet:SPEC:258 | 8 | 2.3 | If metadata-complete is not specified in the descriptors, or is set to false in the deployment descriptor, then the effective metadata for the application is derived by combining the metadata present in the annotations and the descriptors. The rules for merging are specified below - | true |  | false | technology | active | true
Servlet:SPEC:258.1 | 8 | 2.3 | Configuration settings in web fragments are used to augment those specified in the main web.xml in such a way as if they had been specified in the same web.xml. | true |  | false | technology | active | true
Servlet:SPEC:258.2 | 8 | 2.3 | The order in which configuration settings of web fragments are added to those in the main web.xml is as specified above in Section 8.2.2, Ordering of web.xml and web-fragment.xml on page 8-66 | true |  | false | technology | active | true
Servlet:SPEC:258.3 | 8 | 2.3 | The metadata-complete attribute when set to true in the main web.xml, is considered complete and scanning of annotations and fragments will not occur at deployment time. The absolute-ordering and ordering elements will be ignored if present. When set to true on a fragment, the metadata-complete attribute applies only to scanning of annotations in that particular jar. | true |  | false | technology | active | true
Servlet:SPEC:258.4 | 8 | 2.3 | Web fragments are merged into the main web.xml unless the metadata-complete is set to true. The merging takes place after annotation processing on the corresponding fragment. | true |  | false | technology | active | true
Servlet:SPEC:258.5 | 8 | 2.3 | The following are considered configuration conflicts when augmenting a web.xml with web fragments: | true |  | false | technology | active | true
Servlet:SPEC:258.5.1 | 8 | 2.3 | Multiple <init-param> elements with the same <param-name> but different <param-value> | true |  | false | technology | active | true
Servlet:SPEC:258.5.2 | 8 | 2.3 | Multiple <mime-mapping> elements with the same <extension> but different <mime-type> | true |  | false | technology | active | true
Servlet:SPEC:258.6 | 8 | 2.3 | The above configuration conflicts are resolved as follows | true |  | false | technology | active | true
Servlet:SPEC:258.6.1 | 8 | 2.3 | Configuration conflicts between the main web.xml and a web fragment are resolved such that the configuration in the web.xml takes precedence. | true |  | false | technology | active | true
Servlet:SPEC:258.6.2 | 8 | 2.3 | Configuration conflicts between two web fragments, where the element at the center of the conflict is not present in the main web.xml, will result in an error. An informative message must be logged, and the application must fail to deploy | true |  | false | technology | active | false
Servlet:SPEC:258.7 | 8 | 2.3 | After the above conflicts have been resolved, these additional rules are applied: | true |  | false | technology | active | true
Servlet:SPEC:258.7.1 | 8 | 2.3 | Elements that may be declared any number of times are additive across the web-fragments in the resulting web.xml. For example, <context-param> elements with different <param-name> are additive. | true |  | false | technology | active | true
Servlet:SPEC:258.7.2 | 8 | 2.3 | Elements that may be declared any number of times, if specified in the web.xml overrides the values specified in the web-fragments with the same name. | true |  | false | technology | active | true
Servlet:SPEC:258.7.3 | 8 | 2.3 | If an element with a minimum occurrence of zero, and a maximum occurrence of one, is present in a web fragment, and missing in the main web.xml, the main web.xml inherits the setting from the web fragment. If the element is present in both the main web.xml and the web fragment, the configuration setting in the main web.xml takes precedence. For example, if both the main web.xml and a web fragment declare the same servlet, and the servlet declaration in the web fragment specifies a <load-on-startup> element, whereas the one in the main web.xml does not, then the <load-on-startup> element from the web fragment will be used in the merged web.xml. | true |  | false | technology | active | true
Servlet:SPEC:258.7.4 | 8 | 2.3 | It is considered an error if an element with a minimum occurrence of zero, and a maximum occurrence of one, is specified differently in two web fragments, while absent from the main web.xml. For example, if two web fragments declare the same servlet, but with different <load-on-startup> elements, and the same servlet is also declared in the main web.xml, but without any <load-on-startup>, then an error must be reported. | true |  | false | technology | active | false
Servlet:SPEC:258.7.5 | 8 | 2.3 | <welcome-file> declarations are additive. | true |  | false | technology | active | true
Servlet:SPEC:258.7.6 | 8 | 2.3 | <servlet-mapping> elements with the same <servlet-name> are additive across web-fragments. <servlet-mapping> specified in the web.xml overrides values specified in the web-fragments with the same <servlet-name>. | true |  | false | technology | active | true
Servlet:SPEC:258.7.7 | 8 | 2.3 | <filter-mapping> elements with the same <filter-name> are add itive across web-fragments. <filter-mapping> specified in the web.xml overrides values specified in the web-fragments with the same <filter-name>. | true |  | false | technology | active | true
Servlet:SPEC:258.7.8 | 8 | 2.3 | Multiple <listener> elements with the same <listener-class> are treated as a single <listener> declaration | true |  | false | technology | active | true
Servlet:SPEC:258.7.9 | 8 | 2.3 | The web.xml resulting from the merge is considered <distributable> only if all its web fragments are marked as <distributable> as well. | true |  | false | technology | active | true
Servlet:SPEC:258.7.10 | 8 | 2.3 | The top-level <icon> and it's children elements, <display-name>>, and <description> elements of a web fragment are ignored. | true |  | false | technology | active | true
Servlet:SPEC:258.7.11 | 8 | 2.3 | jsp-property-group is additive. It is recommended that jsp-config element use the url-pattern as opposed to extension mappings when bundling static resources in the META-INF/resources directory of a jar file. Further more JSP resources for a fragment should be in a sub-directory same as the fragment name, if there exists one. This helps prevent a web-fragment's jsp-property-group from affecting the JSPs in the main docroot of the application and the jsp-property-group from affecting the JSPs in a fragment's META-INF/resources directory. | true |  | false | platform | active | true
Servlet:SPEC:258.8 | 8 | 2.3 | For all the resource reference elements (env-entry, ejb-ref, ejb-local-ref, service-ref, resource-ref, resource-env-ref, message-destination-ref, persistence-context-ref and persistence-unit-ref) the following rules apply: | true |  | false | platform | active | true
Servlet:SPEC:258.8.1 | 8 | 2.3 | If any resource reference element is present in a web fragment, and is missing in the main web.xml, the main web.xml inherits the value from the web fragment. If the element is present in both the main web.xml and the web fragment, with the same name, the web.xml takes precedence. None of the child elements from the fragment are merged into the main web.xml except for the injection-target as specified below. For example, if both the main web.xml and a web fragment declare a <resource-ref> with the same <resource-ref-name>, the <resource-ref> from the web.xml will be used without any child elements being merged from the fragment except <injection-target> as described below. | true |  | false | platform | active | true
Servlet:SPEC:258.8.2 | 8 | 2.3 | If a resource reference element is specified in two fragments, while absent from the main web.xml, and all the attributes and child elements of the resource reference element are identical, the resource reference will be merged into the main web.xml. It is considered an error if a resource reference element has the same name specified in two fragments, while absent from the main web.xml and the attributes and child elements are not identical in the two fragments. An error must be reported and the application MUST fail to deploy. For example, if two web fragments declare a <resource-ref> with the same <resource-ref-name> element but the type in one is specified as javax.sql.DataSource while the type in the other is that of a JavaMail resource, it is an error and the application will fail to deploy | true |  | false | platform | active | true
Servlet:SPEC:258.8.3 | 8 | 2.3 | For resource reference element with the same name <injection-target> elements from the fragments will be merged into the main web.xml. | true |  | false | platform | active | true
Servlet:SPEC:258.9 | 8 | 2.3 | In addition to the merging rules for web-fragment.xml defined above, the following rules apply when using the resource reference annotations (@Resource, @Resources, @EJB, @EJBs, @WebServiceRef, @WebServiceRefs, @PersistenceContext, @PersistenceContexts,@PersistenceUnit, and @PersistenceUnits) | true |  | false | platform | active | true
Servlet:SPEC:258.9.1 | 8 | 2.3 | If a resource reference annotation is applied on a class, it is equivalent to defining a resource, however it is not equivalent to defining an injection-target. The rules above apply for injection-target element in this case. | true |  | false | platform | active | true
Servlet:SPEC:258.9.2 | 8 | 2.3 | If a resource reference annotation is used on a field it is equivalent to defining the injection-target element in the web.xml. However if there is no injection-target element in the descriptor then the injection-target from the fragments will still be merged into the web.xml as defined above. | true |  | false | platform | active | true
Servlet:SPEC:258.9.3 | 8 | 2.3 | If on the other hand there is an injection-target in the main web.xml and there is a resource reference annotation with the same resource name, then it is considered an override for the resource reference annotation. In this case since there is an injection-target specified in the descriptor, the rules defined above would apply in addition to overriding the value for the resource reference annotation. | true |  | false | platform | active | true
Servlet:SPEC:258.10 | 8 | 2.3 | If a data-source element is specified in two fragments, while absent from the main web.xml, and all the attributes and child elements of the data-source element are identical, the data-source will be merged into the main web.xml. It is considered an error if a data-source element has the same name specified in two fragments, while absent from the main web.xml and the attributes and child elements are not identical in the two fragments. In such a case an error must be reported and the application MUST fail to deploy. | true |  | false | platform | active | true
Servlet:SPEC:258.11 | 8 | 2.3 | If the main web.xml does not have any <post-construct> element specified and web-fragments have specified <post-construct> then the <post-construct> elements from the fragments will be merged into the main web.xml. However if in the main web.xml at least one <post-construct> element is specified then the <post-construct> elements from the fragment will not be merged. It is the responsibility of the author of the web.xml to make sure that the <post-construct> list is complete. | true |  | false | technology | active | true
Servlet:SPEC:258.12 | 8 | 2.3 | If the main web.xml does not have any <pre-destroy> element specified and web-fragments have specified <pre-destroy> then the <pre-destroy> elements from the fragments will be merged into the main web.xml. However if in the main web.xml at least one <pre-destroy> element is specified then the <pre-destroy> elements from the fragment will not be merged. It is the responsibility of the author of the web.xml to make sure that the <pre-destroy> list is complete. | true |  | false | technology | active | true
Servlet:SPEC:258.13 | 8 | 2.3 | After processing the web-fragment.xml, annotations from the corresponding fragment are processed to complete the effective metadata for the fragment before processing the next fragment. The following rules are used for processing annotations: | true |  | false | technology | active | true
Servlet:SPEC:258.14 | 8 | 2.3 | Any metadata specified via an annotation that isn't already present in the descriptor will be used to augment the effective descriptor. | true |  | false | technology | active | true
Servlet:SPEC:258.14.1 | 8 | 2.3 | Configuration specified in the main web.xml or a web fragment takes precedence over the configuration specified via annotations. | true |  | false | technology | active | true
Servlet:SPEC:258.14.2 | 8 | 2.3 | For a servlet defined via the @WebServlet annotation, to override values via the descriptor, the name of the servlet in the descriptor MUST match the name of the servlet specified via the annotation (explicitly specified or the default name, if one is not specified via the annotation). | true |  | false | technology | active | true
Servlet:SPEC:258.14.3 | 8 | 2.3 | Init params for servlets and filters defined via annotations, will be overridden in the descriptor if the name of the init param exactly matches the name specified via the annotation. Init params are additive between the annotations and descriptors. | true |  | false | technology | active | true
Servlet:SPEC:258.14.4 | 8 | 2.3 | url-patterns, when specified in a descriptor for a given servlet name overrides the url patterns specified via the annotation. | true |  | false | technology | active | true
Servlet:SPEC:258.14.5 | 8 | 2.3 | For a filter defined via the @WebFilter annotation, to override values via the descriptor, the name of the filter in the descriptor MUST match the name of the filter specified via the annotation (explicitly specified or the default name, if one is not specified via the annotation). | true |  | false | technology | active | true
Servlet:SPEC:258.14.6 | 8 | 2.3 | url-patterns to which a filter is applied, when specified in a descriptor for a given filter name overrides the url patterns specified via the annotation. | true |  | false | technology | active | true
Servlet:SPEC:258.14.7 | 8 | 2.3 | DispatcherTypes to which a filter applies, when specified in a descriptor for a given filter name overrides the DispatcherTypes specified via the annotation. | true |  | false | technology | active | true
Servlet:SPEC:259 | 8 | 2.4 | In addition to supporting fragments and use of annotations one of the requirements is that not only we be able to plug-in things that are bundled in the WEB-INF/lib but also plugin shared copies of frameworks - including being able to plug-in to the web container things like JAX-WS, JAX-RS and JSF that build on top of the web container. The ServletContainerInitializer allows handling such a use case as described below. | true |  | false | platform | active | true
Servlet:SPEC:259.1 | 8 | 2.4 | The ServletContainerInitializer class is looked up via the jar services API. For each application, an instance of the ServletContainerInitializer is created by the container at application startup time. The framework providing an implementation of the ServletContainerInitializer MUST bundle in the META-INF/services directory of the jar file a file called jakarta.servlet.ServletContainerInitializer, as per the jar services API, that points to the implementation class of the ServletContainerInitializer. | true |  | false | platform | active | true
Servlet:SPEC:259.2 | 8 | 2.4 | In addition to the ServletContainerInitializer we also have an annotation - HandlesTypes. The HandlesTypes annotation on the implementation of the ServletContainerInitializer is used to express interest in classes that may have anotations (type, method or field level annotations) specified in the value of the HandlesTypes or if it extends / implements one those classes anywhere in the class' super types. The HandlesTypes annotation is applied irrespective of the setting of metadata-complete. The container uses the HandlesTypes annotation to determine when to invoke the initializer's onStartup method. When examining the classes of an application to see if they match any of the criteria specified by the HandlesTypes annotation of a ServletContainerInitializer, the container may run into class loading problems if one or more of the application's optional JAR files are missing. Since the container is not in a position to decide whether these types of class loading failures will prevent the application from working correctly, it must ignore them, while at the same time providing a configuration option that would log them. | true |  | false | platform | active | true
Servlet:SPEC:259.3 | 8 | 2.4 | If an implementation of ServletContainerInitializer does not have the @HandlesTypes annotation, or if there are no matches to any of the HandlesType specified, then it will get invoked once for every application with null as the value of the Set. This will allow for the initializer to determine based on the resources available in the application whether it needs to initialize a servet / filter or not. | true |  | false | platform | active | true
Servlet:SPEC:259.4 | 8 | 2.4 | The onStartup method of the ServletContainerInitializer will be invoked when the application is coming up before any of the listener's events are fired. | true |  | false | platform | active | true
Servlet:SPEC:259.5 | 8 | 2.4 | The ServletContainerInitializer's onStartup method get's a Set of Classes that either extend / implement the classes that the initializer expressed interest in or if it is annotated with any of the classes specified via the @HandlesTypes annotation. | true |  | false | platform | active | true
Servlet:SPEC:259.6 | 8 | 2.4 | The framework jar file can also be bundled in WEB-INF/lib directory of the war file. If the ServletContainerInitializer is bundled in a JAR file inside the WEB-INF/lib directory of an application, it's onStartup method will be invoked only once during the startup of the bundling application. If, on the other hand, the ServletContainerInitialzer is bundled in a JAR file outside of the WEB-INF/lib directory, but still discoverable by the runtime's service provider lookup mechanism, it's onStartup method will be invoked every time an application is started. | true |  | false | platform | active | true
Servlet:SPEC:259.7 | 8 | 2.4 | Implementations of the ServletContainerInitializer interface will be discovered by the runtime's service lookup mechanism or a container specific mechanism that is semantically equivalent to it. In either case, ServletContainerInitializer services from web fragment JAR files that are excluded from an absolute ordering MUST be ignored, and the order in which these services are discovered MUST follow the application's class loading delegation model. | true |  | false | platform | active | true
Servlet:SPEC:260 | 8 | 3 | The ServletContainerInitializer and programmatic registration features make it possible to provide a clear separation of responsibilities between the Servlet and JSP containers, by making the Servlet container responsible for parsing only web.xml and web-fragment.xml resources, and delegating the parsing of Tag Library Descriptor (TLD) resources to the JSP container. ` | true |  | false | platform | active | true
Servlet:SPEC:261 | 8 | 3 | Previously, a web container had to scan TLD resources for any listener declarations. With Servlet 3.0, this responsibility may be delegated to the JSP container. A JSP container that is embedded in a Servlet 3.0 compliant Servlet container may provide its own ServletContainerInitializer implementation, search the ServletContext passed to its onStartup method for any TLD resources, scan those resources for listener declarations, and register the corresponding listeners with the ServletContext. | true |  | false | platform | active | true
Servlet:SPEC:262 | 8 | 3 | In addition, prior to Servlet 3.0, a JSP container used to have to scan an application's deployment descriptor for any jsp-config related configuration. With Servlet 3.0, the Servlet container must make available, via the ServletContext.getJspConfigDescriptor method, any jsp-config related configuration from the application's web.xml and web-fragment.xml deployment descriptors. | true |  | false | platform | active | true
Servlet:SPEC:263 | 8 | 3 | Any ServletContextListeners that were discovered in a TLD and registered programmatically are limited in the functionality they provide. Any attempt to call a ServletContext API method on them that was added in Servlet 3.0 will result in an UnsupportedOperationException. | true |  | false | platform | active | true
Servlet:SPEC:264 | 8 | 3 | In addition, a Servlet 3.0 compliant Servlet container must provide a ServletContext attribute with name jakarta.servlet.context.orderedLibs, whose value (of type java.util.List<java.lang.String>) contains the list of names of JAR files in the WEB-INF/lib directory of the application represented by the ServletContext, ordered by their web fragment names (with possible exclusions if fragment JAR files have been excluded from absolute-ordering), or null if the application does not specify any absolute or relative ordering. | true |  | false | platform | active | true
Servlet:SPEC:265 | 8 | 4 | Web applications can include both annotations and the web.xml / web-fragment.xml deployment descriptors. | true |  | false | technology | active | true
Servlet:SPEC:266 | 8 | 4 | . If there is no deployment descriptor, or there is one but does not have the metadata-complete set to true, web.xml, web-fragment.xml and annotations if used in the application must be processed. | true |  | false | technology | active | true
Servlet:SPEC:267 | 8 | 4 | The following table (Table 8-1) describes whether or not to process annotations and web.xml fragments. | true |  | false | technology | active | true
Servlet:SPEC:75 | 9 | 2 | The Container provider must ensure that the dispatch of the request to a target servlet occurs in the same thread of the same VM as the original request. | true |  | false | technology | active | false
Servlet:SPEC:192 | 9 | 3 | The include method of the RequestDispatcher interface may be called at any time. The target servlet of the include method has access to all aspects of the request object, but its use of the response object is more limited. | true |  | false | technology | active | true
Servlet:SPEC:192.1 | 9 | 3 | It can only write information to the ServletOutputStream or Writer of the response object | true |  | false | technology | active | true
Servlet:SPEC:192.2 | 9 | 3 | commit a response by writing content past the end of the response buffer | true |  | false | technology | active | true
Servlet:SPEC:192.3 | 9 | 3 | commit a response by explicitly calling the flushBuffer method of the ServletResponse interface. | true |  | false | technology | active | true
Servlet:SPEC:192.4 | 9 | 3 | It cannot set headers or call any method that affects the headers of the response, with the exception of the HttpServletRequest. getSession() and HttpServletRequest.getSession(boolean) methods. Any attempt to set the headers must be ignored, and any call to HttpServletRequest. getSession() or HttpServletRequest.getSession( boolean) that would require adding a Cookie response header must throw an IllegalStateException if the response has been committed. | true |  | false | technology | active | true
Servlet:SPEC:76 | 9 | 3.1 | Except for servlets obtained by using the getNamedDispatcher method, a servlet being used from within an include has access to the path by which it was invoked. The following request attributes are set: | true |  | false | technology | active | true
Servlet:SPEC:76.1 | 9 | 3.1 | 'jakarta.servlet.include.request_uri' which is the URI by which it was invoked. | true |  | false | technology | active | true
Servlet:SPEC:76.2 | 9 | 3.1 | 'jakarta.servlet.include.context_path' which is the context path portion of the request URI by which it was invoked. | true |  | false | technology | active | true
Servlet:SPEC:76.3 | 9 | 3.1 | 'jakarta.servlet.include.servlet_path' the servlet-path portion of the request URI by which it was invoked. | true |  | false | technology | active | true
Servlet:SPEC:76.4 | 9 | 3.1 | 'jakarta.servlet.include.path_info' the path-info portion of the request URI by which it was invoked. | true |  | false | technology | active | true
Servlet:SPEC:76.5 | 9 | 3.1 | 'jakarta.servlet.include.query_string' the query string portion of the request URI by which it was invoked. | true |  | false | technology | active | true
Servlet:SPEC:77 | 9 | 4 | If output data exists in the response buffer that has not been committed, the content must be cleared before the target's service method is called. | true |  | false | technology | active | true
Servlet:SPEC:78 | 9 | 4 | The path elements of the request object exposed to the target servlet must reflect the path used to obtain the RequestDispatcher. | true |  | false | technology | active | true
Servlet:SPEC:79 | 9 | 4 | If the RequestDispatcher was obtained through getNamedDispatcher the path elements of the request object must reflect those of the original request. | true |  | false | technology | active | false
Servlet:SPEC:80 | 9 | 4 | Before the forward method of the RequestDispatcher interface returns without exception, the response content must be sent and committed, and closed by the servlet container, unless the request was put into the asynchronous mode | true |  | false | technology | active | true
Servlet:SPEC:81 | 9 | 4.1 | The request dispatching mechanism is responsible for aggregating query string parameters when forwarding or including requests. | true |  | false | technology | deprecated | true
Servlet:SPEC:180 | 9 | 4.2 | Except for servlets obtained by using the getNamedDispatcher method, a servlet that has been invoked by another servlet using the forward method of RequestDispatcher has access to the path of the original request. The values of these attributes must be equal to the return values of the HttpServletRequest methods getRequestURI, getContextPath, getServletPath, getPathInfo, getQueryString respectively, invoked on the request object passed to the first servlet object in the call chain that received the request from the client. These attributes are accessible from the forwarded servlet via the getAttribute method on the request object. Note that these attributes must always reflect the information in the original request even under the situation that multiple forwards and subsequent includes are called. If the forwarded servlet was obtained by using the getNamedDispatcher method, these attributes must not be set. | true |  | false | technology | active | true
Servlet:SPEC:180.1 | 9 | 4.2 | jakarta.servlet.forward.request_uri | true |  | false | technology | active | true
Servlet:SPEC:180.2 | 9 | 4.2 | jakarta.servlet.forward.context_path | true |  | false | technology | active | true
Servlet:SPEC:180.3 | 9 | 4.2 | jakarta.servlet.forward.servlet_path | true |  | false | technology | active | true
Servlet:SPEC:180.4 | 9 | 4.2 | jakarta.servlet.forward.path_info | true |  | false | technology | active | true
Servlet:SPEC:180.5 | 9 | 4.2 | jakarta.servlet.forward.query_string | true |  | false | technology | active | true
Servlet:SPEC:181 | 9 | 4.2 | If the forwarded servlet was obtained by using the getNamedDispatcher method, these attributes must not be set. | true |  | false | technology | active | true
Servlet:SPEC:181.1 | 9 | 4.2 | jakarta.servlet.forward.request_uri | true |  | false | technology | active | true
Servlet:SPEC:181.2 | 9 | 4.2 | jakarta.servlet.forward.context_path | true |  | false | technology | active | true
Servlet:SPEC:181.3 | 9 | 4.2 | jakarta.servlet.forward.servlet_path | true |  | false | technology | active | true
Servlet:SPEC:181.4 | 9 | 4.2 | jakarta.servlet.forward.path_info | true |  | false | technology | active | true
Servlet:SPEC:181.5 | 9 | 4.2 | jakarta.servlet.forward.query_string | true |  | false | technology | active | true
Servlet:SPEC:82 | 9 | 5 | If the servlet that is the target of a request dispatcher throws a runtime exception or a checked exception of type ServletException or IOException, it may be propagated to the calling servlet. | true |  | false | technology | active | false
Servlet:SPEC:83 | 9 | 5 | All other exceptions (not a runtime, ServletException, or IOException) should be wrapped as ServletExceptions with the root cause the original exception before propagation. | true |  | false | technology | active | true
Servlet:SPEC:84 | 10 | 1 | An instance of a web application, by default, must run on one VM at any one time. | true |  | false | technology | active | false
Servlet:SPEC:85 | 10 | 1 | An application marked as distributable must obey a more restrictive set of rules than is required of a normal web application (the rules are set through out this list.) | true |  | false | technology | active | false
Servlet:SPEC:86 | 10 | 2 | The servlet container must enforce a one to one correspondence between a web application and a ServletContext. A ServletContext object provides a servlet with its view of the application. | true |  | false | technology | active | false
Servlet:SPEC:87 | 10 | 5 | Since the context path of an application determines the URL namespace of the context of the web application, web containers must reject web application defining a context path could cause potential conflicts in this URL namespace. | true |  | false | technology | active | false
Servlet:SPEC:88 | 10 | 5 | Since request are matched to resources case sensitively, this determination of potential context path namespace conflicts must be performed case sensitively as well. | true |  | false | technology | active | false
Servlet:SPEC:89 | 10 | 5 | The WEB-INF node (or directory) of a web application is not part of the public document tree of the application. Any requests to access the resources in /WEB-INF directory must be returned with a SC_NOT_FOUND(404) response. | true |  | false | technology | active | true
Servlet:SPEC:90 | 10 | 5 | The contents of /WEB-INF are visible to Servlets through the use of ServletContext.getResource or ServletContext.getSourceAsStream. | true |  | false | technology | active | true
Servlet:SPEC:91 | 10 | 5 | The web applcation classloader must load classes from the WEB-INF/ classes directory first, and then from the library JARs in the WEB-INF directory. | true |  | false | technology | active | true
Servlet:SPEC:92 | 10 | 6 | When web applications are packaged in a WAR file (Web ARchive file), a META-INF directory will be present which contains information useful to Java Archive tools. | true |  | false | technology | active | true
Servlet:SPEC:92.1 | 10 | 6 | Any requests to the META-INF directory of a packaged web application will be returned with a SC_NOT_FOUND(404) response. | true |  | false | technology | active | true
Servlet:SPEC:92.2 | 10 | 6 | The content of the META-INF directory of a packaged web application is accessible to servlets using the getResource and getResourceAsStream methods of the ServletContext. | true |  | false | technology | active | true
Servlet:SPEC:93 | 10 | 7.1 | Jakarta EE technology-compliant containers are required to provide a mechanism by which a deployer can learn what JAR files containing resources and code are available for the Web application. | true |  | true | technology | active | false
Servlet:SPEC:97 | 10 | 7.1 | Containers should provide a convenient procedure for editing and configuring library files or extensions. | false |  | true | technology | active | false
Servlet:SPEC:94 | 10 | 7.1 | During deployment of the Web application, the Web container must make the correct versions of the extensions available to the application following the rules defined by the Optional Package Versioning mechanism (https://docs.oracle.com/javase/8/docs/technotes/guides/extensions/extensions.html). | true |  | false | technology | active | false
Servlet:SPEC:95 | 10 | 7.1 | Web containers must also be able to recognize declared dependencies expressed in the manifest entry of any of the library JARs under the WEB-INF/lib entry in a WAR. | true |  | false | technology | active | false
Servlet:SPEC:96 | 10 | 7.1 | If a web container is not able to satisfy the dependencies declared via manifest files, it should reject the application with an informative error message. | false |  | false | technology | active | false
Servlet:SPEC:98 | 10 | 7.2 | The classloader that a container uses to load a servlet in a WAR must allow the developer to load any resources contained in library JARs within the WAR following normal Java SE semantics using getResource. | true |  | false | technology | active | true
Servlet:SPEC:99 | 10 | 7.2 | As described in the Jakarta EE license agreement, servlet containers that are not part of a Jakarta EE product should not allow the application to override Java SE platform classes, such as those in the java.* and javax.* namespaces, that Java SE does not allow to be modified. | true |  | false | technology | active | true
Servlet:SPEC:99.1 | 10 | 7.2 | Also, servlet containers that are part of a Jakarta EE product should not allow the application to override Java SE or Jakarta EE platform classes, such as those in the java.* and javax.* namespaces, that either Java SE or Jakarta EE do not allow to be modified. | true |  | false | technology | active | true
Servlet:SPEC:99.2 | 10 | 7.2 | The class loader that a container uses to load a servlet in a WAR must allow the developer to load any resources contained in library JARs within the WAR following normal Java SE semantics using getResource. | true |  | false | technology | active | true
Servlet:SPEC:99.3 | 10 | 7.2 | It is recommended also that the application class loader be implemented so that classes and resources packaged within the WAR are loaded in preference to classes and resources residing in container-wide library JARs. | true |  | false | technology | active | true
Servlet:SPEC:100 | 10 | 7.2 | It is recommended that the loader not allow servlets in the WAR access to the web container's implementation classes. | false |  | false | technology | active | false
Servlet:SPEC:101 | 10 | 7.2 | It is recommended also that the application classloader be implemented so that classes and resources packaged within the WAR are loaded in preference to classes and resources residing in container-wide library JARs. | false |  | false | technology | active | false
Servlet:SPEC:102 | 10 | 8 | A server should be able to replace an application with a new version without restarting the container. When an application is replaced, the container should provide a robust method for preserving session data within that application. | false |  | true | technology | active | false
Servlet:SPEC:103 | 10 | 9.1 | A web application must be able to specify that when errors occur other resources in the application are used to provide the content body of the error response. | true |  | false | technology | active | true
Servlet:SPEC:104 | 10 | 9.1 | If the location of the error handler is a servlet or JSP page, then: | true |  | false | technology | active | true
Servlet:SPEC:104.1 | 10 | 9.1 | The original unwrapped request and response objects created by the container are passed to the servlet or JSP page. | true |  | false | technology | active | true
Servlet:SPEC:104.2 | 10 | 9.1 | The response setStatus method is disabled and ignored if called. | true |  | false | technology | removed | true
Servlet:SPEC:104.3 | 10 | 9.1 | The request path and attributes are set as if a RequestDispatcher.forward to the error resource has been performed. | true |  | false | technology | active | true
Servlet:SPEC:104.3.1 | 10 | 9.1 | The request attribute 'jakarta.servlet.error.status_code' of type 'java.lang.Integer' will be set containing the HTTP status code of the error condition. | true |  | false | technology | active | true
Servlet:SPEC:104.3.2 | 10 | 9.1 | The request attribute 'jakarta.servlet.error.exception_type' of type 'java.lang.Class' will be set if the error page was invoked due to an uncaught exception. | true |  | false | technology | active | true
Servlet:SPEC:104.3.3 | 10 | 9.1 | The request attribute 'jakarta.servlet.error.message' of type 'java.lang.String' will be set if the error page was invoked due to an uncaught exception. | true |  | false | technology | active | true
Servlet:SPEC:104.3.4 | 10 | 9.1 | The 'jakarta.servlet.error.exception' attribute of type 'java.lang.Throwable' will be set if the error page was invoked due to an uncaught exception. | true |  | false | technology | active | true
Servlet:SPEC:104.3.5 | 10 | 9.1 | The 'jakarta.servlet.error.request_uri' attribute of type 'java.lang.String' will contain the URI of the offending resource. | true |  | false | technology | active | true
Servlet:SPEC:104.3.6 | 10 | 9.1 | The 'jakarta.servlet.error.servlet_name' attribute of type 'java.lang.String' will contain the logical name of the servlet in which the error occurred. | true |  | false | technology | active | true
Servlet:SPEC:105 | 10 | 9.2 | If the sendError method is called 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 returns the resource as indicated by the location entry. | true |  | false | technology | active | true
Servlet:SPEC:106 | 10 | 9.2 | In the case where the container is matching error pages based on the exception-type element, a match results in the container returning the resource indicated in the location entry. The closest match in the class hierarchy wins. | true |  | false | technology | active | true
Servlet:SPEC:107 | 10 | 9.2 | If no error-page declaration containing an exception-type fits using the class-hierarchy match, and the exception throws is a ServletException or subclass thereof the container extraces the wrapped exception, as defined by the ServletException.getRootCause method and a second pass is made of the error page declarations, again attempting the match against the error page declearations, but using the wrapped exception. | true |  | false | technology | active | true
Servlet:SPEC:108 | 10 | 9.2 | Error-page declarations using the exception-type element in the deployment descriptor must be unique up to the class name of the exception type. | true |  | false | technology | active | false
Servlet:SPEC:109 | 10 | 9.2 | Error page declarations using the status-code elements must be unique in the deployment descriptor up to the status-code. | true |  | false | technology | active | true
Servlet:SPEC:110 | 10 | 9.2 | The error page mechanism does not intervene when errors occur when invoked using the RequestDispatcher or Filter.doFilter method. In this way, a filter or servlet using the RequestDispatcher has the opportunity to handle errors generated. | true |  | false | technology | active | true
Servlet:SPEC:111 | 10 | 9.2 | If a servlet generates an error that is not handled by the error page mechanism as described above, the container must ensure to send a response with status 500. | true |  | false | technology | active | true
Servlet:SPEC:112 | 10 | 9.2 | The default servlet and container will use the sendError method to send 4xx and 5xx responses so that the error mechanism may be invoked. | true |  | false | technology | active | true
Servlet:SPEC:113 | 10 | 9.2 | The default servlet and container will use the setStatus method to send 2xx and 3xx responses to bypass the error mechanism | true |  | false | technology | active | true
Servlet:SPEC:114 | 10 | 10 | If a web container receives a valid partial request, the web container must examine the welcome files list, which is an ordered list of partial URLs, with no leading or trailing slash, and append the each welcome file to the partial URI in the order it was defined to find a match. The web container must send the request to the first resource in the WAR that matches. | true |  | false | technology | active | true
Servlet:SPEC:115 | 10 | 10 | If no welcome file match is found, the container may handle the request as it sees fit. | true |  | true | technology | active | false
Servlet:SPEC:116 | 10 | 11 | Jakarta EE compliant servlet containers are required to support the following elements of the web deployment descriptor for specifying information allowing a servlet to obtain references to resources and enterprise beans. The deployment elements that contain this information are: | true |  | false | platform | active | true
Servlet:SPEC:116.1 | 10 | 11 | env-entry | true |  | false | platform | active | true
Servlet:SPEC:116.2 | 10 | 11 | ejb-ref | true |  | false | platform | active | true
Servlet:SPEC:116.3 | 10 | 11 | ejb-local-ref | true |  | false | platform | active | true
Servlet:SPEC:116.4 | 10 | 11 | resource-env-ref | true |  | false | platform | active | true
Servlet:SPEC:116.5 | 10 | 11 | resource-ref | true |  | false | platform | active | true
Servlet:SPEC:117 | 10 | 11 | If the standalone container does not support these lookup facilities, the container should provide a warning upon deployment of an application that has dependencies on such resources. | false |  | false | technology | active | false
Servlet:SPEC:118 | 10 | 11 | Servlet containers that are part of a Jakarta EE technology compliant implementation must support lookups of such objects and calls made to those objects when performed on a thread managed by the servlet container. | true |  | false | platform | active | true
Servlet:SPEC:119 | 10 | 11 | Such servlet containers should support this lookup behavior when performed on threads created by the developer, but are not required to do so. | false |  | false | technology | active | false
Servlet:SPEC:182 | 10 | 12 | <![CDATA[When a web application is deployed into a container, the following steps must be performed, in this order, before the web application begins processing client requests. 1. Instantiate an instance of each event listener identified by a <listener> element in the deployment descriptor. 2. For instantiated listener instances that implement ServletContextListener, call the contextInitialized() method. 3. Instantiate an instance of each filter identified by a <filter>> element in the deployment descriptor and call each filter instances init() method. 4. Instantiate an instance of each servlet identified by a <servlet> element that includes a <load-on-startup> element in the order defined by the load-onstartup element values, and call each servlet instances init() method.]]> | true |  | false | technology | active | true
Servlet:SPEC:201 | 10 | 13 | A web application is NOT required to contain a web.xml if it does NOT contain any Servlet, Filter, or Listener components. In other words an application containing only static files or JSP pages does not require a web.xml to be present. | true |  | false | platform | active | true
Servlet:SPEC:120 | 11 | 3.1 | Each listener class specified in the deployment descriptor must have a public constructor taking no arguments. | true |  | false | technology | active | false
Servlet:SPEC:121 | 11 | 3.2 | Listeners will be invoked in the order that they are defined in the deployment descriptor. | true |  | false | technology | removed | true
Servlet:SPEC:122 | 11 | 3.3 | The Web container creates an instance of each listener class and registers it for event notifications prior to the processing of the first request by the application | true |  | false | technology | active | false
Servlet:SPEC:123 | 11 | 3.3 | The Web container registers the listener instances according to the interfaces they implement and the order in which they appear in the deployment descriptor. | true |  | false | technology | active | true
Servlet:SPEC:124 | 11 | 3.3 | During Web application execution, listeners corresponding to given events are invoked in the order of their registration. | true |  | false | technology | active | true
Servlet:SPEC:125 | 11 | 3.4 | On application shutdown, listeners are notified in reverse order to their declarations with notifications to session listeners preceeding notifications to context listeners. Session listeners must be notified of session invalidations prior to context listeners being notified of application shutdown. | true |  | false | technology | active | false
Servlet:SPEC:126 | 11 | 5 | The container is required to complete instantiation of the listener classes in a web application prior to the start of execution of the first request into the application. | true |  | false | technology | active | true
Servlet:SPEC:127 | 11 | 5 | The container must maintain a reference to each listener instance until the last request is serviced for the web application. | true |  | false | technology | active | false
Servlet:SPEC:128 | 11 | 6 | The container must allow unhandled exceptions to be handled by the error page mechanism described in Section SRV.9.9, "Error Handling". If there is no error page specified for those exceptions, the container must ensure to send a response back with status 500. In this case no more listeners under that event are called. | true |  | false | technology | active | true
Servlet:SPEC:129 | 11 | 6 | In cases where it is not possible to handle an Exception in application code (ex. an Exception occuring during initialization of a ContextListener), the container may response to all subsequent requests with an HTTP status code of 500 to indicate application error. | false |  | false | technology | active | false
Servlet:SPEC:130 | 11 | 7 | In distributed web containers, HttpSession instances are scoped to the particular VM services session requests, and the ServletContext object is scoped to the web container's VM. | false |  | false | technology | active | false
Servlet:SPEC:131 | 11 | 7 | Distributed containers are not required to propogate either servlet context events or HttpSession events to other VMs. | false |  | false | technology | active | false
Servlet:SPEC:132 | 11 | 7 | Listener class instances are scoped to one per deployment descriptor declaration per Java virtual machine. | true |  | false | technology | active | false
Servlet:SPEC:133 | 12 | 1 | Upon receipt of a client request, the Web container determines the Web application to which to forward it. The Web application selected must have the longest context path that matches the start of the request URL. The matched part of the URL is the context path when mapping to servlets. | true |  | false | technology | active | true
Servlet:SPEC:134 | 12 | 1 | The Web container next must locate the servlet to process the request using the path mapping procedure described below. The path used for mapping to a servlet is the request URL from the request object minus the context path and the path parameters. The URL path mapping rules below are used in order. The first successful match is used with no further matches attempted | true |  | false | technology | active | true
Servlet:SPEC:134.1 | 12 | 1 | The container will try to find an exact match of the path of the request to the path of the servlet. A successful match selects the servlet. | true |  | false | technology | active | true
Servlet:SPEC:134.2 | 12 | 1 | The container will recursively try to match the longest path-prefix: This is done by stepping down the path tree a directory at a time, using the '/' character as a path separator. The longest match determines the servlet selected. | true |  | false | technology | active | true
Servlet:SPEC:134.3 | 12 | 1 | If the last segment in the URL path contains an extension (e.g. .jsp), the servlet container will try to match a servlet that handles requests for the extension. An extension is defined as the part of the last segment after the last '.' character. | true |  | false | technology | active | true
Servlet:SPEC:134.4 | 12 | 1 | If neither the previous three rules result in a servlet match, the container will attempt to serve content appropriate for the resource requested. If a "default" servlet is defined for the applications, it will be used. | true |  | false | technology | active | true
Servlet:SPEC:134.5 | 12 | 1 | The container must use case-sensitive string comparisons for matching. | true |  | false | technology | active | true
Servlet:SPEC:220 | 12 | 2 | In the Web application deployment descriptor, the following syntax is used to define mappings | true |  | false | technology | active | true
Servlet:SPEC:220.1 | 12 | 2 | A string beginning with a / character and ending with a /* suffix is used for path mapping. | true |  | false | technology | active | true
Servlet:SPEC:220.2 | 12 | 2 | A string beginning with a *. prefix is used as an extension mapping. | true |  | false | technology | active | true
Servlet:SPEC:220.3 | 12 | 2 | The empty string ("") is a special URL pattern that exactly maps to the application's context root, i.e., requests of the form http://host:port/<contextroot>/. In this case the path info is / and the servlet path and context path is empty string "". | true |  | false | technology | active | true
Servlet:SPEC:220.4 | 12 | 2 | A string containing only the character / indicates the "default" servlet of the application. In this case the servlet path is the request URI minus the context path and the path info is null. | true |  | false | technology | active | true
Servlet:SPEC:220.5 | 12 | 2 | All other strings are used for exact matches only. | true |  | false | technology | active | true
Servlet:SPEC:135 | 12 | 2.1 | If the container has an internal JSP container, the *.jsp extension is mapped to it, allowing JSP pages to be executed on demand. | true |  | false | platform | active | true
Servlet:SPEC:136 | 12 | 2.1 | A servlet container is allowed to make other implicit mappings as long as explicit mappings take precedence. | false |  | false | technology | active | false
Servlet:SPEC:137 | 13 | 2 | Declarative security constraints are not applied when a servlet uses the RequestDispatcher to invoke a static resource or servlet using a forward or an include. | true |  | false | platform | active | true
Servlet:SPEC:138 | 13 | 3 | The isUserInRole method uses the security-role-ref element when determining the return value of the call. If no security-role-ref element matching a security-role element has been declared, the container must default to checking the role-name element against the list of security-role elements for the web applications. | true |  | false | platform | active | true
Servlet:SPEC:290 | 13 | 4.1 | Servlet containers MUST support the use of the @ServletSecurity annotation on classes (and subclasses thereof) that implement the jakarta.servlet.Servlet interface. | true |  | false | platform | active | true
Servlet:SPEC:291 | 13 | 4.1 | The @HttpConstraint annotation is used within the @ServletSecurity annotation to represent the security constraint to be applied to all HTTP protocol methods for which a corresponding @HttpMethodConstraint does NOT occur within the @ServletSecurity annotation. | true |  | false | platform | active | true
Servlet:SPEC:292 | 13 | 4.1 | At most one instance of the @ServletSecurity annotation may occur on a Servlet implementation class, and the @ServletSecurity annotation MUST NOT be specified on (that is, targeted to) a Java method. | true |  | false | platform | active | false
Servlet:SPEC:293 | 13 | 4.1 | When one or more @HttpMethodConstraint annotations are defined within a @ServletSecurity annotation, each @HttpMethodConstraint defines the security-constraint that applies to the HTTP protocol method identified within the @HttpMethodConstraint. The encompassing @ServletSecurity annotation defines the security-constraint that applies to all HTTP protocol methods other than those for which a corresponding @HttpMethodConstraint is defined within the @ServletSecurity annotation. | true |  | false | platform | active | true
Servlet:SPEC:294 | 13 | 4.1 | When a security-constraint in the portable deployment descriptor includes a url-pattern that is an exact match for a pattern mapped to a class annotated with @ServletSecurity, the annotation must have no effect on the constraints enforced by the Servlet container on the pattern. | true |  | false | platform | active | true
Servlet:SPEC:295 | 13 | 4.1 | When metadata-complete=true is defined for a portable deployment descriptor, the @ServletSecurity annotation does not apply to any of the url-patterns mapped to (any servlet mapped to) the annotated class in the deployment descriptor. | true |  | false | platform | active | true
Servlet:SPEC:296 | 13 | 4.1.2 | The enforcement by Servlet containers, of the @ServletSecurity annotation must be equivalent in effect to enforcement, by the container, of the security-constraint elements resulting from the mapping defined in this section. | true |  | false | platform | active | true
Servlet:SPEC:297 | 13 | 4.1.2 | The @ServletSecurity annotation is used to define one method-independent @HttpConstraint followed by a list of zero or more @HttpMethodConstraint specifications. The method-independent constraint is applied to all HTTP methods for which no HTTP method-specific constraint has been defined. | true |  | false | platform | active | true
Servlet:SPEC:298 | 13 | 4.1.2 | When no @HttpMethodConstraint elements are included, a @ServletSecurity annotation corresponds to a single security-constraint element containing a web-resource-collection that contains no http-method elements, and thus pertains to all HTTP methods. | true |  | false | platform | active | true
Servlet:SPEC:139 | 13 | 5 | 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: | true |  | false | platform | active | true
Servlet:SPEC:139.1 | 13 | 5 | 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 principals user group matches the user group to which the security role has been mapped by the deployer. | true |  | false | platform | active | true
Servlet:SPEC:139.2 | 13 | 5 | 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. | true |  | false | platform | active | true
Servlet:SPEC:140 | 13 | 6.1 | HTTP Basic Authentication is required to be supported by servlet containers. | true |  | false | platform | active | true
Servlet:SPEC:141 | 13 | 6.2 | HTTP Digest Authentication is not a required authentication mechanism for servlet containers. | false |  | false | platform | active | false
Servlet:SPEC:142 | 13 | 6.3 | Form based authentication allows the customization of the login screen. | true |  | false | platform | active | false
Servlet:SPEC:142.1 | 13 | 6.3 | The login form used for form based authentication must contain fields for entering a username and a password. These fields must be j_username and j_password, respectively. | true |  | false | platform | active | true
Servlet:SPEC:142.2 | 13 | 6.3 | The login form used by the container can be specified within the deployment descriptor. | true |  | false | platform | active | true
Servlet:SPEC:142.3 | 13 | 6.3 | An error page can be specified in the deployment descriptor which will be returned on failed form based authentication attempts. | true |  | false | platform | active | true
Servlet:SPEC:142.4 | 13 | 6.3 | The authentication process for form based login: | true |  | false | platform | active | false
Servlet:SPEC:142.4.1 | 13 | 6.3 | The login form associated with the security constraint is sent to the client and the URL path triggering the authentication is stored by the container. | true |  | false | platform | active | true
Servlet:SPEC:142.4.2 | 13 | 6.3 | The container attempts to authenticate the user using the information from the form. | true |  | false | platform | active | true
Servlet:SPEC:142.4.3 | 13 | 6.3 | If authentication fails, the error page is returned using either a forward or a redirect, and the status code of the response is set to 200. | true |  | false | platform | active | true
Servlet:SPEC:142.4.4 | 13 | 3.1 | If authentication succeeds, the authenticated user's principal is check to see if it is in an authroized role for accessing the resource. | true |  | false | platform | active | true
Servlet:SPEC:142.4.5 | 13 | 3.1 | If the user is authorized, the client is redirected to the resource using the stored URL path. | true |  | false | platform | active | true
Servlet:SPEC:142.5 | 13 | 6.3.1 | The action of the login form must always be j_security_check. | true |  | false | platform | active | true
Servlet:SPEC:142.6 | 13 | 6.3.1 | If the form based login is invoked because of an HTTP request, the original request parameters must be preserved by the container for use if on successful authentication, it redirects the call to the requested resource. | true |  | false | platform | active | true
Servlet:SPEC:142.7 | 13 | 6.3.1 | If the user is authenticated using form login and has created an HTTP session, the timeout or invalidation of that session leads to the user being logged out in the sense that subsequent requests must cause the user to be re-authenticated. | true |  | false | platform | active | true
Servlet:SPEC:143 | 13 | 6.4 | Servlet containers that are not Jakarta EE technology compliant are not required to support HTTPS protocol/authentication. | false |  | false | platform | active | false
Servlet:SPEC:144 | 13 | 7 | Servlet containers are required to track authentication information at the container level rather than at the web application level. | true |  | false | platform | active | false
Servlet:SPEC:145 | 15 | 3.1 | A security identity, or principal, must always be provided for use in a call to an enterprise bean. | true |  | true | platform | active | false
Servlet:SPEC:146 | 15 | 3.1 | The default mode in calls to enterprise beans from web applications is for the security identity of a web user to be propagated to the Jakarta Enterprise Beans container. | true |  | true | platform | active | false
Servlet:SPEC:147 | 15 | 3.1 | If a container supports calls to Jakarta Enterprise Beans' containers are required to support access to web resources by clients that have not authenticated themselves to the container through the use of the run-as element of the deployment descriptor. The container will use this identity when propagating the call from the web layer to the Jakarta Enterprise Beans layer. | true |  | false | platform | active | false
Servlet:SPEC:147.1 | 15 | 3.1 | The security role propagated through the run-as element must be a security role defined in the deployment descriptor of the web application. | true |  | true | platform | active | false
Servlet:SPEC:148 | 15 | 3.1 | Web containers running as part of a Jakarta EE platform, the use of run-as elements must be supported both for calls to Jakarta Enterprise Beans components within the same Jakarta EE application, and for calls to Jakarta Enterprise Beans components deployed in other Jakarta EE applications. | true |  | false | platform | active | false
Servlet:SPEC:149 | 13 | 8 | If a request is issued against a set of protected resources the user who made the request must be a member of at least one of the named roles to be permitted to perform the contrained requests. | true |  | false | platform | active | true
Servlet:SPEC:150 | 13 | 8 | The special role name "*" is a shorthand for all role names defined in the deployment descriptor. | true |  | false | platform | active | true
Servlet:SPEC:151 | 13 | 8 | An auth constraint that names no roles indicates that access ot the contrained resources must not be permitted under any circumstances. | true |  | false | platform | active | true
Servlet:SPEC:152 | 13 | 8 | A user data constraint establishes a requirement that the constrained requests be received over a protected transport layer connection. | true |  | false | platform | active | false
Servlet:SPEC:152.1 | 13 | 8 | A transport guarantee of INTEGRAL is used to establish a requirement for content integrity. | true |  | false | platform | active | false
Servlet:SPEC:152.2 | 13 | 8 | A transport guarantee of CONFIDENTIAL is used to establish a requirement for confidentiality. | true |  | false | platform | active | false
Servlet:SPEC:152.3 | 13 | 8 | A transport guarantee of NONE indicates that the container must accept the constrained requests when received on any connection including unprotected ones. | true |  | false | platform | active | true
Servlet:SPEC:153 | 13 | 8 | If no auth-constraing applies to a request, the container must accept the request without requiring user authentication. | true |  | false | platform | active | true
Servlet:SPEC:154 | 13 | 8.1 | When a url-pattern and http-method pair occurs in multiple security constraints, the applicable constraints (on the pattern and the method) are defined by combining the individual constraints. | true |  | false | platform | active | true
Servlet:SPEC:154.1 | 13 | 8.1 | A security constraint that does not contain an auth constraint shall combine with auth constraints that name or imply roles to allow unauthenticated access. | true |  | false | platform | active | true
Servlet:SPEC:154.2 | 13 | 8.1 | The special case of an auth constraint that names no roles shall combine with any other constraints to override their affects and cause access to be precluded. | true |  | false | platform | active | true
Servlet:SPEC:154.3 | 13 | 8.1 | The combination of user-data constraints that apply to a common usr-pattern and http-method shall yield the union of connection types accepted by the individual constraints as acceptable connection types. | true |  | false | platform | active | false
Servlet:SPEC:154.4 | 13 | 8.1 | A security constraint that does not contain a user-data constraint shall combine with other user-data constraints to cause the unprotected connection type to be an accepted connection type. | true |  | false | platform | active | true
Servlet:SPEC:155 | 13 | 8.3 | When a Servlet container receives a request, it shall use the url pattern matching algorithm to select the constraints, if any, defined that is the best match to the request URI | true |  | false | platform | active | true
Servlet:SPEC:156 | 13 | 8.3 | If no security contraint can be matched between the defined contraints and the request URI, the container will accept the request. | true |  | false | platform | active | true
Servlet:SPEC:157 | 13 | 8.3 | If a constraint match is found based on the request URI, the container shall determine if the HTTP method of the request is constrained, if it's not, then the constrained request will be accepted. | true |  | false | platform | active | true
Servlet:SPEC:158 | 13 | 8.3 | If the HTTP method is contrained, then the method used for the request must match what is acceptable for the constraint in order for the request to be accepted. | true |  | false | platform | active | true
Servlet:SPEC:159 | 13 | 8.3 | If the characteristics of the connection on which the request was received must satisfy at least one of the supported connection types defined by the constraints. If this rule is not satisfied, the container shall reject the request and redirect it to the HTTPS port. | true |  | false | platform | active | true
Servlet:SPEC:159.1 | 13 | 8.3 | As an optimization, a container should reject the connection request if it doesn't match the constrained connection types and return a 403 (SC_FORBIDDEN) status code if it knows that access will ultimately be precluded (by an auth constraint naming with no roles). | false |  | false | platform | active | false
Servlet:SPEC:160 | 13 | 8.3 | If a constraint naming defined no roles, any attempted requests will result in a 403 (SC_FORBIDDEN). | true |  | false | platform | active | true
Servlet:SPEC:161 | 13 | 8.3 | If access is restricted to permitted roles and the request has not been authenticated, the request shall be rejected as unauthorized and a 401 (SC_UNAUTHORIZED) status code shall be returned to cause authentication. | true |  | false | platform | active | true
Servlet:SPEC:162 | 13 | 8.3 | If access is restricted to permitted roles and the authentication identity of the request is not a member of any of these roles, the request shall be rejected as forbidden and a 403 (SC_FORBIDDEN) status code shall be returned to the user. | true |  | false | platform | active | true
Servlet:SPEC:309 | 13 | 8.4.2 | When the deny-uncovered-http-methods flag is set in the web.xml of an application, the container must deny any HTTP protocol method when it is used with a request URL for which the HTTP method is uncovered at the combined security constraint that applies to the url-pattern that is the best match for the request URL. The denied request shall be rejected as forbidden and a 403 (SC_FORBIDDEN) status code shall be returned. | true |  | false | platform | active | true
Servlet:SPEC:310 | 13 | 8.4.2 | When an applications security configuration contains no uncovered methods, the deny-uncovered-http-methods flag must have no effect on the effective security configuration of the application. | true |  | false | platform | active | true
Servlet:SPEC:163 | 13 | 10 | If a developer creates a session while a user is not authenticated, and the container then authenticates the user, the session visible to developer code after login must be the same session object that was created prior to login occurring so that there is no loss of session information. | true |  | false | platform | active | true
Servlet:SPEC:164 | 13 | 10 | For all authentication methods in both non-single signon and single signon containers, logout is caused by one of the following situations: | true |  | false | platform | removed | true
Servlet:SPEC:164.1 | 13 | 10 | Invalidation of the session. If this occurs, getUserPrincipal will return a null value. | true |  | false | platform | removed | true
Servlet:SPEC:164.2 | 13 | 10 | Session timeouts. If this occurs, getUserPrincipal will return a null value. | true |  | false | platform | removed | true
Servlet:SPEC:164.3 | 13 | 10 | An explicit call to HttpSession.invalidateAll. If this occurs, getUserPrincipal will return a null value. | true |  | false | platform | removed | true
Servlet:SPEC:164.4 | 13 | 10 | An explicit call to HttpSession.logout.If this occurs, getUserPrincipal will return a null value. | true |  | false | platform | removed | true
Servlet:SPEC:165 | 13 | 10 | For non-single signon containers, a session invalidating has no effect on login state or session state in other web applications. | true |  | false | platform | active | false
Servlet:SPEC:166 | 13 | 10 | For single signon containers, logout causes all other active sessions associated with the current user to be invalidated. | true |  | false | platform | active | false
Servlet:SPEC:167 | 13 | 10 | Invalidation or timeout of an individual session causes the termination of that session, but does not cause a logout unless it is the last session for this user, which means that a container is allowed to start a new session for one or more web applications without re-authenticating the user. | false |  | false | platform | removed | false
Servlet:SPEC:168 | 14 | 2 | Servlet 2.5 web containers may use schema to validate the structure of a deployment descriptor. | false |  | false | technology | active | false
Servlet:SPEC:169 | 14 | 1 | The deployment-extension element provides the ability to inject application or framework specific configuration information directly into the deployment descriptor. | true |  | true | technology | removed | false
Servlet:SPEC:169.1 | 14 | 1 | If a container uses schema to validate a deployment descriptor, any new content injected into deployment-extension elements as described below will not be validated by the web container. | false |  | false | technology | removed | false
Servlet:SPEC:169.2 | 14 | 1 | Deployment extensions are only valid within the top level web-app element or within servlet elements. | true |  | false | technology | removed | false
Servlet:SPEC:169.3 | 14 | 1.1 | Servlet 2.5 containers are required to raise an exception if they do not recognize an extension within a deployment descriptor where the mustUnderstand attribute is 'true'. | true |  | false | technology | removed | false
Servlet:SPEC:169.4 | 14 | 1.1 | Servlet 2.5 containers are not required to attempt to process extended deployment information where the nustUnderstand attribute is set to 'false'. | false |  | false | technology | removed | false
Servlet:SPEC:170 | 14 | 1 | Security information which may appear in the deployment descriptor is not required to be supported unless the servlet container is part of an implementation of the Jakarta EE specification. | true |  | false | platform | active | true
Servlet:SPEC:193 | 15 | 4.1 | The following additional elements exist in the Web application deployment descriptor to meet the requirements of Web containers that are JSP pages enabledor part of a Jakarta EE application server. They are not required to be supported by containers wishing to support only the servlet specification: | true |  | false | platform | active | true
Servlet:SPEC:171 | 15 | 4.1 | jsp-config | true |  | false | platform | active | true
Servlet:SPEC:172 | 15 | 4.1 | Syntax for looking up JNDI objects(env-entry, ejb-ref, ejb-local-ref, resource-ref, resource-env-ref) | true |  | false | platform | active | true
Servlet:SPEC:193.1 | 15 | 4.1 | Syntax for specifying the message destination (message-destination, message-destination-ref) | true |  | false | platform | active | true
Servlet:SPEC:193.2 | 15 | 4.1 | Reference to a Web service (service-ref) | true |  | false | platform | active | true
Servlet:SPEC:174 | 14 | 2 | Web containers must remove all leading and trailing whitespace, which is defined as "S(whitespace)" in XML 1.0 (http://www.w3.org/TR/2000/WD-xml- 2e-20000814), for the element content of the text nodes of a deployment descriptor. | true |  | false | technology | removed | true
Servlet:SPEC:175 | 14 | 2 | The containers and tools that are part of Jakarta EE technology-compliant implementation are required to validate deployment descriptor against the XML schema for structural correctness. | true |  | false | technology | active | true
Servlet:SPEC:176 | 14 | 2 | It is recommended that Web containers and tools that manipulate Web applications provide a level of semantic checking. For example, it should be checked that a role referenced in a security constraint has the same name as one of the security roles defined in the deployment descriptor. | false |  | false | technology | active | true
Servlet:SPEC:10176 | 14 | 2 | The sub elements under web-app can be in an arbitrary order. | true |  | false | technology | active | true
Servlet:SPEC:11276 | 14 | 2 | The multiplicity of the elements distributable, session-config, welcome-file-list, jspconfig, login-config, and locale-encoding-mapping-list is "0 or more." | true |  | false | technology | active | false
Servlet:SPEC:11276.1 | 14 | 2 | Containers must inform the developer with a descriptive error message when the deployment descriptor contains more than one element of session-config, jsp-config, and login-config. | true |  | false | technology | active | false
Servlet:SPEC:11276.2 | 14 | 3 | The deployment descriptor instance file must not contain multiple elements of session-config, jsp-config, and login-config. | true |  | false | technology | active | false
Servlet:SPEC:11276.3 | 14 | 2 | The container must concatenate the items in welcome-file-list and locale-encoding-mapping-list when there are multiple occurrences. | true |  | false | technology | active | true
Servlet:SPEC:11276.4 | 14 | 2 | The multiple occurrence of distributable must be treated exactly in the same way as the single occurrence of distributable. | true |  | false | technology | active | true
Servlet:SPEC:11276 | 14 | 2 | URI paths specified in the deployment descriptor are assumed to be in URLdecoded form. | true |  | false | technology | active | false
Servlet:SPEC:11276.1 | 14 | 2 | The containers must inform the developer with a descriptive error message when URL contains CR(#xD) or LF(#xA). | true |  | false | technology | active | false
Servlet:SPEC:11276.2 | 14 | 2 | The containers must preserve all other characters including whitespace in URL. | true |  | false | technology | active | true
Servlet:SPEC:177 | 14 | 2 | Containers must attempt to canonicalize paths in present in the deployment descriptor. | false |  | false | technology | active | true
Servlet:SPEC:178 | 14 | 3 | Paths beginning or resolving to paths that begin with ".." are not valid paths in the deployment descriptor. | true |  | false | technology | active | false
Servlet:SPEC:179 | 14 | 3 | Elements whose valus is an enumerated type must be treated in a case sensitive manner. | true |  | false | technology | active | false
Servlet:SPEC:214 | 14 | 4 | Servlet containers are required to support the use of these annotations within classes that extend the jakarta.servlet.http.HttpServlet abstract class. | true |  | false | technology | removed | true
Servlet:SPEC:215 | 14 | 4 | When specified on a class target, these annotations apply to all requests processed by the public service method of the HttpServlet implementation class. | true |  | false | technology | removed | true
Servlet:SPEC:216 | 14 | 4 | When an annotation is specified at both the class and method level, the method targeted annotation overrides that on the class (for the method). | true |  | false | technology | removed | true
Servlet:SPEC:217 | 14 | 4 | When the metadata-complete attribute is set in the portable deployment descriptor, the annotations described in this section have no effect on the access control policy enforced by the container on behalf of the corresponding web module or web fragment. | true |  | false | technology | removed | true
Servlet:SPEC:218 | 14 | 4 | When a security-constraint in the portable deployment descriptor includes a url-pattern that matches a request URL, the security annotations described in this section have no effect on the access policy that applies to the request URL. | true |  | false | technology | removed | true
Servlet:SPEC:219 | 14 | 4 | When none of these annotations have been assigned to the class and method targets corresponding to a request, the access policy that is applied to the request is established by the applicable security constraints, if any, in the corresponding portable deployment descriptor. | true |  | false | technology | removed | true
Servlet:SPEC:184 | 15 | 2 | Jakarta EE technology-compliant containers are required to provide a mechanism by which a deployer can learn about what jar file containing resources and code are available for the Web application. | true |  | false | platform | active | false
Servlet:SPEC:185 | 15 | 2 | Containers should provide a convenient procedure for editing and configuring library files or extensions. | false |  | true | platform | active | false
Servlet:SPEC:186 | 15 | 2.1 | Servlet containers that are part of a Jakarta EE product should not allow the application to override Java SE or Jakarta EE platform classes, such as those in the java.* and javax.* namespaces, that either Java SE or Jakarta EE do not allow to be modified. | true |  | false | platform | active | true
Servlet:SPEC:187 | 15 | 3.1 | A security identity, or principal, must always be provided for use in a call to an enterprise bean. | true |  | true | platform | active | true
Servlet:SPEC:188 | 15 | 3.1 | The default mode in calls to enterprise beans from web applications is for the security identity of a web user to be propagated to the Jakarta Enterprise Beans container. | true |  | true | platform | active | true
Servlet:SPEC:189 | 15 | 3.1 | web containers are required to allow web users that are not known to the web container or to the Jakarta Enterprise Beans container to make calls: | true |  | false | platform | active | true
Servlet:SPEC:189.1 | 15 | 3.1 | Web containers are required to support access to web resources by clients that have not authenticated themselves to the container. This is the common mode of access to web resources on the Internet. | true |  | true | platform | active | true
Servlet:SPEC:189.2 | 15 | 3.1 | Application code may be the sole processor of signon and customization of data based on caller identity. | true |  | true | platform | active | false
Servlet:SPEC:190 | 15 | 3.1 | a web application deployment descriptor may specify a run-as element. When a run-as role is specified for a Servlet, the Servlet container must propagate a principal mapped to the role as the security identity in any call from the Servlet to an Enterprise Beans, including calls originating from the Servlet's init and destroy methods. The security role name must be one of the security role names defined for the web application. | true |  | false | platform | active | true
Servlet:SPEC:191 | 15 | 3.1 | For web containers running as part of a Jakarta EE platform, the use of run-as elements must be supported both for calls to Jakarta Enterprise Beans components within the same Jakarta EE application, and for calls to Jakarta Enterprise Beans components deployed in other Jakarta EE applications. | true |  | false | platform | active | true
Servlet:SPEC:194 | 15 | 4.2 | Web containers may choose to support running components written to implement a Web service endpoint as defined by the JAX-RPC and/or JAX-WS specifications. | false |  | false | technology | active | true
Servlet:SPEC:173 | 15 | 4.2 | Web containers embedded in a JavaEE conformant implementation are required to support JAX-RPC and JAX-WS web service components. | true |  | false | platform | active | true
Servlet:SPEC:173.1 | 15 | 4.2 | JSR-109 [http://jcp.org/jsr/detail/109.jsp] defines the model for packaging a Web service interface with its associated WSDL description and associated classes. | true |  | false | platform | active | true
Servlet:SPEC:173.2 | 15 | 4.2 | It(JSR-109) defines a mechanism for JAX-WS and JAX-RPC enabled Web containers to link to a component that implements this Web service. | true |  | false | platform | active | true
Servlet:SPEC:173.3 | 15 | 4.2 | JAX-WS and JAX-RPC enabled Web containers must support the developer in using the Web deployment descriptor to define the following information for the endpoint implementation component, using the same syntax as for HTTP Servlet components using the servlet element. The child elements are are used to specify endpoint information in the following way: | true |  | false | platform | active | true
Servlet:SPEC:173.3.1 | 15 | 4.2 | the servlet-name element defines a logical name which may be used to locate this endpoint description among the other Web components in the WAR | true |  | false | platform | active | true
Servlet:SPEC:173.3.2 | 15 | 4.2 | the servlet-class element provides the fully qualified Java class name of this endpoint implementation | true |  | false | platform | active | true
Servlet:SPEC:173.3.3 | 15 | 4.2 | the description element(s) may be used to describe the component and may be displayed in a tool | false |  | false | platform | active | true
Servlet:SPEC:173.3.4 | 15 | 4.2 | the load-on-startup element specifies the order in which the component is initialized relative to other Web components in the Web container | true |  | false | platform | active | true
Servlet:SPEC:173.3.5 | 15 | 4.2 | the security-role-ref element may be used to test whether the authenticated user is in a logical security role | false |  | false | platform | active | true
Servlet:SPEC:173.3.6 | 15 | 4.2 | the run-as element may be used to override the identity propagated to Jakarta Enterprise Beans called by this component | true |  | false | platform | active | true
Servlet:SPEC:173.4 | 15 | 4.2 | Any servlet initialization parameters defined by the developer for this Web component may be ignored by the container. | false |  | false | platform | active | true
Servlet:SPEC:173.5 | 15 | 4.2 | JAX-WS and JAXRPC enabled Web component inherits the traditional Web component mechanisms for defining the following information: | true |  | false | platform | active | true
Servlet:SPEC:173.5.1 | 15 | 4.2 | mapping of the component to the Web container's URL namespace using the servlet mapping technique | true |  | false | platform | active | true
Servlet:SPEC:173.5.2 | 15 | 4.2 | authorization constraints on Web components using security constraints | true |  | false | platform | active | true
Servlet:SPEC:173.5.3 | 15 | 4.2 | the ability to use servlet filters to provide low-level byte stream support for manipulating JAX-WS and/or JAX-RPC messages using the filter mapping technique | true |  | false | platform | active | true
Servlet:SPEC:173.5.4 | 15 | 4.2 | the timeout characteristics of any HTTP sessions that are associated with the component | true |  | false | platform | active | true
Servlet:SPEC:173.5.5 | 15 | 4.2 | links to Jakarta EE objects stored in the JNDI namespace | true |  | false | platform | active | true
Servlet:SPEC:195 | 15 | 5 | Annotations must be supported on the following container managed classes that implement the following interfaces and are declared in the web application deployment descriptor or using the annotations defined in Section8.1, ?Annotations and pluggability? on page8-65 or added programmatically. | true |  | false | platform | active | true
Servlet:SPEC:195.1 | 15 | 5 | jakarta.servlet.Servlet | true |  | false | platform | active | true
Servlet:SPEC:195.2 | 15 | 5 | jakarta.servlet.Filter | true |  | false | platform | active | true
Servlet:SPEC:195.3 | 15 | 5 | jakarta.servlet.ServletContextListener | true |  | false | platform | active | true
Servlet:SPEC:195.4 | 15 | 5 | jakarta.servlet.ServletContextAttributeListener | true |  | false | platform | active | true
Servlet:SPEC:195.5 | 15 | 5 | jakarta.servlet.ServletRequestListener | true |  | false | platform | active | true
Servlet:SPEC:195.6 | 15 | 5 | jakarta.servlet.ServletRequestAttributeListener | true |  | false | platform | active | true
Servlet:SPEC:195.7 | 15 | 5 | jakarta.servlet.http.HttpSessionListener | true |  | false | platform | active | true
Servlet:SPEC:195.8 | 15 | 5 | jakarta.servlet.http.HttpSessionAttributeListener | true |  | false | platform | active | true
Servlet:SPEC:195.10 | 15 | 5 | jakarta.servlet.http.HttpSessionIdListener | true |  | false | platform | active | true
Servlet:SPEC:195.9 | 15 | 5 | jakarta.servlet.AsyncListener | true |  | false | platform | active | true
Servlet:SPEC:196 | 15 | 5 | References must be injected prior to any lifecycle methods being called and the component instance being made available the the application. | true |  | false | platform | active | true
Servlet:SPEC:197 | 15 | 5 | In a web application, classes using resource injection will have their annotations processed only if they are located in the WEB-INF/classes directory, or if they are packaged in a jar file located in WEB-INF/lib. | true |  | false | platform | active | true
Servlet:SPEC:198 | 15 | 5 | The web application deployment descriptor contains a metadata-complete attribute on the web-app element. The metadata-complete attribute defines whether the web descriptor is complete, or whether other sources of metadata used by the deployment process should be considered. Metadata may come from the web.xml file, web-fragment.xml files, annotations on class files in WEB-INF/classes, and annotations on classes in jar files in the WEB-INF/lib directory. If metadata-complete is set to "true", the deployment tool only examines the web.xml file and must ignore annotations such as @WebServlet, @WebFilter, and @WebListener present in the class files of the application, and must also ignore any web-fragment.xml descriptor packaged in a jar file in WEB-INF/lib. If the metadata-complete attribute is not specified or is set to "false", the deployment tool must examine the class files and web-fragment.xml files for metadata, as previously specified. | true |  | false | platform | active | true
Servlet:SPEC:289 | 15 | 5 | The web-fragment.xml also contains the metadata-complete attribute on the web- fragment element. The attribute defines whether the web-fragment.xml descriptor is complete for the given fragment, or whether it should scan for annotations in the classes in the associated jar file. If metadata-complete is set to "true" the deployment tool only examines the web-fragment.xml and must ignore annotations such as @WebServlet, @WebFilter and @WebListener present in the class files of the fragment. If metadata-complete is not specified or is set to "false" the deployment tool must examine the class files for metadata. | true |  | false | platform | active | true
Servlet:SPEC:199 | 15 | 5 | Following are the annotations that are required by a Jakarta EE technology compliant web container. | true |  | false | platform | active | true
Servlet:SPEC:199.1 | 15 | 5.4 | The @Resource annotation is used to declare a reference to a resource such as a data source, Java Messaging Service (JMS) destination, or environment entry. This annotation is equivalent to declaring a resource-ref, message-destinationref or env-ref, or resource-env-ref element in the deployment descriptor. @Resource annotation is specified on a class, method or field. The container is responsible injecting references to resources declared by the @Resource annotation and mapping it to the proper JNDI resources. | true |  | false | platform | active | true
Servlet:SPEC:199.2 | 15 | 5.11 | @Resources annotation acts as a container for multiple @Resource annotations because the Java MetaData specification does not allow for multiple annotations with the same name on the same annotation target. | true |  | false | platform | active | true
Servlet:SPEC:199.3 | 15 | 5.3 | InjectionComplete annotation is declared on a method which will be called after the resources injections have been completed and before any lifecycle methods on a component are called. This allows application code to do post create processing if necessary. | true |  | false | platform | removed | true
Servlet:SPEC:199.4 | 15 | 5.2 | Jakarta Enterprise Beans 4.0 components may be referenced from a web component using the @EJB annotation. The @EJB annotation provides the equivalent functionality of declaring the ejb-ref or ejb-local-ref elements in the deployment descriptor. Fields that have a corresponding @EJB annotation are injected with the a reference to the corresponding Jakarta Enterprise Beans component. | true |  | false | platform | active | true
Servlet:SPEC:199.5 | 15 | 5.13 | The @WebServiceRef annotation provides a reference to a web service in a web component in same way as a resource-ref element would in the deployment descriptor. | true |  | false | platform | active | true
Servlet:SPEC:199.6 | 15 | 5.1 | @DeclareRoles: This annotation is used to define the security roles that comprise the security model of the application. This annotation is specified on a class, and if it is used to define roles that could be tested (i.e., by calling isUserInRole) from within the methods of the annotated class. Roles that are implicitly declared as a result of their use in a @RolesAllowed need not be explicitly declared using the @DeclareRoles annotaion. The @DeclareRoles annotation may only be defined in classes implementing the jakarta.servlet.Servlet interface or a subclass thereof. | true |  | false | platform | active | true
Servlet:SPEC:199.7 | 15 | 5.12 | The @RunAs annotation is equivalent to the run-as element in the deployment descriptor. The @RunAs annotation may only be defined in classes implementing the jakarta.servlet.Servlet interface or a subclass thereof. | true |  | false | platform | active | true
Servlet:SPEC:199.8 | 15 | 5.3 | The @EJBs annotation allows more than one @EJB annotations to be declared on a single resource. | true |  | false | platform | active | true
Servlet:SPEC:199.9 | 15 | 5.5 | This annotation(@PersistenceContext) specifies the container managed entity manager for referenced persistence units. | true |  | false | platform | active | true
Servlet:SPEC:199.10 | 15 | 5.6 | The PersistenceContexts annotation allows more than one @PersistenceContext to be declared on a resource. | true |  | false | platform | active | true
Servlet:SPEC:199.11 | 15 | 5.7 | The @PersistenceUnit annotation provides Jakarta Enterprise Beans components declared in a servlet a reference to a entity manager factory. The entity manager factory is bound to a separate persistence.xml configuration file as described in section 5.10 of the Jakarta Enterprise Beans 4.0 specification. | true |  | false | platform | active | true
Servlet:SPEC:199.12 | 15 | 5.8 | This annotation(@PersistenceUnits) allows for more than one @PersistentUnit annotations to be declared on a resource. | true |  | false | platform | active | true
Servlet:SPEC:199.13 | 15 | 5.9 | The @PostConstruct annotation is declared on a method that does not take any arguments, and must not throw any checked exceptions. The return value must be void. The method MUST be called after the resources injections have been completed and before any lifecycle methods on the component are called. | true |  | false | platform | active | true
Servlet:SPEC:304 | 15 | 5.9 | TThe @PostConstruct annnotation MUST be supported by all classes that support dependency injection and called even if the class does not request any resources to be injected. If the method throws an unchecked exception the class MUST not be put into service and no method on that instance can be called. | true |  | false | platform | active | true
Servlet:SPEC:199.14 | 15 | 5.10 | The @PreDestroy annotation is declared on a method of a container managed component. The method is called prior to component being removed by the container. The method annotated with @PreDestroy must return void and must not throw a checked exception. The method may be public, protected, package private or private. The method must not be static however it may be final. | true |  | false | platform | active | true
Servlet:SPEC:204 | A | 7.1 | sessions of a context must be resumable by requests into that context regardless of whether their associated context was being accessed directly or as the target of a request dispatch at the time the sessions were created. | true |  | false | technology | active | true
Servlet:SPEC:205 | A | 8.1 | (The target servlet of the include method) cannot set headers or call any method that affects the headers of the response, with the exception of the HttpServletRequest.getSession() and HttpServletRequest.getSession(boolean) methods. Any attempt to set the headers must be ignored, and any call to HttpServletRequest.getSession() or HttpServletRequest.getSession(boolean) that would require adding a Cookie response header must throw an IllegalStateException if the response has been committed. | true |  | false | technology | active | true
Servlet:SPEC:206 | A | 8.2 | clarify a way to map a filter to all servlet dispatches ... uses the special servlet name '*'. | true |  | false | technology | active | true
Servlet:SPEC:207 | A | 8.3 | (Servlet 2.5) Previous versions of the servlet schema allows only a single url-pattern or servlet name per servlet mapping. For servlets mapped to multiple URLs this results in needless repetition of whole mapping clauses. The deployment descriptor servlet-mappingType was updated to... | true |  | false | technology | active | true
Servlet:SPEC:208 | A | 8.4 | (Servlet 2.5)Previous versions of the servlet schema allows only a single url-pattern in a filter mapping. For filters mapped to multiple URLs this results in needless repetition of whole mapping clauses. The deployment descriptor schema the filter-mappingType was updated to... This change allows multiple patterns and servlet names to be defined in a single mapping | true |  | false | technology | active | true
Servlet:SPEC:209 | A | 8.5 | The http-method elements now need to be a token as described in HTTP 1.1 specification section 2.2. | true |  | false | technology | active | true
Servlet:SPEC:210 | A | 8.8 | If the location of the error handler is a servlet or a JSP page: [...] The response setStatus method is disabled and ignored if called. | true |  | false | technology | active | true
Servlet:SPEC:211 | A | 8.9 | The API clarification better describes what happens when a client did not specify a session id. The API documentation in Section SRV.16.1.3, HttpServletRequest was updated to specify when false is returned: Returns false if the client did not specify any session ID. | true |  | false | technology | active | true
Servlet:SPEC:212 | A | 8.10 | Section SRV.5.5, Closure of Response Object was updated to the following: "The amount of content specified in the setContentLength method of the response has been greater than zero and has been written to the response". the response's content length is set to 0 via response.setHeader("Content-Length", "0") and any subsequently setHeader() calls are ignored. | true |  | false | technology | active | true
Servlet:SPEC:213 | A | 8.11 | The API in Section SRV.15.2.16, ServletRequest was updated to described the behavior if the method is called after the getReader() was called. If the getReader() is called there will be no effect. | true |  | false | technology | active | true