On 2/5/2012 11:24 AM, Jess Holle wrote:
On 2/5/2012 11:22 AM, Jess Holle wrote:
On 2/5/2012 11:15 AM, Konstantin Kolinko wrote:
I think this issue is specific to AJP.

For HTTP connectors a similar issue was noted and fixed here:
https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c9

I think adding the following line to "REQ_SET_BODY_REPLAY" case in
AbstractAjpProcessor#action() will fix this bug:

    endOfStream = false;

That did the trick! [I just did this via the debugger without a rebuild, but same thing.]

Could someone please patch this into trunk so it's in the next Tomcat release?
By "patch", I mean "commit", of course :-)
Until then I can certainly patch it into my own Tomcat. I just don't want to maintain this patch forever (nor have everyone else suffer from this bug in the AJP case).

Also it strikes me that maxSavePostSize should really be backed up by a use of a SoftReference in SavedRequest.

This would allow one to allow relatively large POST bodies to be saved unless/until this threatened to consume the JVM's overall memory resources, at which point the POST bodies could be dropped.

As it stands now one has to choose between vicious treatment of large POST bodies (i.e. dropping all the user's data) and opening oneself wide open to quick and easy (and possibly accidental) DOS attacks.

--
Jess Holle


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to