On 21/09/17 21:58, Volkan Yazıcı wrote: > 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.
That is not possible. A wrapped request has no access to any wrapper. Mark > 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/> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
