In message <001601c13f7b$614c6b50$6700010a@rightmove1>, Gareth Coltman
<[EMAIL PROTECTED]> writes
>> a) that session tracking is functional on the particular
>> combination of
>> browser/container/etc without entering an infinite redirect loop,
>
>The only reason it would enter an infinite loop though is because
>Turbine sends it into one!? i.e. If session tracking is not
>working then turbine sends it into a loop, but catches this and throws
>an infinite redirect error.
Correct.
>Do I really need this if I am
>working with a standard app server like Tomcat?
Its common practice when working with the servlet API to do a redirect
to establish that session-tracking is functioning correctly. Do you
really need it? That depends on how upset you would be if some
browser/proxy/container combination broke session tracking and sent the
user session into an infinite redirect loop.
>> b) that no redirect specifies the same URL as the request
>
>Actually turbine doesn't catch this if it is done by the application,
>only if it happens on the initial (new session) request.
Sorry yes, I was only referring to the framework-generated redirects in
the initial session setup phase.
>Has anybody else removed this code and then had problems?
Actually I had problems then added the code to fix them.
>What browsers give problems?
Mozilla certainly did cause problems back when this code was added.
>I would love someone to convince me that it
>is necessary, but I just can't see how.
It is not strictly "necessary". It is useful functionality (what a
framework is there for) as it protects your application against a broken
element in the browser->container chain. Note that some of the software
in that chain is out of your control (assuming an Internet based
deployment).
--
Sean Legassick
[EMAIL PROTECTED]
Jeg er mann: Ingenting menneskelig er fremmed for meg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
