Brian Clozel commented

As I've stated in the Boot issue, this is how this ContentCachingRequestWrapper is designed; we can't really change the way it works without breaking backwards compatibility since its behavior is described in the javadoc.

This is a Spring support class that we use in various filters, but it does not mean it's got to support all use cases out there. Feel free to use an implementation that better fits your needs.

Federico Piazza commented

Hi Brian, thanks for your comment.

Yes, I understand, IMHO, adding caching to the input stream shouldn't break anything, on the opposite... will cover important use cases. If you take a look at StackOverflow, this question was scored highly and has more than 50K visits, the answer was scored 60 votes and it still grows.

Brian Clozel commented

Hi Federico Piazza

The implementation you're suggesting is:

• reading the whole request body when we first call getInputStream(), so not really in line with the original intent of the API
• enforcing no limit on the cached content

Again, this use case is interesting, but I can't change the behavior of ContentCachingRequestWrapper when it's clearly documented; how would you feel if that class was working the way you intended, but we suddenly changed its behavior because someone asked for a different one?
This class is mostly meant for internal purposes and we've opened it up because it might be useful to others, but we're not in the business of providing a toolbox for Servlet filters.