Inbu
Inbu

Reputation: 21

Tomcat - How exactly context path matching works?

Suppose I have two Spring webapps deployed to the same Tomcat server instance:

A:

ROOT.war, context = /

@Controller
class TestController {

    @RequestMapping("/api/someMethod")
    public String someMethod() {
        //..
    }

    @RequestMapping("/api/v1/someMethod")
    public String someMethod() {
        //..
    }
}

B:

api#v1.war, context = /api/v1/

@Controller
class TestController {

    @RequestMapping("/someMethod")
    public String someMethod() {
        //..
    }
}

Which web application will be used to process the following HTTP requests?

GET http://<hostname>/api/someMethod

GET http://<hostname>/api/v1/someMethod

GET http://<hostname>/api/v1/nonexistentMethod

As you can see the second HTTP request matches both apps. I have tried to find answer in Tomcat docs, but found none. Where is specified how context path matching works?

Upvotes: 1

Views: 1117

Answers (1)

enzo
enzo

Reputation: 886

According to Servlet 3.0 Specification

10.1 Web Applications Within Web Servers

A Web application is rooted at a specific path within a Web server. For example, a catalog application could be located at http://www.mycorp.com/catalog. All requests that start with this prefix will be routed to the ServletContext which represents the catalog application.

A servlet container can establish rules for automatic generation of Web applications. For example a ~user/ mapping could be used to map to a Web application based at /home/user/public_html/

12.1 Use of URL Paths

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. 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:

  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.

  2. The container will recursively try to ma tch the longest path-pre fix. 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.

  3. 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.

  4. Versions of this specification prior to 2.5 made use of these mapping techniques as a suggestion rather than a requirement, allowing servlet containers to each have their different schemes for mapping client requests to servlets.

  5. If neither of the previous three rules re sult 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. Many containers provide an implicit default servlet for serving content.

Also Tomcat Request Process Flow might be useful

Upvotes: 2

Related Questions