自己配置的tomcat 部署应用时提示错误信息：org.apache.catalina.core.ApplicationContext.log ssi: Can't find file: /index.html
ERROR ErrorPageFilter Cannot forward to error page for request [/] as the response has already been committed. As a result, the response may have the wrong status code. If your application is running on WebSphere Application Server you may be able to resolve this problem by setting com.ibm.ws.webcontainer.invokeFlushAfterService to false
The phenomenon is shown in the figure below:
The result of this error is: the browser prompts 404 when accessing the project. Modify the configured tomcat version to 8.5.51
The strange thing is: Tomcat without configuration can deploy applications normally.
This application is a spring boot project. The index.html in this project is located under WEB-INF\classes\static under the project. The page designation method of this index.html is: the root directory static of the static folder is read by default. file under.
The preliminary judgment is that: a certain configuration of the configured tomcat affects the loading of this static page resource.
Let’s take a look at the error message: org.apache.catalina.core.ApplicationContext.log ssi: Can't find file: /index.html
What is ssi?
SSI is the abbreviation of Server Side Includes, which is a set of instructions embedded in the HTML page. Collection. Before returning the requested page (containing SSI instructions), the server will process these instructions, replace the instructions with the processing results, and then return the page. This allows adding dynamically generated content to HTML pages.
Tomcat has two ways to set up SSI: find the web.xml file in the conf/ directory of the tomcat installation directory
1、SSI Servlet，即web.xml里 SSI servlet和servlet-mapping
2、SSI filter，即web.xml里SSI filter和filter-mapping
In the current problem, the configuration of web.xml for ssi is:
<!-- NOTE: An SSI Filter is also available as an alternative SSI -->
<!-- implementation. Use either the Servlet or the Filter but NOT both. -->
<!-- -->
<!-- Server Side Includes processing servlet, which processes SSI -->
<!-- directives in HTML pages consistent with similar support in web -->
<!-- servers like Apache. Traditionally, this servlet is mapped to the -->
<!-- URL pattern "*.shtml". This servlet supports the following -->
<!-- initialization parameters (default values are in square brackets): -->
<!-- -->
<!-- buffered Should output from this servlet be buffered? -->
<!-- (0=false, 1=true) [0] -->
<!-- -->
<!-- debug Debugging detail level for messages logged -->
<!-- by this servlet. [0] -->
<!-- -->
<!-- expires The number of seconds before a page with SSI -->
<!-- directives will expire. [No default] -->
<!-- -->
<!-- isVirtualWebappRelative -->
<!-- Should "virtual" paths be interpreted as -->
<!-- relative to the context root, instead of -->
<!-- the server root? [false] -->
<!-- -->
<!-- inputEncoding The encoding to assume for SSI resources if -->
<!-- one is not available from the resource. -->
<!-- [Platform default] -->
<!-- -->
<!-- outputEncoding The encoding to use for the page that results -->
<!-- from the SSI processing. [UTF-8] -->
<!-- -->
<!-- allowExec Is use of the exec command enabled? [false] -->
<servlet>
<servlet-name>ssi</servlet-name>
<servlet-class>
org.apache.catalina.ssi.SSIServlet
</servlet-class>
<init-param>
<param-name>buffered</param-name>
<param-value>1</param-value>
</init-param>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>expires</param-name>
<param-value>666</param-value>
</init-param>
<init-param>
<param-name>isVirtualWebappRelative</param-name>
<param-value>false</param-value>
<!--<param-value>true</param-value> -->
</init-param>
<init-param>
<param-name>inputEncoding</param-name>
<param-value>utf-8</param-value>
</init-param>
<init-param>
<param-name>outputEncoding</param-name>
<param-value>utf-8</param-value>
</init-param>
<load-on-startup>4</load-on-startup>
</servlet>
<!-- The mapping for the SSI servlet -->
<servlet-mapping>
<servlet-name>ssi</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>According to comparison with the tomcat web.xml configuration file for normal deployment applications, it can be found:
The normal web.xml configuration (tomcat 8.0.43) configuration: the servlet-mapping of ssi is blocked, and the default ssi url-pattern is: *.shtml
<!--
<servlet-mapping>
<servlet-name>ssi</servlet-name>
<url-pattern>*.shtml</url-pattern>
</servlet-mapping>
-->
The url-pattern of the servlet-mapping of ssi configured after modifying the configuration is*.html
And: Tomcat for normal deployment application does not open ssi filter and ssi servlet:
org.apache.catalina.core.StandardContext.filterStart Exception starting filter ssi
java.lang.SecurityException: Access to class [class org.apache.catalina.ssi.SSIFilter] is forbidden. It is a restricted class. A web application must be configured as privileged to be able to load it错误处理方式
When I open ssi's ssi filter and ssi servlet in normal tomcat, but there is no configurationservlet-mapping< /span>, start tomcat again, there is an error message:
org.apache.catalina.core.StandardContext.filterStart Exception starting filter ssi
java.lang.SecurityException: Access to class [class org.apache.catalina.ssi.SSIFilter] is forbidden. It is a restricted class. A web application must be configured as privileged to be able to load it
At this time, nothing is displayed, and the service cannot be started directly. And when I turn on the content of: The mapping for the SSI servlet:
When I started tomcat again, I found that the error was still reported:
At this time, in context.xml under conf, just add:privileged=true
After starting it again, it was found that the deployment application can be started normally, and the page accessed in the browser displays normally.
At this point, we can basically determine: It is due to the influence of The mapping for the SSI servlet in web.xml:servlet-mapping’s url-pattern The display of the page results in a prompt that the index.html page cannot be found, and the access prompt is 404:
When sets the url-pattern of ssi's servlet-mapping to *.shtml, index.html can be loaded normally.
And if you cannot modify the url-pattern of ssi's servlet-mapping in web.xml to *.shtml, just apply it directly
Just copy all the files under xxx\WEB-INF\classes\static to the xxx directory.
What is the difference between *.shtml and *.html?
Shtml is similar to html. It is also a markup language used for web design. The difference is that html is a purely static markup language. What is written in the html document is what the user sees when he opens the browser. , and shtml is a semi-static and semi-dynamic markup language. SSI commands can be included in shtml. When the user browses the shtml document in the browser, the SSI commands contained in it will be parsed, and then the content will be presented to the user.
What does the ssi command refer to?
SSIBasic format of command
Basic format: <!--Command name="Command parameter">
如：<!--#include file="info.htm"-->
<!--#echo var="last_modified"-->
<!--include virtual="/includes/header.html"-->等
根据分析，出现org.apache.catalina.core.ApplicationContext.log ssi: Can't find file: /index.html
ERROR ErrorPageFilter Cannot forward to error page for request [/] as the response has already been committed. As a result, the response may have the wrong status code. If your application is running on WebSphere Application Server you may be able to resolve this problem by setting com.ibm.ws.webcontainer.invokeFlushAfterService to false
At the time of the problem, there was no similar ssi instruction in the index.html page:
The only thing:
These two sentences don’t look like SSI commands. But the only explanation is:
When the url-pattern of ssi's servlet-mapping is *.html, it looks for the page in the project root directory. This is different from the application static file root directory static that the application itself needs to read, so it cannot be found. Therefore, if you do not change the url-pattern to *.shtml, you can access it by copying all files under static to the application root directory.
As for why? I haven't figured it out yet... I'll just record it first.