> > I can see two problems here. The first is that if the target of the > > internal redirect is a part of the URL namespace which is under the > > control of a different handler, or where ApplicationPath option was set > > explicitly to be different, the PYSID would potentially override a valid > > pysid for the alternate SID context provided by the browser. > > I get your point but is this actually a problem? Since it's an internal > redirect, the browser will not be aware it is being redirected, so it > will always send the same PYSID cookie. (Did that sentence make sense?) > > Even if the second handler sets a session cookie with a path for URL2, > the browser will always send the cookie corresponding to URL1.
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. 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. 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. Is my memory that internal redirect does return actually right? Have no time now to research it. 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. Graham
