Hrm... Now I see it. That is an unfortunate outcome of deep nesting. Anyway... So there are two solutions proposed so far: 1) Reconstruct payload from parameters [me] and 2) use ServletFileUpload to persist+reinstantiate the request [Igal]. Both of them are nasty hacks with their own shortcomings. Just to resolve this discussion:
1. Is there an easier/better way of doing this? 2. Would there be an easier/better way of doing this by making a relatively small change in Tomcat? On Thu, Sep 21, 2017 at 11:46 PM, Mark Thomas <ma...@apache.org> wrote: > On 21/09/17 22:33, Volkan Yazıcı wrote: > > 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. > > That will make no difference. It won't call your implementation because > you are wrapping the request. > > Mark > > > > 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 > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
