cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Judson Lester <>
Subject Re: first impressions on continuations idea
Date Tue, 05 Feb 2002 22:33:44 GMT
<snippage level="much"/>

On Monday 04 February 2002 06:41 pm, Ovidiu Predescu wrote:
> On Fri, 1 Feb 2002 19:10:33 -0600, Judson Lester <> wrote:
> > Can you see this point of view?  I could also see how this might be
> > super-trivial and something you'd ignored.  But rewriting URLs to
> > mark session has significant issues which continuations inherit.
> I think I understand your point now.
> One thing to keep in mind though, is that the continuation identifier
> is not going to be a simple number, but a sufficiently complex, random
> identifier, very similar with the session identifier.
Well sure.  I was using a simple sequence for clarity.  

> What you're saying is that for security reasons we should combine the
> continuation id with a cookie stored on the system. While I think this
> makes a lot of sense in many Web applications that do need security,
> others don't need this extra layer. In addition to this, some
> browsers, notably WAP devices, don't support cookies, or the user may
> decide to disable them.
What I mean, I guess, is that if each session had a map of contuations, from 
special posts or URL rewriting, then we get as much of the contuation 
security as is possible, for free from Servlet sessions, and there's that 
much smaller a contuation space to work from.  

There is the problem (?) that the continuation would have a maximum lifetime 
of a session expiry (I think this is okay).

> I think from Cocoon's point of view, the mechanism used to identify
> the continuation should be completely customizable. Whether the
> developer wants to encode the continuation id in the URL, or as an
> argument of a GET/POST request, or use both continuation id and cookie
> id, they should all be available options.

I'd say that the way Servlets identify sessions is a good place to look for 
this.  I think we really have the URL, and GET/POST as options, that GET/POST 
is preferable (since it's mostly invisible, and difficult to mess with, but 
maybe not always available - for instance if there is an overlap between 
existing POST names, or whatnot.)  I think it should start with URLs 
rewritten within a session, and then expand to POST(or GET)s.  

Now, it may be that your conception of continuations, they already live in 
the session, and so I'm telling you what you already know.  Or I'm missing a 
crucial detail, or something.  (Because I feel like we've gone over this 


To unsubscribe, e-mail:
For additional commands, email:

View raw message