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]
