It is being tested. john mcnally
Peter Lynch wrote: > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
