Hi,
the problem I'm experiencing (I'm the OP) seems a different one, although
it may be related, of course.
1. I'm not accessing the root context (with or without trailing slash)
2. I'm using JRun 26414 on the ReadHat box where the problem occurs.
I suppose this build includes the mentiones patch.
3. I'm using the patched version of JRun 16777 on NT where the problem
does not occur.
4. It can't be I step on other people's session because I made sure I was
the only person accessing the server at the time, and I opened only one
browser session.
5. It's not a caching problem - all happens in our LAN.
6. I'll work on Mike Collins' suggestion to test if an incoming jsessionid gets bound
to the wrong httpsession object. One other thing I'll look for is that maybe
the binding happens too late, so that all user's would share the same session
for their firstv request, and only then get the proper session. Could that happen?
7. Perhaps this is relevant: I am not using any calls to invalidate sessions or
setMaxInactiveInterval(-1) in code.
Best,
Sebastian
>>> [EMAIL PROTECTED] 27.03.2002 18.40 Uhr >>>
So are you saying that the patch for this does not work? Or people do not know about
it?
Please see this URL:
http://www.macromedia.com/v1/handlers/index.cfm?ID=22260&Method=Full
Scott
> -----Original Message-----
> From: michael veit [mailto:[EMAIL PROTECTED]]
>
>
> not the problem - this is on an intranet - no proxy. all our
> pages carry that header as well. This bug is documented and
> reproduced by Macromedia:
> Jrun Bug 24049 - It is possible to get a duplicate session
> id during multi-user use of Jrun if the user browses to a
> Jrun Web application root directory without using a trailing slash.
> "Haseltine, Celeste" <[EMAIL PROTECTED]> wrote: Will,
>
> Good point. All of our web pages carry the header below.
> Perhaps that is
> why we have not experienced this problem.
>
> response.setHeader("Pragma","no-cache"); //HTTP 1.0 refetch
> completely next
> time document is
> needed.
> response.setHeader("Cache-Control","no-cache"); //HTTP 1.1
> response.setDateHeader ("Expires", 0); //prevents caching at the proxy
> server, refetches ONLY if it
> has been modified since last fetch
> response.setHeader("Cache-Control","no-store"); //HTTP 1.1
>
>
> Celeste
>
> -----Original Message-----
> From: Will Berger [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 27, 2002 10:38 AM
> To: JRun-Talk
> Subject: RE: Difficult To Reproduce Session Issue
>
>
> I am coming late to this thread, but I thought I would give
> you my 2 cents.
> We ran into this problem sometime ago where it appeared to be
> a jrun bug
> that caused sessions to get mixed up, turned out to be that
> the new client
> that we signed up had a proxy caching server and our jsp were
> being cached.
> Adding the
>
> response.addHeader("Pragma", "No-cache");
> response.addHeader("Cache-Control", "no-cache");
> response.addDateHeader("Expires", 1);
>
> This resolved the issue.
>
> Will
>
> -----Original Message-----
> From: Mike Collins [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 27, 2002 11:01 AM
> To: JRun-Talk
> Subject: Re: Difficult To Reproduce Session Issue
>
>
> Some ideas on troubleshooting this issue:
>
> I can think of 3 reasons why someone can get the wrong session data:
> 1. your jsessionid cookie somehow gets reset during the
> session to another
> valid session
> 2. when your session is initialized you step on someone
> else's httpsession
> object
> 3. requests with an incoming jsessionid gets bound to the
> wrong httpsession
> object
>
> Some ideas on troubleshooting the above scenarios:
> - upon the creation of a new session, record the jsessionid in the
> httpsession object.
> - if a value already exists you know that you have just hit #2
> - on all subsequent requests validate the jsessionid with the
> value on the
> httpsession object. If they are not equal you know the
> problem is 1 or 3.
>
> If you add these lines of code I would think you have a
> pretty good chance
> at isolating and stopping folks from getting the wrong
> session. I would
> also hope it might lead us to a resolution.
>
> My gut tells me it is number 3, the others seem like they would have
> revealed themselves by now.
>
> Regards,
> Mike
______________________________________________________________________
Your ad could be here. Monies from ads go to support these lists and provide more
resources for the community. http://www.fusionauthority.com/ads.cfm
Archives: http://www.mail-archive.com/jrun-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
