On 2/7/06, Jeff Marshall <[EMAIL PROTECTED]> wrote: > The reply I received seems to indicate that the sessionfilter's cookies > are not designed to last beyond the browser being closed & re-opened. > This makes no sense to me. My expectation has been that the session is > a cookie - therefore it should be completely sane to store a simple > value like "userid" or "last_visit_time" in the session and set the > cookie's expiration out 30 days with the full expectation that the > cookie would still be there for the next 30 days.
CherryPy's behavior seems perfectly normal to me here. A "session" from an application server's point of view is a collection of persistent data objects. You don't want those objects to persist especially long because they're just wasting server memory if the user isn't around. However, it's common to write an app that can "remember" a user. That's a separate cookie whose expiry time the developer sets at will. When your application receives this "identity"-style cookie, it can use that to generate a new session for them. If you want certain kinds of "session" data to persist for long periods, for example a shopping cart, you save that data periodically or on session timeout, and automatically add it to the new session when the user re-enters the site. If it's done right, there's no difference from the user's perspective, but there are enormous implications in resource savings by not over-extending the session. --Liza
