Jeffrey - interesting point! What did you have in mind to encrypt the cookie data? Perhaps you could use Storable to serialize data structure then convert, crypt to scramble and then MIME64 to text encode?
I agree with you on processing delays - that is probably the biggest drawback to needing to send cookies as part of response header. Using Template Toolkit a lot myself, I have to make a workaround to handle the cookie situation as well. I've got a tied interface to Apache::Cookie's mostly completed - it would be easy to add the encryption that you describe above to them. See: http://www.infonium.com/perl/ for a link to Apache::Tie::Cookie. Featuring tied interface and lazy (demand) loading of cookie data. Jay ----- Original Message ----- From: "Jeffrey W. Baker" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, February 13, 2002 3:00 PM Subject: Cookie as session store > I have sometimes proposed or recommended schemes of storing session > information in an HTTP cookie, encoded and protected by cryptographic > digest. I know some people on this list have implemented similar > schemes, but I have never actually had occasion to do so. Now I am > doing that, and I realize the chief drawback to this scheme: all session > information has to be set before generating any HTML output. The chief > advantage is no requirement for server-side storage of session. > > For certain applications, saving all output until the session is > serialized may significantly increase the latency of the first data > packet in the HTTP response. > > -jwb > > > >
