The versions of java required by the servlet specification have been updated to J2SE 1.3. Containers may still be developed to work with older versions of java, but a servlet can now be written to use 1.3 APIs and still be considered portable. Considering the length of time that 1.3 has been released and that 1.4 is now the norm, this is a more than reasonable change.

The specification also now requires that a servlet container supports HTTP/1.0 and HTTP/1.1 (as per RFC2616). This is actually a requirement of the Web Server associated with the servlet container and so could not strictly be policed from a compliance point of view. However the expectation is that filters and servlets may be written to read and generate the HTTP headers supported by these protocols and that whatever actual transport is used by the Servlet Container will respect the semantics of these. For example it is expected that HTTP/1.1 cache control headers will be transported to the client and any proxies even if the AJP13 protocol and apache mod_jk are the actual transport protocol used by the Servlet Container

It is a little known and little used feature of URIs that each path element may be given parameters such as:

/foo;a=1;b=2/bar;c=3

The only common use made of such parameters is by the Servlet specification itself for tracking HttpSession with URL rewriting, e.g.:

/foo/bar;jsessionid=a5d5f25s727a01

The servlet specification currently has no other support for path parameters and has always excluded them from the request parameter API:

The 2.4 servlet goes further in clarifying that path parameter are not considered when mapping URIs to servlets:

In practise, most containers will continue to only correctly handle trailing path parameters until later versions of the specification give a more detailed treatment of path parameters.

The 2.4 specification now better defines the mechanism that a container may use to implement the error pages. Previously the dispatch to use was undefined, so that it was not clear how filters should be applied or what values the path methods should return.

The enhancement to filters already discussed have also made it clear when filters are applied to error pages.

The triggering of the error page mechanism has been explicitly restricted to use of the sendError method and for exceptions thrown back to the container from an original request. Use of the setStatus method and exceptions thrown by RequestDisptachers or calls to doFilter will not invoke the error page mechanism. Finally, it has been made explicit exactly when setStatus and sendError will be used:

Thus it is now clear for example, that setting an error page mapping for the 200 status will not result in the error page being invoked for normal responses.

The dispatch mechanism for welcome files has also been somewhat addressed:

In Australia this would be called a Claytons clarification, after a famous advertising campaign for a non alcoholic drink that used the tag line "the drink I have when I'm not having a drink". The 2.4 specification only clarifies that there is no clarity as to what dispatch mechanism should be used for welcome files. Thus it is unclear what filters will apply and what the request path methods should return and as a result many containers offer an option of several different welcome dispatch mechanisms .

The use of HTTP redirection for welcome files is common, as in 2.3 it was the only way to allow Filters to be applied to welcome files with the same semantics as normal requests. The down side if this is that another round trip to the client is required and that the full welcome file URL is exposed to the user.

The improved filter mechanism makes the HTTP forward mechanism a viable and well defined alternative for welcome file dispatch. Hopefully it will be this that future specifications recommend.

Other "clarifications" to the welcome file mechanism are discussed later in New and Unresolved Problems.

The life cycle of a web application and the events associated with it have been clarified with several changes throughout the specification and javadoc, plus the addition of section SRV.9.12 on web application deployment.

It has now been made explicit that the ServletContextListener.contextInitialized method is called before any filters or servlets are initialized. It thus joins HttpSessionListener.sessionDestroyed as an event whose name has the incorrect tense and thus can be misleading. Hopefully future versions of the specification will deprecate these methods and rename them contentInitialize and destroySession.