Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ContentCachingRequestWrapper cache input stream [SPR-16028] #20577

Closed
spring-projects-issues opened this issue Sep 29, 2017 · 3 comments
Closed

ContentCachingRequestWrapper cache input stream [SPR-16028] #20577

spring-projects-issues opened this issue Sep 29, 2017 · 3 comments

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Sep 29, 2017

Federico Piazza opened SPR-16028 and commented

This ticket comes from an issue I raised in spring boot github:
spring-projects/spring-boot#10452

The class ContentCachingRequestWrapper caches requests but by consuming the input stream, so this is a hard price that pays other filters in the filter chain that cannot read the input stream anymore making this class not very useful.

This issue is created to either improve ContentCachingRequestWrapper or create another wrapper that support multi read request through the filter chain multiple times. Here you can find a stack overflow answer that implements this:
https://stackoverflow.com/questions/10210645/http-servlet-request-lose-params-from-post-body-after-read-it-once


No further details from SPR-16028

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 2, 2017

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.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 2, 2017

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.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 3, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants