Catalina Functional Specifications

Apache Tomcat 7

Version 7.0.100, Feb 11 2020
Apache Logo

Links

Administrative Apps

Internal Servlets

Realm Implementations

Default Servlet

Table of Contents
Overview
Introduction

The purpose of the Default Servlet is to serve static resources of a web application in response to client requests. As the name implies, it is generally configured as the "default" servlet for a web application, by being mapped to a URL pattern "/".

External Specifications

The following external specifications have provisions which partially define the correct behavior of the default servlet:

Implementation Requirements

The implementation of this functionality shall conform to the following requirements:

  • Must be implemented as a servlet.
  • Must support configurable parameters for debugging detail level, input buffer size, output buffer size, whether or not to produce directory listings when no welcome file is present, and whether or not modifications are supported via DELETE and PUT.
  • Log debugging and operational messages (suitably internationalized) via the getServletContext().log() method.
Dependencies
Environmental Dependencies

The following environmental dependencies must be met in order for the default servlet to operate correctly:

  • The default servlet must be registered in the application deployment descriptor (or the default deployment descriptor in file $CATALINA_BASE/conf/web.xml) using a "default servlet" servlet mapping, signified by URL pattern "/".
Container Dependencies

Correct operation of the default servlet depends on the following specific features of the surrounding container:

  • The container shall provide a servlet context attribute that lists the welcome file names that have been defined for this web application.
  • The container shall provide a servlet context attribute that contains a javax.naming.directory.DirContext implementation representing the static resources of this web application.
Functionality
Initialization Functionality

The following processing must be performed when the init() method of the default servlet is called:

  • Process and sanity check configuration parameters.
Per-Request Functionality

For all HTTP request methods, the resource path is determined from the path information provided to this request, either as request attribute javax.servlet.include.path_info (for a request dispatcher access to a static resource) or by calling request.getPathInfo() directly.

On each HTTP DELETE request processed by this servlet, the following processing shall be performed:

  • If modifications to the static resources are not allowed (set by a configuration parameter), return HTTP status 403 (forbidden).
  • If an attempt is made to delete a resource from /META-INF or /WEB-INF, return HTTP status 403 (forbidden).
  • If the requested resource does not exist, return HTTP status 404 (not found)
  • Unbind the resource from the directory context containing the static resources for this web application. If successful, return HTTP status 204 (no content). Otherwise, return HTTP status 405 (method not allowed).

On each HTTP GET request processed by this servlet, the following processing shall be performed:

  • If the request is for a resource under /META-INF or /WEB-INF, return HTTP status 404 (not found).
  • If the requested resource does not exist, return HTTP status 404 (not found).
  • If the requested resource is not a directory, but the resource path ends in "/" or "\", return HTTP status 404 (not found).
  • If the requested resource is a directory:
    • If the request path does not end with "/", redirect to a corresponding path with "/" appended so that relative references in welcome files are resolved correctly.
    • If one of the specified welcome files exists, redirect to the path for that welcome file so that it will be served explicitly.
  • If the request being processed contains an If-Range header, perform the processing described in the HTTP/1.1 specification to determine whether the client's information is up to date.
  • Determine the content type of the response, by looking up the corresponding MIME type in our servlet context.
  • If the requested resource is a directory:
    • If directory listings are suppressed, return HTTP status 404 (not found).
    • Set the content type to text/html.
  • Determine the range(s) to be returned, based on the existence of any If-Range and Range headers.
  • If the requested resource is a directory, include an ETag header in the response, with the value calculated based on the content of the directory.
  • Include a Last-Modified header in the response documenting the date/time that the resource was last modified.
  • Unless we are processing a HEAD request, include the appropriate content (or content ranges) in the response.

On each HTTP HEAD request processed by this servlet, the following processing shall be performed:

  • Processed identically to an HTTP GET request, except that the data content is not transmitted after the headers.

On each HTTP POST request processed by this servlet, the following processing shall be performed:

  • Processed identically to an HTTP GET request.

On each HTTP PUT request processed by this servlet, the following processing shall be performed:

  • If modifications to the static resources are not allowed (set by a configuration parameter), return HTTP status 403 (forbidden).
  • If an attempt is made to delete a resource from /META-INF or /WEB-INF, return HTTP status 403 (forbidden).
  • Create a new resource from the body of this request.
  • Bind or rebind the specified path to the new resource (depending on whether it currently exists or not). Return HTTP status as follows:
    • If binding was unsuccessful, return HTTP status 409 (conflict).
    • If binding was successful and the resource did not previously exist, return HTTP status 201 (created).
    • If binding was successful and the resource previously existed, return HTTP status 204 (no content).
Finalization Functionality

No specific processing is required when the destroy() method is called:

Testable Assertions

In addition to the assertions implied by the functionality requirements listed above, the following additional assertions shall be tested to validate the behavior of the default servlet:

  • Requests for resources that do not exist in the web application must return HTTP status 404 (not found).
  • The default servlet must operate identically for web applications that are run out of a WAR file directly, or from an unpacked directory structure.
  • If the web application is running out of an unpacked directory structure, the default servlet must recognize cases where the resource has been updated through external means.
Comments

Notice: This comments section collects your suggestions on improving documentation for Apache Tomcat.

If you have trouble and need help, read Find Help page and ask your question on the tomcat-users mailing list. Do not ask such questions here. This is not a Q&A section.

The Apache Comments System is explained here. Comments may be removed by our moderators if they are either implemented or considered invalid/off-topic.


Copyright © 1999-2020, Apache Software Foundation