>> I'm trying to understand the rationale, though -- the description in >> request-handler.lisp seems to indicate this was done in order to support >> clients without cookie support. >> >> Is supporting browsers without cookies something we care about? > > Yes, but I don't understand why we would need the redirect in that > place for this.
Do we really want to support cookie-less sessions? Why? Django does not support sessions without cookies: The Django sessions framework is entirely, and solely, cookie-based. It does not fall back to putting session IDs in URLs as a last resort, as PHP does. This is an intentional design decision. Not only does that behavior make URLs ugly, it makes your site vulnerable to session-ID theft via the "Referer" header. (this is from http://docs.djangoproject.com/en/dev/topics/http/sessions/) I killed the initial redirect in my application, which did not solve the problem entirely. I don't fully understand why, but only (setf hunchentoot:*rewrite-for-session-urls* nil) got rid of sessions in URL parameters entirely. Otherwise they would pop up in strange places all of a sudden. More fundamentally, though, I believe weblocks session handling needs to be reworked, at least for my needs. I don't want to establish sessions for every request, that's wasteful. Any externally-accessible URL can be served without a session (possibly from a pre-rendered cache). It is only when the user accesses actions that we really need a session. This might have the added advantage of significantly speeding up weblocks: you would not have to build the whole widget tree on every request. My lazy-navigation does something similar to a certain extent, but we could take it much farther. --J. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
