AW: AW: AW: request.getRemoteAddr() sometimes returning IP address from the previous request
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
Re: AW: AW: AW: request.getRemoteAddr() sometimes returning IP address from the previous request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Clemens, On 3/14/14, 3:33 AM, Clemens Wyss DEV wrote: 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) Okay, you need to fix this. In the meantime, at least set RECYCLE_FACADES which should help quite a bit. Instead of getting bogus data after control has returned to the container (which expects to have complete control -- you have removed control from the container by launching your own thread and retaining references to the request and response), you should end up getting lots of errors. Until you can change your application to use asynchronous IO, you probably want to change things so that the request-processing thread performs your long-running requests instead of delegating them. That should fix the majority of the problems you are experiencing. As for the wisdom of switching to async IO, it depends upon your situation. If most of the wait-time has to do with gathering data -- say, from a database or other relatively slow source -- then async makes sense since the request-processing thread can be used to handle other requests in the meantime. If, however, most of the time is taken actually generating the PDF (just a huge amount of content), then switching to async won't actually buy you anything: you would be better off just using the container's request-processing thread to handle things for you. that can corrupt your requests (and responses) at best and be a severe security vulnerability at worst AGAIN we were not aware of It's okay. You just have to be aware that this is almost certainly the root cause of the problems you are observing. 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. Also nearly everything in the HttpServletResponse class. Where do I find the sepcification you mention? I think you misinterpret the meaning of committed. In the spec, the response is committed when the first byte of the response has been sent back to the client. The request is still in-progress even after it has been committed, and the servlet may continue to run. The specs themselves can be found from the references here: http://wiki.apache.org/tomcat/Specifications Read section 3.11 of the 3.0 version of the spec. (The same section exists in other versions... it just might have a different section-number). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTIvP4AAoJEBzwKT+lPKRYzSQQAKUswaLJ0Ej/fGKkSgFyrcAE R6YrWtWhkomKtWZy7np6ZU33a2PD6oDQA8XqT9FmsENN+Wts3ES1fWMrSjtPHliA pHMv46cbOZhwzB17XdnXT0FikSpWISfQrdtrjnApbR1Q+49rkrZImpCAesn3oXWK PPozaCiPr6pSyg+I0iFZSwRFdX6CDzbRvZcfxxDin6B76T/VsuuY4HbRT6gO0u3R FhckP05onAqsyisfHpxKXtPY9RdsTPytePuOo34GFYkudMbxIZFapjLk4rzoL7G1 nH2GKdCDd7SKVR9zrox3AnCJpFfJxhqceDiipCOQq94j2tXXtQoy3rqwc5HLYA6Z UsKzewaJaiiirJ/UgVPtzudd8jH/eouV1uaIsR+vCoShnfKNRzDPvxNiRDmUs6ub EbqcBF+nBKMkHE8jJGv0TMHp9sqQzm16h07gl/xWii5ug3J/PzeYt2JwdMPIO3DW 9CSzOViA8QvWQCW5qUtQBD3VhbW7vcpX9MfKK3TdojteQo/wa2GGqLxUkK7+ZGxh FIAW8G8cGqKthp5yayGH203uRxyNHYn7Z5gzUjVm/99Jrs60lKRgjbU42/YpZhzv 3OHooWTvrAd87PLIcflJSc9KXAw9ckvzQ90jPfQy+1mx1aUZ8csmtfOHyXBpIj3d 1J1XRMMsIC10I8LDkdHf =U7aZ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: AW: AW: request.getRemoteAddr() sometimes returning IP address from the previous request
Do you have any proof of this or is this just guess work? No guessing. Am taking into account apache's access-log and our application logging. We log the IP (i.e. request#getRemoteAddress) of sepcific requests into our application logs and from time to time see the IP oft he previous request (access.log tells us that this is the IP of the/a previous request) -Ursprüngliche Nachricht- Von: Mark Thomas [mailto:ma...@apache.org] Gesendet: Mittwoch, 12. März 2014 13:38 An: Tomcat Users List Betreff: Re: AW: AW: request.getRemoteAddr() sometimes returning IP address from the previous request -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/03/2014 06:19, Clemens Wyss DEV wrote: VelocityViewServlet or VelocityLayoutServlet? None of these in use I give my szenario another try ;) [HTTP REQUEST 1] enters [HTTP REQUEST 1] starts writing to the response.writer - at a certain buffer limit the response is commited [HTTP REQUEST 2] enters, gets the same (i.e. the recycled) Request as REQUEST 1 Do you have any proof of this or is this just guess work? [HTTP REQUEST 1] while still writing (renderig velocity template) request.getRemoteAddress() is being called [HTTP REQUEST 2] calls request.getRemoteAddress() === what address am I getting? Undefined. It might be the correct answer for request 1, it might be the correct answer for request 2 or it might be garbage. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTIFUeAAoJEBDAHFovYFnnrgoP/i6+PmjPsykx1uT2nF4JVbIn pQ6MDaq7j1KS3MDbecD3HCDMEc2cMDCf4A2WCzRqOl2cLt9zrU9ZR0vFn+fR8uxu bw7p5QvuGGIHG38871260Wfj6TIDuI6U+Aoec6F9YfKbYyrBNGXHodInZV7p4eoE B3Mjz87zfcNeHPTy0u8ihUxEPb/DGAAXCb1S6UsDxh9NadHa+ZKm5A98Dvt0z2v8 /Th8TXeKETm1iTV39vP8gWloYEud8LTFCFBagFRnGCBq5jon0q5jcVTRXcQB6+9r cCBNokB1PeBuejB+EMhuQfWCLPq5hio/ZxomQfBOYXPkgf/8JFCeqOHTg791r37k /kvshmZAqZkH+BYCV+0stve1Z9lV6cst1qWT79PKynv/9liVAi2U5l3X79G4QpvK RbvJ+K5z/m6EZ87H/zsRykoraPEGfR8kwxIpsoHWEDbuTMmcNO2A9hpBQz4ngE2u OPF3hq5lYFvyKU9a3BfqWJN6M0khYXKDFtxshqpIpUL4hoJSJEr1kpyr7rrNEakz ysxHJybGKvxpzgE1TWtbGc8tZKfA06hCbghLXhCd/yf/yiS26wTQ8JLpHk5C60DG c+7HRFCvqmojF0/cN7TbKWWvdtYInk8eaWxGbT5O+JM++xMStZf3j8SNGRTCVTWP 2uIiTY7313P6df1X6qMK =kgoB -END PGP SIGNATURE- - 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
Re: AW: AW: AW: request.getRemoteAddr() sometimes returning IP address from the previous request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Clemens, On 3/12/14, 11:34 AM, Clemens Wyss DEV wrote: Do you have any proof of this or is this just guess work? No guessing. Am taking into account apache's access-log and our application logging. We log the IP (i.e. request#getRemoteAddress) of sepcific requests into our application logs and from time to time see the IP oft he previous request (access.log tells us that this is the IP of the/a previous request) By all means, post the relevant portion of the log file. How do you know that the requests are coming from certain IPs and they are then being reported incorrectly in the access.log or in your own web pages. It would be very helpful if you'd answer my earlier question about how you take a request and route it to Velocity. You may be making serious mistakes when you do that which could be the root cause of these problems. You are unlikely to be able to break the access log, even if you break your own application. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTII4lAAoJEBzwKT+lPKRYYskP/0K/mo6m/TOu5UmfmKAeoIMV uuuNgQSFms8c/ufad+b/kywDt//TcPuu9fUsOMJmFuoMEoK4iI+xKTTApb/fuii5 yA2p8XD/qnRM227RSoquITn9WCsiTLfW9Eu/Hm5/VP9lPJ46yKX3QiEiz2xXPtZh rp5nD22QTulmX+WrNiAPXPd1Z+Dq4xQ8Uto/AU8TUGzjrl7J8IfftAbObYQyqtSo hdlB+gdYY/hvY/WifqmpHHd9eUv7ANzHTa3cKGPmWC6qR42XEaLL8qi5bcnfBPzr onRfANCBq1Qr70xA0P2l02ZQ1WpXIvEgOhkz+M5aQr0myC7MBnTUoymzXXZdkFwo R2Xcj1wC2byHstWlxWIm1ieGrH60iR+krYVNog8JUJ3WCLR3NYCaX2dM/ZGB2dk7 FhpK2OulLKNQUq9WMVEgoTUeGiuxWzurrIXriarQDKPoajjCm2Bw3+ODtC9jxy8H AVFb03E60pdUGDBxq0HOr8A4N9v4sYlbWz69b3lbv5jFlqVKfd4n06sK5hOxxcUE jxQd26m/XwaQ0cYV93r0fb7ygoPxHwmDuK7OC1QuciCraqpbkE94CHuKmIHzD/p4 oz2rf2JVdRWszr+s8HQ6KnyB7uN7D5mnxTZhXJTTGsc3BV+38nA+gLDRHY6yFHIN BcDnVbvH25WtcYxsHsJV =ungh -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
