There are three ways the SpringMVC interceptor does not intercept static resources

  • 2020-06-01 09:41:12
  • OfStack

SpringMVC provide < mvc:resources > To set the static resource, but if the setting is increased by adding interceptors in the way of wildcards, it will still be intercepted by interceptors. The following solutions can be adopted:

Option 1. Add no filtering to the interceptor for static resources (spring-mvc.xml)

<mvc:resources location="/" mapping="/**/*.js"/> 
<mvc:resources location="/" mapping="/**/*.css"/> 
<mvc:resources location="/assets/" mapping="/assets/**/*"/> 
<mvc:resources location="/images/" mapping="/images/*" cache-period="360000"/>

    <mvc:mapping path="/**/*"/>
    <mvc:exclude-mapping path="/**/fonts/*"/>
    <mvc:exclude-mapping path="/**/*.css"/>
    <mvc:exclude-mapping path="/**/*.js"/>
    <mvc:exclude-mapping path="/**/*.png"/>
    <mvc:exclude-mapping path="/**/*.gif"/>
    <mvc:exclude-mapping path="/**/*.jpg"/>
    <mvc:exclude-mapping path="/**/*.jpeg"/>
    <mvc:exclude-mapping path="/**/*login*"/>
    <mvc:exclude-mapping path="/**/*Login*"/>
    <bean class=""></bean>

Scenario 2. Use the default static resource processing Servlet to process static resources (spring-mvc.xml, web.xml)

Enable the default Servlet in spring-mvc.xml


Add the handling of static resources in web.xml


However, the current Settings must be in front of Dispatcher for Spring

Option 3. Modify the global interception setting of Spring to *.do interception (involving web.xml)


With this setting, Spring will only process requests ending in '.do 'and will no longer maintain static resources

The advantages and disadvantages of the three schemes are analyzed as follows:

The first scheme is bloated in configuration, and the number of file lines is increased when multiple interceptors are used, which is not recommended. The second scheme USES the default Servlet to access resource files, and Spring intercepts all requests, and then sends the resource files to the default Sevlet for processing, with no loss in performance. The third solution, Spring, only handles the access ending in '.do ', which is more efficient in performance, but must end in '.do 'in the access path. URL is not very elegant.

To sum up, the second and third solutions are recommended

Related articles: