Is the Default Servlet a (de facto) standard?

Question

Related to this question, is the idea of a default servlet that serves static content a standard (even if a de facto one) across servlet containers, or does its use restrict deployment to Tomcat / Jetty?

For example, 1 shows this method for getting the default dispatcher:

 final RequestDispatcher rd = getServletContext().getNamedDispatcher("default");

From a quick search it seems that this would also work on Jetty. How broadly will this technique work for obtaining a default servlet? For the servlet containers that have a default servlet, is it always a static content servlet?

Answer 1

It's not a standard, but without it appservers can't serve static content. It's just crucial.

[edit] I saw you edited and elaborated your question in a more clear manner:

For example, [1] shows this method for getting the default dispatcher:

final RequestDispatcher rd = getServletContext().getNamedDispatcher("default");

From a quick search it seems that this would also work on Jetty. How broadly will this technique work for obtaining a default servlet? For the servlet containers that have a default servlet, is it always a static content servlet?

In that case, it may be a defacto standard, but I wouldn't rely much on that and for sure not code against implementation specific details or even defacto standards. Ask yourself: what's the sense/value of dispatching the request to the defaultservlet? Exactly, nothing.

Answer 2

Servlet doesn't require a default servlet. However, the name must be "default" if one is defined. Can't imagine a container without default servlet. So you can assume it's standard.

See section SRV.11.1,

4. If neither of 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 application, it will be used.

Answer 3

As long as the servlet container standard is the Servlet API you can see there is no such thing as a DefaultServlet. Most widely used servlet container have some defaults to run out of the box. But it is no "standard" requirement to implement a certain interface or abstract class so the container can run. ( A container can run even without any servlet).

Answer 4

Servlet Specification

The Servlet Specification does mention a "default" servlet, but there is no specification for it, it only mentions how the servlet container should use the default servlet in case it exists, but doesn't describe how the default servlet itself should be implemented.

The Servlet Specification specifies that if there is no URL mapping for a request:

the container will attempt to serve content appropriate for the resource requested. If a "default" servlet is defined for the application, it will be used. Many containers provide an implicit default servlet for serving content.

The "/" URL mapping indicates the default servlet:

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.

Note that the word "indicates" is used, meaning that it is not a requirement.

The default servlet is usually used to serve static content, and is usually included in servlet containers, but it's not a requirement.

You can create your own default servlet (thereby overruling the one provided by the servlet container) by mapping a servlet to "/". Which usually means that it will disable static file serving, unless the selected servlet (or filters) does it. So if you have a simple servlet that only outputs a simple string like "Hello World", and set it as default servlet by mapping it to "/", then you disable things like 404 errors, because your simple servlet won't throw them. So then all (random) url requests that are not handled by more specific URL mappings, will be caught by the simple servlet.

Tomcat

Tomcat about their DefaultServlet:

The default servlet is the servlet which serves static resources as well as serves the directory listings (if directory listings are enabled).

Tomcat also says that you can change their default servlet:

If you need to change the DefaultServlet settings for an application you can override the default configuration by re-defining the DefaultServlet in /WEB-INF/web.xml. However, this will cause problems if you attempt to deploy the application on another container as the DefaultServlet class will not be recognised.

Jetty

Jetty also has a DefaultServlet.

This servlet, normally mapped to /, provides the handling for static content, OPTION and TRACE methods for the context.

Use cases

Change default behavior

You can use the DefaultServlet of your container in case you want to modify default behavior of the servlet container in case no url mapping is found. For example the behavior of directory listing, static file serving, etc.

RequestDispatching

Even though the answer that is currently marked as the solution says "Ask yourself: what's the sense/value of dispatching the request to the defaultservlet? Exactly, nothing.", there can be valid use cases.

In some cases, you may want to programmatically stop further filterchaining of your filters from within one of your filters, and forward the request to default behavior of the servlet container. In that case, you can forward to the DefaultServlet, which usually use the name "default", although this does make the app a bit container dependent. This can be done by using ServletContext.getNamedDispatcher("default")

So then you get something like this:

public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) {
    if (someCondition) {
        // chain to next filter
        chain.doFilter(req, res);
    } else {
        // forward to DefaultServlet, for example, when you don't want 
        // further filters to be applied on the request of a static resource
        req
                .getServletContext()
                .getNamedDispatcher("default")
                .forward(req, res);
    }
}