AbstractRequestLoggingFilter with startAsync: unwrap request to find ContentCachingRequestWrapper [SPR-13764]

[spring-projects-issues]

Andreas Voellmy opened SPR-13764 and commented

In a subclass of AbstractRequestLoggingFilter in beforeRequest(), the request parameter is an instance of ContentCachingRequestWrapper, which allows createMessage(), or subclass code to access the cached content. However, in an asynchronous method return, the request passed to afterRequest() is not an instance of ContentCachingRequestWrapper, so createMessage() doesn't include cached contents. The request object does wrap a ContentCachingRequestWrapper, but the immediate request object is not an instance of ContentCachingRequestWrapper. It seems like it would better if the request argument to afterRequest was also an instance of ContentCachingRequestWrapper.

---

Affects: 4.1 GA, 4.2 GA

Backported to: 4.1.9

[spring-projects-issues]

Andreas Voellmy commented

It seems that, at least in my test case, there are some other filters, like org.springframework.security.web.FilterChainProxy that are included on the chain in the ASYNC dispatch, and these wrap the request. By the time the AbstractRequestLoggingFilter instance is reached, the ContentCachingRequestWrapper is wrapped twice.

Seems like there are two possibilities: (1) always ensure AbstractRequestLoggingFilter is last in the filter chain, (2) have a more robust way of getting the cached content. A "hack" for implementing (2) would be to unwrap wrapped requests until a ContentCachingRequestWrapper is found.

[spring-projects-issues]

Juergen Hoeller commented

Actually, unwrapping the request is not a hack: It's the common technique applied for such Servlet Filter scenarios. We do it in a couple of other places already, so I'll revise AbstractRequestLoggingFilter along those lines for 4.2.4 and 4.1.9.

Juergen