cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Prante <jo...@7val.com>
Subject Re: AW: [C2]: ToDo - List for going Beta
Date Thu, 12 Apr 2001 18:19:36 GMT
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. 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?

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'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.

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


Mime
View raw message