My 2c based on my recent experience with the problem of redirect with
sesssions.
code snippet:
session = request.getSession(true);
session.putValue("xxx", "yyyyy");
request.redirect(anotherURL);
IE4 gets to the next page correctly, but Netscape has a problem. In my case,
we have to support at least both IE4 and Netscape. So I have to stop the
redirection feature.
It is a browser bug, as far as my experience tells me. But it will also be
very nice to have a work around as proposed by Jason Gilbert. If possible,
PLEASE add the workaround.
best regards,
-shaoping zhou
Jason Gilbert wrote:
> I previously reported this problem, but I just downloaded 1.0b3
> and the issue is still there (maybe I should have filed a bug
> report). There wasn't any further discussion on this issue. See
> below for some additional comments.
>
> On Wed, 20 Jan 1999, Craig R. McClanahan wrote:
>
> > Jason Gilbert wrote:
>
> > > 3) The JServConnection.encodeRedirectUrl doesn't quite do the
> > > right thing. It doesn't check to see if cookies were used so
> > > even if cookies are used the sessionId gets included in the query
> > > string. maybe something like the following should be used
> > > instead:
> > >
> > > if (url.indexOf(hostname) == 01) {
> > > return url;
> > > }
> > > return encodeUrl(url);
> > >
> > > or it at least needs to add a check for idCameAsCookie.
> >
> > It would be easy to add the check for idCameAsCookie, but I am wondering
> > if the current behavior might be a deliberate workaround for a browser
> > bug -- perhaps it won't return the cookie after a redirect, and your
> > session would be lost?
> > code longer than I have?
>
> I don't see how this could be a browser bug. Cookies being sent
> to a url is controlled by the browser and if the redirect is back
> to the same server it should be handled by a cookie. So, if it's
> going to include a session at all it should do the standard check
> for a cookie.
>
> This leads to another possible problem that I've noticed.
> There's a bug listed (PR#3941) that somewhat addresses this as a
> problem of cross-zone sessions.
>
> My issue is this: as far as I can tell the ServletManager for a
> zone holds the sessions for that zone so a servlet running in a
> different zone will not have access to sessions in another zone.
> I personally don't have a problem with this. However, the path
> for the session cookie is set to "/" by default. I think the
> path should probably be set to "/<zone-prefix>" instead so that a
> browser can hold sessions for multiple zones on a single host?
> Opinions?
>
> jason
>
> Jason Gilbert | http://www.scott.net/~jason/
> ------------------------------------------------------
> I wish I could make the garbage collector thread in my
> brain less aggressive.
>
> ----------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://www.working-dogs.com/>
> Problems?: [EMAIL PROTECTED]
--
Metaphase Technology Group | voice: (651) 482-2966
4201 Lexington Ave N, Arden Hills, MN 55126
----------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://www.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
