Stack:
Undertow 2.1.4.Final Spring Boot 2.3.4.RELEASE Spring security 5.3.0.RELEASE
Problem
After upgrade to spring-boot 2.3, some of our services start to respond without a body. This has happened only for applications using our custom RequestLoggingFilter(same as in repo below), spring-security library and their endpoint were returning Mono/Flux(asynchronous). I've dug a bit and found out that after a change in undertow which works on current resp/req this starts to fail. After downgrade undertow to 2.1.0.Final everything works fine. It looks like a wrong object is committed and later different is returned to the user. In requests logs, I can see that the response body is logged correctly but there is no response body returned to the client. I've created a simple application and test that reproduce this issue.
Repository
Repository with a test that reproduces the problem: https://github.com/lukidzi/spring-issue
Comment From: wilkinsona
Thanks for the sample. The upgrade to Spring Boot 2.3.x has picked up a new version of Undertow. This version of Undertow fixes a bug in its async request processing and aligns its behaviour with Jetty and Tomcat. You can double-check this by trying your sample with Jetty and Tomcat and seeing that in both cases it behaves in the same way as Undertow now does.
The root cause of the problem appears to be in your request logging filter. The response is being wrapped twice in a ContentCachingResponseWrapper when Spring Security is involved. This double-wrapping happens because the first ContentCachingResponseWrapper is missed due to further wrapping by Spring Security.
The exact intent of your logging filter isn't clear to me so I can't offer exact steps to correct the problem. I would recommend looking at how Spring Framework's ShallowEtagHeaderFilter wraps the response, ensures that this only happens once and also ensures that copyBodyToResponse() is called at that right time.
If you have any further questions, please follow up on Stack Overflow or Gitter. As mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements.