ErrorPageFilter causes a forwarded request that sends an error to actually send a 200 OK response instead

[tankilo]

Question

With default servlet enabled, when deployed in an external Tomcat, the request to non-existent resource returned 200 instead of 404.
I created a demo for this problem. https://github.com/tankilo/spring-boot-problem-demo
Version Info : Spring Boot 1.5.9.RELEASE Tomcat 8.5.24

1. When i used IDEA to deploy war, visiting http://localhost:8080/ will get 200.
   
   And in the log ,i found

2018-01-28 09:38:28.495 ERROR 12928 --- [nio-8080-exec-4] o.s.boot.web.support.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

2. When i used IDEA to run com.tankilo.demo.DemoApplication, visiting http://localhost:8080/ will get Spring Whitelabel Error Page.
   

Personal Understanding

After i debug and compare the two scenes, i find:

1. Only when deployed as a war will ErrorPageFilter be in used. (SpringBootServletInitializer#createRootApplicationContext)
2. When running com.tankilo.demo.DemoApplication, even without ErrorPageFilter, ErrorMvcAutoConfiguration will configure Tomcat ErrorPage，and we still see the Whitelabel Error Page.

I am still not clear about this question, is there something wrong with the way i use springboot? -_-

[wilkinsona]

The problem here is that the ErrorWrapperResponse that's used by ErrorPageFilter suppresses a call to sendError that's done by the default servlet to send the 404 back. Normally this suppression is desirable as it gives the error page filter a chance to send the error at the right time. However, it doesn't work in this case as the dispatch that has forwarded the request to the default servlet concludes by closing the response's writer which commits the response. Due to the suppression of the call to sendError, the response's status is 200 and that's what the client receives. I think we need to send the suppressed error as soon as an attempt is made to access the response's writer.