cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: AW: [C2]: ToDo - List for going Beta
Date Thu, 12 Apr 2001 20:04:45 GMT


On Thu, 12 Apr 2001, [iso-8859-1] Jörg Prante wrote:

> Am Donnerstag, 12. April 2001 14:07 schrieb Carsten Ziegeler:
> > > > 2. Cleaning up the environment
> > > >    We had the recent discussion about the sendRedirect() method of the
> > > >    Response object (same applies to the getRealPath() of the Context).
> > > >    The discussion about sendRedirect() showed, that most of us agreed
> > > >    to remove it from the Request object. But the main problem then
> > > >    would be porting existing applications from C1 to C2. If we leave
> > > >    sendRedirect() only for porting reasion, everybody will use it, and
> > > >    we have no chance to remove it at a later time.
> > > >    My suggestion is to remove the sendRedirect() from the Request. For
> > > >    porting reasion the HttpRequest still contains the sendRedirect(),
> > > >    thus casting the Request to the HttpRequest will allow the call
> > > >    the method. This will only work in the http environment, but for me
> > > >    this sounds reasonable for a fast migration.
> > > >    There are others methods in the environment which should be removed
> > > >    for same reasons as the sendRedirect().
> > > >    If we agree on this, I will volunteer for it.
> > >
> > > We have to take the following into acount for redirect:
> > >
> > > 1. If the pipeline has started to output characters onto the
> > >    OutputStream IIRC the servlet engine will throw an Exception
> > >    when issuing a redirect afterwards. There will be situation where you
> > >    *never* will be able to redirect because of this restriction (think
> > >    of a pipeline containing a XSP generator and an XMLSerializer which
> > >    almost immediately produce output on the OutputStream).
> > >
> > > 2. If we allow redirects we then need a way to report that (probabbly by
> > >    an Exception) to the pipeline from a sitemap component that a
> > >    redirection has occurred to interrupt the resource production because
> > >    it will throw an Exception otherwise.
> >
> > Yes, I think, this is another reason for officially removing
> > sendRedirect(). If really the only problem with sendRedirect() is migrating
> > projects, we could (and will) offer help on the migration.
>
> Hi everyone!
>
> The sendRedirect() is also used in URI-based session generation. Why is this
> important? The situation is when cookies are disabled at the client side and
> the servlet engine generates a new session ID for tracking a session in a
> cookie-less mode.

This is the concern of the servlet engine and is transparent to any
servlet IIRC.

> The URI will not change to include the ID, but a
> sendRedirect() to the same page will make the ID visible in a single request.
> If Cocoon 2 gets detached from the servlet API logic, we need to think about
> a suitable connection to outer session tracking environments to enable this.
>
> I am still thinking about a sitemap-controlled session framework for Cocoon
> 2, together with a Cocoon 2 site reporting application. After the change
> proposed here, it looks like Cocoon 2 will need a private URI encoder for
> URI-based session tracking. But session ID generators are usually located
> outside of Cocoon. How can we incorporate externally created session IDs into
> Cocoon 2?

We never said that you don't have access to vital functionallity of the
environments objects only that those get wrapped with own Interfaces.

>
> In session.xsl, which comes from Cocoon 1, some time ago I added some
> features using HttpResponse.encodeURL(). Also,
> HttpResponse.encodeRedirectURL() is important for session tracking. This must
> also be considered for the rework.

I don't see why the encodeURL() should be hidden. It doesn't alter
anything of the model (in contrary to the sendRedirect).

> I'm hoping that you agree that such a session tracking feature should be
> nice in Cocoon 2? Or should it be delayed for Cocoon 3 ;-) ? Should Cocoon
> 2 be able to connect seamlessly to a HTTP session engine if such a session
> engine is present? Then we might consider something like a
> "SessionTrackingConnector" to Tomcat 4.

Well, would you like to make a proposal?

Giacomo

>
> Jörg
>
> --
> Jörg Prante
> Sevenval AG (HRB 32757) e-business marketing technologies
> D-50667 Köln . Alter Markt 36-42
> Fon +49 221 65007-0 . Fax 4249891
> http://www.sevenval.de . joerg@7val.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message