You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Peter Lynch <pe...@mindspring.com> on 2001/10/21 04:13:24 UTC

[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/turbine-dev@jakarta.apache.org/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/turbine-dev@jakarta.apache.org/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------------------------------------------------------

Re: [PATCH] Removing redirect logic in Turbine.java

Posted by John McNally <jm...@collab.net>.
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" <ga...@majorband.co.uk>
> To: <tu...@jakarta.apache.org>; "'Peter Lynch'"
> <pe...@mindspring.com>
> 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:peterlynch@mindspring.com]
> > > Sent: Sunday, October 21, 2001 03:13
> > > To: turbine-dev@jakarta.apache.org
> > > 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/turbine-dev@jakarta.apache.org/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/turbine-dev@jakarta.apache.org/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: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: [PATCH] Removing redirect logic in Turbine.java

Posted by Peter Lynch <pe...@mindspring.com>.
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" <ga...@majorband.co.uk>
To: <tu...@jakarta.apache.org>; "'Peter Lynch'"
<pe...@mindspring.com>
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:peterlynch@mindspring.com]
> > Sent: Sunday, October 21, 2001 03:13
> > To: turbine-dev@jakarta.apache.org
> > 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/turbine-dev@jakarta.apache.org/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/turbine-dev@jakarta.apache.org/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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: Java logging package

Posted by Kasper Nielsen <ne...@kav.dk>.
----- Original Message -----
From: "Gonzalo A. Diethelm" <go...@aditiva.com>
To: <tu...@jakarta.apache.org>
Sent: Thursday, October 25, 2001 11:01 PM
Subject: Java logging package


> Has anybody looked into using or adapting Java's (1.4) standard
> logging package into Turbine?

> Is this something desirable?
No!
This may come as a surprise but some people are not using the beta version
of jdk 1.4, and we need to make sure these people are also able to use
turbine.

- Kasper



---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

RE: Java logging package

Posted by Ilia Iourovitski <ii...@ydyn.com>.
jakarta-commons-sandbox/logging is going in this direction.
The main inconvenience of Toque using log4j is that Avalon/Cocoon is using
LogKit.

Ilia

-----Original Message-----
From: Jason van Zyl [mailto:jvanzyl@zenplex.com]
Sent: Friday, October 26, 2001 6:50 AM
To: turbine-dev@jakarta.apache.org
Subject: Re: Java logging package


On 10/25/01 5:01 PM, "Gonzalo A. Diethelm" <go...@aditiva.com>
wrote:

> Has anybody looked into using or adapting Java's (1.4) standard
> logging package into Turbine? Is this something desirable?
>
> http://java.sun.com/j2se/1.4/docs/guide/util/logging/overview.html

I believe this will be possible with log4j, and I also believe that someone
has made a set of adapters so this will be possible.

But you must realize that many of the recent changes in the JSR  27 (logging
API) have been altered due to pressure by the log4j community. The APIs are
very close but I still feel that log4j is better. The logging API will also
require Java 1.4 which I don't feel many people will be prepared to jump to
immediately.

--

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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: Java logging package

Posted by Jason van Zyl <jv...@zenplex.com>.
On 10/25/01 5:01 PM, "Gonzalo A. Diethelm" <go...@aditiva.com>
wrote:

> Has anybody looked into using or adapting Java's (1.4) standard
> logging package into Turbine? Is this something desirable?
> 
> http://java.sun.com/j2se/1.4/docs/guide/util/logging/overview.html

I believe this will be possible with log4j, and I also believe that someone
has made a set of adapters so this will be possible.

But you must realize that many of the recent changes in the JSR  27 (logging
API) have been altered due to pressure by the log4j community. The APIs are
very close but I still feel that log4j is better. The logging API will also
require Java 1.4 which I don't feel many people will be prepared to jump to
immediately. 

-- 

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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: Java logging package

Posted by Jon Stevens <jo...@latchkey.com>.
on 10/25/01 2:01 PM, "Gonzalo A. Diethelm" <go...@aditiva.com>
wrote:

> Has anybody looked into using or adapting Java's (1.4) standard
> logging package into Turbine? Is this something desirable?
> 
> http://java.sun.com/j2se/1.4/docs/guide/util/logging/overview.html
> 

On top of what Kasper said...

Please read:

http://jakarta.apache.org/log4j/docs/critique.html
http://jakarta.apache.org/log4j/docs/critique2.html

I would much rather support Log4J. There is no need to use the JDK 1.4
logging when we have the great Log4J project right under our noses. Eat your
own dog food.

-jon


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Java logging package

Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
Has anybody looked into using or adapting Java's (1.4) standard
logging package into Turbine? Is this something desirable?

http://java.sun.com/j2se/1.4/docs/guide/util/logging/overview.html


-- 
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: [PATCH] Removing redirect logic in Turbine.java

Posted by Jon Stevens <jo...@latchkey.com>.
on 10/24/01 9:09 AM, "Jason van Zyl" <jv...@zenplex.com> wrote:

> On 10/24/01 4:36 AM, "Gareth Coltman" <ga...@majorband.co.uk>
> 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.

I applied (and tested my patch against Scarab) against turbine-3.

I don't really do turbine-2 development anymore...

Seems good so far.

-jon


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: [PATCH] Removing redirect logic in Turbine.java

Posted by Jason van Zyl <jv...@zenplex.com>.
On 10/24/01 4:36 AM, "Gareth Coltman" <ga...@majorband.co.uk>
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:peterlynch@mindspring.com]
>> Sent: Sunday, October 21, 2001 03:13
>> To: turbine-dev@jakarta.apache.org
>> 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/turbine-dev@jakarta.apache.org/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/turbine-dev@jakarta.apache.org/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: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

-- 

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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: [PATCH] Removing redirect logic in Turbine.java

Posted by Jon Stevens <jo...@latchkey.com>.
on 10/24/01 1:36 AM, "Gareth Coltman" <ga...@majorband.co.uk>
wrote:

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

Because it takes time to test things and I haven't had the time to test it
yet.

We can't just go making big changes to code that has been in turbine for
about 4 years without doing some testing on it first.

OK?

-jon


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

RE: [PATCH] Removing redirect logic in Turbine.java

Posted by Gareth Coltman <ga...@majorband.co.uk>.
Why hasn't this patch been applying to CVS?

> -----Original Message-----
> From: Peter Lynch [mailto:peterlynch@mindspring.com]
> Sent: Sunday, October 21, 2001 03:13
> To: turbine-dev@jakarta.apache.org
> 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/turbine-dev@jakarta.apache.org/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/turbine-dev@jakarta.apache.org/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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org