.
Unfortunately our OS holds on to ports until a few seconds after the process
dies (waiting for the remote connections to terminate, presumably).
brycenesbitt wrote:
We have a Tomcat application, which binds to port 8080 and AJP 6135. At
3 am we restart this application (because of a memory leak
Stefan Bethke wrote:
Hi,
I hope this is the right list to ask; if not, please direct me to a
better place...
We're currently integrating a couple of web sites under a single
domain. Some of the sites run on separate Tomcats, others use PHP,
Perl or a number of proprietary
Christopher Schultz-2 wrote:
And why only in MSIE?
Stefan also needs to understand that these cookies also have paths
encoded into them, so that that do not interfere (as long as the paths
themselves do not interfere).
- -chris
MSIE processes the paths differently than Gecko based
Simon-76 wrote:
Thanks, I could try this, but I was kind of hoping for a more general
Tomcat
solution (if there is one). I know Resin has a 'enable-url-rewriting' flag
that you can set in it's config.
I guess the question still is, does anyone definitively know if jsessionid
does have
Jason Oullette wrote:
How does tomcat decide if the JSessionID will be put in a cookie or in the
post header(url rewriting)?
If the Cookies attribute in the context is false, then Tomcat rewrites the
URL.
If the Cookies attribute in the cotext is true, then Tomcat uses either
cookies or
Rashmi Rubdi wrote:
As discussed previously in this thread you can turn jsessionid in the URL
off easily by setting the cookies attribute of Context to true.
http://tomcat.apache.org/tomcat-5.0-doc/config/context.html
No option seems to match the need:
true -- uses URL-rewriting if the
Caldarale, Charles R wrote:
Try turning off cookies in your browser.
Sorry for the lack of clarity. I can't force jessionid to show up even with
cookies off in the browser.
Using wget from the unix command line (no cookies!) I get a jsessionid for
images:
Caldarale, Charles R wrote:
From: brycenesbitt [mailto:[EMAIL PROTECTED]
Subject: Re: Web spiders - disabling jsessionid
Creating semicolon-based URL strings is the default in
Tomcat/Struts.
I don't know about Struts, but that's not true for Tomcat. Look at the
cookies attribute
Rashmi Rubdi wrote:
So the solution for Bryce would be to leave the session on on each JSP
page, and omit the cookies attribute of Context which defaults it to
true.
This should solve the problem of jsessionid for bots.
From my observation search bots support cookies otherwise I would
Rashmi Rubdi wrote:
I don't know because this problem doesn't happen in my case, on 2
different web applications.
Bryce should really test his case by setting cookies=true or remove the
cookies attribute and test his links with Xenu to see if he still gets
jsessionid with Xenu.
A
Mikolaj Rydzewski-2 wrote:
Hi,
As you may know url rewriting feature is not a nice thing when spiders
come to index your site -
http://gabrito.com/post/javas-seo-blunder-jsessionid.
I'm having trouble with JSESSIONID with search engines Google, Accoona,
Alexa and Exalead.
My approach
Christopher Schultz-2 wrote:
Perhaps that is the /quickest/ solution, but I would argue that the best
solution is not to create a session if you don't actually need one.
The problem in many cases is the author does not care about sessions at all!
Creating semicolon-based URL strings is
Google's index has 33.4 million pages with a jsessionid:
http://www.google.com/search?hl=enlr=q=inurl%3AjsessionidbtnG=Search
Many of those are duplicates (no different other than the jsessionid).
-Bryce Nesbitt
--
View this message in context:
13 matches
Mail list logo
