<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 <[EMAIL PROTECTED]> 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 once...) Judson --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
