Perhaps requiresNew Session should be deprecated in 2.2 instead, but other than that, I see no reason not to apply this patch. Will someone please apply?
-Peter ----- Original Message ----- From: "Gareth Coltman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "'Peter Lynch'" <[EMAIL PROTECTED]> Sent: Wednesday, October 24, 2001 1:36 AM Subject: RE: [PATCH] Removing redirect logic in Turbine.java > Why hasn't this patch been applying to CVS? > > > -----Original Message----- > > From: Peter Lynch [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, October 21, 2001 03:13 > > To: [EMAIL PROTECTED] > > Subject: [PATCH] Removing redirect logic in Turbine.java > > > > > > Hello, > > > > Here is a patch to turbine-2 the does the following: > > > > 1. Removes the Turbine.java logic of redirection to establish > > new sessions > > which, although reportedly a fix for certain obscure browser > > and server > > combinations, also has the consequence of creating several > > problems itself. > > > > 2. Removes the abstract requiresNewSession from > > SessionValidator.java et > > all. This method is no longer needed as the only place it was > > used was in > > the above removed code. > > > > Hopefully someone can patch this into Turbine-2. ( and port > > to Turbine 3?) > > .Thank you for your assistance. > > > > -Peter > > > > PS - below is a snippet of problems that could be included > > with the commit > > to explain why it is being removed. > > > > > > ---8<-- excerpt from my quasi-rant from another post to > > turbine-user and > > scarab dev----- > > My thinking is that this particular code solves no common > > problem. Instead > > it is itself a hack for a very rare instance/combination of > > agent/container > > or at the very least some session tracking voodoo. Whoever > > encounters a > > problem stemming from this code not being in the core should > > be the one who > > adjusts their own code. I agree I should have not been the one hacking > > workarounds for this piece of code and sharing my findings > > more vigorously > > with others might have helped others. > > > > I can note several distinct problems caused by this code: > > 1. User bookmarks a link with the redirected key, causes > > Infinite redirect > > stack dump to client. Open a new browser and try it yourself: > > http://scarab.whichever.com:8080/scarab/servlet/scarab/redirected/true > > 2. When the code does execute it makes one request into 3 > > separate requests > > ( and responses) causing unnecessary traffic. > > 3. Posted data can be resubmitted as a get, causing overflow > > in Apache or > > the container. > > 4. working around the above problems means the developer has > > to add other > > hacks just to support a core hack condition that will never > > likely occur. > > > > Maybe this code had more solid purpose back in the days of > > Servlet spec 2.1, > > and crappy browsers and containers.. > > > > Reading the list archives tells a sorted tale about this > > redirect code. For > > example > > http://www.mail-archive.com/[email protected]/msg > 03347.html > is one of many messages about the confusion this code causes. > > Here is what Sean Legassick had to say in > http://www.mail-archive.com/[email protected]/msg02713.html > "This mechanism is in place to ensure that session tracking works > correctly. Particularly it allows the container to select URL-based > session tracking if the client browser appears to have cookies disabled, > and it guards against infinite redirects where a containers session > tracking mechanism is broken (it could be argued this latter case is > unlikely these days). It's a fairly common servlet API trick." > > Funny, actually it facilitates infinite redirects. See #1 above. The first > part above is avoided if something like DynamicURI is used to construct all > the URLS in your app. Doing so means the urls returned in the template from > the first response would have the session id appended if a cookie could not > be set. The encoding determines if session id should be appended to the URLs > for you. There is no need to do the redirect thing for the server to figure > it out. > > Lastly, the first call to request.getSession(true) will create a new session > anyway if one does not exist. In Turbine 2.1 this happens in > TurbineRunDataService when the session is put into RunData. > > Sorry, I just have no good things to say about it. The patch is simply to > remove the code. > Not add more hacks to work around the more common problems that the > redirection creates. > ---------8< end rant------------------------------------------------------ > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
