Go to servlet URL matching and URL-Pattern

 

Servlet is a common technology used in J2EE development. It is easy to use, easy to configure, and suitable for all users. It is estimated that most of my friends are directly configured and used without having to worry about specific details. I encountered a problem today and found out only when I checked servlet specifications online, there are some articles in the URL-pattern in servlet, which summarize some things and provide them for your reference to avoid wasting time in case of problems.

1. url matching process of the servlet container:

When a request is sent to the servlet container, the container first uses the requested URL minus the current application context path as the servlet ing URL. For example, I access HTTP: // localhost/test/aaa.html. My application context is test. The Container removes http: // localhost/test, and the rest of the/aaa.html part is used for servlet ing matching. This ing matching process is sequential, and when a servlet matches successfully, it will not ignore the remaining servlet (different filters will be mentioned later ). The matching rules and sequence are as follows:

1. Exact path matching. Example: for example, if the URL-pattern of servleta is/test and the URL-pattern of servletb is/*, if the url I access is http: // localhost/test, in this case, the container will first perform exact Path Matching and find that/test is exactly matched by servleta. Then, the container will call servleta and ignore other servlets.
2. Longest path match. Example: The URL-pattern of servleta is/test/*, while the URL-pattern of servletb is/test/A/*. When you access http: // localhost/test/, the container will select the servlet with the longest path to match, that is, the servletb here.
3. Extension match. If the last segment of the URL contains extensions, the container selects the appropriate servlet Based on the extension. Example: servleta URL-pattern: *. Action
4. If no servlet is found in the first three rules, the container selects the corresponding request Resource Based on the URL. If the application defines a default servlet, the container will throw the request to the default servlet (what is the default servlet? Later ).

According to this rule table, you can clearly understand the servlet matching process. Therefore, when defining the servlet, you must also consider the URL-pattern method to avoid errors.

For a filter, it does not match only one Servlet as the servlet does. Because the set of filters is a chain, there will only be different processing sequence, and only one filter will not be selected. The processing sequence of the filter is the same as that defined by the filter-mapping in Web. xml.

Ii. url-pattern explanation

In the Web. xml file, the following syntax is used to define the ing:

L what starts with "/" and ends with "/*" is used for path ing.

L prefix "*." is used for extension ing.

L "/" is used to define the default servlet ing.

L The rest are used to define detailed mappings. For example:/AA/BB/CC. Action

Therefore, why does the "/*. Action" such a seemingly normal matching look wrong? Because this match is a path ing and also an extension ing, the container cannot judge.

 

Go to servlet URL matching and URL-Pattern