Tom Jackson said: > If something like Ns_SetIGet exists, maybe use that, Good idea, it does and I will.
> I know you were not trying to follow the cookie RFC's on this module, but > maybe point that out so folks don't think that any cookie value will work I'd say it is a matter of pointing it out. I'd hate to do my own escaping as they may well end up setting cookies using other mechanisms and then have them unreadable, or v.v. > it possible to update a set-cookie header? I chose to delete all cookies I don't see why not and I probably should. I'd expect the last one set would be the one the client will use anyway, but better safe than sorry. > What are the limitations of session data? For one they expire if the > server restarts. I understand that this is by design in this case, > but of course sessions which rely on persistent data will fail. That is something I have though about as well. My problem with it is that sessions should be fast and avoiding slow storage. On the other hand, I do see the value in having sessions last beyond restarts, even if I'd never write my app that way. :) I'll look into it. I'll probably do something like mark the session dirty if a change has been made and register a trace to write it to 'modules/nssession/$session_id'. If a request comes in for a key that I don't have in memory, I'll look it up in the file system first. Enabling this would be a config option obviously. I'd say I am probably best off just opening and closing files, that way I never run out of handles and I don't have to serialize this. (just create a $conn_id.tmp file and rename it to $session_id when done) Shouldn't take that long to implement. Thanks for the feedback! Cheers, Bas. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
