Extract ContentCachingRequestWrapper and ContentCachingResponseWrapper for custom use outside of Spring's filters [SPR-12477]

[spring-projects-issues]

Marcel Overdijk opened SPR-12477 and commented

Please move AbstractRequestLoggingFilter.RequestCachingRequestWrapper to it's own independent (public) class so it can be used outside AbstractRequestLoggingFilter.

---

Affects: 4.1.2

Issue Links:

• ShallowEtagHeaderFilter doesn't support Servlet 3.1 setContentLengthLong [SPR-12097] #16713 ShallowEtagHeaderFilter doesn't support Servlet 3.1 setContentLengthLong
• ShallowEtagHeaderFilter should make use of specified content length [SPR-8271] #12919 ShallowEtagHeaderFilter should make use of specified content length

Referenced from: commits decc5cd

[spring-projects-issues]

Marcel Overdijk commented

Use case is I want to create similar class and want to 'cache' the the request to be able to print request body. And of course it would be nice to use existing Spring code.

AbstractRequestLoggingFilter is not abstract in my case because of all options available I don't want to use.

[spring-projects-issues]

Juergen Hoeller commented

I'm taking this opportunity to extract not only a ContentCachingRequestWrapper from AbstractRequestLoggingFilter but also a ContentCachingResponseWrapper from ShallowEtagHeaderFilter, with the latter having been enhanced recently and certainly being generably reusable as well.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

On a further note, our filters will now only decorate the current request/response with the content-caching variant when not already applied. If other filters apply a ContentCachingRequestWrapper and/or a ContentCachingResponseWrapper before, our filters are simply going to use those instead of re-applying another layer of content caching.

Juergen

[spring-projects-issues]

Marcel Overdijk commented

Nice :-)

[spring-projects-issues]

Marcel Overdijk commented

I noticed the payload of the ContentCachingRequestWrapper cannot be retrieved before doing filterChain.doFilter(requestToUse, response);
Is there particular reason for this? It should be possible to have have request wrapper that can read the payload before the doFilter.
Should I write my own request wrapper or can I use the ContentCachingRequestWrapper in this case?

[spring-projects-issues]

Brian Clozel commented

Marcel Overdijk In my opinion, this Wrapper implementation waits on purpose for the filter/servlet/handler/whatever to actually read the request body before caching its content. In your case, you'd need to read the original request body as soon as you wrap it - so probably your own implementation.

Watch out, a request body can be consumed in multiple ways (getting the body stream, getting the request parameters, etc).