Would you mind elaborating your answer? I just want, in org.apache.catalina.connector.Request, readPostBody() method to access the request stream via getInputStream() rather than getStream(). Maybe I am missing something but this looks legit to me.
On Thu, Sep 21, 2017 at 11:13 PM, Mark Thomas <ma...@apache.org> wrote: > 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 > >
