Hey Christopher, 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. Though, thanks for the idea. Maybe I can release a separate artifact just for Tomcat.
Best. On Tue, Sep 19, 2017 at 7:11 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Volkan, > > On 9/19/17 3:07 AM, Volkan Yazıcı wrote: > > Hello, > > > > When you try to access the raw InputStream of a > > x-www-form-urlencoded servlet request, the stream could have > > already been indirectly consumed by a prior access to the > > parameters (e.g., via ServletRequest#getParameterMap()) of the > > request. This feature (bug?) has already been documented in the > > section SRV.3.1.1 of the Servlet spec > > <https://javaee.github.io/servlet-spec/downloads/servlet-3.1/Final/ser > vlet-3_1-final.pdf> > > > > > and there are other people (Bug 47410 > > <https://bz.apache.org/bugzilla/show_bug.cgi?id=47410>) who have > > been bitten by this as well. > > > > This indirect stream consumption makes it, to the best of my > > knowledge, impossible to mirror the InputStream, which is exactly > > what we are trying to achieve in HRRS <https://github.com/vy/hrrs>. > > Hence, I try to re-construct the InputStream from request > > parameters > > <https://github.com/vy/hrrs/blob/master/servlet-filter/src/main/java/c > om/vlkan/hrrs/servlet/HrrsUrlEncodedFormHelper.java>. > > > > > This, as you can imagine, a really nasty hack which I am not fond of > > either. Further, to make the things worse, when servlet pushes the > > form parameters into request parameter map, it merges them with > > query parameters too. Now you need to manually parse both request > > and query parameters to figure out the initial form parameters. I > > am not even talking about lost parameter ordering. A total > > shipwreck. > > > > Even if HRRS is the first filter in the list, it is not consuming > > InputStream, it is just wrapping the InputStream and passing along > > the wrapped request along the chain. Problem is, getParameter() > > calls in Tomcat is using an internal reference to the InputStream > > (that is, o.a.c.connector.Request#getStream()) and not calling > > javax.servlet.ServletRequest#getInputStream(). Hence, InputStream > > gets indirectly consumed without the wrapped one getting used at > > all. Is it possible to make o.a.c.connector.Request#readPostBody() > > use getInputStream() rather than getStream() to solve this problem? > > Or is there an easier fix that I am missing? > > If you use a Valve (which is Tomcat-specific) instead of a Filter, are > you able to intercept input stream more effectively? > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJZwU/RAAoJEBzwKT+lPKRYIB4P/0J7Ok3e5CtJRewaHzM/BMv2 > fLCVhyrB79T0obwQMQ/Zh8A63mGsrzjpH+TJr8pvDlgXeWviT4JHgy01uf/KVt8/ > doHJAGvYMVkSM8ZnXRl2p940Rkw8hJKyTXXqE7fN2XilbxGBse3Q4OP2S61vb/EM > lgHJrSOdvElHyI+Wcdc/H46J/QNirYZx8PMHWl1ha9a1kw6YvOnJaFqK01KwMZR6 > ghUgbiOrP40gqEX8h8zKVYTMejZv2ngnN4worvN3Mp/PjTT2AvLAmgTVHFkHeX6J > HvVNh429YVpJEoCOiKuK7vSEI+YlpyVI9Emym5yi6yfXm7LTi2b8eNwx3jeRT09R > efiUhQWw4KFqBCVQPt5Jh5yjrl9Lzr9AfRIFphURvzCuHeT1qF6B+8zrE4njn4ch > az0PB8q6Okqykbii4BwFYd64cxHRzY0QuMaOqH5gGBcTHSEbk/7rw1Qah+vOG3/R > zt/cA51rgVwAO/jPUYFI1OcpO5vAJ7BTcejFFMCTlP3vLMz6PhhBM50P2fBaBleN > G09KgVNgWQV3hQgOdmbTiOMc775EsLHwv9DMWwTxwsDvAVPmUEZTa4DqM3rqe8hx > QlCjvO7fPilrgy9f6ryH0dfioSpZXUAYhADnhvX98dRbuB3cWooIbLbaTAMgIzBe > KbEM3Ii+bGaox7k4UKeC > =o2M4 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
