Graham Dumpleton
grahamd at dscpl.com.au
Tue Jun 28 18:34:17 EDT 2005
On 29/06/2005, at 8:06 AM, dharana wrote: > Graham Dumpleton wrote: >> At a quick glance I can't see how this may or may not be used by the >> Session >> implementation, but isn't it possible to tie cookies to a particular >> path >> within in a domain? If the session was somehow associated with a >> path, eg. >> the handler root, could different session IDs for different parts of >> the >> documentation tree simply be kept separate by appropriate use of >> Handler >> directive in the root of each separate application context. How does >> the >> existing ApplicationPath option come into this? Never exactly >> understood >> what it did and thought that it was something related to having >> different >> session contexts? Seems to me that this might be better than fudging >> what >> name the session cookie uses. > > It seems Nicolas was faster. Faster in what respect? What is better, a quick answer or a correct answer? :-) Although I did notice that Nicolas' reply to my ApplicationPath mail got to me before my original even came back from the mailing list. Spooky. > Anyways, I don't believe it will hurt to have the cookie name > configurable btw. One also shouldn't let rampant featureism creep in either. If there is already one good way of doing things, one shouldn't be adding in new stuff just for the sake of it. In practice I don't feel that the ability to change the cookie name would get used. The only good reason I can see for the ability to change the name is to eliminate "py" out of the cookie name to hide the fact that Python is used in an implementation of a site. I don't believe one gains anything more than that from the feature given that ApplicationPath already provides a better solution. Graham
|