Am Dienstag, 18. November 2003 18:29 schrieb Brice Ruth: If anyone knows a solution to this matter, I'm definitely interested in hearing about it, too. From all what I can tell, some search engines don't care (Altavista's Scooter, for example), while some do (Google, in particular) and go away when they detect a session. I experimented for quite some time, but to no real avail. One approach I tried is having a custom action explicitly killing all sessions when entering the main page and invoking that one from my index.jsp. This works, but I couldn't keep to this approach when porting (my private site) to Tiles some time ago, didn't look further into the possible reasons behind this. Plus, Struts also stores some info in session scope, the user's locale, for example. When I had to decide between sessions and Google (in fact, I only need sessions for pages 'beyond' authen- tication stage; my provider doesn't grant me access to resin.conf, so I had to write a filter for that task), I decided to better stick to the framework and have Google satisfied otherwise (ah, robots.txt doesn't make any difference in this direction, too). Gone bad already, I chose the cloaking approach (don't try this at home :-), so I changed my index.jsp to something like:
<%@ page contentType="text/html; charset=ISO-8859-1" session="false" %> <% String userAgent = request.getHeader("User-Agent"); if (userAgent.indexOf("oogle") == -1) { %> <jsp:forward page="/main.do" /> <% } else { %> <jsp:forward page="/static/index.html" /> <% } %> and just saved a static snapshot of the main page in /static with Cookies enabled, so the jsessionid things are not appended to the links. Google won't be able to tell the difference because of the forward. Considering 'brute' means as disabling URL rewriting in general, I'd rather guess this is a server-specific thing. In Java, you don't have any means of telling the server how to maintain session state, the only thing you can say is 'request.getSession()' and check for an existing session if you give 'false' as a parameter to the overloaded version, and you can programmatically kill sessions via session.invalidate(). This is all Struts can do, too. So I think you have to check your server's manuals on this matter. If it's Tomcat, I can rather reliably tell that you can decide whether to use cookies or not, but the same is not true for the URL-rewriting approach as a 'fallback' means, and then, the server has to adhere the Servlet specification, after all. Now. As you can't determine *how* sessions are maintained, you can still determine to some degree *when* they're created. One thing I can tell from my experiences with Struts is that using the standard forward Action will auto- matically result in having a session around afterwards, but if you write a custom one that just says 'return mapping.findForward("success");, things are quite different. And so on. I really have to look further into this if my time allows. Note this is just telling from my experiences when developing my private site. On the job, the landing sites usually are static HTML pages, not so much because of session handling or search engines, but because of the general vulnerability of dynamic pages to DoS attacks and high traffic volumes in general. HTH, -- Chris. > Is there any way to disable URL rewriting (with jsessionid) in Tomcat > or via struts-config.xml or anything? I'm about at my wits end with > this jsessionid thing - now our search engine which indexes by > crawling the site (and doesn't support cookies) can't index properly > because of the jsessionid property ... and frankly, I'm not really > caring at this point if the 3-5% of visitors to our site can't use > sessions (there's practically no functionality that depends on it > anyway - mainly a performance improvement, where it is being used). > I'd like to leave sessions via cookies enabled, but disable URL > rewriting for sessions. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]