Hello Sebastian,
before putting effort into reviewing Hunchentoot's session handling functionality, I would like to discuss your request:
Am I right in understanding that you are calling REMOVE-SESSION and START-SESSION in one request, and that you're not seeing correct results? Or rather, are you calling REMOVE-SESSION and then REDIRECT and don't see the results? Is there a reason why you (seem to) need a fresh session rather than just changing the session variable that your application uses?
It would be helpful if you could formulate your problem in terms of a bug report and include steps to reproduce the behavior.
Thanks, Hans
On Sat, Jan 29, 2011 at 1:03 PM, Sebastian Tennant sebyte@smolny.plus.com wrote:
Hi all,
I tried my hand at using sessions for the first time last year, and wrote the following notes in the process.
---8<------8<------8<------8<------8<------8<------8<------8<------8<---
;;; Hunchentoot sessions are one-to-one associations between in-memory CLOS ;;; objects and the (unique) value of any incoming session cookie (a cookie ;;; with a particular name). In short, whenever there's an incoming session ;;; cookie, if there's a corresponding in-memory CLOS object then a session is ;;; taking place and *SESSION* is automatically bound to the CLOS object.
;;; Ending a session is therefore simply a case of deleting the in-memory CLOS ;;; object, and starting a session is a case of arranging for a new session ;;; cookie to be dispatched and creating a corresponding CLOS object.
;;; Nothing is sent over HTTP until the execution of a handler is complete, ;;; including cookies. Imagine for a moment that you want to end the current ;;; session and start a new one. Somewhere near the beginning of your handler ;;; you delete the CLOS object that represents the current session, arrange ;;; for a new cookie to be dispatched and create a new matching CLOS object. ;;; You then begin filling the new CLOS object with data until there comes a ;;; point when you decide you want to perform a redirect, thus aborting the ;;; execution of your handler before it's complete.
;;; How should hunchentoot handle this situation? If you perform the redirect ;;; the new cookie will never be sent and the data in your CLOS object is ;;; effectively lost. Should hunchentoot somehow arrange for the same cookie ;;; to be sent with the next reply? Should it refuse to perform the redirect?
;;; Hunchentoot's answer is to avoid this situation altogether by not adding ;;; CLOS objects to the session database until their corresponding cookies ;;; have actually been sent. In practice this means that you can't delete the ;;; current session and create a new one within the lifetime of a single ;;; handler.
---8<------8<------8<------8<------8<------8<------8<------8<------8<---
Are they accurate? I'm not at all sure about the last three paragraphs.
Seb
Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel