Hey Igal, Today, I've tried to implement your proposal (consuming the InputStream eagerly, wrapping the consumed byte[] as a re-consumable ServletInputStream, and passing it to next filter) and hit by the same Tomcat shortcoming: Since you've already consumed the original InputStream, later on, any access to parameters will trigger o.a.c.connector.Request#readPostBody() which in return will access the original InputStream via o.a.c.connector.Request#getStream() discarding the re-consumable you provided by overriding javax.servlet.ServletRequest#getInputStream(). Long story short, consuming InputStream eagerly breaks the parameter parsing. We still did not get a reply from Tomcat maintainers, but I still do believe this to be a Tomcat shortcoming and can be easily resolved by making sure o.a.c.connector.Request#readPostBody() uses javax.servlet.ServletRequest#getInputStream() instead. Additionally, "reading InputStream eagerly" solution assumes that you're the first filter along the chain, which is not the case for Spring Boot applications.
Best. On Tue, Sep 19, 2017 at 10:48 PM, Igal @ Lucee.org <i...@lucee.org> wrote: > Volkan, > > On 9/19/2017 11:21 AM, Volkan Yazıcı wrote: > > Hey Igal, > > Thanks for the response! I believe having more people suffering from the > same limitation makes it more clear that there is a shortcoming that needs > to addressed in Tomcat. > > The problem is that Tomcat is compliant with the Servlet specification, > and as Mark pointed out in the original ticket #47410 that is part of the > spec. > > Coming back to your project, thanks for the pointer. Though I have two > concerns: 1) It is [still] a Tomcat-specific solution and > > This is not a Tomcat-specific solution. I use it with Jetty as well. It > does use a library from Apache for processing FileUpload, and if you are > running Tomcat you already have it in your classpath, but if you are not, > you need to add that jar. > > 2) it consumes the entire InputStream regardless of whether the request > handler will use it or not. > > I've never had an issue with that, and am not sure what you are worried > about? network traffic? memory? (the FileUpload library writes the > contents to disk after a certain threshold), but if you're concerned with > that then you can write your own filter and model it after mine if you want > to hit the ground running. Then you can break the read whenever you want, > though I really think that you're over-optimizing here. > > TBH I did not read your original emails with Chris in full, so I'm not > sure what your requirements are. > > > Best. > > On Tue, Sep 19, 2017 at 7:55 PM, Igal @ Lucee.org <i...@lucee.org> wrote: > >> Volkan, >> >> On 9/19/2017 10:47 AM, Volkan Yazıcı wrote: >> >>> Did not try (or consider) using a Tomcat Valve, since it would make the >>> entire tool Tomcat-specific. I would rather find a way to solve the >>> problem >>> in a container agnostic way. >>> >> I had a similar issue so I wrote a simple Filter and named it >> "RereadableServletRequestFilter": >> https://github.com/isapir/servlet-filter-utils#rereadableser >> vletrequestfilter >> >> HTH, >> >> >> Igal >> > > > Igal Sapir > Lucee Core Developer > Lucee.org <http://lucee.org/> >
