tomcat配置文件catalina.sh中添加-Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE=true导致的问题

背景：

背景是一个后台管理系统，有一个controller映射的路径是根路径/

@RequestMapping({"/queryItem", "/"})
	public ModelAndView queryItem() {
		//用静态数据模型
		List<item> itemList=new ArrayList<item>();
		
		item item_1=new item();
		item_1.setName("苹果手机");
		item_1.setPrice(5000);
		item_1.setDetail("iphoneX苹果手机!");
		itemList.add(item_1);
		
		item item_2=new item();
		item_2.setName("华为手机");
		item_2.setPrice(6000);
		item_2.setDetail("华为5G网速就是快!");
		itemList.add(item_2);
		ModelAndView mvAndView=new ModelAndView();
		//设置数据模型,相当于request的setAttribute方法,实质上，底层确实也是转成了request()
		//先将k/v数据放入map中，最终根据视图对象不同，再进行后续处理
		mvAndView.addObject("itemList",itemList);
		//设置view视图
		mvAndView.setViewName("/WEB-INF/jsp/item/item-list.jsp");
		return mvAndView;
	}

在某次上线完成后，发现根路径访问出现404错误，上线之前一直是正常的，怀疑是tomcat问题，经过排查，发现此次上线用的是运维提供的tomcat8.5.57版本和官方的tomcat8.5.57有一处不同。

运维提供的tomcat8.5.57版本：

JAVA_OPTS="$JAVA_OPTS -Dorg.apache.catalina.security.SecurityListener.UMASK=`umask` \
                      -Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE=true \
                      -Dorg.apache.catalina.connector.RECYCLE_FACADES=true \
                      -Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH=false \
                      -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=false \
                      -Dorg.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER=false"

官方版本的tomcat

JAVA_OPTS="$JAVA_OPTS -Dorg.apache.catalina.security.SecurityListener.UMASK=`umask`"

问题明确了，就是一些启动参数对根路径的访问产生了影响。具体是哪一个，笨办法：在官方提供的tomcat版本中，一个个添加启动参数，最终定位于是org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true，可以复现此异常。

在tomcat官网查看这个参数的解释：

https://tomcat.apache.org/tomcat-8.5-doc/config/systemprops.html

 通过官方文档，该配置就是一个开关，它控制着其它属性的值。

好吧，继续研究是哪个属性导致的问题。看每个属性的描述，感觉和导致的问题没什么关系，只能笨办法，一个个尝试了。尝试的思路很简单，在catalina.sh脚本中，不添加这个org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true配置，而是依次添加

表格中STRICT_SERVLET_COMPLIANCE所影响的其它属性值，比如说，

这个意识是说，如果org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true设置为了true，那么org.apache.catalina.core.ApplicationContext .GET_RESOURCE_REQUIRE_SLASH也被设置成true。因此，为了验证是否是这个属性导致的问题，在catalina.sh这样写。

JAVA_OPTS="$JAVA_OPTS -Dorg.apache.catalina.security.SecurityListener.UMASK=`umask` \
                      -Dorg.apache.catalina.core.ApplicationContext.GET_RESOURCE_REQUIRE_SLASH=true"

 通过一个一个排查，最终发现是resourceOnlyServlets属性导致的问题。看一下官方对此属性的解释：

resourceOnlyServlets默认值是jsp，如果org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true设置为了true，那么默认是空字符串""。

那么只需要再context.xml设置该属性值为空字符串即可复现异常问题。

<Context resourceOnlyServlets="">

    <!-- Default set of monitored resources. If one of these changes, the    -->
    <!-- web application will be reloaded.                                   -->
    <WatchedResource>WEB-INF/web.xml</WatchedResource>
    <WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>

    <!-- Uncomment this to disable session persistence across Tomcat restarts -->
    <!--
    <Manager pathname="" />
    -->
</Context>

解决办法：

解决办法很简单，删除-Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE=true即可

原因分析：

由于这个属性，可查的资料很少。个人猜测该属性影响了欢迎页的访问。

tomcat在初始化的时候，构造了与servlet对应的MappedWrapper，其中就有一个属性resourceOnly

protected static class MappedWrapper extends MapElement<Wrapper> {

        public final boolean jspWildCard;
        public final boolean resourceOnly;

        public MappedWrapper(String name, Wrapper wrapper, boolean jspWildCard,
                boolean resourceOnly) {
            super(name, wrapper);
            this.jspWildCard = jspWildCard;
            this.resourceOnly = resourceOnly;
        }
    }

在构造MappedWrapper时，需要传入resourceOnly值，看一下addWrapper方法，

protected void addWrapper(ContextVersion context, String path,
        Object wrapper, boolean jspWildCard, boolean resourceOnly) {

再看一下调用addWrapper方法的地方

            mapper.addWrapper(hostName, contextPath, version, mapping, wrapper,
                    jspWildCard, context.isResourceOnlyServlet(wrapperName));

其中context是一个接口，其实现类org.apache.catalina.core.StandardContext：

    @Override
    public boolean isResourceOnlyServlet(String servletName) {
        return resourceOnlyServlets.contains(servletName);
    }

到此resourceOnlyServlets确定影响的是Wrapper了。当一下请求进来时候，要选择不同的Wrapper进行处理。

接下来科普一下url-pattern匹配优先级

(1) 首先精准匹配
(2) 然后是通配符匹配
(3) 然后是扩展名匹配
(4) 然后是欢迎页面匹配（这里又细分了很多的规则）
(5) 最后是默认匹配

注意：如果springmvc项目配置了

	<servlet>
		<servlet-name>springmvc</servlet-name>
		<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
		<!-- 设置spring配置文件路径 -->
		<!-- 如果不设置初始化参数，那么DispatcherServlet会读取默认路径下的配置文件 -->
		<!-- 默认配置文件路径：/WEB-INF/springmvc-servlet.xml -->
		<init-param>
			<param-name>contextConfigLocation</param-name>
			<param-value>classpath:springmvc.xml</param-value>
		</init-param>
		<!-- 指定初始化时机，设置为2，表示Tomcat启动时，它会跟随着启动，DispatcherServlet会跟随着初始化 -->
		<!-- 如果没有指定初始化时机，DispatcherServlet就会在第一次被请求的时候，才会初始化，而且只会被初始化一次(单例模式) -->
		<load-on-startup>2</load-on-startup>
	</servlet>
	<servlet-mapping>
		<servlet-name>springmvc</servlet-name>
		<!-- url-pattern的设置 -->
		<!-- 不要配置为/*，否则报错 -->
		<!-- 通俗解释：会拦截整个项目中的资源访问，包含JSP和静态资源的访问,对于JS的访问，springmvc提供了默认Handler处理器 -->
		<!-- 但是对于JSP来讲，springmvc没有提供默认的处理器，我们也没有手动编写对应的处理器，此时按照springmvc的处理流程分析得知，它down了 -->
		<url-pattern>/</url-pattern>
	</servlet-mapping>

那么DispatcherServlet将会覆盖defaultServlet.

 

通过debug发现，在这种访问locahost:8080/访问时，前面三种都没有匹配到，就会进入欢迎页面匹配，此时path变成了/index.jsp, 欢迎页面匹配细分的规则很多，其中有这样一段代码

 /* welcome file processing - take 2
         * Now that we have looked for welcome files with a physical
         * backing, now look for an extension mapping listed
         * but may not have a physical backing to it. This is for
         * the case of index.jsf, index.do, etc.
         * A watered down version of rule 4
         */
        if (mappingData.wrapper == null) {
            boolean checkWelcomeFiles = checkJspWelcomeFiles;
            if (!checkWelcomeFiles) {
                char[] buf = path.getBuffer();
                checkWelcomeFiles = (buf[pathEnd - 1] == '/');
            }
            if (checkWelcomeFiles) {
                for (int i = 0; (i < contextVersion.welcomeResources.length)
                         && (mappingData.wrapper == null); i++) {
                    path.setOffset(pathOffset);
                    path.setEnd(pathEnd);
                    path.append(contextVersion.welcomeResources[i], 0,
                                contextVersion.welcomeResources[i].length());
                    path.setOffset(servletPath);
                    internalMapExtensionWrapper(extensionWrappers, path,
                                                mappingData, false);
                }

其中 internalMapExtensionWrapper方法中有如下代码：

MappedWrapper wrapper = exactFind(wrappers, path);
                if (wrapper != null
                        && (resourceExpected || !wrapper.resourceOnly)) {
                    mappingData.wrapperPath.setChars(buf, servletPath, pathEnd
                            - servletPath);
                    mappingData.requestPath.setChars(buf, servletPath, pathEnd
                            - servletPath);
                    mappingData.wrapper = wrapper.object;
                    mappingData.matchType = ApplicationMappingMatch.EXTENSION;
                }
                path.setOffset(servletPath);
                path.setEnd(pathEnd);

假设resourceOnlyServlets=""，此时exactFind得到的是Wrapper是jspServlet，对应的resourceOnly属性为false，那么if (wrapper != null&& (resourceExpected || !wrapper.resourceOnly)) 符合条件，构造的mappingData.wrapper = wrapper.object;所以mappingData.wrapper不为空，也就不会再走接下来defaultServlet。因此报错是[/index.jsp] 未找到,也就是404。

如果resourceOnlyServlets不进行特别设置，其默认值是jsp，那么if (wrapper != null&& (resourceExpected || !wrapper.resourceOnly)) 不符合条件，mappingData.wrapper仍然为null，继续走defaultServlet