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
