Re: LYNX-DEV Re: Gimmie a Cookie

[Hiram Lester, Jr.]

Have you guys actually read the draft that Fote posted the URL to when he
implemented the recognition of the Set-Cookie: header?  If not, the url is
listed in the changes file.  Read it... the whole thing... :)  I can tell
Wayne has looked at it. :)  It addresses these issues...

On Tue, 3 Dec 1996, Andrew Kuchling wrote:

>       I don't think you need to parse through the file on every
> access?  Cookies are only handed out to a server if the hostname meets
> the right conditions, so this reparsing need only be done when the
> hostname changes; as long as the hostname is the same, Lynx can keep a
> working set of cookies for that server.
> 
>       Another complexity is that the cookie file has to be locked;
> consider a user running two copies of Lynx, and Lynx 1 is writing
> the file when Lynx 2 tries to read it.  Is there a way to do this
> that's portable to VMS, Unix, and eventually Windows?
> 
>       One could just read the whole cookie file into memory when
> Lynx starts up and write it out on exit, but that 300x4k figure rules
> that out, except for single-user systems.  Perhaps the size of the
> cookie jar should be configurable; 5x4k is a more reasonable figure.

Ok, you bring up good point about locking files which is why the drafte
suggests not storing the cookies in a file which kind of defeats the
purpose...

A locking scheme wouldn't necessarily have to be portable across Unix,
VMS, and Windows/DOS, but it WOULD need to be portable across unices which
could be a problem.  The simplest form of file locking and the most
portable are lock files where the program creates a file with a specific
name in a specific directory when it wants to lock the file and if that
file exists another copy will wait a certain length of time for it to go
away and if it's still there it would assume that it has expired and
wasn;t cleaned up (due to a crash, etc.).  The major problem is that in a
multitasking environment the lock and check must be atomic so that another
process doesn't steal the lock out from under the first when it gets
swapped out.  There are also various forms of kernel locking in various
unices (lockf, flock, ioctl) which are better when available... I'm not
sure what method VMS provides for it, but I would expect it to be more
consistent than those provided on Unix.  Windows and DOS have SHARE.386
and SHARE.EXE which handle both networking and multi-tasking sharing of
files.  The lock file could be used on all systems in the worst case.

As to sizes and numbers of cookies, the specs call for a MINIMUM of 300
cookies at a MAXIMUM of 4k/each, but they imply that you should provide 4k
for each cookie to be safe.  This would mean 1.2M of memory allocated for
cookies unless it's done dynamically (which would HAVE to be the case).

On Tue, 3 Dec 1996, Scott McGee (Personal) wrote:

> If anyone DOES hack in cookie support, let me make a request. First, don't
> forget to provide something like NS does to inform you of a cookie attempt.
> Then, if someone wants to set a cookie, provide a further option to let them
> set the cookie and then immediatly delete it. Why? I hate it when a site wants
> to set cookies with LOTS of unknown data in them, and will refuse me access if
> I decline.
> 
> Maybe we could even have options to only keep cookies for the current session.

On Tue, 3 Dec 1996, Benjamin C. W. Sittler wrote:

> ... or perhaps a cookie editor, where you can mark a bunch of cookies
> (like DIRED mode) and then remove all of them. The same editor could be
> used to inspect their contents, zones, and lifetimes.
> 
> Just an idea.

Ok, read the draft.  It covers these issues of security very well.  One of
the two main authors of the draft in Lou Montoulli who was one of the
primary people in early Lynx development before he went to Netscape. 
Netscape's alerting you to cookies in 3.0+ is their attempt at BEGINNING
to apply the standards mentioned in the draft.  If cookie support is put
into Lynx, it should not be a "hack", but should be implemented properly
according the the draft which would entail all of the stuff mentioned
above in addition to complete disabling of cookies if the user so desires. 
(It might even default to disabled unless you explicitly enabled it.)  The
draft specifies that the user should have complete control over which
cookies are sent and received including editing/deleting cookies, etc.  If
you're really interested in this, read Netscape's unofficial standard
(look in a Netscape cookies.txt file for the URL) and the draft mentioned
above (look in the Lynx CHANGES file for the URL or follow the link in the
HTML'ized CHANGES file on my site). :)

   +------------------------------------+-------------------------------+
   | Hiram W. Lester, Jr.               | E-Mail: address@hidden    |
   | Computer Science                   | Home page:                    |
   | Middle Tennessee State University  |   http://pobox.com/~hwlester/ |
   +------------------------------------+-------------------------------+


;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;