> If you are starting a new thread to generate a PDF yes we do >but blocking the request-processing thread waiting for it to complete no we don't
>Okay, so this is your error handler checking the value of >request.getRemoteAddr() and throwing an error because the IP >address is not valid for that URL, right? true >and the container (Tomcat) assumes that the web application >is not playing games with the request, response, etc. at most getting "stuff" from the request (which we expect(ed) to be "immutable") >that can corrupt your requests (and responses) at best and be a severe >security vulnerability at worst AGAIN we were not aware of >Tomcat re-uses Request and Response objects to reduce the amount of >heap-thrashing that would otherwise occur > which is officially broken if it relies on request or response objects > outliving the time during which >the request-processing thread has been allocated to a particular request >Reading the spec http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html only athenticate and getSession are explicitly meant to not be called after a response has been commited. Where do I find the sepcification you mention? Regards Clemens -----Ursprüngliche Nachricht----- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Donnerstag, 13. März 2014 16:00 An: Tomcat Users List Betreff: Re: AW: AW: request.getRemoteAddr() sometimes returning IP address from the previous request -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Clemens, On 3/13/14, 3:24 AM, Clemens Wyss DEV wrote: > Dear Christopher, >> But you also don't know what you are doing If you don't help us > again I appreciate your help and you definitely know more about tomcat > than I do. IMHO, I do help and I try to focus on what is relevant. It > doesn't make sense to put our million lines-of-code and log entries > online, does it? No. But instead, you might be able to copy/paste like 10 lines of the log that shows what you are talking about. > Follows an example of what we see: access.log (apache) ... [1] > 66.249.78.105 <!! hostname !!> - [13/Mar/2014:07:21:03 +0100] "GET > /de/dialog-product-pdf.html?productGroupId=220 HTTP/1.1" 200 256 "-" > "Mozilla/5.0 (compatible; Googlebot/2.1; > +http://www.google.com/bot.html)" "-" [2] 212.243.6.186 <!! > hostname !!> - [13/Mar/2014:07:21:04 +0100] "GET > /myinterfaces/webstatus/webstatus.xml HTTP/1.1" 404 27851 "-" > "Jakarta Commons-HttpClient/3.1" "$Version=0; > JSESSIONID=E405CB1E766D20B4C0CE82106797ED3D; $Path=/" ... > > [1] 66.249.78.105 (google bot) is accessing > /de/dialog-product-pdf.html?productGroupId=220 [2] 212.243.6.186 (our > monitoring app/site) is accessing > /myinterfaces/webstatus/webstatus.xml Okay, everything looks good so far. > app.log (tomcat, servlet) ... [1] 2014-03-13 07:21:04,155 > ajp-bio-8069-exec-9 WARN > ch.mysign.cms.customized.CmsErrorHandler - HTTP error code '404' > thrown for request '/myinterfaces/webstatus/webstatus.xml'. > Message: Page not found! remote IP: '66.249.78.105', IP-RegExp: > '<!! Regex of IPs allowed !!>' Okay, so this is your error handler checking the value of request.getRemoteAddr() and throwing an error because the IP address is not valid for that URL, right? What code is generating this log message? Does Velocity have anything to do with it? It's probably a red herring, honestly. Would it be possible to get a stack trace of the place where you detect the error? That would help figure out if there is a component where a problem might occur. How are you connecting httpd to Tomcat? What version of whatever are you using? > Does this help? Yes. For instance, you never mentioned that you were using Apache httpd in front of Tomcat before. > We DO NOT manipulate any request-object (no setters, are there ;)) and > we DO NOT share a request-object accross requests. "Worst" > that could (and does) happen is a request-object (in a > velocitycontext) could be accessed for as long as a few minutes IF we > spawn out a thread to handle a long running process ... > rendering a pdf or alike. You need to stop doing this. If you want to service a long-lived request and allow the request-processing thread to go back into thread pool, you must use a formal async API or Bad Things will happen. The spec requires that a single thread handle the entire request when not using async, and the container (Tomcat) assumes that the web application is not playing games with the request, response, etc. objects that are bound to the request. If you are starting a new thread to generate a PDF but blocking the request-processing thread waiting for it to complete, then you are wasting time and resources with the second thread. If I understand you correctly, you are making a mistake that can corrupt your requests (and responses) at best and be a severe security vulnerability at worst. > What is(was) definitely new to me is the fact that the > HttpServletRequest-objects handed into the servlet are not immutable > snapshots of the "point of entrance". Or am I wrong here too? Tomcat re-uses Request and Response objects to reduce the amount of heap-thrashing that would otherwise occur. Likewise, all the buffers are re-used as well. If you enable RECYCLE_FACADES, then the objects are NOT re-used, which significantly reduces the potential for a security problem. It doesn't fix your application, though, which is officially broken if it relies on request or response objects outliving the time during which the request-processing thread has been allocated to a particular request. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTIcgAAAoJEBzwKT+lPKRY5XUQAMQsLv37xIb6fn4z+w14AyJX sXJAMOpqoEnbdYQj/rvW6MUDrfaD8llZHzrjck0DDgLd4uGTm2iVWreMXYNr8ZiI J1mAk9qZ/ErCH92FEPkECNIlEjQHYtti1dOtdt6mmlgkLVyNfoDtUtQOfsevmhF2 wwFIIhEaA3IHL0mIa+nf4yU8QYdIdUutnjRz6SB/MHEFmZ8BhlLpsBfKrX0yRHVX DwjpRM+Y1jvTf4Fy783Cn8CXnrxRLg5jqUgC+1RJkrnE/zuLvyBIUkvfqhLZLNh3 ceWVWK/slSeeG2KY0HnMEmIhaLMhTC638uegD71nvUwUV6C3/QEyHbG1IgK89zw/ 1NmObovzoD1hYBVQhA7Ys2gdVtrl3RwbRcmI/LZlSP+wJdiie0TrzHFRTJ427n/c VfbxHI+RI/MZVK80P5gkSCzJIfsbzmb/sFaNp0qq/6gzui64z/O9Kd5l416NTULq eaJu2WfnVwmtKywkefIR9gF+uI77laMzCtGRm0sbJWj29Shw/vhhtvaSDhSSCnum x42xw4ixyI/8F6UO1YlmrR0cna0/gLkeEE51iNJwU7to3o+okY/I7CxZRGsQNaWs pi8gUjhvlVXSA9fR1I3NT9FDE/Ei5CuiLV3fjzS4/Zd3rTlwpUPaM+NzJfLGPUvm OueB6uMv2TI3MxViEBRP =8Elz -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
