Servlet and filter are common techniques in the development of the Java EE, easy to use and easy to configure. Url-pattern in servlet and filter There are some articles in it that summarize something to avoid problems and wasting time.
One, the servlet container-to-url matching process:
When a 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, for example, I am visiting http://localhost/test/ aaa.html, my application context is test, the container will remove Http://localhost/test, and the rest of the/aaa.html to do the servlet mapping match. The mapping matching process is sequential, and when a servlet match succeeds, the remaining servlet will not be heeded (the filter is different and will be mentioned later). The matching rules and Order are as follows:
1. Exact path matching. Example: For example, Servleta Url-pattern for/TEST,SERVLETB url-pattern for * *, this time, if I access 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, will not ignore the other servlet.
2. Longest path match. Example: Servleta's Url-pattern is/test/*, and Servletb's Url-pattern is/test/a/*, at this time when the http://localhost/test/a is visited, The container chooses the longest path of the servlet to match, which is where the SERVLETB.
3. If the last paragraph of the URL contains an extension, the container will select the appropriate servlet based on the extension. Example: Servleta's Url-pattern:*.action
4. If none of the preceding three rules find a servlet, the container chooses the corresponding request resource based on the URL. If the app defines a default servlet, the container throws the request to the default servlet (what is the default servlet?). will be spoken later).
According to this rule table, it is clear that the servlet matching process, so the definition of servlet should also consider the wording of url-pattern, so as not to make mistakes.
For filter, it does not match just one servlet, as the servlet does, because the collection of filter is a chain, so only the order of processing is different, and no one filter is selected. The filter is processed in the same order as the filter-mapping defined in Web. Xml.
Second, Url-pattern detailed
In the Web. xml file, the following syntax is used to define the mappings:
L. Starting with "/" and ending with "/*" are used for path mapping.
2. Previous prefix "*." The beginning is used to do the extension mapping.
3. "/" is used to define the default servlet mappings.
4. The rest is used to define a detailed mapping. For example:/aa/bb/cc.action
So why is it wrong to define "/*.action" as a seemingly normal match? Because this match belongs to the path mapping, also belongs to the extension mapping, causes the container to be unable to judge. That is, the parser cannot parse the pattern:/*.action
<url-pattern>/</url-pattern> will match a path URL such as/login, and will not match a suffix type such as the pattern *.jsp url<url-pattern>/*</ Url-pattern> matches all URLs: path-type and suffix-type URLs (including/login,*.jsp,*.js and *.html, etc.) matching suffixes:<url-pattern>*.action</url-pattern>/aa/bb/cc.action Detailed mapping
Url-pattern mapping rules in Web. xml
