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]
