On 10/24/01 4:36 AM, "Gareth Coltman" <[EMAIL PROTECTED]>
wrote:

> Why hasn't this patch been applying to CVS?

Nobody has had time to test it. I won't just apply patches unless I test it
with the TDKs to verify that everything is cool. Pressed for time at the
moment.
 
>> -----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]

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to