About the Url-pattern description in servlet-mapping

The following is a servlet defined in Web.xml, including class location and servlet-mapping

<servlet>
<servlet-name>SayHello</servlet-name>
<servlet-class>common. Sayhello</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>SayHello</servlet-name>
<url-pattern>/SayHello</url-pattern>
</servlet-mapping>

When executing the http://localhost:8080/site name/sayhello in the browser, it is possible to execute the servlet, where the SayHello corresponds to the url-pattern defined in servlet-mapping SayHello , if we modify the servlet-mapping:

<servlet-mapping>
<servlet-name>SayHello</servlet-name>
<url-pattern>/SayHello123456</url-pattern>
</servlet-mapping>

Then in the browser execution http://localhost:8080/site name/sayhello is wrong, this is supposed to be http://localhost:8080/site name/sayhello123456

So Url-pattern completely corresponds to the browser's input

3.3.2 <servlet-mapping> elements and their child elements

The <servlet-mapping> element defines a mapping between the servlet and the URL style. It contains two child elements <servlet-name> and <url-pattern>,<servlet-name> elements given by the servlet name must be in <servlet> The name of the servlet declared in the element. The <url-pattern> element specifies the URL path that corresponds to the servlet, which is a path relative to the root of the Web application. For example:

<servlet-mapping> <servlet-name>helloworld</servlet-name> <url-pattern>/hello </url-pattern> </servlet-mapping>

The Servlet 2.5 specification allows <servlet-mapping> <url-pattern> child elements to appear multiple times before the specification allows only one <servlet-mapping> element to contain a < Url-pattern> the child element. Let's look at the following example:

<servlet-mapping> <servlet-name>welcome</servlet-name> <url-pattern>/en/ welcome</url-pattern> <url-pattern>/zh/welcome</url-pattern> </servlet-mapping >

After you configure the mapping between the servlet and the URL style, when a servlet container receives a request, it first determines which Web application should respond to the request. This is determined by comparing the start portion of the request URI with the context path of the Web application. The path mapped to the servlet is the path to the request URI minus the context, and the Web application's context object, after removing the contextual path of the request URI, processes the remainder of the path in the order of the following path mapping rules, and after the first successful match is found, No next match is made.

The container tries to accurately match the path to the request and the paths of the servlet map, and if the match succeeds, call the servlet to process the request.

The container tries to match the longest path prefix, with a slash (/) as the path separator, and the longest matching servlet to process the request, according to the path tree descending to match.

If the requested URL path finally has an extension, such as the. Jsp,servlet container tries to match the servlet that handles this extension.

If a matching servlet is not found according to the preceding 3 rules, the container invokes the Web application default servlet to process the request, and if no default servlet is defined, the container sends an HTTP 404 error message to the client (the request resource does not exist).

In the deployment descriptor, you can use the following syntax to define mappings.

A string ending with//is used to map the path, for example:

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

If there is no exact match, all requests for resources under the/admin/path will be handled by the servlet that maps the URL style described above.

with *. A prefix string is used to map an extension, for example:

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

If there is no exact match and path matching, the request to the resource with the. do extension will be handled by the servlet that maps the URL style described above.

With a separate/directed servlet for this Web application default, for example:

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

If a matching servlet is not found for a request, the default servlet of the Web application is used for processing.

All other characters are used for exact matches, for example:

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

If the request is/login, it is handled by a servlet that maps the URL-style/login.

Let's look at several examples of request mappings, as shown in table 3-2 and table 3-3.

Table 3-2 servlet Mappings

Mapped URLs	The corresponding servlet
/hello	Servlet1
/bbs/admin/*	Servlet2
/bbs/*	Servlet3
*.jsp	Servlet4
/	Servlet5

Table 3-3 Results of the actual request mapping

Remove the remaining path of the context path	Process request servlet
P>/hello	Servlet1
/bbs/admin/login	Serv Let2
/bbs/admin/index.jsp	Servlet2
/bbs/display	Servlet3
/bbs/index.jsp	Servlet3
/bbs	Servlet3
/index.jsp	Servler4
/hello/index.jsp	Servlet4
/hello/index.html	Servlet5
/news	Servlet5

Tomcat has configured the default servlet in the%catalina_home%\conf\web.xml file with the following configuration code:

<servlet> <servlet-name>default</servlet-name> <servlet-class> Org.apache.catalina.servlets.DefaultServlet </servlet-class> <init-param> <param-name >debug</param-name> <param-value>0</param-value> </init-param> < init-param> <param-name>listings</param-name> <param-value>true</param-value > </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>default</servlet-name> <url-pattern>/ </url-pattern> </servlet-mapping>

The configuration in the%catalina_home%\conf\web.xml file is shared by all Web applications that are running in the same Tomcat instance.