Re: How to stop Session Tracking, or stop extraction of ;jsessionid=XXX from requested URL
On 5/4/05, Tim Funk [EMAIL PROTECTED] wrote: The easiest thing to do is to change all your jsp's to have the following code. [EMAIL PROTECTED] session='false'% Hi Tim, Thanks for your response. My understanding of the @page session='false' directive is that it is useful because, under default behavior, JSPs automatically acquire a session using request.getSession(true), and this directive enables you to instruct a single JSP not to do this. However, I'm not using any JSPs; I'm using valves, servlet filters, and servlets. As you mentioned earlier: Then unless you have code specifically asking for a session - no sessions should be created. Okay, that's great to hear. Thank you for clarifying that for me. I now see that that even though CoyoteAdapter parses out the requested sessionid and attaches information about it to the request, a Session has not been created. However, even if Sessions are not being created, I'm still interested in determining how to stop Tomcat from removing ;jsessionid's from an incoming request URI. As I take a closer look, it may not be possible.. (I'm waving my hands a little bit here, and can provide details if they are required.) But, what I see is that the URI is removed by the CoyoteAdapter class during the Connector-Processing phase of the request. This happens *before* the request is handed off to the Engine. It may be necessary to properly map the incoming request to the appropriate Context and Wrapper. Here's a telling set of comments from CoyoteAdapter: // Remove any remaining parameters (other than session id, // which has already been removed in parseSessionId()) // from the URI, so they won't be considered by the mapping // algorithm. If that's the case, then there is likely no way to 'disable' this functionality, as it's core to overall processing scheme. Further, stopping this behavior also has nothing to do with disabling session tracking, as we haven't reached a point where Sessions are being tracked. This means I should solve my problem by, at a later time in the processing of a single request, inserting the ;jsessionid=XXX at the end of my URI. Thanks again, Tim. If anyone sees a flaw in what I've said, or a way to accomplish what we've been discussing, please let us know. Thanks, -Jed Jedidiah Northridge wrote: More specifically, is there anyway I can stop my Tomcat from extracting the ;jsessionid=XXX from an incoming URI? At present, when I analyze an incoming request, if the requested URI looks something like: /index.html;jsessionid=XXX by the time it reaches my servlet, it has been changed to /index.html. I'm asking about this because I'm using my Tomcat as a reverse proxy. I'm encountering difficulty when my Tomcat proxy sits in between a client and a backend Tomcat that legitimately uses URL rewriting for session tracking. When the backend tomcat rewrites a ;jsessionid=XXX as part of a response, this gets back to the client, but when the client requests it, my proxy tomcat (in the middle) consumes the jsessionid that was meant for the backend. I presume this unnecessarily uses memory for session tracking (in the middle), but it definitely strips out the URL so that the jsessionid doesn't make it to the backend. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to stop Session Tracking, or stop extraction of ;jsessionid=XXX from requested URL
Hello, I don't need the functionality of session tracking, either through URL rewriting or via Cookie assignment. Is there anyway I can disable it completely? More specifically, is there anyway I can stop my Tomcat from extracting the ;jsessionid=XXX from an incoming URI? At present, when I analyze an incoming request, if the requested URI looks something like: /index.html;jsessionid=XXX by the time it reaches my servlet, it has been changed to /index.html. I'm running 5.0.28, and I'm using mod_jk2 as my Connector. When I debug the situation, I'm seeing the URI being changed as part of org.apache.coyote.tomcat5.CoyoteAdapter's parseSessionID. The method first parses out the session id, and then extracts it. For test purposes, I've used the HTTP Listener as my Connector, and I still see the same extraction behavior in CoyoteAdapter. I'm asking about this because I'm using my Tomcat as a reverse proxy. I'm encountering difficulty when my Tomcat proxy sits in between a client and a backend Tomcat that legitimately uses URL rewriting for session tracking. When the backend tomcat rewrites a ;jsessionid=XXX as part of a response, this gets back to the client, but when the client requests it, my proxy tomcat (in the middle) consumes the jsessionid that was meant for the backend. I presume this unnecessarily uses memory for session tracking (in the middle), but it definitely strips out the URL so that the jsessionid doesn't make it to the backend. I understand how to re-attach the ;jsessionid using the Session API before proxying the request to the backend. However, seeing as I don't need the session tracking (for the tomcat in the middle), I'd like to stop the process before it starts. Is this possible to achieve using any configuration options? Or programmatically? I see how to change CoyoteAdapter; but would prefer to avoid changing Tomcat code. If the only way to stop it all together is to alter tomcat code, is CoyoteAdapter the place to do it, or do you recommend another, more correct, place to make a change? Thank you very much, -Jed Northridge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to stop Session Tracking, or stop extraction of ;jsessionid=XXX from requested URL
The easiest thing to do is to change all your jsp's to have the following code. [EMAIL PROTECTED] session='false'% Then unless you have code specifically asking for a session - no sessions should be created. A simplier but uglier kludge is to create a Filter which overrides getSession and always returns null instead of allowing a session to be created. -Tim Jedidiah Northridge wrote: Hello, I don't need the functionality of session tracking, either through URL rewriting or via Cookie assignment. Is there anyway I can disable it completely? More specifically, is there anyway I can stop my Tomcat from extracting the ;jsessionid=XXX from an incoming URI? At present, when I analyze an incoming request, if the requested URI looks something like: /index.html;jsessionid=XXX by the time it reaches my servlet, it has been changed to /index.html. I'm running 5.0.28, and I'm using mod_jk2 as my Connector. When I debug the situation, I'm seeing the URI being changed as part of org.apache.coyote.tomcat5.CoyoteAdapter's parseSessionID. The method first parses out the session id, and then extracts it. For test purposes, I've used the HTTP Listener as my Connector, and I still see the same extraction behavior in CoyoteAdapter. I'm asking about this because I'm using my Tomcat as a reverse proxy. I'm encountering difficulty when my Tomcat proxy sits in between a client and a backend Tomcat that legitimately uses URL rewriting for session tracking. When the backend tomcat rewrites a ;jsessionid=XXX as part of a response, this gets back to the client, but when the client requests it, my proxy tomcat (in the middle) consumes the jsessionid that was meant for the backend. I presume this unnecessarily uses memory for session tracking (in the middle), but it definitely strips out the URL so that the jsessionid doesn't make it to the backend. I understand how to re-attach the ;jsessionid using the Session API before proxying the request to the backend. However, seeing as I don't need the session tracking (for the tomcat in the middle), I'd like to stop the process before it starts. Is this possible to achieve using any configuration options? Or programmatically? I see how to change CoyoteAdapter; but would prefer to avoid changing Tomcat code. If the only way to stop it all together is to alter tomcat code, is CoyoteAdapter the place to do it, or do you recommend another, more correct, place to make a change? Thank you very much, -Jed Northridge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]