A detailed description of the servlet's Url-pattern matching rules

I. Overview

When matching a URL request with a servlet or filter, the key is to match the rules, but the matching rules in the servlet container are neither simple nor regular expressions, but rather easily confused by their own rules. This article provides a detailed example of this. The following instructions are validated on the Tomcat server.

First introduce the concept of matching, the example code. In an app, such as the Web. xml file named MyApp, the following information is available:

<servlet>    <Servlet-name>Myservlet</Servlet-name>    <Servlet-class>Com.nau.MyServlet</Servlet-class>  </servlet>    <servlet-mapping>    <Servlet-name>Myservlet</Servlet-name>    <Url-pattern>Xxxxxx</Url-pattern>   <Url-pattern>Yyyyyyy</Url-pattern>  </servlet-mapping>

The configuration information above, where the <servlet> tag is first configured to declare a servlet, including the name of the servlet and the corresponding Java class name.
Where the <servlet-mapping> tag declares a matching rule corresponding to the servlet, each <url-pattern> tag represents 1 matching rules.

When the browser initiates a URL request and the request is sent to the servlet container, the container first subtracts the requested URL from the path of the current application context as a mapped URL for the servlet, such as the URL is http://10.43.11.143/myapp/kata/ Detail.html, the application context is MyApp, the container will Http://10.43.11.143/myapp removed, the remainder of the/kata/detail.html to do the servlet mapping matching. This mapping matching process is prioritized (described later in the order of precedence rules), and when a servlet match succeeds, the remaining servlet is not ignored.

Note that the filter matches the same rules as the servlet, but for filter, it does not match just one servlet as the servlet, because the filter collection is a chain, so there will be only a different order of processing, instead of just selecting one filter. The filter is processed in the same order as the filter-mapping defined in Web. Xml.

Here we describe in detail the various matching rules

Second, exact match

The items configured in <url-pattern> must match exactly with the URL.

The configuration information is as follows:

<servlet-mapping>    <Servlet-name>Myservlet</Servlet-name>    <Url-pattern>/kata/detail.html</Url-pattern>    <Url-pattern>/demo.html</Url-pattern>    <Url-pattern>/table</Url-pattern></servlet-mapping>

When several URLs are entered in the browser, they are matched to the servlet
Http://10.43.11.143/myapp/kata/detail.html
Http://10.43.11.143/myapp/demo.html
Http://10.43.11.143/myapp/table

Attention:

http://10.43.11.143/myapp/table/is an illegal URL and will not be recognized as a http://10.43.11.143/myapp/table

In addition, the above URL can be followed by arbitrary query conditions, will be matched, such as

Http://10.43.11.143/myapp/table?hello this request will be matched to Myservlet.

Third, extension matching

If the matching rules are

< servlet-mapping >    < Servlet-name > Myservlet</servlet-name>    <Url-pattern> *.jsp</url-pattern></servlet-mapping >

Any URL requests with the extension JSP (file name and path arbitrary) will match, such as the following URLs will be matched
http://10.43.11.143/myapp/demo.jsp
http://10.43.11.143/myapp/test.jsp

Four, path matching

If the matching rules are

< servlet-mapping >    < Servlet-name > Myservlet</servlet-name>    <Url-pattern  >/kata/*</url-pattern></servlet-mapping  >

The requested ULR as long as the path before (MyApp) is/kata, and the subsequent path can be arbitrary. For example, the following URLs will be matched.
Http://10.43.11.143/myapp/kata/demo.html
http://10.43.11.143/myapp/kata/test.jsp
Http://10.43.11.143/myapp/kata/test/detail.html

Http://10.43.11.143/myapp/kata/action

http://10.43.11.143/myapp/kata/action/

Note: The path and extension matching cannot be set at the same time, such as the following three <url-pattern> is illegal, if set, start Tomcat server will error.

<url-pattern>/kata/*.jsp</url-pattern>

<url-pattern>/*.jsp</url-pattern>

<url-pattern>he*.jsp</url-pattern>

Also note:<url-pattern>/aa/*/bb</url-pattern>
This is the exact match, the URL must be/aa/*/bb, and here the * is not the meaning of the wildcard

V. Match any URL

If <url-pattern> is configured as one of the following two types of

<url-pattern>/</url-pattern>

<url-pattern>/*</url-pattern>

All URLs can be matched. where/* is the path match, just the path is/.

Vi. Order of Precedence

When a URL matches a match rule for more than one servlet, the corresponding servlet is matched to a priority such as "exact path > Longest path > Extension". Examples are as follows:

Example 1: For example Servleta Url-pattern for/TEST,SERVLETB url-pattern for * *, this time, if I visit the URL is http://localhost/test, This time the container will be the exact path matching, found that the/test is precisely matched by Servleta, then go to call Servleta, do not go to the tube servletb.

Example 2: For example Servleta Url-pattern for/test/*, and Servletb Url-pattern for/test/a/*, at this time to visit http://localhost/test/a, The container chooses the longest path of the servlet to match, which is where the SERVLETB.

Example 3: For example Servleta url-pattern:*.action, Servletb url-pattern is/*, this time, if I visit the URL is http://localhost/ Test.action, this time the container will prioritize path matching instead of matching the extension so that it calls SERVLETB.

Vii. Summary

This article describes the matching rules for servlets in detail. In general, there are three ways to match the exact, path and extension, and the priority is introduced.

A detailed description of the servlet's Url-pattern matching rules