| Jim Gallacher 2005-07-27, 8:45 pm |
| Graham Dumpleton wrote:
>
>
> Probably true. There may be convoluted cases where if someone was doing
> extra wierd stuff with overriding ApplicationPath and playing with the
> option being discussed for SessionCookieName, strange things might
> occur, but if people get that convoluted they get what they deserve.
Agreed. BTW, Nicolas has already implemented a PythonOption to specify
the cookie name.
> One other aspect of this that I have been thinking about is the feature
> in there for auto saving and unlocking a session before doing an
> internal redirect. In doing this you have changed how things work now
> and it does open up slim chance that existing code could break.
>
> Imagine where someone had stored stuff in the session object but then
> used internal redirect to force a special error response by triggering a
> handler outside of the session context. They didn't save the session
> because they wanted to discard their progressive changes. Now that it
> does an autosave, it may save stuff up code given that people didn't
> want it saved.
Point taken.
> Also, you don't recreate the session object after internal redirect has
> returned. Since internal redirect returns control back to the caller
> still, there is a chance that someone might be expecting to still be
> able to use the session object in some way after the internal redirect
> has returned.
Except for the session unlock/save, internal_redirect does not touch the
session object. The session is still available to the caller, so there
is no need to recreate it. Or am I missing something?
> Is my memory that internal redirect does return actually right?
Yes.
> I thus question whether autosave on redirect is a good idea or not.
> People can explicitly do it now themselves. If the code is in there,
> it should perhaps at least be off by default and require an explicit
> option to turn it on. If it has to be turned on though, people may as
> well code it themselves.
I've gone back and forth on the autosave. At this point I agree it's
best to leave the saving to the user's code, so I'll take it out. At one
point I raised the possibility of having an autosave for sessions
themselves and people were pretty much against that idea. By extension
internal_redirect shouldn't save the session so we are at least consistent.
I think the automatic session unlock needs to stay. It's just too easy
for the user to forget a manual unlock, deadlock the session and hose
their server in very short order.
Regards,
Jim
|