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]/msg03347.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------------------------------------------------------
redirect-patch.tar.gz
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
