[Twisted-web] Session class
Maarten ter Huurne
maarten at treewalker.org
Fri Oct 3 07:01:06 EDT 2008
On Wednesday 01 October 2008, glyph at divmod.com wrote:
> On 11:31 am, maarten at treewalker.org wrote:
> >None of this is a critical problem, but it does feel a bit strange. Is
> >current design motivated by something I haven't understood yet, or is
> >something that works well enough in typical use even though it has some
> >unexpected special cases?
> Most likely the latter. twisted.web.server.Session was designed years
> and years ago, before anyone involved in Twisted really had any idea how
> the web worked. It turns out that it works okay for a lot of cases, but
> it could definitely be a lot better.
> It sounds like you've got lots of very specific ideas for making it
> better. I very much doubt that you're misunderstanding it; please
> search around the tracker at <http://twistedmatrix.com/trac/> and find
> existing tickets that describe some of these issues (there are bound to
> be a few) and feel free to file some new ones. Patches (with tests, of
> course) would be very much appreciated.
I looked for tickets describing these issues, and while I found a few that
describe related issues, I did not find any that describe the same issues.
Therefore, I entered two new tickets about session expiry:
Session expiry check frequency should be based on sessionTimeout
Expired session can be revived
While writing the first ticket, I realized that I was mixing up session
expiry and session cleanup. Expiry is when the session timeout occurs,
while cleanup is when the session object is removed. The implementation
also mixes up these concepts though: the callbacks registered with
notifyOnExpire() are called on cleanup, not on expiry.
It might be possible to fix 3457 in such a way that 3458 would be fixed as
well without extra effort: if expired sessions are immediately cleaned up,
it is not possible for an expired session to be revived, since it is simply
no longer around.
I also wrote a ticket about the UIDs generation:
Session UID might be predictable
The most important question in this ticket is whether the session UID is
indeed supposed to be unpredictable, or whether it is good enough if the
UID is unique. Can someone please answer that?
And finally a ticket about session cookies and HTTPS:
Use secure session cookie when connection is secure
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://twistedmatrix.com/pipermail/twisted-web/attachments/20081003/72b021c2/attachment.pgp
More information about the Twisted-web