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: request.getRemoteAddr() sometimes returning IP address from the previous request
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? What remains is describing in detail what we are doing. If I had a minimal example to show I would... 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 app.log (tomcat, servlet) ... [1] 2014-03-13 07:21:04,155ajp-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 !!' ... [1] handling /myinterfaces/webstatus/webstatus.xml we see/get remote address 66.249.78.105 which is not allowed to access this page [and yes I know that IP filtering could be done @apache, BUT for certain situations we do this within tomcat] Does this help? 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. 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? Thx Clemens
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-
AW: AW: request.getRemoteAddr() sometimes returning IP address from the previous request
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 [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? -Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Dienstag, 11. März 2014 19:47 An: Tomcat Users List Betreff: Re: AW: request.getRemoteAddr() sometimes returning IP address from the previous request -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Clemens, On 3/11/14, 11:23 AM, Clemens Wyss DEV wrote: First of all: thanks for the quick replies! I appreciate very much. It would help if you told us which Tomcat version you were using. Tomcat 7.0.52, i.e. latest greatest (The reuse can be disabled via a system property, see RECYCLE_FACADES. I usually do so, for better security) Would I need to compile my own tomcat? Define what you mean by volatile. the members of the request object that are recycled. To be honest, I have not yet looked into the tomcat sources. To render we use velocity. The output is directly rendered into the response-writer. So the first byte written/rendered by velocity sets the response to commited (right?). Not unless you have disabled all buffering. Are you using any of the Velocity Tools stuff, like VelocityViewServlet or VelocityLayoutServlet? AND yes we have templates which we access the request#getRemoteAddress (somewhere close the end). It should not matter. As long as you aren't storing the result of request.remoteAddress anywhere, Velocity won't cache it anywhere. So could it be that these accesses set the remoteAddress tot he caller oft he previous request? This shouldn't happen. But if you play games with storing request objects in various places, you could have a problem. This is why I asked about using VelocityViewServlet. Did you roll your own Velocity servlet? If so, you may have made a mistake building your VelocityContext which ends up using the wrong request object. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTH1okAAoJEBzwKT+lPKRYXWYP+wcp8HQHyD7Wpcmq71JB4KPO S8ivvxpku2NeRcY5v4s5CSfJ6zBbxaL8SYnSL+3nakECxIIUl0GrMZ6dGgVHS7/l cYXhMNtXe7v5mEMJpo/koMA8lajkLtD3wTTKnaJCNkEbH00pEf6mySHxLIAocJ8G IAMVTJXxJPHsuZEJr219o+OJ8j5xLbX1GQq1B27eo1eszIO09YgVrUfAzMwaCesy 3kysGiuWS52/2jvHWAm/nKwdSf+PqWX+6P6fCo7ofVdsPO0PMh+20D8eYRQIRfW2 uJGypEofH9APlWebjZrnEV8+tjUXkcK0J6CuFuvhzAwaxg3TUrOC/BjysxKulMH6 SR9E2cJZjXNB6L3gOXXX7KrFsZVElFI+jJ2HwW8yZBWCmRXnchZBwCuRJZFYOidw N7Pmu8QtdwTIU+7iL5nM9zsUJvddVlIvzgTA7lLHVFk6QteiY4ZwqZAHMOGcpEVQ LkKpUK4SB1QyIZjDtU1HpPFtD4bJKptPEKddTZZ9hJYs6nnWBouCs9XB5Y2zEYUs zK2A+jjIMfqoxJBDfQllHmw4w7uDn6/cH3tp/3uRgEDDlFf326GwgufWw4l2WBN2 NAYJERfKPiYUuz2UC3MKnabuHi2J2vySyHA7jcjLnjMqs/x/+cEihBZ6QCO9LbPM aYpgGu3bs8+BYbfgNErI =k6ip -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: AW: request.getRemoteAddr() sometimes returning IP address from the previous request
(The reuse can be disabled via a system property, see RECYCLE_FACADES. I usually do so, for better security) Would I need to compile my own tomcat? No, just set the system property as per the docs. What ist he (performance) impact of setting this property to true? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: request.getRemoteAddr() sometimes returning IP address from the previous request
On 12/03/2014 08:38, Clemens Wyss DEV wrote: (The reuse can be disabled via a system property, see RECYCLE_FACADES. I usually do so, for better security) Would I need to compile my own tomcat? No, just set the system property as per the docs. What ist he (performance) impact of setting this property to true? There is some but I doubt you'll notice it given the other technology you have in play. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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
Re: AW: AW: request.getRemoteAddr() sometimes returning IP address from the previous request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/12/14, 8:34 AM, Mark Thomas wrote: On 12/03/2014 08:38, Clemens Wyss DEV wrote: (The reuse can be disabled via a system property, see RECYCLE_FACADES. I usually do so, for better security) Would I need to compile my own tomcat? No, just set the system property as per the docs. What ist he (performance) impact of setting this property to true? There is some but I doubt you'll notice it given the other technology you have in play. Are you insinuating that Velocity is slow? ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTIG1pAAoJEBzwKT+lPKRYbhMP/jQ1tuYDWz73LltaAtxtmvgM Hjsn5yBlewKLAW+o1bBPL5YYKlrwsydoMSjZG5IH2C91XaEpi2a5EfCEzVTHF7Iu LKqfICZ3IRznk/ic6j429NZwrj6jb+k1BZUYjdzng67O6pq9j5pDPby6/EkoT4+Y vxkWA7JLIaMo28VEOGpE8AbXy0A80pJ65ZjKUZpNYh7ZIyyZjfzZHhwuwGOo+Ntd 5iPpUTCkoOtEXmGnaioLSRvT0hV8/AlGb6kNnA9V5baunuHr5X5ap/3HmdIfpyoL 7hwjmFKzGfjAVJesMpTAWZvRqjmFpzXyzmhC8HniVqG7Wpe0QIozO5z9C2FTPHVn 1AjjsOW9pbgPWkbBtlc4txDcYOthzesjOhNIKcTpBcDF7ASkL/Aj5dvJ1VWlRNLu FXCZ2k66BiWkCV3QqrHXNeNtunVj6klfucqoUH1uoaSj/HBAqLeN4T4Hr5Xr8vu2 ax/oyRiNrHGsHTotvbREIIbVAwNSlNWFVsPObGYuLouRyabNp8lAi2r91zl/UcQk 2h56uD+JRbvceJY6Gnqk7xLsabe+FkwoCURZwoIcXEzBjgfp5IGXtLRylS3NV0Lz ctXL4/yXaD4WKXrplCvydSb+nhqv0Izum2lOvq42ghLyqmzXTDMQP+CMGshau8ea Gk1wKYKS2f8algCT3T8P =B30F -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
AW: request.getRemoteAddr() sometimes returning IP address from the previous request
By all means, post the relevant portion of the log file. I don't think this is of big help here. It would be very helpful if you'd answer my earlier question about how you take a request and route it to Velocity We put the request into the velocityContext and hence have the possibility to access whe(r|n)ever needed 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. 1) in the access.log we see all requests 2) if a specific monitoring-URL is called from our monitoring site (which's IP we know ;) ), AND the IP does not match the monitoring site, we write out the remote IP into the app-log as an error Now if the load on our site is high (bots accessing) then we frm time to time see these errors AND in the access.log we see that reported IP matches the request before the monitoring request (from the bot) Hope this helps -Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Mittwoch, 12. März 2014 17:41 An: Tomcat Users List Betreff: 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
Re: AW: request.getRemoteAddr() sometimes returning IP address from the previous request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Clemens, On 3/12/14, 1:34 PM, Clemens Wyss DEV wrote: By all means, post the relevant portion of the log file. I don't think this is of big help here. But you also don't know what you are doing. If you don't help us, we can't help you. Tomcat itself does not usually confuse requests in the way you describe, so the likely conclusion is that it is your web application. It would be very helpful if you'd answer my earlier question about how you take a request and route it to Velocity We put the request into the velocityContext and hence have the possibility to access whe(r|n)ever needed Yes, but how do you build that? There are many ways to do it incorrectly, like inappropriately-sharing resources between threads, etc. that can lead to the situation you are describing. 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. 1) in the access.log we see all requests 2) if a specific monitoring-URL is called from our monitoring site (which's IP we know ;) ), AND the IP does not match the monitoring site, we write out the remote IP into the app-log as an error Now if the load on our site is high (bots accessing) then we frm time to time see these errors AND in the access.log we see that reported IP matches the request before the monitoring request (from the bot) Hope this helps It doesn't. You need to provide more real information instead of just saying we know something is wrong; help us fix it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTIKDiAAoJEBzwKT+lPKRYqvAP/3SLGyn/ABzGYnuyks12Mfqt AUmBxUb3d/4EgccvkMIsjPI7FG8cSUQdRL9JCPosBUXCEoLfv0GMKK7KWe7S88dy VaPkFV+6kWlz2ou5m5Hhs89gGUDuVW6ENGhQSCq+qIGplBpf/PuLzwM5yfraZlCV fTpUgzSPXNTtJrK9rnAllqB2kvCVujpdvfw2/BAUuwa97v4pzdvyAeOKCN6kNVBy SAttVKul2ZC3LEhOasD8ygizf1EbsA1kIrlRHdDPWB6RwX+KU36SJPRrcnTDGkgD s02LyXPDyh9zKuj9eK90no+ZmEPJeJ4HNr//XVx8jaQIyvDOaGm9Br6ov7FPZDvj iMkaEMxeMrEkAfe+R6DvibMPHzrHEcbLUkfz6Lbjf4tooJjIClrYJf4DyAcys/6m b0HYFGwgNHKOEoBuHXJKfr9hvQhJB+Ig2XJwWqsWgwAJWlMcDjpV/36zyPLkIfRk BrjGoHhynk4F1Y87iwqlu6PBo0i1ZpD12njrScXQXxHdnc4xKWU18UETLs1M2M7l QnHmtEqIRHHntHsJeLaFGBTHy7tkZGSBJSqmKEx9EvVNHBRnLTa2mLIUIOQ+UMoj oNa+n25/wCy7kfX/ex8S3h5OcXs1V9EM/clV9oEJD6n1a8RU186WVTKsisoLCFIF Ci/6R1gZuqyR2JJAbP5C =KJXr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
request.getRemoteAddr() sometimes returning IP address from the previous request
Hi all, we are still facing this issue here https://issues.apache.org/bugzilla/show_bug.cgi as Mark Thomas points out https://issues.apache.org/bugzilla/show_bug.cgi?id=51872#c16 the bug is fixed. Trying to find out what we are doing wrong I have the following questions: 1) as soon as a response is commited we should no longer access the corresponding request? 2) a response is commited (at latest) as soon as a byte is written into the response's writer? 3) which members of the request are volatile? Are these specified in the ServletRequest API? Thx Clemens - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: request.getRemoteAddr() sometimes returning IP address from the previous request
2014-03-11 18:16 GMT+04:00 Clemens Wyss DEV clemens...@mysign.ch: Hi all, we are still facing this issue here https://issues.apache.org/bugzilla/show_bug.cgi as Mark Thomas points out https://issues.apache.org/bugzilla/show_bug.cgi?id=51872#c16 the bug is fixed. Tomcat version = ? Trying to find out what we are doing wrong I have the following questions: 1) as soon as a response is commited we should no longer access the corresponding request? There is no such requirement. A requirement is that you should not access it once request processing has been returned to Tomcat. Once request processing finishes, the request object is recycled by Tomcat and may be reused for a subsequent request. (The reuse can be disabled via a system property, see RECYCLE_FACADES. I usually do so, for better security). 2) a response is commited (at latest) as soon as a byte is written into the response's writer? No. It happens when you explicitly flush it, or a buffer overflows. It happens immediately of you have configured buffer size of 0. 3) which members of the request are volatile? Are these specified in the ServletRequest API? Not specified. (I am talking about classic Servlet API. No async processing.) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: request.getRemoteAddr() sometimes returning IP address from the previous request
On 11/03/2014 14:16, Clemens Wyss DEV wrote: Hi all, we are still facing this issue here https://issues.apache.org/bugzilla/show_bug.cgi as Mark Thomas points out https://issues.apache.org/bugzilla/show_bug.cgi?id=51872#c16 the bug is fixed. Trying to find out what we are doing wrong I have the following questions: 1) as soon as a response is commited we should no longer access the corresponding request? There are no such restrictions. 2) a response is commited (at latest) as soon as a byte is written into the response's writer? A response is committed when the first byte is sent to the client. 3) which members of the request are volatile? Are these specified in the ServletRequest API? Define what you mean by volatile. The typical causes of this type of issue is retaining a reference to a request and/or response (in a filter, in a session or similar) and then trying to use the request or response object when processing a different request/response pair. It would help if you told us which Tomcat version you were using. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: request.getRemoteAddr() sometimes returning IP address from the previous request
First of all: thanks for the quick replies! I appreciate very much. It would help if you told us which Tomcat version you were using. Tomcat 7.0.52, i.e. latest greatest (The reuse can be disabled via a system property, see RECYCLE_FACADES. I usually do so, for better security) Would I need to compile my own tomcat? Define what you mean by volatile. the members of the request object that are recycled. To be honest, I have not yet looked into the tomcat sources. To render we use velocity. The output is directly rendered into the response-writer. So the first byte written/rendered by velocity sets the response to commited (right?). AND yes we have templates which we access the request#getRemoteAddress (somewhere close the end). So could it be that these accesses set the remoteAddress tot he caller oft he previous request? Thx Clemens -Ursprüngliche Nachricht- Von: Mark Thomas [mailto:ma...@apache.org] Gesendet: Dienstag, 11. März 2014 15:34 An: Tomcat Users List Betreff: Re: request.getRemoteAddr() sometimes returning IP address from the previous request On 11/03/2014 14:16, Clemens Wyss DEV wrote: Hi all, we are still facing this issue here https://issues.apache.org/bugzilla/show_bug.cgi as Mark Thomas points out https://issues.apache.org/bugzilla/show_bug.cgi?id=51872#c16 the bug is fixed. Trying to find out what we are doing wrong I have the following questions: 1) as soon as a response is commited we should no longer access the corresponding request? There are no such restrictions. 2) a response is commited (at latest) as soon as a byte is written into the response's writer? A response is committed when the first byte is sent to the client. 3) which members of the request are volatile? Are these specified in the ServletRequest API? Define what you mean by volatile. The typical causes of this type of issue is retaining a reference to a request and/or response (in a filter, in a session or similar) and then trying to use the request or response object when processing a different request/response pair. It would help if you told us which Tomcat version you were using. Mark - 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: request.getRemoteAddr() sometimes returning IP address from the previous request
On 11/03/2014 15:23, Clemens Wyss DEV wrote: First of all: thanks for the quick replies! I appreciate very much. It would help if you told us which Tomcat version you were using. Tomcat 7.0.52, i.e. latest greatest OK. That rules out all the known issues that might cause this. (The reuse can be disabled via a system property, see RECYCLE_FACADES. I usually do so, for better security) Would I need to compile my own tomcat? No, just set the system property as per the docs. Define what you mean by volatile. the members of the request object that are recycled. To be honest, I have not yet looked into the tomcat sources. Pretty much everything. To render we use velocity. The output is directly rendered into the response-writer. So the first byte written/rendered by velocity sets the response to commited (right?). AND yes we have templates which we access the request#getRemoteAddress (somewhere close the end). So could it be that these accesses set the remoteAddress to the caller of the previous request? Unlikely unless those templates are somehow caching the request or the result of getRemoteAddress(). Mark Thx Clemens -Ursprüngliche Nachricht- Von: Mark Thomas [mailto:ma...@apache.org] Gesendet: Dienstag, 11. März 2014 15:34 An: Tomcat Users List Betreff: Re: request.getRemoteAddr() sometimes returning IP address from the previous request On 11/03/2014 14:16, Clemens Wyss DEV wrote: Hi all, we are still facing this issue here https://issues.apache.org/bugzilla/show_bug.cgi as Mark Thomas points out https://issues.apache.org/bugzilla/show_bug.cgi?id=51872#c16 the bug is fixed. Trying to find out what we are doing wrong I have the following questions: 1) as soon as a response is commited we should no longer access the corresponding request? There are no such restrictions. 2) a response is commited (at latest) as soon as a byte is written into the response's writer? A response is committed when the first byte is sent to the client. 3) which members of the request are volatile? Are these specified in the ServletRequest API? Define what you mean by volatile. The typical causes of this type of issue is retaining a reference to a request and/or response (in a filter, in a session or similar) and then trying to use the request or response object when processing a different request/response pair. It would help if you told us which Tomcat version you were using. Mark - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: request.getRemoteAddr() sometimes returning IP address from the previous request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Clemens, On 3/11/14, 11:23 AM, Clemens Wyss DEV wrote: First of all: thanks for the quick replies! I appreciate very much. It would help if you told us which Tomcat version you were using. Tomcat 7.0.52, i.e. latest greatest (The reuse can be disabled via a system property, see RECYCLE_FACADES. I usually do so, for better security) Would I need to compile my own tomcat? Define what you mean by volatile. the members of the request object that are recycled. To be honest, I have not yet looked into the tomcat sources. To render we use velocity. The output is directly rendered into the response-writer. So the first byte written/rendered by velocity sets the response to commited (right?). Not unless you have disabled all buffering. Are you using any of the Velocity Tools stuff, like VelocityViewServlet or VelocityLayoutServlet? AND yes we have templates which we access the request#getRemoteAddress (somewhere close the end). It should not matter. As long as you aren't storing the result of request.remoteAddress anywhere, Velocity won't cache it anywhere. So could it be that these accesses set the remoteAddress tot he caller oft he previous request? This shouldn't happen. But if you play games with storing request objects in various places, you could have a problem. This is why I asked about using VelocityViewServlet. Did you roll your own Velocity servlet? If so, you may have made a mistake building your VelocityContext which ends up using the wrong request object. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTH1okAAoJEBzwKT+lPKRYXWYP+wcp8HQHyD7Wpcmq71JB4KPO S8ivvxpku2NeRcY5v4s5CSfJ6zBbxaL8SYnSL+3nakECxIIUl0GrMZ6dGgVHS7/l cYXhMNtXe7v5mEMJpo/koMA8lajkLtD3wTTKnaJCNkEbH00pEf6mySHxLIAocJ8G IAMVTJXxJPHsuZEJr219o+OJ8j5xLbX1GQq1B27eo1eszIO09YgVrUfAzMwaCesy 3kysGiuWS52/2jvHWAm/nKwdSf+PqWX+6P6fCo7ofVdsPO0PMh+20D8eYRQIRfW2 uJGypEofH9APlWebjZrnEV8+tjUXkcK0J6CuFuvhzAwaxg3TUrOC/BjysxKulMH6 SR9E2cJZjXNB6L3gOXXX7KrFsZVElFI+jJ2HwW8yZBWCmRXnchZBwCuRJZFYOidw N7Pmu8QtdwTIU+7iL5nM9zsUJvddVlIvzgTA7lLHVFk6QteiY4ZwqZAHMOGcpEVQ LkKpUK4SB1QyIZjDtU1HpPFtD4bJKptPEKddTZZ9hJYs6nnWBouCs9XB5Y2zEYUs zK2A+jjIMfqoxJBDfQllHmw4w7uDn6/cH3tp/3uRgEDDlFf326GwgufWw4l2WBN2 NAYJERfKPiYUuz2UC3MKnabuHi2J2vySyHA7jcjLnjMqs/x/+cEihBZ6QCO9LbPM aYpgGu3bs8+BYbfgNErI =k6ip -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
